En realidad no hay comunicación entre Apache y WordPress. La "magia" está sucediendo en las mod_rewritereglas de Apache .
Para una instalación estándar de WordPress, tiene las siguientes reglas en .htaccess:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Observe esta línea: RewriteRule . /index.php [L]
Aquí, le estamos diciendo a Apache que redirija internamente cualquier solicitud de URL /index.php.
A menos que: esta línea: seRewriteCond %{REQUEST_FILENAME} !-fvuelva falsa. Eso significa que, al agregar estoRewriteCondcon lo anteriorRewriteRule, le estamos diciendo a Apache que envíe todas las solicitudes/index.php, pero no si es un archivo existente .
Además, cuando esta línea: seRewriteCond %{REQUEST_FILENAME} !-dvuelve falsa. Eso significa que, al agregar estoRewriteCondcon lo anteriorRewriteRule, le estamos diciendo a Apache que envíe todas las solicitudes/index.php, pero no si es un directorio existente .
Entonces, al final, a menos que sea un archivo existente o un directorio existente, Apache está enviando internamente todas las demás solicitudes a /index.php .
Como puede ver, no hay comunicación entre Apache y WordPress. Apache es decidir todo por sí mismo y nos están diciendo que lo haga utilizando RewriteRuleyRewriteCond directivas.
Lea más sobre mod_rewriteAQUÍ .
if ( !defined(‘ABSPATH’)) exit;!defined(‘ABSPATH’)evalúa como verdadero, significa que algo más que WordPress está tratando de acceder al script (porque ABSPATH está definido en wp-config.php), y por lo tanto, debe ignorar esa solicitud. ¿Es eso correcto?ABSPATHen cualquier otro script PHP, entonces permitirá otros scripts en su propio servidor. Lo que no permitirá es el acceso directo a ese archivo desde fuera de su servidor (digamos desde el navegador). Porque al acceder a ese archivo directamente, los usuarios no pueden definir de ninguna maneraABSPATH.