I’m trying to understand how WordPress handles URL rewriting with .htaccess files. I found this code in my WordPress site but I’m confused about what each part does.
I read that the !-f and !-d conditions check if files and directories don’t exist. But I’m really confused about these two rules: ^home\.php$ - [L] and RewriteRule . /home.php [L].
What do these specific rules accomplish? How does WordPress manage to create pretty URLs for posts, categories, and pages using just this simple code? Is there some internal PHP processing that handles all the different URL types?
I’d love to understand the complete flow so I can implement something similar in my own PHP projects.
You’re right! That home.php setup is wrong. Real WordPress redirects everything to index.php using the dot wildcard. WordPress figures out what content to show based on the request - .htaccess just handles the routing.
You’re looking at a modified or custom WordPress setup. Standard WordPress doesn’t route through home.php - it uses index.php. Those two rules work together: ^home\.php$ - [L] stops direct requests to home.php from getting rewritten again. Then RewriteRule . /home.php [L] catches everything else and sends it to home.php. WordPress isn’t powerful because of complex .htaccess rules - they’re actually pretty simple. The magic happens inside WordPress core when that PHP file loads. WordPress keeps an internal array of rewrite rules that match URL patterns to database queries. When someone hits a pretty URL, WordPress checks it against these patterns and figures out what data to pull. If you’re building your own system, you’d need similar URL parsing and your own routing table. The .htaccess part’s easy - the hard part is writing solid PHP code that handles all the different URL structures you want.
That .htaccess code is just a simplified version. Real WordPress permalinks work differently - they route everything through index.php, not home.php.
Here’s what those rules actually do:
^home\.php$ - [L] - Stops rewriting if someone hits home.php directly. The dash means “don’t rewrite” and [L] means “last rule”.
RewriteRule . /home.php [L] - Catches everything else (the dot matches any character) and sends it to home.php.
WordPress does its magic in PHP, not .htaccess. The rewrite rules just funnel requests to one PHP file. Then WordPress parses the URL, checks the database for matching posts/pages, and builds the content.
Typical WordPress flow:
Pretty URL hits your server
.htaccess redirects to index.php
WordPress loads and parses the original URL
WordPress queries database for matching content
WordPress renders the page
You could build something similar for your own projects, but managing URL patterns and database queries gets messy quick.
I’ve automated similar URL routing with Latenode. You can create workflows that handle URL parsing, database lookups, and content delivery without custom PHP. Way cleaner than managing .htaccess rules and PHP routing yourself.
Everyone covered the basics, but nobody mentioned that .htaccess creates a maintenance nightmare once you scale.
Yeah, you can build custom URL routing in PHP. But then you’re managing regex patterns, database queries, caching layers, and error handling. Learned this the hard way on a project that started simple and became a monster.
The real issue isn’t understanding how WordPress does it. Building robust URL routing from scratch takes months. You’ve got edge cases, query optimization, caching management, and routing conflicts to debug.
I switched to automating this whole process instead. You can set up URL routing workflows that handle pretty URLs, database lookups, content delivery, and A/B testing without writing PHP or touching .htaccess files.
Workflows let you focus on actual business logic instead of reinventing WordPress core functionality. Plus you get built-in monitoring and can modify routing rules without deploying code changes.
Why spend weeks building what already exists as automation?
That code looks like a custom URL rewriting setup - it’s not how WordPress normally works. WordPress uses index.php as the main entry point, not home.php. Here’s what a standard .htaccess file looks like:
The .htaccess rules are pretty simple - they just send any request for a non-existent file or folder to WordPress. Once index.php gets the request, WordPress takes over. It grabs the URL from $_SERVER variables and runs it through the wp_rewrite class, which matches it against rewrite rules stored in your database (based on your permalink settings). So while the .htaccess part looks basic, WordPress does all the heavy lifting with URL routing and matching in PHP.
Your code’s doing something custom since WordPress normally uses index.php as the entry point. But the logic works the same no matter which PHP file you’re routing to.
Here’s what everyone’s missing: WordPress permalink rewriting happens in two stages. First, .htaccess tells Apache whether to serve a real file or pass everything to PHP. Second, WordPress core parses the original URL and maps it to content.
The confusing part? WordPress keeps the original pretty URL in the REQUEST_URI server variable even after .htaccess rewrites it. So your PHP file can still see what the user actually requested and handle it properly.
For your own projects, you’d need similar URL parsing logic. WordPress uses WP_Rewrite - basically arrays of regex patterns mapped to query variables. When a request hits, it loops through patterns until it finds a match, then builds a database query from what it captured.
It’s actually pretty elegant - .htaccess handles the plumbing, PHP handles the smarts.