TYPO3 MenuProcessor shows root page when empty? - typo3

I have a basic menu element using the Pages field and the MenuProcessor.
In the fluid template I only want to output something only if there are pages in the Page field. But if the field is empty the MenuProcessor adds the root page to the array.
How do I prevent the root page being added to what should be an empty array?
typoscript looks like this:
dataProcessing {
10 = TYPO3\CMS\Frontend\DataProcessing\MenuProcessor
10 {
special = list
special.value.field = pages
levels = 1
as = menuItems
expandAll = 1
includeNotInMenu = 1
titleField = nav_title // title
}
}

I suppose it is a very special edge case (which could be handled in the menu processor, you might open a ticket on https://forge.typo3.org ).
As you have identified the reason with empty input parameters you might build a condition on that case.
Either in FLUID or in typoscript.
In typoscript you could add a stdWrap function:
10 {
:
if.isTrue.field = pages
}

Did you try the entryLevel?
dataProcessing {
10 = TYPO3\CMS\Frontend\DataProcessing\MenuProcessor
10 {
entryLevel = 0
}
}

Related

How to get "leveltitle" for HMENU items via TypoScript?

I have a menu (HMENU with special = updated) that gives me the latest sub and sub-sub pages from 3 categories.
The page structure looks like this in the backend:
In addition to the title, I would like to output the name of the respective category (the parent level-1 page).
This is my TypoScript attempt:
lib.myMenu = HMENU
lib.myMenu {
special = updated
special{
value.field = 10,11,12
beginAtLevel = 1
limit = 99
}
1 = TMENU
1{
NO{
doNotLinkIt = 1
stdWrap.cObject = COA
stdWrap.cObject {
10 = TEXT
10{
wrap = <h3>|</h3>
field = seo_title // title
typolink.parameter.field = uid
}
20 = HMENU
20{
wrap = <div class="category attempt-1">|</div>
special = rootline
special.range = 1|1
special.value.field = uid # does not work
1 = TMENU
1.NO.allWrap = |
}
30 = TEXT
30{
wrap = <div class="category attempt-2">|</div>
data = leveltitle : 1 # does not work as expected
}
}
}
}
}
Unfortunately it does not work, because …
special = rootline does not support special.value.
data = leveltitle : 1 uses the ID of the current page, instead of the TMENU item ID.
Does anyone have another approach how I can get the title of the respective category using TypoScript?
Edit: Background information / what this is needed for
With this menu I intend to replace the news module ext:news of an existing project. Instead of news records, pages are now used and this menu creates the list view. Of course a TypoScript page browser will be added.
I would not rebuild the complete menu item generation (NO.doNotLinkIt = 1).
Just use NO.after.cObject = COA.
leveltitle : 1 is correct if you want to have the title for the current page.
The same if you show a rootline menu: it is generated for the current page.
If you want the levelfield for another page you need to build it by yourself.
In typoscript you might use a userfunction. (there is a core function for getting the rootline for a given page id)
If you generate your menu with FLUID you might use a viewhelper. (You might get inspired from this option of viewhelper menu.directory or this option of VH page.breadCrumb in ext:vhs.)
Edit:
you might store the needed information directly in the pagesrecord.
add a new field to the record (or use any unused).
then make sure that each category page contains some page TS_config:
TCADefaults.pages.<yourfield> = CategoryName
With this configuration each new page below will get this value set automatically.
Of course you need to set these values for all existing pages by hand or by some manual queries.
And if the editors are to be prevented from changing this value you need to remove the field from the edit form with this TSConfig on the top-page:
TCEForm.pages.<yourfield>.hide= 1
I have found a pure TypoScript solution that may not be very elegant, but it works:
lib.myMenu = HMENU
lib.myMenu {
special = updated
special{
value.field = 10,11,12
beginAtLevel = 1
limit = 99
}
1 = TMENU
1{
NO{
doNotLinkIt = 1
stdWrap.cObject = COA
stdWrap.cObject {
10 = TEXT
10{
wrap = <h3>|</h3>
field = seo_title // title
typolink.parameter.field = uid
}
20 = HMENU
20{
wrap = <div class="category">|</div>
special = list
special.value.field = pid
1 = TMENU
1{
NO{
doNotLinkIt = 1
stdWrap.override{
# Overwrite it if we are not yet at the category level
if{
# The ID of the page parent to the categories ("Website") is 1618
equals = 1618
value.field = pid
negate = 1
}
cObject = HMENU
cObject{
special = list
special.value.field = pid
1 = TMENU
1.NO.doNotLinkIt = 1
}
}
}
}
}
}
}
}
}
If the menu is to go over further levels, the override must of course be nested even deeper.
Edit – Improvements:
RECORDS instead of HMENU: Bernd Wilke suggested in the comments to use CONTENT instead of HMENU to generate the category title. This caused problems in my tests when sysfolders (as subpages of the categories) were used to structure the items. This could be related to the bug/feature #20933 (Enable working with SysFolders in CONTENT). But RECORDS might be comparable. I tried it and was able to improve the render times a little bit (see table below).
lib.myMenu.1.NO.stdWrap.cObject.20 = RECORDS
lib.myMenu.1.NO.stdWrap.cObject.20{
stdWrap.wrap = <div class="category">|</div>
source.field = pid
tables = pages
conf.pages = TEXT
conf.pages {
field = seo_title // title
stdWrap.override{
# Overwrite it if we are not yet at the category level
if{
# The ID of the page parent to the categories ("Website") is 1618
equals = 1618
value.field = pid
negate = 1
}
cObject = RECORDS
cObject{
source.field = pid
tables = pages
conf.pages = TEXT
conf.pages.field = seo_title // title
}
}
}
}
CONTENT instead of HMENU: if no sysfolders are needed (as of TYPO3 10.4 sysfolders should also work)
lib.myMenu.1.NO.stdWrap.cObject.20 = CONTENT
lib.myMenu.1.NO.stdWrap.cObject.20{
stdWrap.wrap = <div class="category">|</div>
table = pages
select {
uidInList.field = pid
pidInList = 0
selectFields = uid, pid, seo_title, title
}
renderObj = TEXT
renderObj {
field = seo_title // title
stdWrap.override{
# Overwrite it if we are not yet at the category level
if{
# The ID of the page parent to the categories ("Website") is 1618
equals = 1618
value.field = pid
negate = 1
}
cObject = CONTENT
cObject{
table = pages
select {
uidInList.field = pid
pidInList = 0
selectFields = uid, pid, seo_title, title
}
renderObj = TEXT
renderObj.field = seo_title // title
}
}
}
}
userFunc instead of HMENU: Bernd Wilke suggested in his answer to use a userfunction. Even if this is not a pure TypoScript solution, I would have liked to test it to be able to compare the performance. The method getRootLine() has unfortunately been marked as deprecated. Since I'm not an extension developer, it's not clear to me yet how to read the category via a userFunc and if this is actually more effective. If I still come across a solution regarding this, it will be added here.
Rendertime: I have test-implemented the menu in the live site (in the existing template) and compared the website render times with and without the output of the categories to see how much the nested menu affects the performance. The values are average values from 10 measurements. I also limited the output to 20 items, which should be a more realistic value per page later on:
mode
20 items
100 items
without category
99 ms
218 ms
categories via HMENU
133 ms
353 ms
categories via RECORDS
132 ms
331 ms
categories via CONTENT
121 ms
255 ms
categories via userFunc
TBD
TBD
You should neither use a separate HMENU nor a userFunc but a simple LOAD_REGISTER within the menu items of the parent level. This generates register entries, that can be added, changed or restored while looping through the different levels of the HMENU structure.
So you don't need the custom code of a PHP function and you won't get the performance penalty of a nested HMENU.
Basically it's shown in the official documentation, but with a CSS class instead of a title. But of course you could hand over other information from the parent to its children the same way.
Here is the example:
10 = COA
10 {
### left menu table column
10 = LOAD_REGISTER
10 {
ulClass = col-left
}
### right menu table column
20 = LOAD_REGISTER
20 {
ulClass = col-right
}
30 = HMENU
30 {
special = list
special.value = 1
1 = TMENU
# ...
3 = TMENU
3 {
stdWrap {
preCObject = COA
preCObject {
10 = RESTORE_REGISTER
}
dataWrap = <ul class="{register:ulClass}">|</ul>
}
wrap =
SPC = 1
SPC {
allStdWrap {
replacement {
10 {
search = ---
replace =
}
}
dataWrap = </ul>|<ul class="{register:ulClass}">
}
}
}
}
}
And here the link to the full documentation page:
https://docs.typo3.org/m/typo3/reference-typoscript/master/en-us/UsingSetting/Register.html

Typo3 10.4.4 Gridelements 10.0.0 extension not working

Hey I am pretty new to typo3 and I want to build a website.
I am running version 10.4.4 of TYPO3 with the bootstrap package installed.
I have tried to follow the guide on https://docs.typo3.org/typo3cms/extensions/gridelements/stable/
I have copied the TypoScript into my template setup, but there is no output on the frontend.
Remember I am new to this so I don't understand the TypoScript well yet.
So any ideas to what I could do?
EDIT:
I want to use GriElements so that I can create my own layouts on my page. The standard layouts are good but I need more freedom than what they offer.
I can get output on the frontend without GridElements, but when I use the extension only the content in the GridElements block wont show. If I remove the standard TypoScript from the example on the manual page for this extension i get an error saying "Oops an error occurred! Code:" and then a code that changes every time I update the page.
My TypoScript on my template looks like this:
page.includeCSS.1 = fileadmin/user_upload/template/css/fonts.css
page.includeCSS.theme = fileadmin/user_upload/template/css/custom-theme.scss
# plugin.tx_bootstrappackage._LOCAL_LANG.da.readmore = test (NOT WORKING)
# https://docs.typo3.org/m/typo3/reference-coreapi/10.4/en-us/ApiOverview/Internationalization/ManagingTranslations.html
page.meta.robots = noindex, nofollow
page.meta.robots.replace = 1
page.10.partialRootPaths.3 = fileadmin/user_upload/template/partials/ContentElements/
page.10.partialRootPaths.4 = fileadmin/user_upload/template/Partials/Page/
page.10.dataProcessing.10.levels = 3
page.includeJSFooterlibs.bootstrap_navbar = fileadmin/user_upload/template/js
page.includeJSFooterlibs.bootstrap_navbar = fileadmin/user_upload/template/js/navbar.js
lib.contentElement.partialRootPaths.20 = fileadmin/user_upload/template/partials/ContentElements/
lib.contentElement.partialRootPaths.20 = fileadmin/user_upload/template/Partials/ContentElements/
lib.gridelements.defaultGridSetup {
// stdWrap functions being applied to each element
columns {
default {
renderObj = COA
renderObj {
# You can use registers to i.e. provide different image settings for each column
# 10 = LOAD_REGISTER
20 =< tt_content
# And you can reset the register later on
# 30 = RESTORE_REGISTER
}
}
}
# if you want to provide your own templating, just insert a cObject here
# this will prevent the collected content from being rendered directly
# i.e. cObject = TEMPLATE or cObject = FLUIDTEMPLATE will be available from the core
# the content will be available via fieldnames like
# tx_gridelements_view_columns (an array containing each column)
# or tx_gridelements_view_children (an array containing each child)
# tx_gridelements_view_column_123 (123 is the number of the column)
# or tx_gridelements_view_child_123 (123 is the UID of the child)
}
lib.tt_content.shortcut.pages = COA
lib.tt_content.shortcut.pages {
10 = USER
10 {
userFunc = tx_gridelements_view->user_getTreeList
}
20 = CONTENT
20 {
table = tt_content
select {
pidInList.data = register:pidInList
where = colPos >= 0
orderBy = colPos,sorting
orderBy.dataWrap = FIND_IN_SET(pid,'{register:pidInList}'),|
}
}
}
tt_content.shortcut.5 = LOAD_REGISTER
tt_content.shortcut.5 {
tt_content_shortcut_recursive.field = recursive
}
tt_content.shortcut.20 {
0 {
tables := addToList(pages)
conf.pages < lib.tt_content.shortcut.pages
}
1 {
tables := addToList(pages)
conf.pages < lib.tt_content.shortcut.pages
}
}
tt_content.gridelements_pi1 >
tt_content.gridelements_pi1 = COA
tt_content.gridelements_pi1 {
#10 =< lib.stdheader
20 = COA
20 {
10 = USER
10 {
userFunc = tx_gridelements_view->main
setup {
default < lib.gridelements.defaultGridSetup
}
}
}
}
The statics i included is:
Bootstrap Package: Full Pacakage (bootstrap_package)
Bootstrap Package: Bootstrap 4.x (SCSS) (bootstrap_package)
XML Sitemap (seo)
Gridelements w/DataProssing (recommended) (gridelements)
Gallery (bm_image_gallery)
EDIT2:
New TypoScript with DataProcessing
lib.gridelements.defaultGridSetup =< lib.contentElement
lib.gridelements.defaultGridSetup {
templateName.field = tx_gridelements_backend_layout
templateName.ifEmpty = GridElement
layoutRootPaths {
1 = EXT:gridelements/Resources/Private/Layouts/
}
partialRootPaths {
1 = EXT:gridelements/Resources/Private/Partials/
}
templateRootPaths {
1 = EXT:gridelements/Resources/Private/Templates/
}
dataProcessing {
10 = GridElementsTeam\Gridelements\DataProcessing\GridChildrenProcessor
10 {
default {
as = children
# Default options of the grid children processor
# Change them according to the needs of your layout
# Read more about it in the TypoScript section of the manual
# options {
# sortingDirection = ASC
# sortingField = sorting
# recursive = 0
# resolveFlexFormData = 1
# resolveBackendLayout = 1
# respectColumns = 1
# respectRows = 1
# }
}
}
}
}
My includes:
Fluid Contetn Elements (fluid_styled_content)
Fluid Contetn Elements CSS (fluid_styled_content)
Bootstrap Package: Full Pacakage (bootstrap_package)
Bootstrap Package: Bootstrap 4.x (SCSS) (bootstrap_package)
XML Sitemap (seo)
Gridelements w/DataProssing (recommended) (gridelements)
Gallery (bm_image_gallery)
The error I get:
Tried resolving a template file for controller action "Standard->3" in format ".html", but none of the paths contained the expected template file (Standard/3.html). The following paths were checked: /httpdocs/typo3conf/ext/bootstrap_package/Resources/Private/Templates/ContentElements/, /httpdocs/typo3conf/ext/gridelements/Resources/Private/Templates/
You probably missed to include the static template of gridelemnts. To do so edit your TS-Root-Template, select in the dropdown at the top "Info/Modify", hit the button "Edit the whole template record", go to tab "Includes" and select gridelements static setup in the Multiselect box on the right.
Please provide more information:
Which static templates have you included at all? Maybe you forgot to include fluid_styled_content?
How does your Typoscript/Flexform setup look like?
For what do you need gridelements?
EDIT: bootstrap_package did not very well together with gridelements in the past. Maybe you should first try to install Benjamin Knott's extension autogrids (see this issue on github for more information)
EDIT 2: Try this Typoscript, it just wraps a section around all elements but maybe you will then see your content in the frontend:
tt_content.gridelements_pi1.20.10.setup {
section < lib.gridelements.defaultGridSetup
section {
wrap >
dataWrap = <section id="c{field:uid}">|</section>
}
}
SOLVED:
I installed an extension that is called "Grids for bootstrap" included it in the template and it worked.
Thnaks for all the help you guys gave!
I think your problem is coming from your fluid code for gridelemnts, you didn't use the right syntax maybe.

Check field on parent page in TMENU?

In a TMENU, can I check the value of a field on the parent page?
I want to do something like this:
lib.mymenu = HMENU
lib.mymenu {
entryLevel=0
1 = TMENU
1 {
...
}
2 < .1
2 {
NO {
stdWrap.wrap {
if.equals.field = parent:myfield
if.value = 1
cObject < lib.specialmenu
}
}
}
}
Does the parent mean the item of the first level in this case? Or in other words: a field in the record which UID is the PID of the current item?
Then, there's a (german) blogpost on how to get dynamically fields via stdWrap:
https://blog.marit.ag/2009/12/15/datenbankfelder-stdwrap-data/
guess you have to implement a custom menuprocessor, or try at least a fluid version of your menu. in plain typoscript i dont know a solution for this.
this link may help you for my suggestion: https://docs.typo3.org/m/typo3/tutorial-sitepackage/master/en-us/MainMenuCreation/Index.html

Typo3 Fluid Templates - How to set up different templates for different pages

I'm trying to build from scratch a website with typo3 9.5 and setting up different template files for different pages. How do I achieve this?
I'm following the tutorial from https://docs.typo3.org/m/typo3/tutorial-sitepackage/master/en-us/TypoScriptConfiguration/Index.html and also tried the solution with no success provided at Typo3 Fluid Templates How to add multiple templates
Now all pages load the Default template and if I set the default cObject to Alternative, it loads the Alternative.html to all pages, even when the TCA at Typo3 is set correctly for each page:
All Pages Back-end Layout to [Default]
Contact set to [Alternative].
_
page = PAGE
page {
typeNum = 0
// Part 1: Fluid template section
10 = FLUIDTEMPLATE
10 {
templateName = TEXT
templateName.stdWrap.cObject = CASE
templateName.stdWrap.cObject {
key.data = pagelayout
pagets__default = TEXT
pagets__default.value = Default
default = TEXT
default.value = Default
pagets__alternative = TEXT
pagets__alternative.value = Alternative
alternative = TEXT
alternative.value = Alternative
}
templateRootPaths {
0 = EXT:photo/Resources/Private/Templates/Page/
1 = {$page.fluidtemplate.templateRootPath}
}
partialRootPaths {
0 = EXT:photo/Resources/Private/Partials/Page/
1 = {$page.fluidtemplate.partialRootPath}
}
layoutRootPaths {
0 = EXT:photo/Resources/Private/Layouts/Page/
1 = {$page.fluidtemplate.layoutRootPath}
}
dataProcessing {
10 = TYPO3\CMS\Frontend\DataProcessing\MenuProcessor
10 {
levels = 1
includeSpacer = 1
as = mainnavigation
}
}
}
I want to use for instance a default.html template for all pages except contact page, which will have it's own template ( site_template/Resources/Private/Templates/Page/Alternative.html ).
First:
you should use higher numbers for the paths to your templates.
The higher the number the higher the priority for overriding files with the same name.
second:
there is no field pagelayout. either use layout or better backend_layout and backend_layout_next_level (example configuration with the full usage of configuration for subpages).
Your key values (pagets__default and pagets__alternative) already hint to the usage of backend_layout (pagets__* is the usual key for backend layouts defined in page TSconfig).
Probably the example in the documentation needs some correction. (Pull-request commited)

typoscript backend_layout_next_level not working

I have the following config
page = PAGE
page {
typeNum = 0
10 = FLUIDTEMPLATE
10 {
templateRootPath = EXT:folder/Resources/Private/Website/Templates/
partialRootPath = EXT:folder/Resources/Private/Website/Partials/
layoutRootPath = EXT:folder/Resources/Private/Website/Layout/
file.stdWrap.cObject = CASE
file.stdWrap.cObject {
key.data = levelfield:-1, backend_layout_next_level, slide
key.override.field = backend_layout
default = TEXT
default.value = whatever.html
1 < .default
2 = TEXT
2.value = whatever-else.html
}
}
Somehow the 'backend_layout_next_level' is not working; it is not sliding down the tree. As a result I have to set a backend_layout for each page which is not what one should expect.
Is there a way of knowing/debugging/finding out what's causing this? I thought it might be something related to a curly brace being in the wrong place (too early, too late or just plain wrong) inside my typoscript. Therefor I looked inside the Typoscript Template Analyzer and found some errors which I've fixed, but the problem still persists.
Thanks already!
Best regards
You use have to give the full path to the file as a value in the .file property or you should use .templateName instead and only provide the name (case sensitive!!!) of the template file without suffix.
#see https://docs.typo3.org/typo3cms/TyposcriptReference/ContentObjects/Fluidtemplate/Index.html
Note that in your current setting, the uid of the template record must be 1 or 2.
And you can try to use levelfield: -2 instead of levelfield: -1.
TBH I never understood this #^$#% CASE syntax... Therefore definitely prefer common condition which works perfect, you must to add custom condition like I showed in other post, so you can use it like:
page {
typeNum = 0
10 = FLUIDTEMPLATE
10 {
templateRootPath = EXT:folder/Resources/Private/Website/Templates/
partialRootPath = EXT:folder/Resources/Private/Website/Partials/
layoutRootPath = EXT:folder/Resources/Private/Website/Layout/
file = whatever.html
}
}
[userFunc = user_beLayout(2)]
page.10.file = whatever-else.html
[userFunc = user_beLayout(3)]
page.10.file = yet-other.html
[userFunc = user_beLayout(4)]
page.10.file = etc.html
[end]
Edit - to satisfy some comments
Note: When I say that I don't understand CASE syntax, that doesn't mean that I don't know it... especially that I studied it in details not once, here's the conclusion...
About performance:
Custom conditions solution is faster than using CASE and slide combination as it doesn't involve additional DB queries (slide does), it iterates $GLOBALS['TSFE']->page array, which is already collected, and stops further checks ASAP, so it's cheaper than slide which makes additional queries if it finds slide in TS (doesn't matter if it's required or not) - (examine the code for slide mechanics), so actually conditions are performance-saver not killer :)
Yet more
Using conditions blocks you can change behavior of multiple elements at once (instead writing separate CASE for each) i.e.:
[userFunc = user_beLayout(2)]
page.10.file = whatever-else.html
lib.genericMenu >
config.absRefPrefix = /layout-specific-abs/
// etc...
[end]
Using CASE syntax you'll need to repeat all these checks for each element... (where's DRY?)
Finally
Both solutions are ... usable especially when using with cached pages, (difference between them will be about teens or maybe in drastic situation hundred milliseconds -conditions will be faster), for uncached pages most probably it will be good idea to set be_layout directly for each pages record in both cases.
It is quite some time ago, you probably resolved your issue but here is a working approach:
page = PAGE
page {
10 = FLUIDTEMPLATE
10 {
# select different html files for layouts - ref: backend_layout
file.stdWrap.cObject = TEXT
file.stdWrap.cObject {
data = levelfield:-2,backend_layout_next_level,slide
override.field = backend_layout
split {
token = pagets__
1.current = 1
1.wrap = |
}
wrap = EXT:folder/Resources/Private/Templates/|.html
}
layoutRootPath = EXT:folder/Resources/Private/Layouts/
partialRootPath = EXT:folder/Resources/Private/Partials/
}
}
or you can pass it as a variable:
page = PAGE
page {
10 = FLUIDTEMPLATE
10 {
file = EXT:folder/Resources/Private/Templates/Main.html
layoutRootPath = EXT:folder/Resources/Private/Layouts/
partialRootPath = EXT:folder/Resources/Private/Partials/
variables {
# BE_Layout
BE_Layout = COA
BE_Layout {
stdWrap.cObject = TEXT
stdWrap.cObject {
data = levelfield:-2,backend_layout_next_level,slide
override.field = backend_layout
split {
token = pagets__
1.current = 1
1.wrap = |
}
wrap = |.html
}
}
}
}