This question is a reformulation of this question which had evolved in a confusing way. Please refer to this question if you search some in depth details or are interested in workarounds and alternative solutions.
This question is about the call to template folder_full_view_item.pt in folder_full_view.pt, not about other templates in general!
Please avoid workarounds like skin layers, editskinswitcher, etc. I don't want to solve a particular use case here. What I want is to really understand how this actually works.
I present this question in three parts: scenario, result, questions.
scenario
Have a Folder with a Document. The layout of the Folder is folder_full_view. The layout of the Document is document_view:
Folder (layout=folder_full_view)
Document (layout=document_view)
The template folder_full_view.pt calls template folder_full_view_item.pt via item.getObject().folder_full_view_item().
folder_full_view_item.pt calls (e.g. for a Document content type ) the template document_view.pt via use-macro="item_macro" (item_macro being something like here/document_view/macros/content-core). Schematically as follows:
folder_full_view.pt :: item.getObject().folder_full_view_item()
folder_full_view_item.pt :: use-macro="here/document_view/macros/content-core"
document_view.pt
In a plone3_theme have overriden versions of the templates folder_full_view.pt, folder_full_view_item.pt, and document_view.pt. These templates are registered as follows in configure.zcml.
<browser:page
for="*"
name="folder_full_view_item"
template="folder_full_view_item.pt"
layer="example.theme.browser.interfaces.IThemeSpecific"
permission="zope2.View"
/>
<browser:page
for="Products.ATContentTypes.content.folder.ATFolder"
name="folder_full_view"
template="folder_full_view.pt"
layer="example.theme.browser.interfaces.IThemeSpecific"
permission="zope2.View"
/>
<browser:page
for="Products.ATContentTypes.content.document.ATDocument"
name="document_view"
template="document_view.pt"
layer="example.theme.browser.interfaces.IThemeSpecific"
permission="zope2.View"
/>
results
With the theme installed the results are:
Document and Folder get their templates (I guess) via traversal. The (sub)templates though don't go through the traversal.
Folder: uses overriden folder_full_view.pt, original folder_full_view_item.pt, and original document_view.pt
Document: uses overriden document_view.pt
questions
is it the case that item.getObject().folder_full_view_item() doesn't go through traversal? If yes why?
what can be modified (in folder_full_view.pt!) to force a traversal to the overriden folder_full_view_item.pt(!) and subsequently to the overriden document_view.pt? Is this possible?
Again, please avoid workarounds like skin layers, editskinswitcher, etc. I don't want to solve a particular use case here. What I want is to really understand how this actually works.
Related
I'm using Typo3 8.7.11 and the extension indexedSearch 8.7.11 with Fluid-Templates
I created an extension with my own fluid-templates for the search and search-results form.
Now I also want to use my own translations for these templates. So I created the following files in myTemplateExt/Resources/Private/Language:
locallang.xlf (for the default - en - language)
de.locallang.xlf
fr.locallang.xlf
it.locallang.xlf
Alas, the translations are not loaded.
I found out that I can add the whole path to the translations like
<f:translate key="LLL:EXT:myTemplateExt/Resources/Private/Language/locallang.xlf:sform.submit" />
But then only the locallang.xlf file is loaded. All other languages are ignored.
I also tried to add my own variable to the indexed-search TS-setup:
plugin.tx_indexedsearch.settings.langfile = EXT:myTemplateExt/Resources/Private/Language/locallang.xlf
Which of course fails miserably (most likely because I can't define my own settings-var in TS for another extension?)
Any ideas how I can make the indexed-search extension use my own lang-files?
P.S. I found this suggestion on StackOverflow:
Typo3 Indexed Search Local_Lang path
But this is not what I want - I need more flexibility for my templates, as I need to add some more text than just the regular keys that indexed-search provides to them (yeah, customers, you know ;)
It might not be the best solution, but I solved the problem like this:
I set a variable according to the current language:
<v:variable.set name="currentLang" value="{v:page.language(languages: 'LLL:EXT:myExt/Resources/Private/Language/de.locallang.xlf,
LLL:EXT:myExt/Resources/Private/Language/en.locallang.xlf,
LLL:EXT:myExt/Resources/Private/Language/fr.locallang.xlf,
LLL:EXT:myExt/Resources/Private/Language/it.locallang.xlf',
normalWhenNoLanguage: 'LLL:EXT:myExt/Resources/Private/Language/de.locallang.xlf')}" />
And then for the translation:
<f:form.submit name="search[submitButton]" value="{f:translate(key: '{currentLang}:sform.submit')}" id="tx-indexedsearch-searchbox-button-submit" class="tx-indexedsearch-searchbox-button" />
This isn't elegant, but it works...
In the src/AppBundle/Controller folder, there is a file called DefaultController.php.
I'll create url's like below, should I use just DefaultController.php for all URL requests or is it recommended to use a different controller.php file (UserController.php, FeedController.php, etc) for each part of the site? (profile, feed, settings, etc)
I also have another question. As far as I understand, we put our html files in our /App/Resources/views folder to keep them separated. Do I need to create a specific file for each part of the website just like flat PHP? (settings/index.php, settings/password.php, settings/things.php, settings/security.php, etc).
I am not sure whether this question is suitable for SO or not.
settings
/settings
/settings/password
/settings/things
/settings/security
/settings/privacy
/settings/ban
/settings/notifications
/settings/mail
/settings/mobile
/settings/applications
/settings/advertising
/settings/invite
user
/username
/username/photos
/username/friends
/username/posts
feed
/feed
/feed/posts/postid
For both questions is no hard answer. I should create a controller for each part of your website AT LEAST. Theoretical you could throw everything into one controller but it will be a very long list if you are finished. Another problem is that your action names like indexAction will repeat which is of course not possible because every method must have a different name. And names like index1Action, index2Action and so on is also not a proper solution :-). Another helper is to create an own controller for every ENTITY.
Twig files should only be written for one page only or only for a part of a page. Imagine that you have a homepage with last 10 newsitems but also a news page with more news items (maybe with pagination). The newsitems themselves looks the same on both pages. In this case you could make a home.html.twig, a news.html.twig and also a newsitem.html.twig. Both home and news will include newsitem to show the newsitems...
Hope i gave you a light.
In Alfresco, if a type name is removed/changed all nodes of that type will disappears but still exists.
Using alfresco 5.0.c I've added some custom types:
eg:
<type name="my:test">
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
now i deploy it and create a folder of this type (a simple folder, then change type)
Now i edit the type like this:
<type name="my:test2"> <!-- from my:test to my:test2 -->
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
Deploying this: any "my:test" folder will disappear, but, if I try to create another folder with the same name I get an error becouse the node still exists.
These nodes will not be not even listed within the folder child:
print(document.getChildren());
How can I recover (if possible using the the javascript console) all the "broken" nodes and be able to change the type?
A little preface: as widely stated by Alfresco, if you want to change your custom content model you should change it only incrementally.
This means that you can't remove any properties, types or aspect at definition level of the model, you only can add new definitions in the content model of Alfresco.
So it is a very bad practice to change types "on the fly".
A good practice is to always start with a model as small as you can and then add features as long as you need them.
In your case you should have deleted all nodes referencing my:test type BEFORE changing the model and then safely remove it and finally you should have performed a full reindex. This could be the reason why the repository tells you that the folder exists even if you cannot see it anymore.
As far as I know it is not possible to delete this inconsistent nodes through the console, so my advice is to perform a full reindex. If the issues come up again then you should consider to start again from scratch.
Another approach next time is to add the new type and programmatically hide the older one.
Is there a simple way to check if a content-type, or a specific object, has Versioning enabled/disabled in Plone (4.3.2)?
For context, I am making some unique conditionals around portal_actions. So instead of checking path('object/##iterate_control').checkout_allowed(), I need to first see if versioning is even enabled. Otherwise, the action in question does not display for items that have versioning disabled, because obviously it isn't checkout_allowed.
I didn't have any luck with good ole Google, and couldn't find this question anywhere here, so I hope it's not a dupe. Thanks!
I was able to get this working by creating a new script, importing getToolByName, and checking current content type against portal_repository.getVersionableContentTypes(). Then just included that script in the conditional.
I was looking for something like this that already existed, so if anyone knows of one let me know. Otherwise, I've got my own now. Thanks again!
The first thing that checkout_allowed does is check if the object in question supports versioning at all:
if not interfaces.IIterateAware.providedBy(context):
return False
(the interface being plone.app.iterate.interfaces.IIterateAware:
class IIterateAware( Interface ):
"""An object that can be used for check-in/check-out operations.
"""
The semantics Interface.providedBy(instance) are a bit unfortunate for usage in conditions or TAL scripts, because you'd need to import the interface, but there's a reversal helper:
context.portal_interface.objectImplements(context,
'plone.app.iterate.interfaces.IIterateAware')
What is the most sraightforward (but not very hackish - unPlonish) way to create a "page" in Plone (v 4.x), which would show some Plone internals info? I'd like to generate a page document, which would paste dir() (or whatever my own function) result to <pre/> or something like that. Straightforward.. i mean, without having to create a Plone product or having to modify server files directly - just using ZMI..
You want to install plone.app.debugtoolbar
http://pypi.python.org/pypi/plone.app.debugtoolbar/
which gives you access to the most imporant informations about the current context object, request data etc.
Products.DocFinderTab adds a "Doc" tab in the ZMI that allows you to explore the current object and its methods. If you installed with the Unified Installer and use the "develop" configuration, it's already loaded.
Products.Clouseau may still work with recent Plone's, though it's aging. It gives you an AJAX interface to explore the context from within Plone.
Finally, to explore the request object, you may just add:
<div tal:replace="structure request" />
to a template. That will allow you to check all the HTTP and form variables as well as what's stored in the request.
Go to the ZMI, add a "Script (Python)", and define your function dir() and print the result like this :
print dir()
return printed