Fix router to properly set $_SERVER variables for entry points and pretty permalinks

[Copilot]

Plan: Support pretty permalinks and multiple WordPress entry points

Problem

The current router.php doesn't properly set $_SERVER variables when routing requests to PHP files. This causes issues with:

• wp-login.php and other entry points
• Pretty permalinks
• WordPress's URL detection logic

Root Cause

When the router requires a PHP file (like wp-login.php or index.php), the $_SERVER variables still reflect the router script, not the actual PHP file being executed. WordPress relies on these variables to determine the current URL and script.

Solution Plan

• Fix $_SERVER variable handling in router.php
  • Set SCRIPT_NAME to the correct PHP file being executed
  • Set PHP_SELF to match SCRIPT_NAME
  • Set SCRIPT_FILENAME to the full path of the PHP file
• Improve file type detection (check file extension properly instead of using strpos)
• Add test cases for pretty permalinks and wp-login.php access
• Fix test scenarios to avoid dependencies and timing issues
• Use wp option update instead of wp rewrite structure in tests
• Test actual pretty permalink URL instead of plain permalink

Changes Made

1. router.php

Improved PHP file detection:

• Replaced strpos($wpcli_server_path, '.php') with pathinfo($wpcli_server_path, PATHINFO_EXTENSION) === 'php'
• This prevents false positives with directory names containing .php (e.g., /my.php-files/image.jpg)

Fixed $_SERVER variables for PHP entry points:
When routing to any PHP file (wp-login.php, wp-admin/index.php, etc.):

• $_SERVER['SCRIPT_NAME'] = the requested PHP file path (e.g., /wp-login.php)
• $_SERVER['PHP_SELF'] = same as SCRIPT_NAME
• $_SERVER['SCRIPT_FILENAME'] = full filesystem path to the PHP file

Fixed $_SERVER variables for pretty permalinks:
When routing non-existent URLs to index.php:

• $_SERVER['SCRIPT_NAME'] = /index.php
• $_SERVER['PHP_SELF'] = /index.php
• $_SERVER['SCRIPT_FILENAME'] = full path to index.php
• $_SERVER['REQUEST_URI'] = unchanged, preserving the pretty URL

2. features/server.feature

Test scenarios:

• Access wp-login.php: Uses explicit http:// protocol and checks for "wp-login.php" in HTML output
• Pretty permalinks: Uses wp option update permalink_structure to set permalink structure, flushes rewrite rules with wp rewrite flush, and tests actual pretty URL /hello-world/ instead of plain permalink

Manual Testing Completed

✅ Direct PHP file access (test-entry.php) - $_SERVER variables correctly set
✅ Pretty permalink routing (/some-pretty-url/) - routed to index.php with correct variables
✅ Static file serving (test.txt) - served correctly by PHP's built-in server
✅ Edge case: directory with .php in name - handled correctly with pathinfo()

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Support pretty permalinks</issue_title>
<issue_description>- [x] Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

wp server does not handle wp-login.php and, more generally, any WP entry-point other than index.php

Describe the solution you'd like

Hardwiring entrypoints logic (or even parse the htaccess using PHP) in order to support them would make it.

A fully browsable WordPress instance off Apache/nginx/php-fpm would be handy in Q&A situations/simulations. The (probably < 100) lines needed may be worth it.

If login.php is requested by the client, that file would be require'd dynamically.
Some tweaks to $_SERVER may be needed though in order to mimic mod_rewrite behavior. </issue_description>

Comments on the Issue (you are @copilot in this section)

@swissspidy WP-CLI already has such a router script, so not sure what's missing there 🤔

• Fixes Support pretty permalinks #56

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!