Handling redirects unified and in a proper way in TYPO3

(Benni Mack) #1

Discussion Topic

I’d like to give you a rundown on my idea for redirects that should be handled natively within TYPO3 core.

The pains:

In the process towards a good base for speaking URLs, the “sys_domain” record and its logic seems very odd to me - as it is right now, but the whole topic is a different one (e.g. different domains for an environment, 404 pages etc.). Right now, having multiple sys_domain records and 9 of 10 records a redirects to the main domain seems stupid and odd to me.

Then, we have extensions that do redirects already:

Additionally, if we ever want to handle “I rename a page, but it should be available the next 90 days”, we would need proper redirects available handling that.

If SEO people come around and want short URLs, the core can do that.

A proper Backend module for handling redirects (to a page ID) + an efficient solution (so no additional SQL queries are made in FE, having everything in a cache) to deal with them should be shipped with the core.

I hereby propose to add a system extension “redirects” (part of factory default) with a backend modules with the most important features and a nice UI should be part of that.

Yes, for all the server fans, we can create a “Export as htaccess rules” button for apache and/or nginx, but the management part should be part of the Core.

Impact

  • A new backend module in a new system extension “redirects” (luckily I have this extension key)
  • Removing redirect logic from “sys_domain” (with an upgrade wizard)

Possible Migrations

  • Upgrade wizard to install this extension, and to migrate sys_domain redirect records.

Pro

  • sys_domain does not handle redirects anymore
  • A good basis for dealing with renaming / deleting pages for Speaking URLs in the core
  • A nice UX goodie for all marketeers

Con

  • Another core feature :frowning:

Remarks and notes

I would actually add a new main module (“Marketing”) where “redirects” is anchored, and SEO-related functionality can be added as well later on.

Organizational

Topic Initiator: Benni Mack
Topic Mentor: Benni Mack

(Richard Haeser) #2

I really like the idea and I think it is good to have this in core. One of the things that is important is to have a good user interaction. So when you move a page, you do get a “popup” asking to automatically create a redirect.
Another important thing is that the amount of days that the redirect should be available should be configurable. We as a company, would prefer the redirects are not expiring at all for example.

Will share some more thoughts later on this week, but for now I really like the idea and when doing this step by step will give TYPO3 a very needed new feature!

(Riccardo De Contardi) #3

I think I like the idea, too

Umm… I wonder what would happen especially in a development scenario, when maybe you don’t have a clear idea of what your pagetree should look like and you move or rename pages very often…
I would prefer a way to disable it (for example,as I said, in development context)

I am not an expert on this topic, so maybe I am writing a stupid thing: would it be possible to write the redirects in the .htaccess (or equivalent) file?

(Richard Haeser) #4

I think it should be configurable for the whole installation (so you can for example only enable it on production environments) but maybe also on a user base.

Not everyone is using Apache as a webserver. There are several ways to do that, but maybe this option to export should be a version 2 thing to not make the feature to big.

(Riccardo De Contardi) #5

that’s why I wrote “or equivalent” (web.config for IIS etc) :slight_smile:

(Richard Haeser) #6

Yes I know, but because there are a lot of equivalents, I don’t think we should focus on that for now. Just have a PHP-redirecter as default for now and adding export possibilities in the future will be fine for now.

(Riccardo De Contardi) #7

I accept the remark, I should have been more specific :slight_smile:

Ok. +1

I was just visualizing something like a module that gives a report of all the “problematic” urls and writes the proper webserver config with one click. As you said, maybe in the future :wink:

P.s. I remember on this topic an old post by Dimitry Dulepov (alas, not available online anymore)

(Frans Saris) #8

A UX wise nice backend module would indeed be a requirement.

But maybe also some visible representation in the page tree like in https://extensions.typo3.org/extension/url_forwarding/

(Mathias Brodala) #9

I’d love to have this as a native feature in TYPO3.

One thing which could be very useful is using a link field for the target URL. This way one can easily pick a page, content element, even a custom record or an external URL as usual. However, we’d need a solution for generating URLs for FE in BE here. Alternatively the link URN could be resolved to the final URL upon request but that will always be slower. If you use a cache, you have to think about proper invalidation again.

A few other remarks:

I would actually add a new main module (“Marketing”) where “redirects” is anchored, and SEO-related functionality can be added as well later on.

