I am having a horrible time trying to get WordPress to work with basic rewrite rules. I have a php page in a plugin directory which needs to receive an id number so that it can lookup a related record. I want the user to visit the url example.com/redirect/{redirectid} which should serve a page found at example.com/wp-content/plugins/myplugin/redirect/index.php?redirectid=$1 but this never works.
I have tried adding the redirect rule via the rewrite API. The rule seems to ignore the RewriteBase when creating the rule. This is a Bitnami WordPress installation on a Windows PC which hosts the WP site in a subdirectory called /wordpress/ instead of the root, so the RewriteBase is /wordpress/ instead of /.
When I try to add the rewrite rule as follows it only prepends the RewriteBase to the second part.
add_rewrite_rule( 'redirect/([0-9]+)/?', 'wp-content/plugins/myplugin/redirect/index.php?redirectid=$matches[1]', 'top' );
add_rewrite_tag( '%redirect%', '(.*)' );
flush_rewrite_rules();
This results int the following rewrite rule being added to the .htaccess file:
RewriteRule ^redirect/([0-9]+)/? /wordpress/wp-content/plugins/myplugin/redirect/index.php?urlid=$matches[1] [QSA,L]
Despite this rule, URLs like example.com/redirect/1/ result in a WordPress generated 404 error page. Part of this might be due to pages using a similar URL structure of /pagename/ but that is not the same as /pagename/id/ so it should be fine. I tried copying and pasting the rule above and below WordPress in the .htaccess file but the results are the same. Same goes if I manually edit the first part of the rule to say ^wordpress/redirect/([0-9]+)/?
I don’t know how to check to see what query variables are currently in WordPress. The rewrite tag function doesn’t add anything to the .htaccess file and I can’t seem to find query variables stored in the database anywhere. I tried the following, but it only produced an empty array:
global $wp_query;
var_dump($wp_query->query_vars);
Because this is all going in the activation function of a plugin I need a solution that is entirely code based within WordPress to avoid having to instruct users to make changes to their .htaccess file directly on their own or presenting users with long URLs to the plugin in their posts. It is a URL cloaking plugin so I’d rather have a URL shown to users which looks cleaner than the location of a php file in a plugin directory which does nothing more than lookup URLs in a database based on id and redirect users.
Also, is it possible to stop the QSA part of the rule from being auto-generated by WordPress? I’ve been told by others to get rid of the QSA but I don’t know how without manually editing the .htaccess file.
According to Regex101 the problem is the carat character prepended automatically by WordPress. If I test this regex without the charat prepended it works ok as long as the slashes are escaped https://regex101.com/r/3vVMV7/1 which indicates something is wrong because every example of the API I have seen does not escape slashes and offers no way to stop the carat from being prepended.
UPDATE: This problem is caused by Bitnami. I posted a question on their Github support forum. Their response was, "By default, our installations disable the .htaccess files as recommended by the Apache Software Foundation. All the configuration found in those files at installation time are moved in to a separated wordpress-htaccess.conf file under the /opt/bitnami/apache2/conf/vhosts/htaccess folder. You can add the needed configuration for your plugin there, or enable back .htaccess files. Please find more information about this in our guide linked below"
I have responded by letting them know how outrageous their position is and asking how to edit their special file using WordPress Rewrite API because I doubt it is possible. Recommendation: don’t use Bitnami.
2
Answers
STOP USING BITNAMI!
When I stopped using Bitnami, I was able to find a rewrite rule that works. It required me to edit a live site on a remote server due to my development environment using Bitnami. Bitnami responded to my support questions with an admission that they disable .htaccess by default. They provided advice for how to enable it but the advice did not work.
WITHOUT BITNAMI you can add a rewrite rule and see it work as follows:
The above must go in your activation function for your plugin.
New Problem: Sometimes the .htaccess file gets overwritten by Wordpress and other plugins requiring that the plugin be deactivated before being reactivated to recreate the rules. For instance, when I changed the permalink structure for posts the .htaccess file was regenerated without the rule.
Just enable basic rewrite rules in your .htaccess file as so: