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%).
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
For the construction of an extensive list of links, since the source page is a thematic portal, I am looking for a suitable EXT., Which also runs under TYPO3 7.6 LTS.
it if the list of links to a permits the use of categories and multiple categorization of links is possible would be nice. should Weiterrhin the links are described not only the destination address and an alias but here should still an outline of the target page (possibly with photo) be possible.
Additional functions such as proposing links by users, reporting broken links or even a User Voting would nice additional features.
There were times the Modern Linklist, but they were no longer being developed for TYPO3 <6.x.
Is there perhaps somewhere an alternative or as one might like to vorhnandenen solutions might realize? It would be nice of course, without any programming knowledge, since I'm not a programmer.
P.S .: It is not about building a spam list but high quality links with topics relating to the original page.
As this seems to be a straight forward usage you could try to build that extension by yourself with the ExtensionBuilder.
just build up the records neccessary for your data. and let the EB generate all usefull actions: list & show, even create, edit, delete in FE would be possible.
Afterwards you just need to edit the generated fluid templates.
these links may help:
Overview
EB manual
small remark: if you want the newest code state, use the EB from git instead of TER
I`m not aware of an existing extension for it but it could be a good project to learn extbase / fluid.
You should also take a look at
typo3/sysext/fluid_styled_content/Resources/Private/Partials/Menu
and
typo3/sysext/fluid_styled_content/Classes/ViewHelpers/Menu
Fluid Content contains everything you need to create a list like that, you "just" have to combine the necessary bits and pieces.
You can do a lot with TYPO3 core functionality: there is a page type "external URL", pages can have categories by default, there are plenty of menu options (TypoScript HMENU, menu content elements, Fluid menu Viewhelpers). The Linkvalidator can periodically check all links and report broken links.
For suggestions you could add a form. Powermail for example can also store submitted info in database records, so your visitors could prepare page records (they are hidden until you make them visible).
I am very new in TYPO3 (I came from Joomla and WordPress) and I am having difficulties in understanding how templates are handled in TYPO3 (it seems to me that the situation is more complex in TYPO3 than it is in Joomla and in WordPress).
I have installed and I am testing this version of TYPO3 introductionpackage-6.1.3.zip
In Joomla and in WordPress a template simply is an HTML structure (which are marked in the various areas of the page where the CMS modules will be placed) and the related CSS settings.
In TYPO3 it seems to me that the situation is very different or am I wrong?
At this moment I am reading this section of the official documentation that references the default template of the TYPO3 Introduction Package: http://docs.typo3.org/typo3cms/GettingStartedTutorial/Templates/Index.html
The difference between static content and dynamic content of a website created using a CMS is pretty clear to me (this is not different from any others CMS like Joomla or WP)
Dynamic content: is something that is dynamically created by the CMS (executing some queries) as a menu (it look into a DB table and then a script renders the menu on the page)
Static content: is something that is fixed as the title of the website or a background image
Until now I think that it is pretty clear for me but I have many doubts when the documentation speaks about the Template Record as a way to implement the previous principle.
Here: http://docs.typo3.org/typo3cms/GettingStartedTutorial/Templates/%28%28generated%29%29/Index.html
it says that:
This is a control element that instructs TYPO3 how to handle a certain
branch of the page tree.
In particular with this image it shows how to modify these template records for the Introduction Package Template (Introduction Package is also the name of the template provided with this package or what?):
Then on this section on the documentation it says:
If you edit the template "Introduction Package" you will see that most
fields are empty. For each website you need a TypoScript template on
the ROOT level, in this case that is the "Introduction Package"
template. The TypoScript configuration of a website can be quite long
therefore it is possible to make many small TypoScript templates that
get included in the main template. For better maintenance, all
TypoScript of the Introduction Package has been put into the folder
'Typoscript Templates'. The only thing the "Introduction Package"
template does is to include the "ROOT" template that in turn includes
other templates.
And this is totaly obscure for me: I have understood that TypoScript is a configuration language that can be used to configure the frontend (so I think that I can use it to configure how my page will appear) but I can't understand the following assertions:
What does this mean: For each website you need a TypoScript template on the ROOT level, in this case that is the "Introduction Package" template ? I have installed TYPO3 Introduction Package and I have only a web site !!! What is the ROOT level of the website? Is it the Welcome to TYPO3 node in the List section Tree? So in pracatice I am assigning a specific template to the root of a website and this is used in all subnodes (all the pages as Home, About TYPO3, Features, etc)?
What does it mean when it says: For better maintenance, all TypoScript of the Introduction Package has been put into the folder 'Typoscript Templates'. Where is this folder? I don't have it.
What does it mean when it says: The only thing the "Introduction Package" template does is to include the "ROOT" template that in turn includes other templates.?
Tnx so much
Andrea
The root level of your website is the page called Home. It also has the globe instead of a normal page icon, because the flag Use as root page is set in the page properties under behavior.
When you access a page in TYPO3 CMS, then it will walk up the rootline until it finds a root page with a template record. In this case, it is indeed a record called Introduction Package, but what is more important, is that this is a record of the type template.
OK, so far we have found a template for your request. Now TypoScript comes into play. On a normal request, the template engine will search for an object named page which is (usually) of the type PAGE. Thus the most simple template is:
page = PAGE
page.10 = TEXT
page.10.value = <h1>Hello World</h1>
Which just prints Hello World on your website.
What happens next depends on your template approach chosen (marker base, automaketemple+marker, templavoila, fluid, fedext, ...). That means that TYPO3 CMS does not just have one template approach (or one kind of template), but is extensible and very flexible, as you can combine them.
In the Introduction Package uses the automaketemplate+markers approach. This includes a ready HTML template, automatically creates blocks based on certain rules and then replaces those blocks with dynamic content.
OK, where do you find the configuration for this?
The actual template file is fileadmin/default/templates/introduction_package_site_structure_template.html.
The TypoScript configuration is in fileadmin/default/TypoScript. There you can find a file called setup.ts. It includes all other TypoScript files. There are various folders, e.g. menu for the menu definition, block for the dynamic blocks, etc.
The configuration of automaeketemplate is in Extension/AutomakeTemplate/setup.ts.
The sections defined with the help of automaketemplate are replaced in Page/setup.ts.
The full TypoScript defines a tree structure of objects with their configuration. You can view the full parsed template with either the Template Analyzer or the TypoScript Object Browser which you find in the template tools in the dropdown select box on top of the module.
The separation of the TypoScript into several files is done by the purpose of the configuration inside the files. This is meant for easy maintenance and not for easy learning. You can always use the Template Analyzer to see the full template that is generated out of the fragments and the TS Object Browser to see what kind of configuration tree this results in.
This might sound a bit difficult at first, especially compared to the primitive template systems of other products, however it gives you great possibilities that are yet easy to maintain, even if you do major updates.
It is great to see that people decide to use TYPO3. In my point of view the biggest difference to WordPress, Drupal...
is the strict separation between HTML and dynamic logic, witch can be TypoScript/userFunc or Fluid logic...
and even this makes TYPO3 so powerful. nothing against WordPress, Drupal... ect. but to use PHP in templates is especially for updates a dangerous thing to do.
I am always impressed whats possible with TYPO3. "I cant do it" is not valid for TYPO3. TYPO§ always has a way.
It is indeed a hard way through to learn all the corners of TYPO3 but it is worth.
Keep doing it and you will succeed
Ludwig
Great to hear you also wanna use TYPO3 as a CMS.
To understand the TYPO3 CMS better, i think you can better begin from scratch, meaning download the source + dummy package and install it on your server, or maby download a wamp package.
Currently I use Fluid to build my templates. For the part outside TYPO3 its much like Joomla, just create one or more HTML files, with some special markers.
The other parts, which are in TYPO3, may be some more difficult now, and it would take a lot of time to explain that here, so i'll refer to a tutorial made by Thomas Deuling:
http://thomas.deuling.org/2011/06/create-a-complete-typo3-website-by-using-the-fluid-template-engine/
You might wanna join the TYPO3 mailing list for italy, found at http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-ug-italy.
Furthermore, the TYPO3 website is filled with documentation, although sometimes out of date its still usefull. Also you might wanna take a look at the TYPO3 certified integrator program. There you can find all the basics to become a master at TYPO3.
Please feel welcome to the community, TYPO3 is inspiring people to share!
Kind regards,
Jeroen
Hi i wrote a little starter ts time ago.. maybe helps you
Remember in TYPO3 there are many ways to solve things!..
gl
Setup:
config {
baseURL = http://www.bla.com/
prefixLocalAnchors = all
meaningfulTempFilePrefix=1
doctype=xhtml_trans
htmlTag_langKey=de
remove_defaultJS=external
inlineStyle2TempFile=1
disablePrefixComment = 1
linkVars=L
sys_language_uid=0
language=en
locale_all = en_EN.UTF-8
xmlprologue = none
}
page = PAGE
page.typeNum = 0
page.bodyTag=<body>
page.10=TEMPLATE
page.10 {
template = FILE
template.file = fileadmin/templates/template.html
workOnSubpart = DOCUMENT
subparts {
CONTENT=COA
CONTENT.10<styles.content.get
}
}
File: template.html
<!-- ###DOCUMENT### -->
<!-- ###CONTENT### -->CONTENT<!-- ###CONTENT### -->
<!-- ###DOCUMENT### -->
Up to now, I used to use template auto-parser. I like the fact I can modify any element of the template using typoscript, without altering the initial HTML file. I also like the fact that I can render the html template directly in a web browser, filling it with dummy elements to see examples of menus and content elements. Finally, with the new backend templates, i now can place content elements anywhere on a grid, in a way that mimics the real aspect of the website.
I know there is also TemplaVoila. I never took the time to learn it. My feeling is that it is less compatible with some extensions, but maybe I am wrong.
Now, there is fluid, that will be used in the next version of Typo3. While it is clear that it is better using it that using template markers, I don't really understand why I should be better using Fluid than using template auto-parser or TemplaVoila. What I dislike is the fact it requires to modify the html template with special tags, meaning that either the web designer has to know Fluid, or the Typo3 integrator has to modify templates from the designer each time a modification is performed.
My question is: should I migrate form template auto-parser to Fluid for my website template? What are the benefits of using Fluid? Why should it be better? What template system should I use with Typo3?
As long as TypoScript does not support objects, the benefits of FLUIDTEMPLATE over template auto-parser are only a few. So there is no need to migrate.
But IMHO there are some arguments to switch to fluid:
more and more extensions will use fluid, so it will help you to learn fluid
you can use an ide with code-completion for fluid (it is just XML!)
fluid is really powerfull, you can have f.e. if statements which checks for empty content
some day TypoScript will support objects as well
But for extension developement, it is totally different. In an Extension, i would allways prefere using FLUID. You do not have to deal with template things inside your extension anymore. Just pass the data to fluid and things which concern the view will be done in your template.
Whever you choose, it should be something based on Fluid - this will allow you to be extremely versatile and it makes the implementation less important than the template, which is quite good.
I myself am the creator of the "Fluid Powered TYPO3" framework (formerly known as FED) and would of course recommend that you take a look at what this framework can do for you - it's capable of great things, not the least of which is saving you a lot of time while at the same time allowing you to create even more consistent templating for pages and content - and even backend modules.
And we're always happy to help new users. We are currently in the process of improving our documentation, but you can already find many fully up-to-date guides on our Github page - https://github.com/FluidTYPO3 - the repository called "documentation" is the place we will store all the documentation.
You may want to have a look at http://fedext.net http://fluidtypo3.org - especially the "Tour of features" which tries to explain the point of Fluid Powered TYPO3 in as few words as possible. After that, the examples from the documentation will give you a much clearer picture of what Fluid Powered TYPO3 can do for you.
We focus on efficiency always - we've tried to do all the heavy lifting so that you really can just sit down and begin creating page templates. We took a lot of inspiration from TemplaVoila but there is no more re-mapping of content and things like this: when you change your templates, that change is immediately reflected, which makes it very nice to work with in iterations and do things like continuous delivery and -integration.
Hopefully this helps!
Cheers,
Claus aka. NamelessCoder
You could also argue, that adding special tags like
<f:section name="typo-content">
<div id="content">This is where the designer intended content to go</<div>
</f:section>
Could assist your designer while doing a redesign to know where you "mapped" your content elements to. This is neither the case with autoparser nor with TemplaVoila. So if the designer moves stuff around you probably get your templates back and they still work without any modifications.
I'm investigating Adobe CQ5 and would like any advice on how to integrate its drag-and-drop UI to create a responsive website. It seems as if it works on a concept of fairly bland templates with components that can be dropped in pretty much anywhere, including things like "three-column control" - which would make designing a responsive grid structure very hard (as it would be hard to prevent users from dropping in a control that could ruin the layout).
Does anyone have any experience or advice on this? I'm really looking for deep technical details on the structure of templates vs components (paragraphs), and where/how to manage to the CSS.
CQ5 offers ways to control what can be done within a template, so thinking that components "can be dropped in pretty much anywhere" may be misleading. Page templates are designed and configured so that you control which components can be added to a certain area of a page. This allows you to only make those components available that will work with the template layout, excluding components that would wreck the layout. Then authors are only allowed to use things that will work. If they attempt to drag a component onto a paragraph (parsys) where that component has not been configured as available, the UI will not allow them to use it there. So CQ actually makes it easy to prevent users from dropping a control somewhere that would ruin the layout.
This is outlined a bit here:
http://dev.day.com/docs/en/cq/current/howto/components_develop.html#Adding%20a%20new%20component%20to%20the%20paragraph%20system%20%28design%20%20%20%20%20mode%29 which states that
"The components can be activated (or deactivated) to determine which
are offered to the author when editing a page."
When it comes to CSS and JavaScript, you can create a client library and then include the relevant client library on the page. Backend CQ functionality will take care of combining multiple CSS (or JavaScript) files into a single minified file to allow for a single HTTP request of an optimized file. This it outlined a bit here:
http://dev.day.com/docs/en/cq/current/developing/widgets.html#Including%20the%20Client-Sided%20Code%20in%20a%20Page as well as
http://dev.day.com/docs/en/cq/current/howto/taglib.html#%3Ccq:includeClientLib%3E
So you might develop several components that share a client library, then when any of the components is added to a paragraph the client library will be included on the page. You may also want a CSS library that applies to all the templates to give a common look and feel, yet allow components to add their own when they are used.
These guidelines for using templates and components outline how you provide control, yet flexibility:
http://dev.day.com/docs/en/cq/5-5/developing/developing_guidelines_bestpractices.html#Guidelines%20for%20Using%20Templates%20and%20Components
I'll document our successful WIP experience with RWD and CQ5
Assumptions:
A well documented style guide.
Our First Steps:
Modified existing column control component css to utilize twitter bootstrap grid css.
Create a base page property allowing two different classes on the grid container to be set and inherited by child pages. (container||container-fluid).
Leverage out-of-the-box components where ever possible.
All component widths inherit the width of their parent container allowing for components to be dropped into any location within a template.
Issues:
The out-of-the-box column control component can not be nested.
We are looking into building a custom column control component.
Takeaways: this is an evolutionary project and we are constantly iterating.
With the recent launch of AEM 6.0, they have an example website called as Geomatrixx Media. This website is responsive.
You can take this example as reference and start building on top of it.