I have a typo3 with multiple trees (one per language) under a common root and domain,
www.example.com (maintemplate)
-en (+ext)
--news
---singleview(hidden)
-fr (+ext)
--french_news
---singleview(hidden)
-de (+ext)
--german_news
---singleview(hidden)
-Newsfolder
--english
--french
--german
the tt_news.SinglePID is configured via constants in the extension templates.
My Problem is, that Realurl always uses the SinglePID from the english tree, for example when I click on a german news entry Realurl brings me to the english page and shows the german news. Any Idea how to fix that?
Thanks
Set the single pid with the TypoScript instead of form and then use common conditions for changing it
Are you sure it's a RealURL issue? Turn it off via TypoScript setup config.tx_realurl_enable = 0 to see whether it's buggy even without RealURL manipulating your urls or not.
Regarding your issue try this in your global TypoScript constants:
plugin.tt_news.singlePid = x
[PIDinRootline = a]
plugin.tt_news.singlePid = y
[PIDinRootline = b]
plugin.tt_news.singlePid = z
[global]
Whereby x is the uid of the english single page, y the german one, z the french one. And a and b the root pages of those trees.
Related
According to http://www.typo3-probleme.de/2018/07/11/typo3-sitemap-mit-typoscript-erstellen-2285/ I let TYPO3 V8.7.24 generate the sitemap.xml file. So far it works. But in the file there are not proper URL's. On every URLs end is "?type=500001", for example an URL looks like "https://www.domain.ch/angebot/online-marketing/?type=500001". As a side note , there is also Ext:Realurl in use.
My request is, how can you remove the segment "?type=500001" ? Is the reason typoscript or the extension Realurl? How can I analyse it?
Any hint is welcome. Thanks in advance for your help.
It's the link generation inside of TYPO3. that is configured by typoscript, so you could see typoscript as the culprit.
If you want to know whether realurl (or any other extension) is the culprit: disable the extension in mind. if the error is gone there is a reason to suspect this extension.
When links are generated by TYPO3 it holds some parameter to stay in the current context. Which paramaters should be considered is a configuration (so it is grounded in typoscript).
Have a look (TSOB) at config.linkVars in general (it is copied implicit to every page object) or of your page object page.config.linkVars (in your case: xml_sitemap.config.linkVars)
There is a note in the manual:
Do not include the type parameter in the linkVars list, as this can result in unexpected behavior.
Other option would be to explicit set &type=0 to every link. But don't forget to set config.uniqueLinkVars = 1 (or xml_sitemap.config.uniqueLinkVars = 1)
Is there a way to get the Log In Form for Frontend User on every page? I would prefer the footer.
And if someone is logged in you can see the Log Out Button.
Is this possible without an extension?
You can copy the default felogin output to wherever you want on your template. For example use lib.login, copy the plugin.tx_felogin_pi1 into it, change the template and you're fine.
lib.login < plugin.tx_felogin_pi1
lib.login.templateFile = path/to/your/template/file
More you can see in the official documentation: https://docs.typo3.org/typo3cms/extensions/felogin/8.7/Configuration/Index.html
In general there are three options to include a CE (e.g. the Login-form) on all pages:
use typoscript to generate the CE. Normally the CEs are defined in tt_content, from where you could copy the base configuration and adapt it. For some plugins you also find a complete configuration beyond lib (for newer extensions there you only find the settings). All the configuration must be done in typoscript.
use typoscript to render the content of a special page/ column. In this variant you have a special page only for content referenced somewhere else. Advantage: you could configure the CE in the usual way. Try to avoid referencing CEs by uid as an editor might disable or delete the current element(s) and insert a new one which would not be rendered.
use a special column in your root page and inherit the content to all subpages. Advantage: you could change the inherited content easily on each page (if this column is available in the current backend layout).
example for 3:
variables {
footer_content < styles.content.get
footer_content.select.where = colPos = 15
footer_content.slide = -1
}
I have this in nearly every project: TypoScript cascades to child nodes in the pagetree by default. If you want to prevent it from being applied to child nodes, one solution is to create an extra TS template that undoes it and include it as "template on next level".
E.g. you want to apply some TS to a specific parent page, but not it's children:
temp.somemenu.wrap = **|**
Apart from the "template on next level" approach, solutions/hacks include:
if you know which level you start from:
[treeLevel = 2]
temp.somemenu.wrap = **|**
[global]
If you have the pid and want to wire it in a constant:
[page|uid = {$targetPagePid}]
temp.somemenu.wrap = **|**
[global]
EDIT: adapted to constant – this is quite a robust solution!
Isn't there some switch to make a TS setting NOT cascade? Or define the number of levels it can cascade to?
Something like
<INCLUDE_TYPOSCRIPT: source="path/to/my.ts" treeLevelsDown="0">
or
[global treeLevelsDown = 0]
temp.somemenu.wrap = **|**
[global]
This would mean that the TS is kind of self-aware, knowing on which tree level it has been set. Not sure if that's even possible.
Does it make sense?
Or am I missing some existing solution?
No, this does not work any other way than those you already mentioned in your question. The reason for this is, that TYPO3 start from a page and the looks upwards the page tree, until it finds a TypoScript template. (It collects all extension templates on the way and applies them on top of the first found root template).
Therefore it never goes down, but only up. If it would stop cascading after a certain level, what should be used as TypoScript template for those sites? It still needs a configuration to render the page.
The question is theoretical, and #pgampe answers it.
About my use case, here's the solution from #bernd-wilke-πφ, which works just fine
// just apply to page references
[page|uid = {$pidReferencesList}]
// add some additional js (a list filter)
page.includeJSFooter {
refs = {$templatePath}/Resources/Public/additional_js/references.js
}
// add some markup
lib.thecontent.wrap = <div id="items-list-wrapper">|</div>
[global]
I use this condition
[globalVar = GP:colPos==0]&&[page|backend_layout = pagets__MainTemplate]
My problem is that my „subpage“ has no backend_layout selected because the parent pages "Backend Layout (subpages of this page)“ is set. So the condition does not work on subpages.
Can create a condition like that?
lib.backendLayout = TEXT
lib.backendLayout {
data = levelfield:-1, backend_layout_next_level, slide
override.data = TSFE:page|backend_layout
}
I want do white/blacklist CTypes in BE Columns in this way:
[globalVar = GP:colPos==0]&&[page|backend_layout = pagets__MainTemplate]
TCEFORM.tt_content.CType.keepItems := addToList(header)
[end]
Not as far as I know, as you can only access the current page record with the "page" condition.
Instead you could
a) Write your own condition (see https://docs.typo3.org/typo3cms/TyposcriptReference/8.7/Conditions/Reference/Index.html#custom-conditions or starting with version 9 https://docs.typo3.org/typo3cms/TyposcriptReference/Conditions/Reference.html#extending-the-expression-language-with-own-functions-like-old-userfunc)
b) Use a userFunc (like "a" only older and less fancy ;)) - see https://docs.typo3.org/typo3cms/TyposcriptReference/8.7/Conditions/Reference/Index.html#userfunc
new c) follow Jigals suggestion (or use a similar extension - there are a few - but they mostly do a lot more than what you need)
--- EDIT after question update ---
As you want it working in TSConfig c) is actually not an option.
c) depending on what you actually want to achieve with your condition use if and data (like in your description) directly at the TS objects that should have different behavior if your condition is true.
For reference:
Differences between TSConfig Conditions and TS Conditions:
https://docs.typo3.org/typo3cms/TSconfigReference/8.7/Conditions/Index.html#differences-to-conditions-in-typoscript-templates
As an alternative to Susi's solutions you could use Gridelements. This extension has the feature that you can set inside each block in a backend layout which CEs are allowed.
I'm in the process of building a website using TYPO3 6.2.
I have the following page structure:
- Page Root (id=0)
- Page A (id=1, alias=pagea)
- Content 1 (id=3, alias=content1)
- Detail 1 (id=5, alias=detail1)
- Detail 2 (id=6, alias=detail2)
- Content 2 (id=4, alias=content2)
- Detail 3 (id=7, alias=detail3)
- Page B (id=2, alias=pageb)
- Content 3 (id=4, alias=content3)
I am using realURL, so in order to access page with id = 5, the following URL would be valid: web.site/pagea/content1/detail1
Pages in the second level (eg Page A) inherit the content of its children (eg Content 1, Content 2). So the "Content X" pages should not be individually browseable and instead redirect to their parent (Page X), with the alias as a hashtag. So if one were to open web.site/pagea/content1/, it should redirect to web.site/pagea/#content1
I tried accessing the DB and build my individual redirect URL in the redirect-header, but it doesnt replace the {} queries
[treeLevel = 2]
config >
config.additionalHeaders = HTTP/1.0 301 Permanent Redirect | Location: https://web.site/{levelfield:-2, alias}#{page:alias}
[end]
Anyone got a solution to this?
P.S. Setting the Contnet-pages as a shortcut does not work for me, as it looses the hashtag and requires it to be set for each "Content #"-Page
The data type of config.additionalHeaders is string so trying to access the DB or working with constants inside config.additionalHeaders can't work, unfortunately.
You might find a solution on another layer:
Try to build a regexp in your .htaccess which identifies urls with more than two path segments and rewrite/redirect it to the top-level with an anchor.
As you want to have the same links in your website you might need to use the same replacement as last stdWrap on page generation so every 'normal' deep link is replaced first hand and urls with multiple path segemnts are not known to the world (google) at all.