F5F Stay Refreshed Hardware Desktop Discuss WordPress link handling and CPT issues with Apache servers.

Discuss WordPress link handling and CPT issues with Apache servers.

Discuss WordPress link handling and CPT issues with Apache servers.

F
FlameSquid32
Senior Member
Find
501
04-24-2023, 08:51 PM
#1
Hello everyone, welcome to my first post of the new year. I’m hoping you all have a bright and prosperous 2026. Right now I’m working on a WordPress setup with Apache 2.4 (mod_rewrite enabled), PHP 8.x, and a custom post type created through the CPT UI. The .htaccess file is straightforward, but I’m running into some tricky edge cases between Apache, mod_rewrite, and WordPress routing.

Here’s a simplified setup: Apache 2.4 with mod_rewrite PHP 8.x, a standard WordPress installation, and a custom post type registered via CPT UI. My .htaccess follows typical rules, but I’m seeing issues with specific paths. For example, /?p=123 works fine, the WordPress admin functions correctly, and PHP and .htaccess are all healthy. However, requests like /foo/ or /test.php return a 403 Access denied.

What caught my attention is that Apache blocks certain path-based requests before WordPress even processes them. This makes me wonder how server-side logic should handle such situations. In WordPress, CPTs aren’t routed through Apache rules but via a catch-all index.php file. So the challenge is clear: I need to understand why Apache isn’t allowing these paths to reach WordPress at all.

Some observations stand out:
- The server seems to expect an explicit rewrite rule for /edih/, but WordPress doesn’t use Apache rules for that.
- The main hurdle appears to be a combination of .htaccess handling, mod_security/WAF settings, and the way WordPress interprets URLs without a proper rewrite chain.

I’m still confused about how to fix this without more context. I’d love to hear from others who’ve faced similar problems. This situation really taught me that sometimes the solution lies in understanding the layered interactions between servers and applications. Thanks for your time, and I look forward to sharing what I learn!
Reply
Reply
F
FlameSquid32
04-24-2023, 08:51 PM #1

Hello everyone, welcome to my first post of the new year. I’m hoping you all have a bright and prosperous 2026. Right now I’m working on a WordPress setup with Apache 2.4 (mod_rewrite enabled), PHP 8.x, and a custom post type created through the CPT UI. The .htaccess file is straightforward, but I’m running into some tricky edge cases between Apache, mod_rewrite, and WordPress routing.

Here’s a simplified setup: Apache 2.4 with mod_rewrite PHP 8.x, a standard WordPress installation, and a custom post type registered via CPT UI. My .htaccess follows typical rules, but I’m seeing issues with specific paths. For example, /?p=123 works fine, the WordPress admin functions correctly, and PHP and .htaccess are all healthy. However, requests like /foo/ or /test.php return a 403 Access denied.

What caught my attention is that Apache blocks certain path-based requests before WordPress even processes them. This makes me wonder how server-side logic should handle such situations. In WordPress, CPTs aren’t routed through Apache rules but via a catch-all index.php file. So the challenge is clear: I need to understand why Apache isn’t allowing these paths to reach WordPress at all.

Some observations stand out:
- The server seems to expect an explicit rewrite rule for /edih/, but WordPress doesn’t use Apache rules for that.
- The main hurdle appears to be a combination of .htaccess handling, mod_security/WAF settings, and the way WordPress interprets URLs without a proper rewrite chain.

I’m still confused about how to fix this without more context. I’d love to hear from others who’ve faced similar problems. This situation really taught me that sometimes the solution lies in understanding the layered interactions between servers and applications. Thanks for your time, and I look forward to sharing what I learn!

Reply
Reply