[PHP] Lege pagina's in frontend Joomla

[ericck]

Na installatie van Joomla 1.5 en enkele plug-ins krijg ik bij een aantal pagina's in de frontend helemaal niets te zien.

Deze index pagina (category list view) wordt wel getoond:
http://bit.ly/cpL9Yj

Maar sommige onderliggende pagina's niet, bijvoorbeeld deze (Groepsfoto 2007/2008):
http://bit.ly/bhyoeA

Vraag 1: waarom zie ik een compleet lege pagina en geen foutmeldingen? Ik heb al show errors op 'Maximum' gezet en het volgende stukje code toegevoegd aan configuration.php:

PHP:

    ini_set( 'display_errors', true ); error_reporting( E_ALL );

Maar toch krijg ik geen errors te zien.

In de backend ziet de content van de laatste pagina er als volgt uit:

code:

<p>Groepsfoto's van schooljaar 2007-2008.</p>
<p>{gallery}groeps/0708{/gallery}</p>

De {gallery} tag verwijst naar Simple Image Gallery Pro.

Vraag 2: waarom wordt deze pagina niet getoond en de andere soortgelijke pagina's wel?

[NMe]

Daarom:

Although display_errors may be set at runtime (with ini_set()), it won't have any affect if the script has fatal errors. This is because the desired runtime action does not get executed.

Je hebt gewoon ergens een grove fout gemaakt die een fatal error oplevert. Kun je oplossen door in je serverconfiguratie aan te geven dat je fatal errors ook wil zien.

Daarnaast moet het volgens mij ini_set( 'display_errors', '1' ); zijn; ik weet niet of PHP de booleanwaarde true netjes omzet naar de stringwaarde '1'.

[ericck]

Je hebt gewoon ergens een grove fout gemaakt die een fatal error oplevert. Kun je oplossen door in je serverconfiguratie aan te geven dat je fatal errors ook wil zien.

Een fatal error, dat geloof ik graag, maar ik ben vooral benieuwd welke :-)
Kan met een shared server die configuratie aanpassend an?

Daarnaast moet het volgens mij ini_set( 'display_errors', '1' ); zijn; ik weet niet of PHP de booleanwaarde true netjes omzet naar de stringwaarde '1'.

Voor de zekerheid aangepast. Maakt geen verschil.

[NMe]

ericck schreef op zondag 21 november 2010 @ 21:17:
[...]

Een fatal error, dat geloof ik graag, maar ik ben vooral benieuwd welke :-)
Kan met een shared server die configuratie aanpassend an?

Testen doe je lokaal op een server waar dat wél kan, en pas als het werkt gooi je het op je shared hosting account.

[Matis]

NMe schreef op zondag 21 november 2010 @ 21:18:
Testen doe je lokaal op een server waar dat wél kan, en pas als het werkt gooi je het op je shared hosting account.

offtopic:
Ik doe dat gewoon first time right

---

Bestaat het artikel waar de groepsfoto's naar linken überhaupt wel? Normaal serveert Joomla een eigen 404 pagina, maar misschien heb je juist die wel om zeep geholpen.

[ Voor 45% gewijzigd door Matis op 21-11-2010 21:24 ]

[ericck]

Matis schreef op zondag 21 november 2010 @ 21:20:
Bestaat het artikel waar de groepsfoto's naar linken überhaupt wel? Normaal serveert Joomla een eigen 404 pagina, maar misschien heb je juist die wel om zeep geholpen.

Het artikel bestaat wel. De link ernaar is namelijk automatisch gegenereerd door Joomla. Of er moet echt een major bug in Joomla zitten waardoor category lists niet correct werken, maar laten we daar niet van uitgaan.

En de 404 heb ik niet om zeep geholpen, verander maar eens wat getallen in de URL naar een willekeurig getal... voila, 404 error page.

[marko77]

NMe schreef op zondag 21 november 2010 @ 21:18:
[...]

Testen doe je lokaal op een server waar dat wél kan, en pas als het werkt gooi je het op je shared hosting account.

Inderdaad, maar alleen als die test server gelijk is qua config aan de 'live' server. Anders kun je niet met zekerheid zeggen dat het daar ook zal werken. Lijkt me in dit geval wel handig.

[ericck]

marko77 schreef op zondag 21 november 2010 @ 21:26:
[...]
Inderdaad, maar alleen als die test server gelijk is qua config aan de 'live' server. Anders kun je niet met zekerheid zeggen dat het daar ook zal werken. Lijkt me in dit geval wel handig.

In ieder geval zal ik het nu moeten doen met de configuratie van de 'live' server. Die is nu eenmaal zoals ie is.

De plug-in Simple Image Gallery PRO (by JoomlaWorks) uitschakelen werkt wel om weer output te krijgen. Maar die plug-in heb ik nu juist zo hard nodig...

[marko77]

heb je wellicht toegang tot de apache error logs? Daar kun je wellicht ook e.e.a. uit halen.

[ericck]

marko77 schreef op zondag 21 november 2010 @ 21:42:
heb je wellicht toegang tot de apache error logs? Daar kun je wellicht ook e.e.a. uit halen.

In standaardmapje /usr/local/apache/logs van XS4All shared hosting zijn geen nieuwe logs te vinden. Laatste dateert uit 2005.

[ericck]

Toch een stapje verder gekomen. Debug mode aangezet in de plug-in waarvan ik verwacht dat die problemen geeft (Simple Image Gallery Pro).
Dan krijg ik op de 'foute' pagina's de volgende melding:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 3104 bytes) in /usr/local/WWW/A/.5c1/k/kareleyk/htdocs/nieuw/plugins/content/jw_sigpro/sigpro.engine.php on line 209

