So, if I understand correctly, typo3 treats every content item (article, news item, same “site area” information etc) as pages, right?
So, if I wanted to have a common page layout (let’s say with a contact details element at the right or a sub-navigation or something else common to all items of same navigation area), I would have to duplicate (or refer as copies of) all modules to every page or make a layout that would load specific modules from code). Right?
Is there a “portlet” way that just freezes a set of boxes around the variable content? Something like the news extension which re-uses a list and a “detail” page?
I think you have not got the concept of TYPO3 yet. So I try to make clear some wordings.
All content is stored in database records. and there are multiple kind of records. especially each extension can create their own kind of records.
There is a basic structure in TYPO3 for each instance. this structure is based on ‘pages’ records. there is a virtual page with ID 0 where all is started.after that each record (even ‘pages’ records) are stored in (/assigned to) a pages record. In this way you get a hierarchy of pages, a page tree.
There are some common fields (nearly) each record in TYPO3 contained: uid (unique Identifier), pid (parent id/ page id = id of page this record is stored in)
there are different kind of pages. the most importent one: normal pages for visible content and folder for record storage only.
specialized records (from an extension) are handled by plugins and can be styled and displayed in any kind.
the main content is stored in records in a table named ‘tt_content’. this records can have multiple types. there are some preconfigured types to store the usual data of websites.
a tt_content record can represent a plugin: some code which handles records stored somewhere else. typically there a list-views and detail-views. But that could also be forms, diagrams or anything you can imagine.
as each tt_content record has a page assigned (‘pid’) it’s data is assigned to one page. there are more fields to identify the position in the page: there is a field for ordering and there is a field for assigning data to different areas (columns). if the page layout consists of multiple columns like header, left, main, right footer. in each of these columns can be content.
as we have a hierarchy of pages it is easy to define a mechanism of inheritance, where content of one column can be inherited to sub pages, either additional or as insert if no content in the column of that page is available.
in this way your intended concept could be reached with multiple pages, where content of a common parent page is inherited.
Or you just use one single page with a plugin which can display different records. While the other columns always have the same content, the displayed record may vary and result in different main content.
Thank you Bernd, for the time you took to write this explanation. I appreciate it!
It makes sense, and from a developer’s point of view I can understand what’s happening. However, when you say “it’s easy to define a mechanism of inheritance” do you mean it’s easy to develop an extension for this purpose?
To answer my own question, I added <f:cObject typoscriptObjectPath="lib.toolbox"></f:cObject>
to the template file that I was overriding (2Columns.html) from bootstrap_package. The addition was applied where the right column renders its contents. Then, in setup.typoscript of my site_package, I wrote