[njoy]

Testade lägga upp en webbplats på City Network efter att ha hört gott om dom. Nu söker jag era åsikter då jag genast ramlade över en massa bekymmer.

Jag fick en vit sida i Firefox men HTTP 500 i Chrome. Detta (som alla vet) beror på ett PHP fatal error.

- Ingen errors.log existerar på FTP platsen.
- Ingen information finns hur man slår på felmeddelanden.
- En php_flag i htaccess genererar ett 404 file not found (?wtf felsidan finns inte?)
- En ini_set('display_errors', 'On') i scriptet ger ingen verkan.
- Sätta en egen errors_log genom ini_set ger ingen verkan.
- Supporten vet knappt vad jag pratar om.

Jag meddelar att det är viktigt och talar om vad jag provat. De återkommer och ber mig prova ini_set. Jag skrev precis att jag redan provat det. *suck*

Efter en vecka återkommer dom. Prioritet! *ironi*. De kan bekräfta att alla php fel är avstängda på servernivå och vare sig varningar, notices eller syntax errors kan visas. De tänker heller inte slå på det. Jag fick tipset att om jag inkluderar skripten i ett annat skript så finns möjlighet att error ska visas. Här tappar jag förståndet.

För mig upplever jag detta som lekstuga. Tekniker som trycker på knappar utan tänka på konsekvenserna. Jag vet att webbhotell kan ha varningar avstängda som standard. Men är det inte lite ifrågasättande varför man gjort det omöjligt att få fram felmeddelanden?

Jag har reklamerat mitt köp.

[abergman]

Jag hade också problem med liknande hos CN, men jag tror inte att det är specifikt för dom, utan Binero bör ha samma problem.

Det jag kom fram till då är att eftersom webbservern inte rapporterar felen själv direkt, utan filen måste parsas igenom så kommer felen inte visas om det blir fel vid header output.

Så troligen ligger ditt fel där.

[abergman]

Ursprungligen postat av Kjette

abergman: Bara för att vi använder oss av samma leverantör utav kontrollpanel så är det rätt stora skillnader mellan oss och Atomias kunder.

Felmeddelanden i PHP fungerar klockrent hos oss (aka Binero). Allt annat är felkonfigurerad.

Didn't know! Utgick kallt från att ni kör samma prylar more or less.

Det problem jag hade berodde på den förbannade WP-pluggen Timthumb som flippade ur och eftersom scriptet körs innan servern skickar ut några headers så syntes inget alls, även om jag slagit på all rapportering både till skärm och till fil.

[Danielos]

Ursprungligen postat av njoy

Efter en vecka återkommer dom. Prioritet! *ironi*. De kan bekräfta att alla php fel är avstängda på servernivå och vare sig varningar, notices eller syntax errors kan visas. De tänker heller inte slå på det. Jag fick tipset att om jag inkluderar skripten i ett annat skript så finns möjlighet att error ska visas. Här tappar jag förståndet.

För mig upplever jag detta som lekstuga. Tekniker som trycker på knappar utan tänka på konsekvenserna. Jag vet att webbhotell kan ha varningar avstängda som standard. Men är det inte lite ifrågasättande varför man gjort det omöjligt att få fram felmeddelanden?

Jag har reklamerat mitt köp.

Låter onekligen jättekonstigt, att man väljer att helt slå av det och att kunden inte kan slå på det. Vi får se vad johan1234 säger om det. Jag är av uppfattningen att man ska kunna justera 100% i php.ini specifikt för en kund, men jag vet att de flesta webbhotell inte kan/vill eller klarar av att ordna detta.

[Webbkonsulterna]

Ursprungligen postat av Danielos

Jag är av uppfattningen att man ska kunna justera 100% i php.ini specifikt för en kund, men jag vet att de flesta webbhotell inte kan/vill eller klarar av att ordna detta.

Man tappar verkligen hakan när man läser detta. Självklart ska man kunna se vad som går fel både genom errorlog och display_errors. Självklar ska man också kunna få unika inställningar i php.ini också om man vill. Trodde verkligen att alla webbhotell stödde en sådan grundläggande sak...

[tartareandesire]

Ursprungligen postat av Webbkonsulterna