Volgens mijn PHP settings (via System info in Joomla) staat: memory_limit op 8M. Kan het daar iets mee te maken hebben? En hoe pas ik dat aan?

[Matis]

Ik zou eens gaan zoeken waarom er meer dan 8meg aan RAM nodig is om een eenvoudig artikel weer te geven. Het lijkt eerder een memory leak.

De foutmelding kan je iig verder helpen met het zoeken naar de specifieke foutmelding.

[ericck]

Matis schreef op zondag 21 november 2010 @ 22:28:
Ik zou eens gaan zoeken waarom er meer dan 8meg aan RAM nodig is om een eenvoudig artikel weer te geven. Het lijkt eerder een memory leak.

De foutmelding kan je iig verder helpen met het zoeken naar de specifieke foutmelding.

Nou, het is artikel is misschien iets minder eenvoudig dan je zou denken. Die ene tag {gallery} genereert een image gallery met ca. 15 foto's van ca. 100 kb.
Mogelijk veroorzaakt dat die error, en het zou ook verklaren waarom sommige pagina's wel de error geven en andere niet.
Of denk jij dat met een memory_limit van 8M je dit makkelijk zou moeten redden? Dan is het misschien gewoon een slecht geschreven plug-in.

[NMe]

Een JPEG van 100KB heeft afhankelijk van de afmetingen/compressie wel meer nodig een paar MB, en dan heb jij er ook nog eens meer dan eentje... Wat je aan geheugen nodig hebt is 4 bytes per pixel (RGBA), dus breedte * hoogte * 4. Een simpel plaatje van 1000 x 1000 pixels bewerken kost je dus al 4MB aan geheugen. Hoe je die limiet verhoogt kan Google je wel vertellen, daar heb je ons niet voor nodig. Ik kan je helaas wel vertellen dat de kans dat je host je hierbij gaat helpen (wat nodig is) nihil is, zeker op een shared hosting-bak.

[ReenL]

Of denk jij dat met een memory_limit van 8M je dit makkelijk zou moeten redden?

Heel erg afhankelijk van de exacte werking van het script en de groote van je plaatjes zoals NMe zegt.

Ik zie dat die plugin een debug mode heeft, misschien dat die je nog iets nuttigs kan vertellen.

Check daarna even of je cache-map van joomla schrijfbaar is.

You also have to make sure that Joomla's /cache folder is writable, in other words, check that the permissions for this folder are 755 or 777.

[ericck]

Hoe je die limiet verhoogt kan Google je wel vertellen, daar heb je ons niet voor nodig. Ik kan je helaas wel vertellen dat de kans dat je host je hierbij gaat helpen (wat nodig is) nihil is, zeker op een shared hosting-bak.

Viel mee. De XS4ALL helpdesk ging akkoord, op voorwaarde dat ik conservatieve settings zou gebruiken. Wat mij betreft prima, als 16M voldoende is dan gebruiken we 16M :-)

Check daarna even of je cache-map van joomla schrijfbaar is.

Cache deed het goed. Al ook al even cache cleanup gedaan voor de zekerheid, maar zit blijkbaar echt in de memory_limit.

Nu alleen het volgende probleem: dit handige (NOT!) scriptje Dreamhost Auto PHP.ini gebruikt, omdat een lege PHP.ini met één regel over memory_limit niet werkte, maar die heeft alles verknoeid. Alle PHP files geven nu een foutmelding dat ze "not found on server" zijn.

[NMe]

Zet dan gewoon met .htaccess je memory_limit hoger?

[Frerk]

En als je ze nou eens een voor een laad, en niet ze allemaal tegelijk? Met 4MB per .jpg moet dat met 8MB te doen zijn.

[NMe]

Frerk schreef op dinsdag 23 november 2010 @ 08:48:
En als je ze nou eens een voor een laad, en niet ze allemaal tegelijk? Met 4MB per .jpg moet dat met 8MB te doen zijn.

Voor resize-acties heb je sowieso tenminste 2 afbeeldingen in het geheugen nodig.

[LuCarD]

ericck schreef op maandag 22 november 2010 @ 21:47:
[...]

Viel mee. De XS4ALL helpdesk ging akkoord, op voorwaarde dat ik conservatieve settings zou gebruiken. Wat mij betreft prima, als 16M voldoende is dan gebruiken we 16M :-)


[...]

Cache deed het goed. Al ook al even cache cleanup gedaan voor de zekerheid, maar zit blijkbaar echt in de memory_limit.

Nu alleen het volgende probleem: dit handige (NOT!) scriptje Dreamhost Auto PHP.ini gebruikt, omdat een lege PHP.ini met één regel over memory_limit niet werkte, maar die heeft alles verknoeid. Alle PHP files geven nu een foutmelding dat ze "not found on server" zijn.

Heb je enig idee wat dat script doet?

Ik heb er even naar gekeken, en een poging gedaan door de obscurification heen te kijken. Het ziet er naar uit dat dit script weer andere scripts download. Deze loopt te installeren in de LAMP omgeving.
Volgens mij probeerd hij een Zend_Extension te installeren.

Zonder 100% zeker te zijn zou ik dit script nooit en te nimmer op een server of test omgeving draaien. Dit is IMHO Malware/Virus of iets dergelijks.

[edit]
Kan natuurlijk zijn dat het wel een legitieme Zend_Extension zijn, maar gezien de moeite die de schrijver heeft genomen om het script onleesbaar te maken. Ik Vertrouw het niet

[ Voor 7% gewijzigd door LuCarD op 23-11-2010 11:50 ]