The following parameters are optional.
If Nothing Was Found
Add the parameter default_redirect_to where you can specify a default destination if the other criteria return an empty result. It accepts as value the ID of a post or page. If this parameter is omitted or if the post or page with this ID cannot be found, then the default destination is the front page.
Tracking
Use these parameters for tracking the redirects in your statistics. Supported are Google Analytics (utm_source, utm_campaign, utm_medium, utm_term and utm_content) and Piwik Matomo (pk_campaign, pk_kwd, pk_source, pk_medium and pk_content).
What ever you use here will be passed through to the final URL of the post.
Example For Tracking
Redirect to the latest post that uses the tag with the ID 23 and add the campaign identifier “my_link” . If no post uses that tag, go to the post or page with the ID 12.
http://www.example.com/?redirect_to=latest&tag_id=23&default_redirect_to=12&utm_campaign=my_link
Pass-Through Parameters
You can add your own pass-through parameters by defining a constant in the wp-config.php file. The value of that constant is a comma-separated list of your URL parameter keys (or just one key without a comma).
Example
Add into wp-config.php:
define( 'CHATTY_MANGO_RUTP_PASS_THROUGH', 'go,do' );This would pass through any parameters like …&go=there&do=that.
Caching
If you have a busy website with many posts, complicated database queries can affect performance. For this reason it is recommended to cache the results so that they can be used again for a specified time. The default caching time is 60 seconds.
In most cases we are caching the final post for a given set of parameters. The only exception is “redirect_to=random” where we cache the entire set of posts from which we then pick a random post. That means that you can safely use “random” with caching.
The value is the cache lifetime in seconds. 0 (zero) means off. The time starts counting when a particular search query is used the first time, no matter by which visitor.
There are two ways how you can change the value for caching:
1. URL
Add the parameter cache to the URL.
Example
Redirect to a random post and cache the pool of posts for 120 seconds.
http://www.example.com/?redirect_to=random&cache=120
2. wp-config.php
Add the following constant definition to wp-config.php. This constant takes priority over the URL parameter. That means that you can use this way to enforce caching.((If you’re afraid that a malignant visitor might disable the cache per URL parameter.))
define('CHATTY_MANGO_RUTP_CACHE', 600 );Each Post Only Once in Random Order
With each_once you can prevent that visitors see the same post twice in a series of random posts. Use each_once=rewind to start over again after all posts are done. Use each_once= with a target post/page ID if you want to send your visitors to a post or page after all posts are done.
Example:
www.example.com/?redirect_to=random&each_once=rewind
This feature works only in the same browser and if your visitors accept and keep cookies.
Hints:
- If you add the parameter &rutpdebug, you will see a warning if the post IDs wouldn’t fit into a cookie.
- Use directory_cookie if you need to set different cookies per directory/path.
Suppressing Filters
By default, the plugin tries to suppress filters in order to avoid interference from other plugins. In some cases, however, you might want them to interfere, for example if a multilingual plugin filters the posts by language. In that case just add suppress_filters=0 to the URL and make sure that no other plugin changes the post order.
Repeat the Same Post for a Given Time
If you want your visitor to see for a given time on each page reload always the same post, you can use the parameter lock with a number in seconds. Example: lock=86400.
The lock works only in the same browser and if your visitors accept and keep cookies.
Note: We apply the lock only if the locked post is still among the posts that correspond to the search query. (For example, it might in the meantime have slipped outside a time frame. Use the cache if you need to preserve the list of posts. Please note, however, that the cache does not work per visitor and might expire before the lock.)
Cookie Scope
We save information that is distinct per visitor (like seen or locked posts) in browser cookies. By default these cookies are saved with a domain-wide validity. That way it doesn’t matter which page a visitor is on when a redirect happens.
You can switch to separate cookies for each directory with the parameter directory_cookie. This might be useful for example when using lock with redirects to the previous or next post since here the target depends on the directory (which is the current post’s permalink).
Loop With prev and next
If you use redirect_to=prev or redirect_to=next (on the URL of a post) and there is no previous or next post, because you are already at the end, you can use the parameter loop=1 to restart with the last or first post.
Fragment
Add a fragment (aka “named anchor”) with fragment=….
Debugging
In debug.log
If you enable logging to a file, you can add the parameter verbose_debug to the URL in order to get more detailed messages. Verbose debugging does not interrupt the redirections.
Please note that on a production server many threads can run simultaneously and incoherent log messages might therefore appear mixed together.
On the screen
Add rutpdebug to the URL if you want to see on the screen what is happening in the background without doing any redirection. With rutpdebug=2 you also see the relevant arguments for the database query.
Since this information is accessible from the frontend, we expose no internal or critical data. Everything visible here can be inferred from the URL parameters and the resulting link is exactly what we would normally redirect to.
Examples
Find many more examples on the example page.