Seit einiger Zeit kann man die Kategorieliste nicht mehr bearbeiten (V4.5.0) - auch das Upgrade auf V4.5.1 hat nichts eingebracht.
Sobald man in der Adminansicht eine existierende Kategorie anklickt, um sie zu bearbeiten, erhalte ich folgenden Fehler:
Fatal error: Out of memory (allocated 31195136) (tried to allocate 16 bytes) in /[…]/core/oxbase.php on line 1192
oder
Fatal error: Out of memory (allocated 31195136) (tried to allocate 49 bytes) in /[…]/core/oxbase.php on line 325
an beiden Stellen (V4.5.1) wird etwas mit longnames gemacht.
Momentan kann mein Kunde keine Kategorieen mehr erfassen. Wie löse ich das Problem, bitte dringend um Hilfe.
memory_limit ist auf 90M gesetzt…
Hallo RocknRole - sicher dass 90 M auch für den Kunden gesetzt ist?
PHP macht hier bei 32 MB Speicher dicht …? Testhalber setze mal den Wert fürs memory_limit unter 30 MB. Wäre interessant ob dann mehr als 16 oder 49 Byte nicht mehr reinpassen…
Hallo Thomas,
Stimmt das ist komisch - angezeigt werden via phpinfo(); 90MB, aber 32MB ist offensichtlich das limit…
ich habe in der php.ini folgendes gesetzt:
memory_limit 20M
—>
Gleiches Ergebnis- es fehlen wieder die gleiche Anzahl bytes bei ca. 32M allociertem Speicher…
Macht der shop im php selbst einen ini_set irgendwo?
VG
RocknRole
Also - eine wichtige Info noch:
Der Hoster ist 1&1.
Laut FAQ zieht die php.ini NUR im Verzeichnis, in dem sie liegt, NICHT in den Unterverzeichnissen.
Ich habe die php.ini ins admin Verzeichnis kopiert und jetzt sind die oberen beiden Fehler weg, die Kategoriefelder werden geladen, aber ich erhalte nun einen neune Fehler:
Fatal error: Out of memory (allocated 33292288) (tried to allocate 311296 bytes) in /[…]/tmp/a435dcfc52bd1103d7f91233cf5842f3^%%E9^E91^E91AD39C%%bottomnaviitem.tpl.php on line 8
eine php.ini im tmp Verzeichnis bring nichts…
Irgendwelche Vorschläge?
VG
RocknRole
Kennt sich irgend jemand mit dem Problem aus? Was kann ich tun, außer das Projekt abzublasen? - Scherz beiseite - wenn so etwas im Echtbetrieb passiert, Prost Mahlzeit…
Was kann man konkret unternehmen, um den Fehler einzugrenzen, man kann auch keine Kategorien mehr anlegen. Fakt ist - ich brauche schnelle Hilfe, ansonsten kann ich das mit dem Oxid Shop vergessen und muss irgendwie die Daten in ein anderes System übernehmen…
Gibt es außer dem Forum einen professionellen Support?
VG
RocknRole
Wie - wir sind also nicht professionell? 
Klar gibts auch einen hauseigenen Support von Oxid -> http://www.oxid-esales.com/de/service/consulting/onlineshop-service/matrix, wobei ich das Memory-Problem eher beim Hoster sehe…
Kannst Du nicht das globale Memory-Limit hochsetzen?
Natürlich gibts hier NUR Profis !!!
Zum Hoster - 1und1 ist jetzt nichts Exotisches - wenn ich mir die Marktanteile anschaue dann kann auch ein Oxid Shop System das nicht unberücksichtigt lassen.
Laut 1und1 Doku wirkt sich eine php.ini - mit der ich das memory limit beeinflussen kann - nur im jeweiligen Verzeichnis aus - wie kann ich demnach das globale memory Limit hochsetzen?
Der Kunde hat keinen Root - Server.
Gibt es wenigstens irgendwelche Mindest-Systemvorraussetzungen in Abhängigkeit der Artikel / Kategorien? Wenn es nachvollziebare Hinweise gibt, kann man ja das Paket upgraden, aber so ins Blaue ohne fundierte Facts mit try & error läuft das nur im Labor…nicht im Echtbetrieb.
Am liebsten wäre mir ein Hint wie ich den fatal Error im tmp Verzeichnis umgehen könnte… Wer kennt sich so gut aus?
also im /tmp wundert mich das etwas…
das hier kennst Du?
und ein kleiner Helfer zum php.ini "verteilen"
http://www.oxid-esales.com/forum/showthread.php?t=9262#post54891
Also auch mein Shop ist bei 1&1 auf einem managed server und da kann ich das memory Limit selbst setzen, für die Bearbeitung von (vielen) Kategorien werden 128 MByte benötigt
mfG
Michael
Vielen Dank für die Tipps - ich habe das gleich ausprobiert - obwohl ich die CE Edition im Einsatz habe, habe ich mir nach 1&1 Anleitung den ZendOptimizer installiert und die php.ini mit dem von Hebsacker (Danke!) geposteten Script verteilt.
Jetzt mal folgende Ergebnisse -
Ich bekomme das noch nicht so richtig logisch auf die Reihe, deswegen hier mal eine Art Matrix, dessen was ich gemacht habe und zu welchen Ergebnissen das geführt hat:
[B]1. Konstellation:[/B]
KEINE PHP.ini
- Die Oxid Systeminfo zeigt 90MB mermory_limit an.
- beim Anzeigen einer Kategorie bekomme ich die initial beschriebenen Fehler in oxbase:
Fatal error: Out of memory (allocated 31195136) (tried to allocate 16 bytes) in /[…]/core/oxbase.php on line 1192
Fatal error: Out of memory (allocated 31195136) (tried to allocate 49 bytes) in /[…]/core/oxbase.php on line 325
–> Beobachtung: Er steigt nach [B]32M[/B] aus, obwohl laut phpinfo() [B]90 MB[/B] zur Verfügung gestellt werden. ???
[B]2. Konstellation: [/B]
PHP:INI auf 128MB gesetzt, die ini befinded sich NUR im ADMIN Verzeichnis
- Die Oxid systeminfo zeigt 128MB mermory_limit an.
- beim Anzeigen der Kategorien, kommen jetzt die Eingabefelder, aber ich erhalte ganz am Ende einen anderen Fehler im TMP Verzeichnis:
Fatal error: Out of memory (allocated 33292288) (tried to allocate 311296 bytes) in /[…]/tmp/a435dcfc52bd1103d7f91233cf5842f3^%%E9^E91^E91AD39C %%bottomnaviitem.tpl.php on line 8
–> Beobachtung: Er steigt ebenso nach [B]32M[/B] aus, obwohl laut phpinfo() [B]128 MB[/B] zur Verfügung gestellt werden.
[B]3. Konstellation:[/B]
PHP ini mit 128MB in alle Shop Unterverzeichnisse verteilt, via Helferscript:
- exakt gleiches Verhalten, wie in Konstellation 2
[B]4. Konstellation:[/B]
PHP Ini mit Zendoptimizer und 128MB memory_limit in allen Unterverzeichnissen:
- Die Oxid systeminfo zeigt 128MB mermory_limit an.
- beim Anzeigen einer Kategorie bekomme ich die initial beschriebenen Fehler in oxbase:
Fatal error: Out of memory (allocated 31195136) (tried to allocate 16 bytes) in /[…]/core/oxbase.php on line 1192
Fatal error: Out of memory (allocated 31195136) (tried to allocate 49 bytes) in /[…]/core/oxbase.php on line 325
–> Beobachtung: Er steigt nach [B]32M[/B] aus, obwohl laut phpinfo() [B]128 MB[/B] zur Verfügung gestellt werden.
So - das ist für mich jetzt nicht mehr logisch erklärbar…?
Warum steigt das script egal mit welcher Konfig immer nach 32MB aus, obwohl viel mehr zur Verfügung stehen?
Warum funktioniert mit dem ZendOptimizer noch weniger? Der ist ja fpr PE/EE Pflicht oder nicht?
Fragen über Fragen…
Ach ja php V5.2.17…
VG
RocknRole
Einfach die htaccess vom Oxid Shop bearbeiten und folgenden Eintrag hinzufügen:
" php_value memory_limit 128M "
Dies kann man für jeden Ordner einzeln mit entsprechender htaccess erledigen.
Freundliche Grüße
über .htaccess habe ich das auch versucht:
<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
RewriteCond %{REQUEST_URI} oxseo.php$
RewriteCond %{QUERY_STRING} mod_rewrite_module_is=off
RewriteRule oxseo.php$ oxseo.php?mod_rewrite_module_is=on [L]
RewriteCond %{REQUEST_URI} !(/admin/|/core/|/export/|/modules/|/out/|/setup/|/tmp/|/views/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !(.html|/|.jpg|.css|.pdf|.doc|.gif|.png|.js|.htc)$ %{REQUEST_URI}/ [R=301,L]
RewriteCond %{REQUEST_URI} !(/admin/|/core/|/export/|/modules/|/out/|/setup/|/tmp/|/views/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.html|/)$ oxseo.php
RewriteCond %{REQUEST_URI} (/out/pictures/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.jpg|.gif|.png)$ core/utils/getimg.php
</IfModule>
disabling log file access from outside
<FilesMatch “(EXCEPTION_LOG.txt|.log$|.tpl$|pkg.rev)”>
order allow,deny
deny from all
</FilesMatch>
Options -Indexes
DirectoryIndex index.php index.html
php version:
-------------------------------------------------------------------------------
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php
php_value memory_limit 128M
Das Resultat:
INTERNAL SERVER ERROR 500
Hat niemand mehr eine Idee?
Wo sind die Oxid Entwickler?
Hallo,
das hat nix mit OXID und auch nix mit Entwicklern zu tun.
Du hast wahrscheinlich nur die php.ini nicht in alle Unterordner kopiert. Bitte kopier Deine selbsterstellte php.ini auch in Verzeichnisse wie /admin/, /core/ und /modules/.
Gruß
Hallo Marco,
ich habe die PHP.ini mit dem im Thread beschriebenen PHP Script in alle Unterverzeichnisse kopiert - siehe Tip auf der ersten Seite des Requests…
Ich bin leider im Moment ratlos, da das verhalten nicht logisch nachvollziehbar ist, siehe Kommentar 11.
Was kann ich noch tun?
VG
RocknRole
In der Tabelle oxcategories sind 995 Sätze.
Hat jemand einen Oxid Shop mit so vielen Kategorien im Einsatz oder gibt es da eine Begrenzung? Ist der Oxid shop dafür geeignet?
Hi,
[QUOTE=RocknRole;66281]In der Tabelle oxcategories sind 995 Sätze.
Hat jemand einen Oxid Shop mit so vielen Kategorien im Einsatz oder gibt es da eine Begrenzung? Ist der Oxid shop dafür geeignet?[/QUOTE]
Natürlich, solche Konstellationen gibt es und das schafft der Shop auch. Kümmern wir uns um die Fehlermeldung? Kannst Du mal eine separate phpinfo erstellen (Du weißt, wie das geht?) und das dort angezeigte memory_limit hier posten?
Gruß
Und nicht zu vergessen: Nenn uns endlich mal das Hostingpaket beim Namen
mfG
Michael
Liebe Leute,
bitte nicht arrogant werden…wie könnt ihr so sicher sein, dass Ihr es mit einem DAU zu tun habt?
… ein alt bekanntes Leiden unter uns IT´lern nicht wahr?
Aber lassen wir das…
Hier die Infos:
Hosting Paket: 1&1 Homepage Perfect,
Plattenplatz 1.714,00 MB von 5.000,00 MB
Mysql V5.0, 86,95 MB von 100MB frei
Zur phpinfo - aufgerufen aus dem Shop Root:
PHP Version 5.2.17
Configuration
PHP Core
Directive Local Value Master Value
memory_limit 128M 128M
Was könnte sonst noch hilfreich sein?
VG
RocknRole
ach ja - eins noch:
Das Shop Root entspricht nicht dem DOCUMENT_ROOT. die php.ini ist aber ab Shop Root in alle Unterverzeichnisse verteilt.
[UPDATE]
PHP.ini ist jetzt vom Document_Root in alle Unterverzeichnisse verteilt.
Trotzdem bekomme ich den Fehler aus dem tmp Verzeichnis…
Wenn keiner mehr eine Idee hat werde ich wohl mal den kompletten shop auf meinem lokalen Webserver installieren und schauen, ob der Fehler immer noch bleibt…
- Vorgehensweise: db_dumb, komplette Verzeichnisstruktur kopieren und htaccess anpassen.
Gibt es sonst noch was zu beachten?