De afbeelding wordt niet getoond. Bij het direct aanroepen krijg ik een 404 melding: afbeelding
De afbeelding is wel beschikbaar op het hoofd domein
De doorverwijzing in .htaccess:
####SUBDOMAINS_HEADER####
RewriteEngine on
#RULE:,mb-stable-management.nl,http://stable-management.nl/$1
#RULE:www,mb-stable-management.nl,http://stable-management.nl/$1
#RULE:www,stable-management.nl,/event_2018/
RewriteCond %{HTTP_HOST} ^mb-stable-management.nl$
RewriteRule (.*) http://stable-management.nl/$1 [last,R=301]
RewriteCond %{HTTP_HOST} ^www.mb-stable-management.nl$
RewriteRule (.*) http://stable-management.nl/$1 [last,R=301]
RewriteCond %{HTTP_HOST} ^www.stable-management.nl$
RewriteCond %{REQUEST_URI} !^/event_2018//
RewriteRule (.*) /event_2018//$1 [last]
####SUBDOMAINS_TAILER####
####CUSTOM_HEADER####
#NL: Place your custom rules here
#EN: Plaats je eigen regels hier
####SESSIONID BEHAIVIOR####
RewriteEngine On
####CUSTOM_TAILER####
####ERROR_HEADER####
####ERROR_TAILER####
Moet die RewriteCond wel eindigen met een dubbele slash? Als je namelijk een url gebruikt zonder dubbele slash, dan zal de RewriteRule in werking treden. Dat was de reden dat je op deze url een 404 kreeg:
/event_2018/images/site-picture.png
werd namelijk omgezet naar
/event_2018//event_2018/images/site-picture.png
en die zal niet bestaan.
Een ander interessant dingetje is dat /images/site-picture.png wordt herschreven naar /event_2018//site-picture.png. Ik kan daarvoor in de rewriterules geen verklaring vinden, maar misschien doet ook hier die // iets geks.
Als je die rewritecond/rule corrigeert, heb je waarschijnlijk die base-directive niet meer nodig.
In je RewriteRule staat nog steeds de // die ik verdenk van problemen.
Als ik /event_2018/images/site-picture.png opvraag, krijg ik het plaatje te zien. Vraag ik echter /images/site-picture.png op, dan wordt die nog steeds herschreven naar /event_2018/site_picture.png (waarbij al wel de dubbele slash weg is).
Ik vermoed dat die // een feature van Apache is om een niveau in je directoryboom te snoeien, maar ik kan dat niet terugvinden in de documentatie, het is een lastige zoekterm voor google en ik heb momenteel geen tijd/zin om het in mijn eigen omgeving te testen. ;-)
Overigens zou ik aanraden om van de (.*) in je rewriterule ^(.*) te maken. Dan is het voor zowel jou als voor de regular expression parser duidelijk dat je alles vanaf het begin wilt matchen.
Verder kopieer je je rewriterules voor het domein met en zonder www-prefix. Je kan e.e.a. samennemen door je conditie iets aan te passen:
Deze conditie matcht zowel www.stable-management.nl als stable-management.nl. (Formeel genomen moet je elke . ook nog schrijven als \. omdat de expressie anders niet matcht op punten maar op willekeurige tekens, maar in dit geval kan dat niet zoveel kwaad.)
Het vervelende is dat deze file geschreven wordt door de hosting manager van de provider en geven daar geen ondersteuning op want wat zij aanbieden werkt goed is het antwoord, dus jij doet iets fout.
Wat het voor mij ook onbegrijpelijk maakt is het voor de mat54 website (wiki) wel werkt
Als ik regel 3 en 7 van je htaccess met elkaar vergelijk, dan zie ik dat de rule op regel 3 met een / eindigt, en die op regel 7 niet. Waarschijnlijk staat in de hosting manager ergens een / teveel ingevuld. Ik weet niet of dat iets is dat jij beheert of dat het iets is dat zij beheren, maar ergens moet er iets verkeerd geconfigureerd zijn.
Ik zie dat er ook ruimte is voor custom rules. Ik ken de software niet, dus ik weet niet of er een mogelijkheid is om de gegenereerde rules weg te halen, maar als die mogelijkheid er is, zou je alle rewriterules naar het custom-gedeelte kunnen verhuizen.
