4

So my rewriterule is like

RewriteRule ^test$ index.php [L]

I tested it on https://htaccess.madewithlove.com?share=b0a9904b-1ec4-49cd-917c-36426ff6150a it works fine.

enter image description here

I also tested it on live Joomla sites and on a HTML sites, it all work fine.

However, when I try to test this on a Wordpress site, I am always getting a 404 page. By default, wordpress site's .htaccess file is like

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

I add my rewrite rule above to the first line, but when I open mysite.com/test I will get a 404 error.

To test, I create a 1.php file and modify my rule to

RewriteRule ^test$ 1.php [L]

This time, when I open mysite.com/test it successfully executes 1.php. So the catch here is index.php.

What I don't understand is if I open mysite.com/index.php it will load mysite.com without problem. And I believe

RewriteRule ^test$ index.php [L]

in essential is telling the server when user request mysite.com/test show him mysite.com/index.php, then why in actuality I am getting a 404 page(not a blank 404, but the 404 page handled by wordpress's theme) when trying to open mysite.com/test?

P.S. I've also tried removing the default wordpress rules, but still getting the same result.

1 Answer 1

2

I am getting a 404 page(not a blank 404, but the 404 page handled by wordpress's theme)

Your rule is successfully rewriting the request to index.php, however...

index.php is the WordPress front-controller. Code in this file looks at the requested URL (eg. /test in your example) and decides how to handle it. If /test is not a valid route defined in WordPress then WordPress (not Apache) generates a 404. This isn't reporting that the file index.php does not exist, but that the URL /test does not exist inside of WordPress, ie. there is no route defined for this URL in WordPress.

I add my rewrite rule above to the first line

UPDATE: Incidentally, unless /test maps to an existing directory (or file) then the WordPress code block already does exactly what you are doing with the rewrite... it rewrites the request to /index.php with the last rule.

So, the directive you are adding is in fact entirely superfluous anyway.

RewriteRule ^test$ 1.php [L]

If the code in 1.php responds with a 404 (for whatever reason), then this would also result in a 404.

15
  • So although Apache rewrites the URL it still passes the original request (in my case /test) to Wordpress? And how then do I rewrite /test to /?
    – Wen Shenk
    Feb 4 at 14:28
  • 1
    @WenShenk Yes, the original request is available to PHP (ie. WordPress) in the $_SERVER['REQUEST_URI'] superglobal - and WP uses this to route the URL through the CMS. Incidentally, your rewrite is really superfluous (assuming /test does not map to a file or directory) since the WordPress code block already rewrites the request to /index.php in the last rule.
    – MrWhite
    Feb 4 at 15:08
  • 2
    @WenShenk "how then do I rewrite /test to /?" - Do you mean "redirect"? It doesn't make sense to internally rewrite /test to /. / itself is not a valid end-point. It would require further rewriting to handle the request (eg. to serve the DirectoryIndex). However, unless you are implementing an additional app outside of WordPress then all URLs/routing need to be configured in WordPress itself - not .htaccess. AFAIK, WordPress itself does not provide a mechanism to "rewrite" requests outside of WP itself, unlike some other CMS, since it always looks that the URL the user requested.
    – MrWhite
    Feb 4 at 15:12
  • 1
    @WenShenk I just tried the /shop URL on your site and I'm 302 redirected to google.com, so unless you've changed something, you're probably seeing a cached response/redirect (as mentioned above).
    – MrWhite
    Feb 4 at 19:08
  • 1
    Thank you so much. Wasn't aware this could be cached.
    – Wen Shenk
    Feb 4 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.