TYPO3 onepager + normal pages structure - typo3

I am very new to TYPO3 and I am having problems achieving the following:
A website structure looking like so
-home
— Sub content 1
— Sub content 2
— Sub content 3
— etc..
-page 1
-page 2
-etc…
The home page should be collecting the “sub content 1” “sub content 2” & "sub content3", so it should behave like a one pager.
And the other pages should be behaving as ‘normal’ pages.
I downloaded the FluidTypo3 kickstarter package. And followed then this tutorial: https://worksonmymachine.org/blog/onepage-design-with-fluidtypo3 where it is described how to achieve a onepager with FluidTypo3.
I managed so far to get this result:
-root
—Sub content 1
—Sub content 2
—Sub content 3
As soon as I add a new level:
-root
—home
—— sub content 1
—— sub content 2
The Onepager effect stops functioning, and the sub pages are not being collected anymore. I did configure under “Edit page” which template should be used, yet no success.
I am stuck to this step and can’t figure out why this is not functioning? Ideas?
I have Typo3 6.2 installed.

The problem is simple:
You have added one level to your menu so your old page structure not correct anymore. You use a
v:page.menu
And it should have the correct access point to you page structure.
If you check the specification of this ViewHelper, you find the
entryLevel
However the specification says only:
Optional entryLevel TS equivalent of the menu (integer)
You need to search a bit more to understand its working, and if you see the TypoScript documentation for HMENU then you see how it works:
Defines at which level in the rootLine the menu should start.
Default is "0" which gives us a menu of the very first pages on the
site.
If the value is < 0, entryLevel is chosen from "behind" in the
rootLine. Thus "-1" is a menu with items from the outermost level,
"-2" is the level before the outermost...
(You got already the help in the comments, but I wanted to write here an answer based on the feedbacks)

Related

indexed_search Multidomain (TYPO3 9 LTS)

There is a multidomain setup (domains next to each other on the same level), each domain has their own search page and configuration. I've tried...
plugin.tx_indexedsearch.settings.rootPidList = 3
...to get the search results limited to the domains pagetree only. But as soon as using rootPidList, there are no results at all any more. Then i've tried...
plugin.tx_indexedsearch.settings.defaultOptions.sections = rl1_3
...and this seems to work correctly to limit the results to the pagetree (below page id 3).
So what is "rootPidList" ment to be used for?
According to the comment in the code (typo3/sysext/indexed_search/Classes/Controller/SearchController.php, Line 232):
Setting the list of root PIDs for the search. Notice, these page IDs MUST have a TypoScript template with root flag on them!
Basically this list is used to select on the "rl0" field and page ids are registered as "rl0" only if a TypoScript template record with root flag is there.
This happens AFTER the use of $this->searchRootPageIdList above because the above will then fetch the menu for the CURRENT site - regardless of this kind of searching here. Thus a general search will lookup in the WHOLE database while a specific section search will take the current sections.
In a multi domain setup we have set rootPidList to the overall root page (in this case id=457).
defaultOptions.sections is set like this:
defaultOptions.sections=rl{$customer_theme.search.level}_{$customer_theme.root}
{$customer_theme.search.level} is set to 1 or 2 depending on the availability of more than one language per country.
{$customer_theme.root} is the root page (marked by the root page flag).
e.g. for Indonesia (english) we use level = 2 and root = 12947.

Typo3 9.5 Fluid template navigation menu only starts at one page id

Working on Typo3 project, we are using Typo3 9.5
There is already an extension created for the project by my colleague, which has a navigation menu going something like this
<div class="collapse navbar-collapse" id="navbarNavDropdown">
<v:menu pageUid="2">
<ul class="navbar-nav">...
As you can see v:menu is assigned a hard-coded pageUid.
Is there a way to remove hardcoding so that the extension could be transfered between systems and assigned to various pages without worying about changing the value every time it's done.
I can also see it becoming an issue once we need to run more then one root level layout from this template :-(
Have a look into the documentation of that VH
Similar to a typoscript menu you can start a menu with an entryLevel.
0 = root
1 = first level
2 = second level
:
-1 = current level
-2 = parent level from current
:
if you do not provide the parameter pageUid an entryLevel = 0 is default.

Typo3 Blog with Subtemplate

I am trying to set up the following structure:
Landing-Page (Root-Template)
--- Content Webpage 1
--- Content Webpage 2
------ Other Sub stuff
--- Blog (Blog-Template)
------ Blog stuff (apply Blog-Template)
--- 404, etc.
My problem with this is that if I am applying the blog template to my blog root, then my template is applied to all sites at the same level (so: Content Webpage 1 & 2, ...).
How can I prevent this and only assign my blog template to this site and lower?
P.S.: I am a beginner, so a bit of background would be nice if this is possible. I read a few of the Tutorials on docs.typo3.org, but that did not help...
You an create a template-record on the page Blog, then only that page and subpages get that configuration. Else the default configuration is taken which is or has to be defined in the root-template.
You also could use Conditions in the root-template to check for the Blog-Page and assign the special template inside that condition. Assumed your Blog has the pid (Page-Id) 5 the condition would look like this:
... (other stuff before)
[PIDinRootline = 5]
here you special template configuration
[global]
... (other stuff afterwards)
There is another option but there you need already advanced knowledge, as it's not explained too deep in my answer there (the TCA-part is missing): how to add multiple fluid-templates.
Okay, I finally got it to work like I desired.
Because the Blog-Template is a static Template I just assigend it to the main Template. Important was the order of the static Template includes.
Fluid styled content
Bootstrap package
Typo3 Blog
Typo3 Blog Template
The reason for that is that the Typo3 Blog Template needs the Fluid styled content and because my Fluid styled content include was the last one before, Typo3 threw me an error that it was not able to find some fluid elements.

How to get the Log In Form on every page? (for example in footer) Typo3

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
}

TYPO3: Dynamically redirect to parent page with typoscript

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.