Bildproblem

Hej Folke!

Följande är ett försök till systematisk genomgång av tänkbara felkällor och vad du kan göra åt det.

Inmatningsformat

T.Barregren du har rätt till en del om HTML-koden som försvann. Inne bland filterinställningarna hittade jag en inställning om tillåtna html taggar och där finns ju inte img src med...Kan det varit det som spökade tidigare?

Ja, om HTML filtret ingick i det inmatningsformat du använde på den nod som inte visade bilden, så är det ganska säker förklaringen till varför <img>-elementet inte kom med. Du känner säkert redan til hur det här med filter och inmatningsformat fungerar, men låt mig i alla fall, bara för fullständighetens skull, förklara hur de olika delarna hänger ihop.

Inmatningsformat och filter

En nods brödtext sparas exakt som det står i databasen. (Detta gäller alla textytor som använder inmatningsfilter.) Det innebär att både HTML:en koden nedan till vänster och Markdown-koden nedan till höger sparas exakt som de står skrivna i databasen:

Det är viktigt att förstå att båda texterna sparas exakt som de står oavsett vilket inmatnigsformat som är valt eller filka filter dessa innehåller. Det är först när sidan skall visas som den lagrade texten transformeras från sitt källformat (HTML respektive Markdown) till den utmatade HTML-koden. Denna transformering sker så att de i det valda inmatningsformatet valda filterna appliceras en efter en i stigande viktordning. Inmatningsformat borde därför egentligen kallas för utmatningsformat. Den sålunda transformerade texten cachas till sist, så de därpå följande sidvisning slipper vänta den tid som transformationen tar.

Åter till ditt problem

Det är därför som källtexten kan innehålla ett <img>-element medan detsamma är borttaget i den utmatade HTML-koden. Lösningen är alltså att konfigurera HTML-filtret så att <img>-elemetet tillåts, eller ta bort HTML-filtret från inmatningsformatet eller välja ett annat inmatningsformat.

När man installerar Drupal är Filtered HTML det förvalda inmatningsformatet. Det är ett bra val om man tillåter vanliga besökare att kommentera eller har ett stort antal personer som får skapa sidor. Men om det bara är en själv eller liten grupp med betrodda medarbetare så är det bättre att sätta Full HTML som "default". Då kan man göra allt man förväntar sig kunna göra med vanlig HTML.

safe_mode

Som framgår på annan plats så ger jag inte mycket (inget alls närmare bestämt) för safe_mode. Jag förstår att det kan vara svårt att påverka din leverantör att ta bort safe_mode från just ditt konto. Men du kan ju alltid överväga att byta till en annan leverantör som har bättre koll på PHP och använder open_basedir i stället.

Men om du ändå måste uthärda safe_mode så är det viktigt att tänka på att alla filer som ligger i Drupals rot eller därunder måste ägas av webbservern eller, om safe_mode_gid är satt, höra till en grupp som också webbservern hör till. Du vet att du har problem med safe_mode om Drupal påstår att en fil inte är läsbar/skrivbar trots att ls -l visar -rw-r--r-- eller -rw-rw-r--. Observera att WSoD ej kan skyllas på safe_mode.

White Screen of Death (WSoD)

Drupalt själv fångar upp alla fel, loggar dem och presenterar en lämplig sida. Direkt ur lådan visar Drupal även ett felmeddelande på skärmen. Detta är bra vid utveckling, men skall givetvis stängas av innan webbplatsen går live.

Så när du får WSoD så är det ett tecken på att fel som ligger utanför Drupal självt. Det uppkommer om Apache eller PHP i ett tidigt skede upptäcker ett fatalt fel och på grund av inställningar inte är tillåten att rapportera felet (vilket är klokt på en produktionsserver). Orsaken till felet står att finna i Apaches logg.

Den absolut vanligaste orsaken till WSoD i Drupalsammanhang är Apache direktivet Options i Druapls .htaccess filer i installations-, files- och tmp-katalogerna samtidigt som webbplatsens "virtual host" AllowOverride ej inkluderar just Options. Den enklaste lösningen är att ta bort Options-direktivet ur Drupals tre stycken .htaccess-filer. Kvarstår felet så måste du mycket sannolikt ta bort ytterligare direktiv ur .htaccess-filen som ligger i Drupals rot.

En annan källa till WSoD är för snålt tilltaget minne (memory_limit) för PHP.

Även om jag förstår att det inte är aktuellt i ditt fall, så vill jag ändå ta tillfället i akt och påpeka att det ur ett prestanda perspektiv är olämpligt att ha .htaccess-filer då dessa läses och tolkas vid varje(!) sidvisning. Därför bör man flytta in allt som finns i Drupals .htaccess-fil i webbplatsens VirtualHost-direktiv.

Filuppladdning

Icke alls relaterat till WSoD, men ger upphov till samma snopna känsla, är den fullständiga avsaknaden av felmeddelande när uppladdningen av en stor fel slutar med... ingen fil alls. :-( Detta inträffar när man försöker ladda upp en fil

• som i sig är större än den av PHP största tillåtna storleken (upload_max_filesize), eller
• som tillsammans med filer som redan har laddats upp i samma anrop överstiger den av PHP största tillåtna storleken (post_max_size), eller
• som tar mer tid att ladda upp än den av PHP längsta tillåtna uppladdningstiden, (max_input_time).

Filnedladdning

Ett sista råd. Jag ser att du har ställt in Drupal att använda "private download". Det har i sig inget med ditt problem. Men jag vill ändå passa på att avråda dig från detta. När du använder "private download" så går hela filen genom Drupal och PHP på väg till mottagaren. Det belastar datorn onödigt mycket och ger också försämrad genomströmningshastighet. Använder du däremot "public download" så är det Apache som skickar filen. Eftersom Apache är byggd för ett enda ändamål -- att skicka filer (HTML- eller JPEG-filer spelar ingen roll) -- så är den betydligt bättra på det än Drupal/PHP.

Du har säkert valt "private download" eftersom du har filer som verkligen måste hållas oåtkomliga för kreti och pleti. Men som regel går det att hitta andra och bättre lösningar än "private download" för detta. En lösning är att ställa in "public download" men ändå används "private download" för vissa filer. Det går att ordna med lite Apache konfiguration samt par rader PHP-kod. Vi har använt denna lösning på webbplatser vi har byggt för bl.a. Vinnova, Norrlandsflyg och Qondoc. Ett annat alterantiv är att låta Apache sköta autentiseringen på en del av webbplatsen (se t.ex. Secure Site).

Thomas Barregren – Webbredaktören