Onderwerp: Log file flooding ondanks file verbod?

Op een server hebben we momenteel het probleem dat de error log met grote regelmaat geflood wordt.
Een 20 mb logfile op een paar uurtjes is geen probleem, het gaat hier om de apache errorlog. Server draait op Centos en Cpanel.

De volgende regel is eigenlijk diegene wat continu voorkomt en de flooding veroorzaakt:

[Sun Aug 14 02:57:57 2011] [error] [client 66.249.72.155] PHP Notice: Undefined variable: result in /home/usernaam/public_html/seo.php on line 117

Er zijn al verschillende seo.php bestanden geprobeerd en er zijn ook meerdere van deze creloaded shops op de server, maar alleen deze site heeft er last van. Ip is zo te zien van googlebot, dus ik dacht dat googlebot hem dan ook aanriep.
Dus dan zetten we in de robots.txt gewoon:
disallow: /seo.php
maar dat wil van geen kant helpen.

Nu hebben we in een bestaande .htaccess als eerste regeltjes het volgende opgenomen:

<Files seo.php>
order allow,deny
deny from all
</Files>

Maar toch was er vannacht opnieuw weer flooding met diezelfde alsboven genoemde error op seo.php.
Ook al geprobeerd een seo.php te kopiëren van een shop die geen last heeft maar ook dat mag niet baten.

Wat doen we fout? Hoe kan het dat ondanks deze "deny from all" toch nog deze melding kan komen?
En hoe komen we nu van deze logfile floodings af? Afgezien dan van creloaded om support vragen...

Kijk in je php.ini (of custom php.ini binnen de user) om de error_reporting aan te passen

Code:

error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED

Dit toont de notice & deprecated errors niet meer maar al de rest wel, zo krijg je die notice ook niet meer in je error log van apache.

Of optie 2 je kijkt in de seo.php op lijn 117 welke vars er undefined zijn en maakt deze variable aan voor lijn 117 (bvb: $var = ""; of $var = array; ).

Hiermee verhelp je alleen de symptomen, het daadwerkelijke probleem blijft.
Zelfs een notice is gewoon een bug. En die behoren te worden opgelost.

Beste is dus om contact te zoeken met de ontwikkelaar(s).
Gezien dat het feit dat je er voor betaald, is dat niet meer dan normaal.

OT/rant:
Als ik kijk op de website zie ik dat seo een extensie is.
http://www.creloaded.com/Extensions/...CDpath=187_194

Code:

Example of Category URL
Before: /index.php?cPath=30
Optimized: /Mens/c30/index.html

Example of Product URL
Before: /product_info.php?cPath=30&products_id=53
Optimized: /Mens/c30/p53/poloshirt/product_info.html

* Smylie die over de grond ligt van het lagen *
Serieus, de idioot die extensie heeft gemaakt zou 100 strafregels moeten schrijven dat hij dit geen SEO mag noemen.
Het enige dat hij nu doet is de parameters omzetten naar mappen. Nee dat maakt het duidelijker zeg.

SEO is meer in de trend van dit: /Dames/Broeken/53-Wrangler-versleten-look.html


Edit:

Maar alleen deze site heeft er last van.

Draait hij toevallig op een oudere versie?

@The-Boss: Ik had inderdaad liever het probleem opgelost dan de logs te beperken. Middels de logs kan ik dan sneller fouten ontdekken als die er zijn.
Dit is een stukje code uit die seo.php:

Code:

              $cat_name = tep_db_fetch_array( $sql_query );
              if( !$count ){
                $result .= encode_str($cat_name['categories_name']);
                $count = true;
              } else {
                $result .= '-' . encode_str($cat_name['categories_name']);
              }
            }
            $cat = $result;

Waarvan de derde regel nummer 117 is, dus deze:

Code:

$result .= encode_str($cat_name['categories_name']);

@Rollerscapes: Dat omvormen naar html wordt voor die seo volgens mij gedaan met een doos rewrite rules in de .htaccess waarvan dit er enkele zijn.

# cre SEO reformat for index.html pages
RewriteRule ^m(.*)/(.*)/p(.*)/(.*)/index\.html$ index.php?manufacturers_id=$1&products_id=$3 [QSA,L]
RewriteRule ^m(.*)/(.*)/index\.html$ index.php?manufacturers_id=$1 [QSA,L]
RewriteRule ^(.*)/c(.*)/m(.*)/(.*)/p(.*)/(.*)/index\.html$ index.php?cPath=$2&products_id=$5 [QSA,L]
RewriteRule ^(.*)/c(.*)/p(.*)/(.*)/index\.html$ index.php?cPath=$2&products_id=$3 [QSA,L]
RewriteRule ^(.*)/c(.*)/index\.html$ index.php?cPath=$2 [QSA,L]

Vandaar krijg ik ook van deze zooi te zien, zij het een stuk weiniger:

[Sun Aug 14 15:13:31 2011] [error] [client 200.11.75.102] PHP Notice: Use of undefined constant TEXT_PRODUCT_DATE_ADDED - assumed 'TEXT_PRODUCT_DATE_ADDED' in /home/user/public_html/admin/categories.php on line 3229
[Sun Aug 14 15:13:31 2011] [error] [client 200.11.75.102] PHP Notice: Undefined property: objectInfo::$products_date_added in /home/user/public_html/admin/categories.php on line 3229
[Sun Aug 14 15:13:31 2011] [error] [client 200.11.75.102] PHP Notice: Undefined variable: products_name in /home/user/public_html/admin/categories.php on line 3129

