V1 - cause already using it since years.
Variant 2
The reason is a part that can be found under “Not to be discussed”:
Reusing same partials in multiple extensions, pages & content elements
For me, partials make sense especially if they are not assigned to a specific extension, but are used as general building blocks for content of any kind.
Actually this works like single components of a frontend framework, which basically use the same HTML, no matter by which extension they are used for what purpose.
Ideally, you would then only have a distinction between extensions under layouts and templates, because additional classes may be assigned there for the DIV containers of individual elements.
The inner building blocks - aka Partials - would then be identical and would only come from the Partials folder.
V1, I’m doing it this way for years now.
I am undecided but if I had to choose definitely v1.
I actually do it like that…
I mimick the complete extension structure. (requires .htaccess changes)
Thanks for your feedback!
The reason is a part that can be found under “Not to be discussed”:
Some reasons why I don’t want to discuss that currently: Most sites are using 1 domain and 1 tree. Having a default configuration which considers “everything” makes it very hard for all others and the chances are high that it still doesn’t fit everybody.
Most agencies/devs have their own site package and reuse that and this is of course ok but those people already know the system by heart but those are not really the main target group for me for now
Reusing same partials in multiple extensions, pages & content elements
For me, partials make sense especially if they are not assigned to a specific extension, but are used as general building blocks for content of any kind.
I use that as well but using https://extensions.typo3.org/extension/fluid_components/
Having reusable partials requires deeper integration knowledge and means that your have another directory which contains those abstract partials which can be used. So maybe something like
plugin.tx_news.view.partialRootPaths {
0 = default partials from EXT:news
1 = site_package/news-partials
2 = site_package/abstract-partials
}
having such code means for me:
- Another new layer for beginners
- Another magic
- Still doesn’t cover stuff like multi site fallbacks, so still no full support of all which could happen
- integrators need to fully rewrite templates of extensions to make it really use the abstract partials. many agencies might do that but a lot of integrators use the default templates and just change some lines or often just apply some custom css and use the 100% of the original templates without changes at all.
My point is, that the structure should be the same for both, the usual integrators and the agencies. Otherwise you would get a job as a usual integrator within such an agency and you would have to unlearn things before going on with the “professional” way.
IMHO there should be no difference between “professional” and “beginner” from a structural point of view. So the best practice for beginners should be the one that can be easily extended to the professional level later on.
That’s why I would still recommend to go for Variant 2
I fully get that but again, even your setup doesn’t take stuff like multi site into account
Well - actually we do multi sites with this structure, because we use a “sitepackage” literally as a package for a single site. So a multisite-setup within a single TYPO3 instance would get one sitepackage per individual customer frontend output.
If they have got a lot in common, there might still be a “basepackage” in between, providing the shared content elements, structures and features. But within those packages the structure will never be mixed between sites, so a site always would be the “root” level of a folder structure.
I agree, Variant 1 seems the better option to me.
Variant 1 seems more practical and portable.
I used v2 in the past, it felt natural. But when I read both proposals I would choose v1. I would expect it to be a more cleaner outcome for systems with a lot extensions.
+1 for V1. It’s more clear.
I am preferring variant 1, since I’m using this since a couple of time and it is more efficient to work inside one extension.
Variant 1 - if I have to choose between these two suggestions.
In real-world projects we use another approach, the structure looks like what Jonas Eberle already showed in an answer before.
As you can see, extension related configuration is all scoped in here too. Not just templates.
Best practices are made to be broken. 
This topic was automatically closed after 14 days. New replies are no longer allowed.