Why “Marketing”? This is an essential feature which covers so many non-marketing areas, thus “Web” would make much more sense.

One of the things that is important is to have a good user interaction. So when you move a page, you do get a “popup” asking to automatically create a redirect.

I’d avoid that. It would be better if redirects are created automatically upon renaming/moving pages similar to what RealURL does currently.

(Richard Haeser) #10

To be honest, I don’t like the visible representation in the page tree. With a single redirect it can be fine, but with a lot of redirects your page tree will be quite a mess. You don’t want to “bother” a normal user with this information in my opinion.

(Richard Haeser) #11

First of all, I think this part should be out of scope for an MVP, but for a second version:

I think this should be a setting for a user. In our case our editor do want to choose which http code will be used to redirect.

It is even better to not change the URL by default. In WordPress they thought a long time on this and there the slug stays the old slug until you actively changed it to another slug. When you do that you can ask the user to make a redirect with a specific http-code. I checked this with the guys of Yoast and they say exactly the same. For your SEO you want to change your url as little as possible.

(Jigal Van Hemert) #12

Regarding the types of redirects we should handle I think it shouldn’t be restricted to only pages:

  • Pages
  • Files
  • External URLs (use case: page is now in a different server of the same organization)
  • Records (we have linkhandler in the core!)

The export can be extensible so other target platforms can be added later on (or by third party exts).

The efficiency of doing redirects inside the CMS is already questionable. The whole webserver-PHP-database stack is already fully running before a simple redirect is issued. Of course we shouldn’t have more processing than absolutely necessary. The mentioned export functionality would really help, although it would not be usable for everyone and in all cases. Support for both methods is indeed a good way.

(Patrick Broens) #13

As the publisher of url_forwarding I would definately like to have this functionality in the core.

My extension is using the first hook available, so not everything is fully running, unlike the old redirect functionality of realURL, which was at the end of the process (was triggered just before “page not found”). It is used on the website of the Technical University of Eindhoven, which is quite large. For them it is working out very well. One of their websites almost has 1000 redirects, mostly used as kind of shortcut.

Redirect functionality should only be there for redirecting, like using some kind of shortcuts. The handling of modified pages should be done by the routing/path handling, like realURL (already does) or core solution. Old URL’s should be handled as much automated as can be. An editor should not be bothered much when renaming or moving a page.

True, it should be extensible. url_forwarding also has, for instance, the possibility to replace a part of a path. But this is added to handle renamed or moved pages which have a lot of subpages. Like I said, this should be handled by the path handling/routing automatically, if possible.

As Mathias Brodola is already mentioning, this is not only for marketing, but covers much more.

Sometimes it is really helpful. Since I’m using dedicated records for the redirects, you don’t have a clear overview in the page tree which page contains a redirect. With this option you can make this visible. Maybe have the possibility to turn it on/off for certain backend user groups?

Somehow this should also be incorporated/linked in SEO tools, like Yoast SEO for instance for the page slug.

I am still uncertain if dedicated records are needed for page redirects, or should be handled directly in the page properties.

A proper BE module is needed to maintain the redirects.

(Andreas Fernandez) #14

What about an additional entry in a page’s context menu called “Redirects” that either opens a modal or opens the record list, both listing the stored redirects for that page.

(Andreas Wolf) #15

I think this is crucial information for designing the new URL handling. Thanks for that! :slight_smile:

(Richard Haeser) #16

I think that can be a solution indeed. But this is “new” ux so we have to decide if a new ux only for this option is the way to go. I’m not afraid of changes and to start somewhere, but this behaviour should be used in several other parts as well so it is not “strange” for a backenduser.

(Alexander Opitz) #17

For redirecting I’d like more an approach that can handle a Apache RewriteMap/Nginx map_module

For the visual representation, I didn’t tried url_forwarding yet, maybe as new module with it’s own tree design.

(Richard Haeser) #18

I’m totally with you with the rewrite maps and map_module. The only thing is that you always has to have a fallback because not everyone have the possibility to use that.

This is a first step towards “speaking urls” in core. If we make this function to big, it can affect the real function where we all are waiting for. So as a MVP-version I would say: just the PHP-redirecter and go on with the next step towards the speaking urls. As a side project the export / integrations to Apache / Nginx can be done.

But that’s just my opinion :wink:

(Benni Mack) #19

This topic was automatically closed after 14 days. New replies are no longer allowed.