Feature #87844
closedAdd option to exclude pages from speaking url
0%
Description
Add a option to exclude pages from speaking url (slug), if the page is not the current page.
This feature is necessary for every installation that used realurl in the past.
Links to e.q. landingpages may don't work anymore, if a installation upgrades from 8.7 with realurl to 9.5 with native url handling.
If this feature would be developed, the upgrade wizard "PopulatePageSlugs" should be extended to set the exclude flag on upgrade.
Updated by Chris Müller over 5 years ago
I think this feature isn't needed, because you can set the slug of the page individually. Take for example the structure:
page-1
page-1 -> subpage-1-1
page-1 -> subpage-1-2 -> subsubpage-1-2-1
You can change your slug e.g. to
/subpage-1-2 instead of /page-1/subpage-1-2
so that page-1 isn't shown in slug for subpage-1-2
Any subsequent pages of subpage-1-2 will also omit page-1, because the slug of the parent page is taken into account when generating a new page under subpage-1-2.
This behaviour is more flexibel than with RealURL, because you can change the complete slug of the page, not only the segment of the page (where you need a possibility to omit a segment).
To make it short, just set the slug of your landing page to the slug you want. That's it.
Updated by Patrick Lenk over 5 years ago
For new projects you are absolutly right.
But at least a update solution for projects with used exclude function of realurl over several years on thousands of pages could/should be shipped with 9.5.
Updated by André Buchmann over 5 years ago
For your example it works!
But if you want subpage-1-1 or subpage-1-2 to be excluded from speaking url, you have to edit every slug on third level.
I think it's bad to say the editor has to care for this.
Updated by Sebastian Krikke over 5 years ago
I think even for new projects this is a nice to have feature.
When editiors create new pages and in-between Page segment schould not be shown then the editor has to edit the slug every Time they create a page.
In that regard it would be much easier to simply tell the parent page to not show in a slug, so that editors don't have to bother with the slug.
Another Point is, when you use sluggenerator (for example: 3rd-Party extensions) so rearrange the whole page tree after an upgrade. Here you need to go into every Page to press the refresh button and modify the Slug after. it would be much more comfortable to exclude some specific pages and let the rest autogenerate.
Updated by Benni Mack over 5 years ago
- Target version changed from next-patchlevel to Candidate for patchlevel
Updated by Benni Mack over 5 years ago
- Status changed from New to Needs Feedback
Hey everybody,
it's not possible for us to build such a solution in TYPO3 v9 as it would require to modify the database, which I agreed to not do again after 9.5.5 (due to some hundreds of installations with auto-updates breaking as there was a missing DB field).
So, what I've built was a hook within the Slug Generation which can take care of this:
So, it should be fairly easy to create an extension to handle all custom specifications needed for an extension author. Hope this helps. If there are well-proven extensions we can look into that for adding this to TYPO3 v10. If there are any extensions available, let me know.
Sorry for the inconvenience on handling it for TYPO3 v9.
Benni.
Updated by Benni Mack over 5 years ago
- Related to Feature #88198: Allow modifications of Slugs by Hooks added
Updated by Patrick Lenk over 5 years ago
Thanks for the transparent and professional solution. Looking forward to third party extensions on this feature.
Updated by Christian Hackl over 5 years ago
It should be possible because (e.g. a extension with list and detail/show page):
a) Length of the URL for SEO
b) 'detail/show' as detailpage-title is not a (SEO-)category
c) Sometimes you do not know exactly how to name a "detail" page - cause of its content which is a direct child-category from the list-page... belongs to b)
d) IMPORTANT Independent content of the list page (ie anything that does not belongs to the plugin) should not appear on the detail page (SEO - DuplicateContent), in addition, the user must scroll again (Current solution one plugin/page for list and detail view)
e) and so on
Sorry but i don't know how to fix this with your hook @Benni Mack Mack ?
I believe in TYPO3 version 9.4, at least before 9.5.5 it was possible to do something like this in the routeEnhancers in the yaml config ('/../'):
-
routePath: '/../{news_title}'
_controller: 'News :: detail'
_arguments:
news_title: news
That worked great too, can you reinstall that please?
Updated by Patrick Lenk over 5 years ago
I tried https://github.com/b13/masi and it worked so far, except from the migration command. I migrated the db fields with db admin. It is currently not available via packagist or ter.
Updated by Riccardo De Contardi about 5 years ago
- Related to Bug #89487: Set pageTypes to ignore for slug generation added
Updated by Benni Mack over 4 years ago
- Status changed from Needs Feedback to Closed
Christian Hackl wrote:
Sorry but i don't know how to fix this with your hook @Benni Mack Mack ?
See this extension "masi" which uses the hook and adds the actual feature request from this ticket https://github.com/b13/masi
I believe in TYPO3 version 9.4, at least before 9.5.5 it was possible to do something like this in the routeEnhancers in the yaml config ('/../'):
-
routePath: '/../{news_title}'
_controller: 'News :: detail'
_arguments:
news_title: newsThat worked great too, can you reinstall that please?
That adds more conflicts "..". I never tried it, and if it was possible, we would need a proper description for that.
In any case, I'm closing this issue (comments still welcome - possible still on this ticket) as this feature can be added as third-party extension (see above). I don't believe that TYPO3 Core (especially v9) needs to ship all features that RealURL had in the past, but should provide options / hooks to make this possible via third-party integration - depending on their use case. RealURL's "exclude this page from the URL segment" had several conceptual problems (esp. in multi-language handling) when added by Kasper for v4.x. This was just never taken into account because it was built-in already and people used it.