The following parameters are optional.
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.
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.
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.
If you have a busy website with many posts, complicated database queries can affect performance. For this reason it is recommended to use caching so that results 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:
Add the parameter cache to the URL.
Redirect to a random post and cache the pool of posts for 120 seconds.
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.1
define('CHATTY_MANGO_RUTP_CACHE', 600 );
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.
This feature works only in the same browser and if your visitors accept and keep cookies.
- 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.
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.
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=
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.)
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).
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.
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.
Find many more examples on the example page.