Volgens de gebruiker draait ie de laatste versie. Waar kan ik dat het beste checken?

een echte oplossing is het niet, maar maak er van

PHP Code:

@$result .= encode_str($cat_name['categories_name']); 


en je krijgt geen foutmelding meer en het verandert het script ook niet

Bedankt T.Bloo, ik ga het meteen proberen want een custom php.ini plaatsen hield helaas de foutmeldingen ook niet tegen.
Dus in feite gewoon een apastaartje ervoor zetten als ik het goed zie. Een echte oplossing moet betreffende zelf maar even regelen met de maker van de plugin. Als het vollopen van de logs maar effe stopt. Thanks!

Onderwerp van een paar weken oud maar het probleem speelt nog steeds maar dan weer met andere bestanden.
Ik heb nu in de php.ini de voglende regel staan:
error_reporting = E_ALL & ~E_NOTICE

Dus zou ik geen notices meer moeten zien in de log, toch vindt er log flooding plaats met dit soort dingen.

[Mon Sep 05 14:15:04 2011] [error] [client 66.249.71.139] PHP Notice: Undefined variable: page_set in /home/user/public_html/shop-xxxxxx/includes/modules/product_listing.php on line 42
[Mon Sep 05 14:15:04 2011] [error] [client 66.249.71.139] PHP Notice: Undefined variable: page_set in /home/user/public_html/shop-xxxxx/includes/modules/product_listing.php on line 42
[Mon Sep 05 14:15:03 2011] [error] [client 66.249.71.139] PHP Notice: Constant FILENAME_AFFILIATE_SIGNUP already defined in /home/user/public_html/shop-xxxxx/includes/filenames.php on line 336
[Mon Sep 05 14:15:03 2011] [error] [client 66.249.71.139] PHP Notice: Use of undefined constant CONTENT_AFFILIATE_TERMS_POPUP - assumed 'CONTENT_AFFILIATE_TERMS_POPUP' in /home/user/public_html/shop-xxxxx/includes/filenames.php on line 340

Allemaal PHP Notice dus. Maar hoe kan het dat deze nog weergegeven worden terwijl het in de globale php.ini uitgeschakeld staat?
Er staat geen php.ini in de directory van de gebruiker.
In de .htaccess staat ook niets over php logging.

maak even een phpinfo aan op de site van de klant, en check of het wel echt uit staat (en of die niet stiekem een andere php.ini gebruikt bijv)

Heb je apache/httpd wel herstart na je aanpassing?

Mbt $result en $page_set: de foutmelding is redelijk simpel; ze bestaan gewoon niet. Met .= ga je namelijk aan een bestaande variabele de waarde uitbreiden met de daarachter staande waarde. Als de variabele niet bestaat dan zal je inderdaad die foutmelding krijgen.

@Wijtec: Er stond een php.ini die ik zelf geplaatst had, daarin stond hetzelfde, maar die heb ik nu weggehaald.
Dit zie ik in de phpinfo:
error_reporting 6135 6135 (en da's e_all zonder e_notice), lijkt me dus goed.

@The-Boss: Jazekers, na elke php.ini wijziging. Het is overigens een Cpanel server dus volgens mij gebeurt dat automatisch, maar ik doe het altijd nog een keer just to be sure.

Kan het zijn dat hij het toch als een error ziet omdat het vooraan begint met [error] en later pas die php notice komt?

@Yourwebhoster: Ja ik geloof het graag, maar er zijn zoveel verschillende regels, da's afdeling voor de klant.

Je heb log_errors nodig niet error_reporting
http://www.php.net/manual/en/errorfu...ini.log-errors

Niet helemaal waar, die kun je overullen met error_reporting( nr ) ;

het probleem is dat de errors in de log komen, dat regel je met log_errors
heel veel scripts zetten hun eigen error_reporting dus dat gaat in je ini niet zoveel uitmaken

Hmz....... Zo staat de log_errors directive:
log_errors Off On

Dus lokaal uit en master op aan.
Ik heb weinig interesse om de master ook op uit te zetten aangezien je toch wel graag wilt weten wat er mis is als er een klant problemen heeft.

Ik dacht net dat je met die error_reporting bepaalde welke errors er (mede) in je log kwamen te staan.

Ik zal nog eens proberen met "php_flag log_errors off" in zijn .htaccess te zetten, kijken of dat dan beter gaat.
Dat is namelijk waar ik nu testte het geval, maar niet bij die waar het mis ging zag ik net.

Dit krijg je al als je alleen al de hoofdpagina bezoekt.

[Mon Sep 05 17:31:39 2011] [error] [client 195.240.xx.xx] PHP Notice: Constant MODULE_PAYMENT_PAYPAL_DEFAULT_CURRENCY already defined in /home/user/public_html/shop-soxxx/includes/application_top.php on line 96, referer: http://www.xxxxx.nl/

Toch nog maar eens de gebruiker aanspreken op zijn zootje.