In general it is much better to handle redirect on the PHP side. (assuming is is implemented by semi competent developer) It is more flexible and uses less overhead. Specifically to the question, the set of wordpress rules will handle all URLs, therefor your rule is too late and you should move it to be … Read more
apache “AllowOverride” was set “None” but changing it to “All” made no effect : I changed the “AllowOverride” in the “apache2.conf” file. It’s still not clear where exactly you are setting AllowOverride. This directive can only be used in a directory context. ie. Inside a <Directory> container in your main server or VirtualHost config. You … Read more
Assuming you have changed your permalinks in WordPress (under Settings > Permalinks), as mentioned earlier, then you can redirect your old URLs en masse (in order to preserve SEO) with something like the following at the top of your .htaccess file, using mod_rewrite: RewriteRule ^([\w-]+)-\d{7,}\.html$ /$1/ [R=302,L] This will redirect URLs of the form /%postname%-%monthnum%%year%%post_id%.html … Read more
Assuming you have already moved your site from the /blog subdirectory to the document root and changed the URL structure within WordPress itself, so the /blog subdirectory is not included in all your internal links, then you can either do a simple redirect (using mod_rewrite) in the /blog/.htaccess file (preferable): RewriteEngine On RewriteRule (.*) /$1 … Read more
So, you just want to inject a /client subdirectory, for specific URLs, from the document root. You can do this using mod_rewrite, at the top of your .htaccess file (before the WordPress front-controller). For example: RewriteRule ^view(invoice|ticket)\.php$ /client/$0 [R=302,L] This will redirect either /viewinvoice.php or /viewticket.php to /client/viewinvoice.php and /client/viewticket.php respectively. The query string is … Read more
You certainly should not be modifying the # BEGIN WordPress block, as this is likely to be overridden by WordPress itself. You should create a new section before the WordPress front-controller. This will work just as well and keep the directives separate. There is no need to use a <IfModule mod_rewrite.c> wrapper, in fact you … Read more
If both the main domain and subdomain point to the same directory on the filesystem, then you need to check the requested host using a mod_rewrite condition. So, for example, the following directives should go before the WordPress front-controller (ie. before the # BEGIN WordPress section): RewriteCond %{HTTP_HOST} ^(example\.com) [NC] RewriteRule ^(music/end/)$ http://music.%1/$1 [R=301,L] The … Read more
Do these lines mean HTTPS urls will not be cached? Well, it certainly means that on most servers that have an SSL cert installed, the URL will not be rewritten to /wp-content/cache/all/<requested-URL-path>/index.html. If that means the cache will be bypassed, then yes, it prevents caching. The idea of not caching HTTPS requests would seem to … Read more
Plain permalinks of the form /?p=14523 (or /index.php?p=14523) don’t necessarily need any .htaccess file since they don’t require mod_rewrite to rewrite the URL (unlike the the custom permalinks you mention). However, for a URL of the form /?p=14523 (as opposed to /index.php?p=14523), where you don’t explicitly state the index document (ie. index.php) in the URL … Read more
You can do something like the following at the top of your .htaccess file to replace all – with + that occur after the /search/ path segment in the requested URL: RewriteRule ^(search/[^-]*)-([^-]*-.*) /$1+$2 [N] RewriteRule ^(search/[^-]*)-([^-]*)$ /$1+$2 [R=302,L] The first RewriteRule loops (internally) until all except 1 hyphen has been replaced with +. The … Read more