in sulu 1.6 it was possible to limit the available page types per webspace via a workaround by limiting the theme tenplate files
Now after the migration to 2.0 They are all showing up:
The workaround is still in place, by only providing the templates for certain themes:
Is there a different way to filter out Available Page Types in Sulu 2?
This mechanism changed in Sulu 2.0. It was very confusing to newcomers, that their new template didn't show up in this list, when they forgot to add the twig template in the correct way (also there was no clue about what was wrong).
So we decided to make this behavior more explicit, and now there is the excluded-templates tag, which allows you to do that in a very explicit way.
Related
I am new to TYPO3 and have trouble understanding the general relation between extensions and the backend of TYPO3.
For example, is it true that the goal of making an extension is to be able add edited/new content elements to your page that cannot be found in TYPO3 out of the box?
For example if I wanted to add a carousel to my page, would I make an extension and design it in such a way that I can add it from my backend to the desired page? Or would it make more sense to, for example, put it as a partial and import it to the desired page using fluid (all of this without using the backend and just using code).
Or are both approaches possible and when would you go for the first or the second (or seek out a third approach)?
Sorry if this question is too general/vague. I feel like I do not understand how the backend and the files in my TYPO3 folder communicate to generate the website and that I am using content elements in the backend one time and typing out the elements in HTML the next time without a good reason for it.
I try to bring some light into the dark areas.
Backend This is the admin area of the CMS where in most cases the content is created by editors.
Frontend: How the website looks to a regular visitor
Extension: An extension is custom code, either your own code or by others which extend TYPO3 in one or more ways. The benefit is that you don't change the code of TYPO3 core itself and therefore it can be always updated.
An extension can be used for a lot of things:
- Shipping a site template with all the assets like CSS, JavaScript, HTML template, ..
- Providing custom content elements
- Providing new record types like news or forms
- Improve user experience
So yes, if you want to have a new kind of content elements you need to use an extension:
Search on https://extensions.typo3.org to check if there is already something which fits your needs
Use https://extensions.typo3.org/extension/mask/ (best in combination with https://extensions.typo3.org/extension/mask_export/) or https://extensions.typo3.org/extension/dce/ to make it a lot faster to create content elements
If experienced you can also create a custom content elements without any additional extension but for start I don't recommend that.
One approach to look at this question in a different way might be to differentiate between content created and maintained by editors (the backend users which typically add and maintain content) and parts of the visible webpages created in other ways. For example, the header, footer, menu of a site may be created by a sitepackage extension - this is something the editor (backend user without admin access) typically has no permission to access and that is one of the points of a CMS - the content is editable by someone without technical background. Of course this improves the stability as well because you don't have people fiddling around with things they should not be able to have access to and thus cannot break.
If you want your editors to be able to add (remove, change) content - do it in a way they have access to (typically using content elements).
You are right, the core provides content elements (such as "textmedia"), extensions can extend this by adding other content elements.
For your example with "carousel" you might want to look at the (official) Introduction Package which uses the bootstrap_package which offers a carousel content element. The Installation Guide explains how to setup a TYPO3 installation with "Introduction Package" so you may already be using that.
For example, is it true that the goal of making an extension is to be able to add edited/new content elements to your page that cannot be found in TYPO3 out of the box?
That is one of many, many other possible purposes of an extension. For example, look at the extension "min". It does not provide any content element and there is no visible change for the editor. An extension is just a way to extend the TYPO3 core (while the core itself also consists of extensions).
Introduction of Extensions in TYPO3 Explained
Sitepackage Tutorial
I have a sulu 1.6 installation with multiple webspaces. I have multiple page template definitions in app/Resources/templates/pages, like default.xml, homepage.xml, blog.xml, center.xml.
Is it possible to make for example the center.xml only available for the content of one webspace and not all the others?
UPDATDE:
Where can I change this behaviour in the code, that per webspace only the ones are showing up, that are defined in the webspace.xml? This is really blocking and a super bad user experience, since the template is directly linked together with the configured webspace, but the others do not fit.
Thx a lot!
Andreas
The template is only shown in the dropdown if its .html.twig file exists. So if you use the SuluThemeBundle and only a specific theme implements its .html.twig file the template will not be shown on the other theme aslong as the .html.twig does not exists there.
This feature has not yet been implemented, because not too many people have asked for it...
Since Sulu 2.0 you can limit the template on the webspace using the exclude-templates inside your webspace configuration:
<excluded-templates>
<excluded-template>overview</excluded-template>
</excluded-templates>
Before the only way to limit page templates was to work with themes.
I'm using Typo3 for the first time and have been asked to update a site built on it.
Making changes to existing templates so far has been OK since they were mainly CSS changes or replacing images. Now though I need to create a couple of new page templates.
What's the easiest way to go about this? The existing site has a home.html and layout.hmlt in the fileadmin directory. Do I need to create a new html file there, if so how do I use this as a new template for some of my pages?
I'm coming from a mainly WordPress background in terms of CMS (I've nearly given in a recoded the site as a WordPress site since I think it would be quicker at this stage) but I'd really prefer to figure this out.
Any suggestions would be greatly appreciated as I'm pulling my hair out trying to read through the documentation and getting nowhere. The site is using Typo3 version 4.4.6
Thanks!
How you add a new template to your page depends on how templating is handled. Sadly TYPO3 has a poor templating out of the box, so there is most likely an extension that does the job on your site.
Probably one of these:
automaketemplate
templa_voila
flux & fluidpages
Check if one of these extension is installed and add a new page template according to the extensions manual or specify your question afterwards.
Edit:
If plain TYPO3 was used, you'll find something like
page = PAGE
page.10 = TEMPLATE
page.10 {
file = fileadmin/myTemplate.html
}
in your Typoscript. You can add tmplate files like the ones that are already there. To use a different template on a page, you have to replace the page.10.file with the template you want to use. This can be done with a new template record (crated in backend via the template module). But this is a rather anoying procedure to change the template, because you have to create each time you want to change the page template for a page and its children. That is why mostly extensions are used for this.
The out of the box situation gets better with newer TYPO3 versions but in 4.4.6 there are no Backend Layouts that could be uses for a template switch ot something like that.
In Addition to change the mere file you have to adjust the subparts or marker that are filled with the content. You'll find that configured in your TypoScript as well
I have an TYPO3 installation with two domains. Each domain has its own provider extension and static template file.
Example:
domain1.com -> providerextension1
domain2.com -> providerextension2
Is it possible to hide the fluidcontent FCEs from providerextension1 in domain2.com?
Example from Bootstrappackage (https://github.com/Ecodev/bootstrap_package)
As soon as an extension has included fluidcontent FCEs (like the fluidcontent_bootstrap) it will add these to all domains, also when the TypoScript Configuration is not included.
If I understand the question completely, the answer is no: you cannot in TYPO3 make your TypoScript that is available in the backend, depend on the domain name being used. There is a way to make TypoScript conditions for the frontend output (for example a condition to only add template paths for your provider A when domain is X), but the same is not possible in the backend.
You are of course welcome to add a feature request on our issue tracker - I don't see any immediate problem with a feature to toggle on and off particular provider extensions based on for example a TypoScript setting. But you should keep in mind the limitation mentioned above since it implies that in order to achieve your desired goal you must place each domain record on a page tree of its own and closely manage the TypoScript that controls the available Provider Extensions on each page tree.
Put shortly: even if you get this feature request filled, it may not be the solution you want and you may have to restructure your pages and domains to get where you need to be.
The problem is, that the FCE are defined in the "ext_tables.php" and "ext_localconf.php" and these files are always loaded when the extension is enabled.
You can alter "ext_tables/ext_localconf" with a simple condition like
if($_SERVER['server_name'] == "www.yourdomain.com") {
//init FCEs here
}
You can try to override the template paths for one domain with an empty value or at least a path to an empty directory. Maybe flux is smart enough to ignore empty template paths.
What is to be understood by "Fluid powered TYPO3" (as stated by http://fedext.net/) and what are its benefits for the integration?
Are there other modern templating approaches for TYPO3 6.x that would be best practice to switch to now?
I don't understand the different systems that are around at the moment and I need some clarification.
The background of the question, what I am looking for:
Don't use Templavoila
Keep it simple, little coding overhead
That's why I still use markers!
Enable Custom content items in the backend like FCEs in TV
Foment "structured content" approach in TYPO3: predefined inputs and detailed rendering vs. "Anything goes" like in css_styled_content
And what about https://github.com/Ecodev/bootstrap_package ? Is it recommendable?
Although this question is fairly old by now (I didn't see it until now) and you probably already found out more about what Fluid Powered TYPO3 offers:
The features you ask for (TV-style FCEs, low coding overhead and especially the last one which is more regarding the process than the tool) are exactly what Fluid Powered TYPO3 is all about:
We provide simple ways to get page and content templates recognised by TYPO3 and made available to use by the site's content editors.
We use a common API approach (which is built on top of TYPO3's TCA/TCEforms) which you can use in both page and content templates to add custom fields (as an example: create a field to set the color of the site's header or configure a content element to have a blue background, and so on).
We use Fluid which is (as Michael already stated) a superb rendering engine.
But this is just a small part of the possibilities you have with the extensions (currently there are 20 - no, really, 20) which all provide different feature sets: there's the ViewHelper library VHS which you can use with any type of Fluid template, there's fluidpages, fluidcontent and fluidbackend which lets you place template files in a recognised path and made available to use without further hassle, there's view which lets you use overlay paths for plugin templateRootPaths (example: override only one template file from EXT:news without having to copy all template files from EXT:news). There's builder which can generate extensions, ViewHelper unit test classes, test your Fluid templates and more. There's tool which contains a range of Extbase Service-type classes that you can use in your own Extbase plugins. There's fluidwidget which is a great base for complex Fluid Widgets. You've got side utilities like *extbase_realurl* which can generate automatic realurl rules for any Extbase plugin. And there's schemaker which can let you create your own XSD schemas for your own ViewHelpers (or any version of for example fluid itself, or VHS, or flux etc.).
And there is more than this. Simply put, we offer you every tool you need to create every type of site, template or plugin. Our tools have one primary focus: efficiency.
It sounds like a huge mouthful but it isn't as complicated as it seems. Usually you will start off by using three or four of the extensions and their purpose is quite clear: Flux allows you to add the form fields which content editors use to configure content, pages and plugin instances; VHS provides a large number of multipurpose VieWHelpers to use whenever you need more than just those included with Fluid. And then one or both of fluidcontent and fluidpages which are -very- simple in that all they do is allow you to use template files as content elements or page templates.
There is quite a bit to get used to - this is true of any framework - but we spent a lot of effort on making the API the same across the line, which means anything you learn in one context (for example page templates) you can use in others (like content templates and backend modules).
If you want to save time and be consistent when creating content, pages and plugins, Fluid Powered TYPO3 (which is the umbrella name for all those twenty-something extensions) will do exactly that for you.
I can recommend taking a few minutes to read the new tour I published on fedext.net - the URL is http://fedext.net/tour/form-api.html - it primarily speaks to developers who've touched on Extbase and Fluid earlier, but even if you're used to "just" working with TYPO3 the main points should make sense.
And if you need more details than this you are welcome to find us on Github or on IRC (#typo3 on Freenet). We're always happy to help new users.
Cheers,
Claus aka. NamelessCoder
Fluid offers a much cleaner approach of dividing template logic from display logic and controller logic. Your result will be structured much better when using the possibilities fluid and the mentioned extensions like vhs provide (like layouts and partials).
The usage is actually very simple but can still be combined with the oldschool marker approach (you can do things like <f:cObject typoscriptObjectPath="lib.marks.MAIN-MENU"/>). If you need more flexibility in the backend like in TV, you (of course) have to code some things yourself.
The easiest way is to use an extension which is created by modelling it in the backend to fit your custom needs, but you can also adjust the rendering of pages and/or default content elements by using typoscript and the fields given (like pages.layout, header_layout, section_frame and so on).
So you always have the choice between detailed inputs (extbase extension objects) and using the TYPO3 default things like page properties and RTE config in combination with some typoscript magic (css_styled_content).
So as a conclusion I strongly recommend using fluid templates and additional extensions like vhs as they provide a lot of (additional) power and reusable templates while still let you use markers if you want to. Personally, I also prefer to enhance or limit the RTE in the backend in favor of writing too much special code for an FCE-like result.
BTW: There are very good autocomplete features by using the DTDs/XSDs from fedext.net in your IDE which made my template programming much faster (like 25%).