What means the TYPO3 configuration "Disable override demand"? Sometimes plugins can have this configuration. Can anyone explain it in two or three sentences? Translations in my language are not satisfactory.
This isn't a convention, but rather an implementation that depends on each extension, but I assume you mean EXT:news so I will use that as example.
Disabling override demands means users can't override the settings you (the editor) defined in the plugin instance, when they view the plugin rendered in the frontend. So for example, disabling this means things like filtering and sorting will not be possible - the filtering and sorting you decided will always be used.
Take this with a grain of salt though. There could be some arguments which are exempt from being disabled - as stated, the exact implementation may differ and you need to check the individual extensions' documentation for a detailed description of the behavior.
Related
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.
I am customizing a pingfederate temaplte (for login).
As part of this customization I would like to be able to have a java script variable that is dependent on the configuration of the form being used. Essentially to distinguish between a test and a live environment.
I'm trying to keep the templates in source control and not have duplicated code and also to be able to test configurations before I deploy.
I'd like to think that I could set a variable somewhere in the admin interface and get this exposed in the template, however I have found nothing in the documentation to suggest that this is possible.
Is there a way to do this, or a reasonable work around?
From the perspective of PingFederate itself, no. There are plenty of mechanisms in Javascript that you could use, like window.location.host to trigger CSS properties. You could even use the Velocity variable of $PingFedBaseURL to drive CSS properties.
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%).
I have a set of GWT UIs, some created directly in Java and others created using UI Binder ui.xml files.
I localized them following the official GWT guidelines (e.g. creating interface extending Messages interface).
I now wonder if there is an easy way to write a unit test to validate that message keys get replaced by the corresponding values from property files?
I guess I could do that using GWTTestCase, but actually I don't need a browser to render the page. Instead, it would be enough to get the raw string output and check with some regex that the messages are present.
Is that possible? Or is it better to test such things in running application like using Selenium?
Just a note. Besides the important things you are trying to validate, one of the critical points in my project during messages localization tests is to see: if the translated text fits the allocated space. If it's a box of fixed size, overlapping texts don't look nice. And this cannot be checked with unit tests. That's why the manual review is in to-do list when new locale is added or certain labels/messages are changed.
I'd recommend Selenium. Checking that the messages are present could be tricky, because in that case you should know the place where the label is located, in which tags. In my opinion, using GWTTestCase makes sense when it comes to testing controllers' behavior. Simple search by value guarantees only presence but not correct placement.
I think, it also makes sense to use those translation properties in the tests, so the strings are not duplicates in the tests.