In my typo3 website I have a root page and many sub pages which most of them share the same structure. Therefore I have created my template with automaketemplate on the root page so it can be shared through all of the sub pages. For the ones that I have a slightly different structure I can create an extension template. My problem is with the root page - its structure is different and I need to use another template file. But I can't create an extension template for it since it already has a main template. What is the workaround on this? Thanks in advance.
As far as I understand your site structure looks like this:
root (home)
|- Subpage 1
|- Subpage 2
|- etc.
I would suggest you change it to this one:
root (Shortcut to Home)
|- Home
|- Subpage 1
|- Subpage 2
|- etc.
That way all your templates can inherit from root but Home can have a completely different structure.
Related
How are the menus organized in the Content Repository (CR)? Namely, a main menu, a meta menu, and a footer menu. Is there any obvious disadvantage to using this CR:
Home
|- Main Menu (ID 1)
|- Blog
|- Products
|- Services
|- ..
|- Meta Menu (ID 2)
|- Contact Us
|- ..
|- Footer Menu (ID 3)
|- Privacy Terms
|- Imprint
|- ..
We normally assume that the "normal" pages showing up in the "main menu" are directly underneath the Site Node (in your example "Home").
For additional menus like meta or footer, we create a Document Node of type Folder. The package neos/nodetypes-folder provides such a Node Type. It also allows you to exclude the path segment generated by the folder (e.g. meta-menu) from the URL so you have nice URLs in the frontend but still a clean backend.
I have completed Reso Coder tutorial about Clean Architecture with TDD in Flutter Apps. But there are two points interesting for me:
If we have global widgets like Loading, Failure, Empty Case and so on, in which layer and how we can store them to access from any feature? is it okay to create folder like widgets in core folder to store these widgets?
If we have the same API calls, or same local data in different pages, in different features, how can we store them? is it okay to create independent features that have not views itself, just contains domain and data layer for other features?
This is my repository:
https://github.com/thisisyusub/tdd-learn-example
By checking your repo I'm guessing you are talking about your FailureWidget and LoadingWidget and by "global widgets" you meant widgets used in multiple features of your application. Now to answer your questions :
In my opinion you can definitely put widgets shared in multiple features in the core/ folder but I would recommend to keep some sort of coherence with your different layers. By that I mean that widgets should be putted inside a presentation subfolder because only your presentation layer should depend on those.
lib/
|- core/
| |- presentation/
| | |- loading_widget.dart
| | |- failure_widget.dart
Same goes for API calls you want to re-use in multiple features, you can put them inside a data/ subfolder of core/.
lib/
|- core/
| |- data/
| |- data_sources/
I'm setting up Doxygen in my codebase and want to use the Markdown support to produce a number of different 'how to' and 'design' types page in a logical hierarchy, e.g.
index.md
design/
architecture.md
database.md
how-to/
build.md
restore-backups.md
...etc...
Using the Markdown support, I can give labels to each page and then use those to link to other pages and create a page hierarchy, e.g.
Design {#design}
======
This section contains design documentation.
#subpage architecture
#subpage database
The problem I've got is that this means every level in the hierarchy needs to define which pages are its sub-pages. This litters the documentation with lots of links which I don't really need. When the hierarchy gets 3+ levels deep you end up with lots of dummy pages which only exist to define the subpages.
My question is, is it possible to define the entire navigation hierarchy in one external page so that I only have one place to define and update when new pages are added? Something like:
Navigation {#navigation}
=========
This page defines the navigation tree for the whole project.
#page design
#subpage architecture
#subpage database
#page how-to
#subpage build
... etc ...
I have the latest version of TYPO3, and the data I entered in the RTE is not rendered properly in the frond end (in site).
So for example <p>asdf</p> will show as it is in frond end.
I googled it and tried with some RTE default configuration changes, but that did not work well.
Please try with some basic testing first.
Create a new site on root level (directly below the globe). Create one content element with all text and styles you want to test.
Create a new Typoscript template for this site and put the following in the setup section:
page = PAGE
page.10 < styles.content.get
Make sure to include CSS Styled content inside the static template section.
Now watch your page page in frontend. Does it work?
Otherwise try step 0. and create a new (admin) backend user first.
Most likely you have either a strange transformation rule inside your RTE config in backend (UserTS or PageTS) or you have some kind of htmlspecialchar definition for your frontend rendering.
Please post something of the following basic Typo3 configuration settings and/or tell us if you use something of that:
You Upgraded from an older Typo3 version? Than it could be, that some configuration is missing.
Root Template or Site Template inside Typo3 Backend you can create or edit one, when you click in the most left menu on "Template"
If you choose "Create Template for new site" button the most basic Typo3 Typoscript * is automatically created
# Default PAGE object:
page = PAGE
page.10 = TEXT
page.10.value = HELLO WORLD!
Do you have such an TS (= Typoscript) tested? TEST IT and tell us if it works!!!
Does this work for you?
(Typo3's own configuration language - both a blessing and a curse - can be so easy and so painful - most laughful description i ever read, you can found on hatetypo3.blogspot.de "spaghetti code festival")
Don't miss include "CSS styled content" (it's in the form "edit whole template -> Includes)
But if you don't have include this, normally no site content is displayed in the frontend.
Another way is to include basic TS configuration in one or mor separate files. To get the files working, you have to referce them by this snippet in a Site Template in the BE
<INCLUDE_TYPOSCRIPT: source="FILE: yourfile">
# BTW I saw that it is common to place the file in a dir like
/fileadmin/ts/yourtyposcriptfile.ts
So give us this info or ask for more, if i miss something.
The Scenario
I have a website with several autogenerated menus:
Main menu ("root level" pages)
Tree menu (full tree down to current page)
Breadcrumb (only .ACT)
Now I see two possibilities regarding these menus and the RealURL extension.
Strategy A: Root as Front Page
I will create the page tree like so:
⊛ www.site.tld
↳ Page 1
↳ Page 2
↳ Page 3
Pros & Cons
Con: I will have to manually add a link to the "Front Page" (content from page "www.site.tld") to all permutations of the menus (as this is not on the same physical level as the other "root level" pages)
Pro: RealURL will per default render all links to the front page (the root page) as /
Strategy B: Front Page as Separate Page in Tree
I will create the page tree like so:
⊛ www.site.tld
↳ Front page
↳ Page 1
↳ Page 2
↳ Page 3
Pros & Cons
Pro: A link to the "Front Page" is automatically added to all permutations of the menus (as this is an explicit page on the correct level)
Con: RealURL will per default render all links to the front page as /front-page/ while I want it to link as /
Best Practice?
Is there a best practice in the front-page-as-root vs. front-page-as-separate-page question? I.e, should I go with A and manually extend the menus, or with B (if so, how to configure RealURL to render the correct links)?
Edit: The Answer
Phil provided me with a solution to the specific problem. Go with strategy B, but let the page "Front page" be a link (dokType = shortcut) to the root (the page "www.site.tld"). This will fix the menus and the links. ("Front page" being a shortcut, contents will reside on "www.site.tld".)
If anyone knows of alternatives to this one, please let me know. I do believe, however, that this will satisfy my needs concerning this issue.
I see 2 solutions (if I really understand youre question).
Put the Front page type to link, and link it to /
If you have access to the .htaccess, redirect /front-page/ to /
The solution B is easier, and it can be done without a special RealURL config