Bug #87452
closed
Page Slug generation doesn't take path of parent SysFolders into account
0%
Description
Problem/Description¶
If I create a SysFolder "Sessions" within following SysFolder structure Storage -> 2019 -> Sessions (each of them successively) then the page slug /sessions is automatically added to this SysFolder.
It's now only possible to add a normal page in the root of the site with /sessions if I adapt the previous added SysFolder on path Home/Storage/2019/Sessions.
Thoughts¶
- Is it really necessary to exclude parent sysfolder pages from the automatic page slug creation?
- Can this behaviour be customized/configured
- From my actual perspective this should be adopted to make the integrator/editor life more shiny
What do you think about?
Updated by Josef Glatz almost 6 years ago
- Subject changed from Page Slug generation doesn't take path of SysFolders into account to Page Slug generation doesn't take path of parent SysFolders into account
Updated by Wolfgang Twaroch over 5 years ago
A solution for respecting all page types in URL generation and adding a checkbox at page level to exclude this can be found at https://github.com/b13/masi
Updated by Frank Nägler about 5 years ago
SlugHelper::resolveParentPageRecord is skipping the folder, the comment of the method says:
Fetch a parent page, but exclude spacers, recyclers and sys-folders and all doktypes > 200
I am not sure if this behavior is intended.
Updated by Anonymous about 5 years ago
"Is it really necessary to exclude parent sysfolder pages from the automatic page slug creation?"
Well realURL did so. If we migrate a project from realURL we can not simply take the folders into the path!
At least there has to be a setting to enable it, OR Folders should not have slugs at all! Because they are not used but blocking pages from getting the path.
Contact[folder] -> Slug: /contact
Contact[page] -> Slug: /contact-1
Updated by Christian Eßl over 4 years ago
- Related to Bug #86456: Skip special doktype parent pages in slug generation added
Updated by Christian Eßl over 4 years ago
- Related to Feature #86216: Allow empty slug for root pages and sysfolders added
Updated by Christian Eßl over 4 years ago
The changes made in #18079 now lifted the restrictions in PageRepository that were present for all doktypes > 200.
This should also be lifted for SlugHelper::resolveParentPageRecord() that currently excludes any page >= 199.
- DOKTYPE_SPACER (199)
- DOKTYPE_SYSFOLDER (254)
- DOKTYPE_RECYCLER (255)
However I think it should be configurable for DOKTYPE_SYSFOLDER, if a sysfolder slug should be added to a child page or not. Currently, pages of doktype sysfolder even show the "slug" field, although it is not used...
Updated by Christian Eßl over 4 years ago
- Related to Task #90947: Lift doktype restrictions in SlugHelper::resolveParentPageRecord added
Updated by Benni Mack over 4 years ago
- Status changed from New to Rejected
Hey all,
the behaviour as defined is intended. If you want to have sysfolders as part of the slug that is generated for a subpage included, check out Extensions such as EXT:masi https://github.com/b13/masi - 80% of the sysfolders are folders like "Meta navigation" etc where a slug added is tedious and a pain to reconfigure. However, EXT:masi provides such as solution.
The point is: TYPO3 Core is flexible enough to support such features, however it does not ship all features that people need, in order to reduce the number of "options" available for regular editors.