The minimum support PHP is bumped to 7.4. This is more of a preparation thing, and there have been no major changes to PHP.

In terms of general updates there are a selection of small changes and fixes:

• Add multi-select support with shift-click in tables
• Add WP-CLI verbose flag for settings command to display setting names
• Improve log deletion performance with adaptive batch sizing for large backlogs
• Add permissions policy header
• Improve trash monitoring

A lot of people use Redirection, and this brings with it extra challenges in terms of not breaking existing sites. Ideally no one notices the changes, and to help with this the modernisation will occur over several steps.

This first step (5.6) focuses on improving the PHP code by reformatting and linting, and ensuring everything checks out with PHPCS and PHPStan, as well as updating some of the build tools. A new settings class has been introduced to make unit testing easier, and the client has been reduced in size. These changes shouldn’t cause any functional changes, but the minimum supported version of PHP is bumped to 7.2 (from 7.0)

The second step (5.7) will focus on the client, ensuring it too is fully type checked, and uses more modern libraries. The PHP files will be moved to a better location in preparation for the final step. As before, this shouldn’t cause any functional changes, although the minimum supported version of PHP will be bumped to 7.4 (from 7.2).

The last step involves updating the PHP code to use namespaces and autoloading. Although there shouldn’t be any functional changes, it could affect people who directly use Redirection classes for custom functionality (please get in touch if you think this may affect you). The plugin will be at version 6.0 by this point so it should be clear it’s a major change. The minimum supported PHP may also be bumped to 8, although this will depend on the general WordPress environment.

There are many new features and improvements lined up after the modernisation, and I look forward to implementing them.

• Multiple ‘URL and WP page type’ redirects will now work
• Translations now use WP core

A full breakdown of the changes is listed below:

• Don’t encode negative lookaheads in regular expressions
• Remove port from server name
• Importing into a disabled group now sets the items as disabled
• Fix saving of x-content-type-options
• Fix save of multiple spaces in a URL
• Add an option to pick the IP header to ensure it is the correct one

Once you’ve created redirects for this task a common question is how long do you need to keep them around for?

The simple answer is that a redirect should exist as long as anyone might visit the old URL.

Let’s break that down a bit.

The are two main reasons for creating redirects when migrating your pages:

• To update search engines with new URLs
• To ensure direct access doesn’t 404

Assuming everything is set up correctly, search engines will eventually update their index. Once this happens the redirects don’t need to exist anymore – their job is complete.

Direct access is a more complicated matter. As long as the potential exists for someone to access your site directly then a redirect will be needed. People may have bookmarked links, shared them in emails or social media, and they may be referenced on other websites and in advertising.

There is a common misconception that having a lot of redirects will slow your site down, or that it is in some way ‘messy’. This isn’t the case, and as it essentially costs nothing to keep a redirect the simplest solution is just to leave them until the possibility of direct access is zero.

If the possibility will never be zero they probably should remain.

If you do want to clean out redirects you can use the ‘last access‘ feature in Redirection to tell you when a redirect was last used. If, after a sufficient period of time has passed, you decide there is no possibility of anyone accessing that redirect then it’s probably safe to remove.

Of course, this is just a general rule, and your site may have different needs. It doesn’t cost anything to keep a redirect around, but if you do delete redirects the 404 log can help identify if they need to be restored.

A full breakdown of the changes is listed below:

• Improve installation process
• Improve permalink migration so it works with more permalinks
• Prevent ordering columns by HTTP code
• Better encode URLs in Nginx export
• Allow escaped characters to work in the redirect checker
• Reduce CSV import time

The simple answer to this is: don’t!

The question is based on the mistaken belief that a 404 page is bad and needs fixing.

A 404 is the correct response for a page that doesn’t exist and has never existed.

If you wish to provide more useful information to a viewer then you can modify your 404 page. In WordPress this can be achieved by modifying your theme, or even with another plugin. However, it is important that it remains a 404.

A redirect is the correct response for a page that used to exist at one location and has now moved to another. Most times this needs to be permanent (301), but some times you may want a temporary redirect (307).

If you have a page that no longer exists then you should return a 410 message to indicate that it has gone.

But my SEO will suffer

No, it won’t. Automatically redirecting all 404s to another unrelated page is incorrect. This indicates that the page used to exist and now exists elsewhere. This is probably not what you want.

Redirecting to a page that has no relevance to the original URL also has no purpose and may even be detrimental to your site.

For example, it would be possible to misuse this and make spurious (and potentially harmful) requests to a site. The automatic redirect indicates this request is now valid and lives elsewhere.

Redirection’s 404 log

Redirection provides a log of 404s, and people often interpret this as a todo list.

The 404 log can be used to track down pages that do need to be redirected because the URL has changed.

You can use the ‘group by’ filter to organise the log by the most-requested URLs, and then go through those and see if any need redirecting.

It is not necessary to redirect ‘bots’ – automated requests – and doing so is creating yourself more work, adds overhead to your site, and doesn’t improve anything.

A full breakdown of the changes is listed below:

• Improve URL checker and show more details
• Retain query parameter case when passing to target URL
• Remove unnecessary database stage option check
• PHP 8.1 compatibility

It also improves the behaviour of the permalink migration feature, as well as fixing issues to do with log deletion, .htaccess, and the ‘do nothing’ action.

A full breakdown of the changes is listed below:

• Add importer for PrettyLinks
• Fix crash converting a ‘do nothing’ to ‘redirect to URL’
• Improve warning messages
• Improve permalink migration when is_404 is not set
• Fix ‘delete log entries’ returning blank data
• Fix missing .htaccess location
• Fix hits & date not imported with JSON format

• Caching support
• Migrated permalink structures
• Dynamic URL variables

Caching

You can now use an object cache to cache redirects. This will improve performance, particularly with regular expressions.

Caching support is currently marked as beta, and can be enabled from the options page.

Migrated Permalink Structures

You can now enter old permalink structures and Redirection will perform all of the redirects without needing to enter any redirects or regular expressions.

This option is also marked as beta, and can be found on the Site page.

Dynamic URL variables

A set of shortcodes can be entered into a target URL and will be replaced at runtime. You can use these to insert data, such as usernames, and even transform a URL, such as converting it from upper to lower case.

The current supported shortcodes are:

• User ID
• User login
• Time (Unix)

The following transforms are supported:

• MD5
• Uppercase
• Lowercase
• Convert underscores to dashes
• Convert dashes to underscores

More information can be found on the Dynamic URLs support page.

Other improvements

• Add fully automatic database upgrade option
• Add a new version release information prompt
• Improve performance when many redirects have the same path
• Move bulk all action to a separate button after selecting all
• Fix error in display with restricted capabilities
• Avoid problems with 7G Firewall
• Improve handling of invalid encoded characters