Bug #89450
closed
Slug of page of type "Link to external URL" should be ignored
0%
Description
Scenario:
- Page "My Page" shows a detail view of a single record, e.g. "My News".
- Slug is generated as "/my-page/my-news".
- Editor adds a page of type "Link to external URL" and wrongly enters "/my-page/my-news" as its slug (he doesn't know better :) ).
Impact:
The editor achieves to run into a duplicate slug which causes a 404 or redirect loop.
The scenario is one that could happen in other constellations too, sure. But in this constellation it does not make sense to even consider the page's slug, as the page's link surrogate is the external URL anyway. The slug of that page type could be ignored or even hidden/nulled.
By not taking a "Link to external URL"'s slug into consideration the error could be prevented at at least one place.
Updated by
Updated by Benni Mack about 5 years ago
Hey.
I see your issue, however if we make "slug" field empty for page dokype=3, we have problems as e.g. menus are using the link (and not using the target directly, there are other issues related to that topic).
In addition, not having "slugs" for every page, will result in quite some other side effects.
However, there is another caveat: If you change your doktype (similar to tt_content.CType and other TCA functionality with fields) the "old" values are kept, thus, making this field "invisible".
So, a couple of ideas on how to approach this issue in general:
- First: We could/should add a consistency URL checker - finding duplicates based on exact this topic. Ensuring that your TYPO3 installation does not have such loop holes. Same also applies to redirects: If you have a sys_redirect to "/my-page/my-news" to something else - you're doomed as well. So this should be tackled.
- Merge together DOKTYPE shortcut and external URL, allowing to have a link selector for shortcut (to any kind of record or page, as well as external pages) - there is also an issue about this topic available already
- Build links to external pages (doktype=3) directly to use the external links at ANY time - this might break functionality (in the past, this was related to jumpurl and link tracking, to know if a page was still "in use")
- Last - and to simply overcome your described issue: we could prepend DOKTYPE=3 slugs automatically with "external-" in each slug. This is a workaround, but also fairly easy to achieve in a single place.
Updated by Andreas Kießling over 4 years ago
Any news on that? While testing an upgrade from 8.7 to 9.5 i found some issues with migrated realurl paths: shortcuts received the correct slugs, while the real pages got a "-1" suffix
Updated by Benni Mack over 4 years ago
Andreas Kiessling wrote:
Any news on that? While testing an upgrade from 8.7 to 9.5 i found some issues with migrated realurl paths: shortcuts received the correct slugs, while the real pages got a "-1" suffix
Hey Andreas,
this would be another issue, right?
Updated by Andreas Kießling over 4 years ago
Hi Benni,
seems like i picked the wrong issue for my commend, sorry.
My problem was that the shortcuts were used in such a page structure so that the resulting complete urls were identical to the actual pages -> "-1" was appended
I simply duplicated the slug generator to exclude shortcuts, then the core migrator generated the remaining ones. If you don't have such a structure, you probably won't run into this error.
I can open another issue for that, but i don't think its worth spending a lot of time on it.
Updated by Benni Mack over 4 years ago
- Status changed from New to Closed
Andreas Kiessling wrote:
I can open another issue for that, but i don't think its worth spending a lot of time on it.
Yeah, I agree. I'll close this one for the time being.