Tappar verkligen hakan när man läser detta. Självklart ska man kunna se vad som går fel både genom errorlog och display_errors. Självklar ska man också kunna få unika inställningar i php.ini också om man vill. Trodde verkligen att alla webbhotell stödde en sådan grundläggande sak men vi kanske är unik på fler saker än vi trott...

Nej, ni är verkligen inte unika Är tämligen övertygad om att felmeddelanden varit tillgängliga i CN:s gamla system men har knappt använt det nya än så det kan jag inte säga så mycket om.

[jonny]

Ursprungligen postat av Danielos

Låter onekligen jättekonstigt, att man väljer att helt slå av det och att kunden inte kan slå på det. Vi får se vad johan1234 säger om det. Jag är av uppfattningen att man ska kunna justera 100% i php.ini specifikt för en kund, men jag vet att de flesta webbhotell inte kan/vill eller klarar av att ordna detta.

Där skiljer sig nog uppfattningarna. Det finns ju inställningar som minnesanvändning och liknande som en enskild kund i delad miljö inte bör kunna påverka.

Att styra felrapportering vore dock trevligt.
Själv har jag nyligen svurit över att det som kund inte går att stänga av magic quotes.

Däremot bör ju supporten rimligen kunna åtgärda detta och hjälpa en kund.

[Danielos]

Ursprungligen postat av jonny

Där skiljer sig nog uppfattningarna. Det finns ju inställningar som minnesanvändning och liknande som en enskild kund i delad miljö inte bör kunna påverka.

Men det är ändå 2 skilda saker, vad en kund via tex. .htaccess kan ändra och vad som är möjligt att ändra av webbhotellet för kunden. Vissa inställningar ska naturligtvis kunden inte själv kunna sätta fritt, minnesanvändning osv, men vad jag menar är att det ska vara tekniskt möjligt för webbhotellet att ändra 100% av php.ini utifrån samförstånd med kunden och eventuellt ta mer betalt för högre utnyttjande.

[johan1234]

njoy - först och främst vill jag säga hur djupt beklagad jag är över att det har tagit sådant tid för dig att få svar och få det löst.

Vi har valt att inte ha felmeddelanden aktiverat globalt. Majoriteten (som vi talat med) önskar det så och många vill inte att lite småfel i sin kod kan störa sidorna. Det kan också bli så att ett litet fel i någon av de större installationerna som WP eller annat skulle teoritiskt kunna ge fel i större skala vid en uppgradering eller liknande. Vi har alltså valt att låta de som kan utveckla och har behov - få aktivera det själva.

Självklart sätter du själv igång det på enkelt sätt och du har varit på rätt spår hela tiden. Men det verkar tyvärr vara så att du hade ett kritiskt fel i den filen där du aktiverar felmeddelandet. Därför kommer det inte igång. Jag tror Johan F nämnde det till dig i något av supportmailen - om än sent. Ser självklart gärna att antinget du tar bort det kritiska felet (så felrapporteingen kan komma igång) eller att vi får hjälpa dig göra det (borde vår support redan gjort proaktivt - med ditt tillstånd). Du kan alltså, precis som du säger, sätta igång både errors.log filen eller få direkta felmeddelanden - gäller bara att du inte har fel i just den filen där du sätter igång det. Något supporten självklart skulle funnit långt tidigare och du har helt rätt i att kritisera oss för detta.

Det finns inga ursäkter till att det tog tid - men vill ändå tillägga mer som förklaring - att några av våra experter på området är på semester och belastningen något högre generellt i semestertider. Något som vi av ditt problem kommer se till att det blir ändring på nästa sommar.

Vill också poängtera det kjette säger - det är absolut skillnader i hur Binero och City Network driftar (bland annat underliggande hårdvara) - även om kontrollpanelerna och funktionalitet är relativt lika. Vi äger dessutom vår huvudhall och har full kontroll på miljön.

[tartareandesire]

Då verkar ju allt vara som det ska (utöver tidsaspekten då). Jag anser också att det är lämpligt att ha felmeddelanden avstängt per default såsom t.ex. Loopia och City Network kör. I produktion vill man ju precis som Johan säger inte ha några felmeddelanden.