web.config no funciona con los enlaces permanentes de WordPress en la subcarpeta

3 minutos de lectura

Tengo WP instalado en un servidor IIS en la carpeta raíz. Esto funciona con bonitos enlaces permanentes.

También hay otra instalación de wordpress en /development que utiliza el siguiente web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
            <rule name="WordPress1" patternSyntax="Wildcard">
                <match url="*"/>
                    <conditions>
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
                    </conditions>
                <action type="Rewrite" url="index.php"/>
            </rule></rules>
    </rewrite>
    <staticContent>
      <clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="365.00:00:00"/>
      <remove fileExtension=".woff"/>
      <remove fileExtension=".woff2"/>
      <mimeMap fileExtension=".woff" mimeType="application/x-font-woff"/>
      <mimeMap fileExtension=".woff2" mimeType="application/font-woff2"/>
    </staticContent>

  </system.webServer>
</configuration>

Sin embargo, los bonitos enlaces permanentes no funcionan en este sitio en la subcarpeta

Sin embargo, la página de inicio funciona con esta subcarpeta y cuando se seleccionan enlaces permanentes simples

¿Alguna idea de por qué?

La respuesta, como dice pee2pee, es colocar esa línea en el código.

<remove name="YourRuleName"/>

Para hacer esto, primero debe mirar el archivo web.config de la raíz y buscar esta línea.

<rule name = "YourRuleName" patternSyntax = "Wildcard">

y luego copie la línea en el archivo web.config de su directorio o subcarpeta, cambiando “YourRuleName” por el nombre que encontró en el archivo web.config de la raíz justo encima de la primera etiqueta.

Luego, su archivo web.config de la subcarpeta debería verse así

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
            <remove name="YourRuleName"/>
            <rule name="YourSubFolderRuleName" patternSyntax="Wildcard">
                <match url="*"/>
                    <conditions>
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
                    </conditions>
                <action type="Rewrite" url="index.php"/>
            </rule></rules>
    </rewrite>
  </system.webServer>
</configuration>

Espero que sea de ayuda, para mí lo ha sido.

  • ¡Esto me ayudó aquí! ¡Gracias!

    – Dicristo

    15 de febrero de 2019 a las 0:02

Asegúrese de que la carpeta raíz (que sirve al sitio principal) y la subcarpeta (donde reside la secundaria o /shop) tengan cada una un archivo web.config único.

En el archivo web.config de su subcarpeta, debe eliminar la regla que se configuró en la carpeta raíz. En nuestro caso, la regla de reescritura de WordPress establecida en la carpeta raíz se llamaba “PrimarySite”, por lo que en la subcarpeta web.config tenemos:

<remove name="PrimarySite"/>

Y eso es todo lo que se necesitó para que las cosas funcionaran. Sencillo, ¿eh?

A partir de WP 5.9 (pero estoy seguro de que hace años y versiones) no es necesario agregar web.config manualmente.

En caso El módulo de reescritura de IIS está instalado (que es un requisito previo) cuando modifica Configuración/Enlace permanente, WP emite automáticamente web.config en la raíz de su sitio.

Incluso escribe en la GUI un mensaje de advertencia para revocar el acceso de escritura desde web.config.

Si el módulo de reescritura de IIS no está instaladotodo lo anterior no es posible, ni manualmente, por lo que WP incluirá el /index.php/ fragmento en el camino. Si sobrescribe esta configuración con una configuración de enlace permanente personalizada, los enlaces adoptarán (por lo que no contendrán el /index.php/ fragmento, pero debido a la falta de facilidad de reescritura IIS le dará 404.

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad