Advanced Subfolder Proxy

Alleen voor ervaren beheerders

Voer deze aanpassingen alleen uit als je ervaring hebt met webserverconfiguratie, reverse proxies en HTTPS. Een verkeerde configuratie kan je website of clones onbereikbaar maken. Ben je hier niet mee bekend? Laat de configuratie dan uitvoeren door je hostingpartij of serverbeheerder.

De Clonable WordPress plugin handelt subfolder clones normaal gesproken automatisch af. Je hoeft hiervoor zelf geen proxy in te stellen.

Voor drukbezochte websites kan deze werkwijze extra belasting veroorzaken. Wil je deze belasting verminderen? Dan kun je de subfolder rechtstreeks door je webserver laten afhandelen. Op deze pagina lees je hoe dit werkt en wat je hiervoor moet instellen.

Hoe werkt de standaardconfiguratie?

Wanneer een bezoeker een subfolder zoals website.com/nl/ opent, wordt eerst WordPress geladen. De plugin herkent de subfolder en haalt met cURL de vertaalde pagina op bij Clonable. Clonable haalt vervolgens de originele pagina op wanneer die nodig is voor de vertaling.

Bij een verzoek zonder cache ziet dit er zo uit:

Bezoeker → website.com/nl/ → WordPress → Clonable plugin
         → Clonable → originele WordPress-pagina → vertaalde pagina

Hierdoor zijn twee PHP-workers tegelijk nodig: één om het verzoek door te sturen en op het antwoord te wachten, en één om de originele pagina op te bouwen. Een PHP-worker is een proces op je server dat PHP-verzoeken uitvoert. WordPress wordt bij deze werkwijze dus ook twee keer geladen.

Bij veel gelijktijdige bezoekers kunnen de beschikbare workers bezet raken. Nieuwe verzoeken moeten dan wachten, waardoor de website trager wordt. Caching kan dit verminderen, maar neemt de oorzaak niet weg.

Wat doet een externe subfolder proxy?

Een subfolder proxy op je webserver stuurt het verzoek naar Clonable voordat WordPress wordt geladen.

Bezoeker → website.com/nl/ → webserver → Clonable
         → originele WordPress-pagina → vertaalde pagina

De extra PHP-worker voor het doorsturen is dan niet meer nodig. Alleen het opbouwen van de originele pagina vereist nog WordPress wanneer deze niet uit een cache kan worden geleverd.

Je kunt de belasting ook beperken door volledige pagina's langer te cachen. Wijzigingen zijn dan mogelijk pas zichtbaar nadat de cache verloopt of wordt geleegd. Voor websites waar prestaties en actuele inhoud belangrijk zijn, raden wij aan om de subfolder buiten WordPress af te handelen. Hiervoor is geen extra cachelaag nodig. Bestaande caches blijven wel invloed hebben op hoe snel wijzigingen zichtbaar worden.

Wat heb je nodig?

Voor deze configuratie heb je het volgende nodig:

• Een werkende subfolder clone in Clonable, inclusief HTTPS.
• Toegang tot de NGINX- of Apache-configuratie, of een hostingpartij die deze voor je kan aanpassen.
• Een testomgeving om de configuratie te controleren voordat je deze op je live website gebruikt.

Niet elke WordPress-hostingpartij staat eigen proxyregels toe. Vraag daarom eerst na wat er binnen je hostingpakket mogelijk is.

WordPress plugin behouden

Je kunt de plugin blijven gebruiken voor onder andere language tags en de language switcher. Schakel bij de overstap alleen Enable subfolder service uit, zoals hieronder beschreven. De plugin zelf blijft actief.

Verzoeken van Clonable herkennen

Clonable moet de originele pagina kunnen blijven ophalen. Dit verzoek mag niet opnieuw naar Clonable worden doorgestuurd, anders ontstaat er een lus.

De voorbeelden hieronder gebruiken hiervoor de header Clonable-Request-ID. Verzoeken zonder deze header gaan naar Clonable. Verzoeken met deze header volgen de bestaande afhandeling voor de originele website. De header is bedoeld voor routering en is geen authenticatie.

Behoud bij het doorsturen de publieke hostnaam, het volledige subfolderpad, de querystring, de HTTP-methode en de requestbody. Laat ook bestaande subfolder exclusions intact.

NGINX configuratie

Voeg de onderstaande location-blokken toe aan het bestaande HTTPS-server-blok van je website. De proxy maakt rechtstreeks verbinding met lb.clonable.net, zodat je geen apart upstream-blok hoeft toe te voegen. Behoud de bestaande PHP-handler.

Wat moet je aanpassen?

• /nl/ en /nl → vervang deze door de subfolder van je clone.
• website.com → vervang deze door de hostnaam van je website, inclusief www. als je dat gebruikt.

Jouw configuratie kan anders zijn

Het voorbeeld gaat uit van een standaard WordPress-installatie waarin index.php de paginaverzoeken afhandelt. Stuurt NGINX door naar Apache, of gebruikt je hostingpartij een andere inrichting? Laat dan vooral de regel met try_files aanpassen aan de bestaande configuratie.

location = /nl {
    return 308 /nl/$is_args$args;
}

location ^~ /nl/ {
    # Stuur bezoekersverzoeken door voordat PHP wordt gestart.
    if ($http_clonable_request_id = "") {
        rewrite ^(.*)$ /clonable$1 last;
    }

    # Verzoeken voor de originele inhoud volgen de bestaande WordPress-configuratie.
    try_files $uri $uri/ /index.php$is_args$args;
}

location ^~ /clonable/ {
    internal; # Voorkom rechtstreekse toegang van buitenaf.
    rewrite ^/clonable(.*) $1 break; # Verwijder de interne prefix.

    # SNI en de publieke hostnaam.
    proxy_ssl_server_name on;
    proxy_ssl_name website.com;
    proxy_set_header Host website.com;
    # Gebruik HTTP/1.1 voor de proxyverbinding.
    proxy_http_version 1.1;
    # TLS-protocollen voor de verbinding naar Clonable.
    proxy_ssl_protocols TLSv1.2 TLSv1.3;
    proxy_pass https://lb.clonable.net;
    # Vergroot de buffers voor antwoorden van Clonable.
    proxy_buffer_size          128k;
    proxy_buffers              4 256k;
    proxy_busy_buffers_size    256k;
}

Hoe werkt deze configuratie?

Het eerste locatieblok stuurt /nl door naar /nl/. Het tweede blok herschrijft bezoekersverzoeken intern naar /clonable/nl/.... De browser blijft het oorspronkelijke adres gebruiken. Hiervoor is geen extra HTTP-statuscode nodig.

De locatie /clonable/ verwijdert de interne prefix en stuurt het verzoek naar lb.clonable.net. De subfolder en querystring blijven behouden. Met internal; voorkom je dat bezoekers deze locatie rechtstreeks kunnen openen. De HTTP-header Host en de TLS-servernaam geven aan voor welke website het verzoek bedoeld is. Behoud proxy_pass https://lb.clonable.net; zonder afsluitende slash en vervang dit adres niet door je eigen domein: dat verwijst normaal gesproken terug naar je eigen server.

Voor WordPress gebruiken we bij beide prefixlocaties ^~. Daarmee krijgen deze voorrang op locaties met reguliere expressies, zoals bestaande PHP- en statische-bestandsregels. Controleer daarom ook hoe deze bestanden binnen je subfolder worden afgehandeld. Herhaal de subfolderblokken voor elke clone; de locatie /clonable/ kan binnen hetzelfde server-blok worden gedeeld.

Aanvullende instellingen voor je hosting

Laat je hostingpartij daarnaast controleren welke instellingen uit de bestaande configuratie worden overgenomen:

• Caching: wil je hier geen proxycache gebruiken, voeg dan proxy_cache off; toe als er op een hoger niveau caching is ingesteld.
• Certificaatcontrole: SNI stelt de servernaam in, maar schakelt certificaatcontrole niet in. Hiervoor raden wij proxy_ssl_verify on; aan, samen met proxy_ssl_trusted_certificate en het juiste CA-bundelpad van je hostingpartij.

Meer informatie vind je in de documentatie van de NGINX-proxymodule.

Apache configuratie

Gebruik je Apache? Dan kun je de subfolder ook buiten WordPress afhandelen. Voor de beste prestaties raden wij aan om de proxy in de virtual-hostconfiguratie van je website te plaatsen. Je hostingpartij kan daar ook hergebruik van verbindingen instellen.

Kan dit via .htaccess?

Ja, met een RewriteRule en de vlag [P] kan Apache een verzoek doorsturen zonder WordPress te laden. Alleen een regel toevoegen aan .htaccess is echter niet voldoende: je hostingpartij moet eerst de benodigde proxyfuncties inschakelen.

Daarnaast gebruikt [P] standaard een proxy-worker zonder connection pooling. Verbindingen worden daarmee niet via een pool hergebruikt. Voor optimale prestaties is aanvullende serverconfiguratie nodig. Zie ook de Apache-documentatie over de proxyvlag.

Wat moet je hostingpartij instellen?

Laat je hostingpartij de volgende onderdelen controleren:

• Schakel mod_rewrite, mod_proxy, mod_proxy_http en mod_ssl in.
• Sta rewriteregels in .htaccess toe via AllowOverride FileInfo of een gelijkwaardige lijst met toegestane directives.
• Schakel SSLProxyEngine On en certificaatcontrole voor de upstream in de serverconfiguratie in.
• Stel ProxyPreserveHost On in voor de website en behoud ProxyRequests Off.
• Stem de HTTPS-hostnaam van de upstream af met Clonable. De upstream is de server waar Apache het verzoek naartoe stuurt.

Apache bepaalt de TLS-servernaam op basis van het proxydoel. Alleen de HTTP-header Host behouden geeft daarom niet dezelfde TLS-configuratie als het NGINX-voorbeeld.

Proxyregel toevoegen

Wanneer de serverconfiguratie klaar is, kun je onderstaand patroon toevoegen aan het .htaccess-bestand in de hoofdmap van WordPress. Plaats het boven en buiten het gegenereerde BEGIN WordPress-blok, zodat WordPress het niet overschrijft.

Vervang nl door de subfolder van je clone en CLONABLE_UPSTREAM_HOST door het HTTPS-endpoint dat je hostingpartij met Clonable heeft afgestemd. Dit endpoint moet naar Clonable verwijzen en de juiste TLS-configuratie en routering voor je publieke hostnaam ondersteunen. Het voorbeeld is dus niet direct over te nemen zonder deze aanpassingen.

# Plaats dit boven en buiten het gegenereerde BEGIN WordPress-blok.
RewriteEngine On
RewriteCond %{HTTP:Clonable-Request-ID} ^$
RewriteRule ^(nl(?:/.*)?)$ https://CLONABLE_UPSTREAM_HOST/$1 [P,L]

Deze regel herkent /nl en /nl/..., maar niet /nl-other. In .htaccess begint het te vergelijken pad niet met een slash. De querystring blijft behouden. Verzoeken met de Clonable-header worden verder afgehandeld door de bestaande WordPress-regels.

Laat je hostingpartij ook redirects controleren en waar nodig ProxyPassReverse instellen. Zo voorkom je dat bezoekers naar een upstreamadres worden doorgestuurd. Plaats de serverinstellingen in de virtual-hostconfiguratie, niet in .htaccess.

Meer informatie vind je bij de Apache-proxyinstellingen en HTTPS-proxyinstellingen.

Subfolder service uitschakelen in WordPress

Wanneer je webserver de subfolder proxy afhandelt, moet je de subfolder service in de Clonable plugin uitschakelen. Zo neemt de webserver het doorsturen naar Clonable over van de plugin.

1. Open Clonable in de WordPress-beheeromgeving.
2. Ga naar het tabblad Settings.
3. Verwijder onder Miscellaneous settings het vinkje bij Enable subfolder service.
4. Sla de instellingen op.

Onderdeel van de overstap

Schakel deze service pas uit wanneer de proxyconfiguratie op de webserver klaarstaat en wordt geactiveerd. Zonder de pluginservice of een werkende webserverproxy zijn je subfolder clones niet bereikbaar zoals bedoeld. Deze stap geldt voor zowel NGINX als Apache.

Controleren of alles goed werkt

Laat je hostingpartij de configuratie valideren en opnieuw laden. Controleer of Enable subfolder service is uitgeschakeld en de wijziging is opgeslagen. Controleer daarna het volgende:

1. Open /nl, /nl/, een vertaalde subpagina en een URL met queryparameters. Controleer of de juiste vertaling verschijnt en er geen doorverwijslus ontstaat. In het tabblad Network van de ontwikkelaarstools kun je de Clonable-responseheaders bekijken.
2. Test de originele website, het WordPress-beheer, statische bestanden en uitgesloten paden. Gebruik je WooCommerce? Test dan ook de winkelwagen, het afrekenen en formulieren.
3. Controleer of redirects en cookies het juiste publieke domein en de juiste paden gebruiken. Test ook URL's met spaties of tekens met accenten.
4. Laat in de server- en PHP-logs controleren of bezoekersverzoeken voor de subfolder worden doorgestuurd voordat PHP start. Alleen het ophalen van de originele pagina hoort WordPress te laden wanneer dat nodig is.
5. Pas inhoud op de originele website aan en controleer of de wijziging zichtbaar wordt zoals je met je cache-instellingen verwacht. Vergelijk ook responstijden en het gebruik van PHP-workers bij een vergelijkbare belasting.

Gebruik je een CDN of andere cache vóór WordPress? Laat je hostingpartij dan zorgen dat vertaalde antwoorden en verzoeken voor de originele inhoud gescheiden blijven in de cacheregels.

Bewaar de vorige serverconfiguratie, zodat je de proxyregels kunt terugdraaien als iets niet goed werkt. Ga je terug naar de afhandeling via de plugin? Schakel dan ook Enable subfolder service weer in en sla de instellingen op. Kom je er met je hostingpartij niet uit? Neem dan contact met ons op en stuur het domein, de subfolder en eventuele foutmeldingen uit de serverlogs mee.