Release: Redirects

[cb2004]

Would be nice if this was supported in the core as well in the settings tab. I setup my redirects in there now and use the 404 logger module as that seems to cater for my current needs when rebuilding a site

[benbyf]

On 6/20/2020 at 11:21 PM, cb2004 said:

Would be nice if this was supported in the core as well in the settings tab. I setup my redirects in there now and use the 404 logger module as that seems to cater for my current needs when rebuilding a site

yeah, core redirects would make sense, something that I can imagine seems common enough and can link in with the tracking of page url changes and redirecting.

not sure I understand how you're doing it, can you explain?

[cb2004]

@benbyf I am not sure what version this was added, but if you have 'PagePathHistory' installed, if you go to the 'Settings' tab in a page, you have 'What other URLs redirect to this page?' section. I then use https://modules.processwire.com/modules/process404-logger/. On big sites, I would still potentially use Jumplinks as a power tool.

[teppo]

Hey folks!

Just wanted to mention that ProcessRedirects 2.0.0 is now out. As far as I can tell it should fix most of the issues that have been reported here, as well as those reported via GitHub. This is a major update and the module now requires ProcessWire 3.0.112+ and PHP 7.1+, so please keep that in mind if and when updating ?

Here's a kind-of-a-changelog for this release from the PR that got merged earlier today:

Quote

• Mechanism for keeping track of and updating database schema.
• Various GUI updates, including more JavaScript based checks, the use of vex dialogs and ProcessWire panels (for redirect testing), and a brand new export view.
• Support for wildcard redirects by adding special meaning to star symbol (/path-to-*/subpath/ etc.)
• Proper CSRF checks.
• Switch from MySQLi to PDO.
• ProcessWire 3.x namespace (hence module version 2.x, this alone would be a breaking change.)

... and some overall updates and "modernizations".

In case anyone is wondering why update this module now even though we already have a very powerful alternative (Jumplinks), the thing is that this module still serves a purpose: it's super easy to use, and does what it needs to do — no more, no less. Powerful features can be a double-edged sword, as they also tend to increase complexity, at least to some extent. When it comes to "power users", Jumplinks is by far a superior tool, but for regular content editors who just need the occasional shortlink (or something similar), this module is often just the right fit.

Hope that makes sense. Anyway, I still have some relatively minor additions in mind that I'd like to add to the module (assuming that Antti thinks they are a good fit), but again, for the most part this module already does what it needs to. Power users will likely feel more at home with Jumplinks ?

If you find a bug or have a feature in mind that this module really needs to have, feel free to open an issue at the GitHub repository. Thanks!

[KarlvonKarton]

I have a problem with the redirects:

I have one redirect:
/site/be/en/ ->/projects/belgium/

But when I add another one like under, then I get error "The Redirect From URL already exists as a page path. Redirect not added. "

/site/be/nl/ -> /nl/projects/belgium/

Why is this?

[strandoo]

Hi all. I've used this module loads of times but I'm having a problem now. I've imported a long list of redirects that I've grabbed from a sitemap.xml file. They imported fine and looked good. When I came back a few days later, many (if not most) of the 'redirect to' entries turned into 5 digits preceded by a carat character (^). See screen shot. I've tried a few times since, including pasting in the list in small chunks. Any idea what is going on?

[tomasanjosbarao]

Most of the times I use redirects for temporary purposes, usually for short links that should change over time (for example, `https://mysite.org/conference-signup`). So it was important for me that this module could redirect with other status codes, mainly 302, instead of 301.

I haven't created any ProcessWire modules yet, but I decided to try and improve apeisa's module, and I got it to work like I wanted, so I thought I should contribute this to the community. I know I should make a pull request, but I'm not experienced in git yet and I have little time now, so the best I can do now is leave here the file for you to see if you want. I'm sorry for this.

I added a column "status" to the table process_redirects, like this:

`status` enum('301','302','303','307') NOT NULL DEFAULT '302',

I only used the status codes specified on the documentation for $session->redirect. In future I'd like to specify them in a constant or static property (not sure), and then use it to generate the options in the edit form.

I haven't bumped version, and I'm not sure how to procceed about updating the database schema.

Could you have a look, please?

ProcessRedirects-tomasanjosbarao.module

[Boost]

Hei @apeisaIs it possible for me to give an user the permission to create redirects or is it just superuser? 

I can not see the permission for redirect here.

[Stefanowitsch]

@apeisa I am using this module on a page and I am getting this error in my log frequently:

PHP Warning: Undefined array key "path" in /xxxxx/site/modules/ProcessRedirects/ProcessRedirects.module:653

The PHP Version is 8.1. What causes this message to appear?

[Mikel]

Hi everyone,

we ran into two issues with Redirects on multi-language sites and I've submitted a pull request that fixes both: https://github.com/teppokoivula/ProcessRedirects/pull/28

1. Redirect targets lose their language

When the target is a local path to an existing page, the module stores only the page ID (1234). So a target like /en/products/ is shown as the default-language path in the admin list, and on redirect the URL is built in the current language, which is the language of the source URL prefix. In practice:

• /en/old-page/ → /en/products/ works (by accident)
• /old-page/ → /en/products/ redirects to the default-language page
• /en/old-page/ → /products-default/ redirects to the English page

The export also contains the wrong paths, so re-importing an export changes the redirects.

2. "The Redirect From URL already exists as a page path" for non-existing paths

getByPath() with useLanguages also returns partial matches. A non-existing source like /en/old/shoe/ matches any page whose English name is shoe, and since $page->name is the default-language name, the check rejects the redirect. Adding the same redirect via CSV import works, because the import doesn't run this check.

What the PR does

• Page targets are stored as [page ID]:[language ID] and resolved with localHttpUrl(), so the language is kept and redirects still follow renamed or moved pages.
• An exact page/language lookup replaces thegetByPath() check, which fixes the false positive.
• The edit form gets a language select next to the page picker, and the instructions explain the multi-language usage.
• Fully backwards compatible: existing redirects and single-language sites behave as before, no database changes.

Tested on a fresh PW 3.0 install (PHP 8.3) and on a live multi-language site.

Until it's merged, you can grab the module from the branch: https://github.com/frameless-at/ProcessRedirects/tree/multilanguage-targets

Feedback welcome!
Cheers, Mike