Bei einem Kunden, der viele Artikelattribute hat, tritt plötzlich das Problem auf, dass die Attribute nicht mehr geändert werden können. In meiner lokalen Umgebung funktioniert das weiterhin. Durch Debugging auf dem Server habe ich festgestellt, dass nicht mehr alle Werte des Attribute-Formulars an den Server übertragen werden, insbesondere auch nicht die gewünschten Attribut-Werte In den POST-Daten von FireBug fand ich dann diese merkwürdige Meldung: Was das Verhalten erklären würde... Kann man beim APACHE-Server die zulässige Größe des POST-Daten-Bereichs konfigurieren? Hat jemand eine Idee?
Also mein post_max_size ist bei 24M (apache) das ist ja eigentlich eine ganze Menge. Sollte das post_max_size bei deinem Kunden etwa zu klein sein? Aufschluss gibt die php.ini
Das habe ich mir auch schon gedacht.... "max_input_vars" könnte es auch sein, der ist derzeit auf 1000 begrenzt, und bei so vielen Attributen und dem plötzlichen Auftreten des Problems irgendwie plausibel.
Guten Morgen, das liegt an dem PHP Suhosin Patch, der die max_input_vars beschränkt. Standard ist 1000. Wir empfehlen dort einen Wert nahe 10000 (bisher keine weiteren Probleme gehabt). MfG, Timo
Hi, eine elegantere Lösung wäre die Elemente die nicht benötgt werden erst gar nicht zu übertragen. Dafür hab ich die /admin/includes/modules/new_attributes_include.php angepasst. Hab alle Felder die nicht gechecked sind mit dem Attribut "disabled=true" deaktiviert. Dann noch ein wenig jQuery am Ende der Datei eingefügt, damit nur die Felder aktiviert und deaktiviert werden, wenn man eine Checkbox aktiviert. Jetzt werden nur noch die Felder per POST übergeben, wo auch die Checkbox aktiviert ist, somit kommt man nicht mehr an die max_input_vars 1000er Grenze und die Attribute werden ohne Probleme gespeichert. Im Anhang findet ihr die angepasste Datei. Einfach in den Ordner /admin/includes/modules/ kopieren und die vorhandene Datei überschreiben. Sicherung der alten Datei nicht vergessen.
Das sieht doch nach einer sehr guten Lösung aus! Allerdings gibt es zwei Probleme mit dem Javascript: Das Skript darf erst bei "document ready" ausgeführt werden, da sonst u.U. (und browserabhängig!) bei vielen Attributen "$('input[type=checkbox]').click(" ausgeführt wird, bevor alle Elemente geladen sind.... Die "Select"-Boxen werden nicht "enabled. Hier meine Skript-Version, die das löst: PHP: <script type="text/javascript">//Avenger$(document).ready(function(){ $('input[type=checkbox]').click(function() { $(this).closest('tr').find('input, select').not('input[type=checkbox]').attr('disabled', !$(this).is(':checked')); });});//Avenger</script>
Lieber Avenger, lieber Till, das ist sehr cool, denn plötzlich werden unsere Attribute wieder gespeichtert (yippie, ein Ticket weniger). Aber vielleicht geht da noch was: Mich nervt es seit Jahren, dass ich bis zur Ohnmacht scrollen muss, um an die entsprechenden Attribute zu kommen. Kann man die nicht irgendwie sortieren, dass die gecheckten immer oben sind... oder so?
Ja, die Attributverwaltung ist ziemlich übel, wenn man es mit vielen Gruppen und Werten zu tun hat. Vor Jahren habe ich das deshalb für einen xtc-Shop komplett anders, und m.E. wesentlich übersichtlicher gelöst: Bei den Optionen (siehe erstes Bild) hat man auf der linken Bildschirmseite die Optionsgruppen angezeigt. Wenn man dann eine Optionsgruppe auswählt, werden auf der rechten Bildschirmseite die zu dieser Gruppe gehörenden Optionswerte angezeigt. Bei den Artikeloptionen ist es so, dass nach dem Laden nur die Gruppen geöffnet sind, aus denen für den Artikel Werte ausgewählt wurden.... Die einzelnen Gruppen kann man auf- und zu klappen, so dass man immer einen übersichtlichen Schirm hat. (Wobei man das dann auch evtl. besser mit dem in 2 Seiten geteilten Bildschirm lösen sollte.... )
Kurze Frage, dieses Skript einfach mit dem Skript am Ende der new_attributes_include von Till austauschen?
Habe gerade festgestellt dass die „Webkit“-Browser (Chrome, Safari) das im „FireFox“ funktionierende jQuery-Javascript zum aktivieren der Eingabe nicht mochten…. Ich habe das jetzt anders konstruiert, jetzt sind alle zufrieden… PHP: <script type="text/javascript">//Avenger$(document).ready(function(){ $('input[type=checkbox]').click(function() { var row,columns; row=$(this).closest('tr'); columns=row.find('input, select').not('input[type=checkbox]'); if ($(this).is(':checked')) { columns.removeAttr('disabled'); } else { columns.attr('disabled', true); } });});//Avenger</script>
Hi Avenger, welche Browserversion hast du getestet für Safari und Chrome. Folgendes Script funktioniert bei mir in allen aktuellen Browserversionen: PHP: <script type="text/javascript">$(document).ready(function(){ $('input[type=checkbox]').click(function() { if($(this).is(':checked')) $(this).closest('tr').find('input, select').not('input[type=checkbox]').attr('disabled', false); else $(this).closest('tr').find('input, select').not('input[type=checkbox]').attr('disabled', true); });});</script> Kannst du meine Variante in deinen Browsern testen?
Die Variante funktioniert... Ich hatte ja eine verkürzte Variante verwendet (die im FF wunderbar funktioniert) nicht aber in den WedKit-Browsern... PHP: (this).closest('tr').find('input, select').not('input[type=checkbox]').attr('disabled', !$(this).is(':checked'));
Sehe ich das richtig, dass die neue Dateiversion, die Till hier anbietet, nicht ins aktuelle Programmpaket oder Servicepack übernommen wurde? Wir hatten das gleiche Problem und ich habe die Datei jetzt per Forensuche gefunden. Noch besser wäre, wenn das Problem in der aktuellen Version gar nicht mehr auftreten würde.
So, wir haben uns jetzt daran versucht und es sieht aus wie immer *grübel* Kann mir bitte jemand sagen, ob es so wie auf den Miniaturansichten von Avenger aussieht, oder ob die Felder einfach nur weiß sind und man dennoch unendlich scrollen muss?
Aufgrund der Button-Lösung hat es so gut wie keine Weiterentwicklung und damit auch keine neue Shopversion gegeben. Der Fix kommt natürlich mit in die nächste Shopversion 2.0.11.
Hallo, war froh endlich eine Lösung für dieses Problem gefunden zu haben. Leider müsste die Datei eine php sein, keine css (eben adäquat zur Originaldatei). Könntest du bitte die Datei bitte nochmals einstellen? Sorry, bin Laie aber lernfähig!
Hallo me, willkommen im Forum. Ich habe den Fred nur überflogen, konnte aber keine css-Anpassung finden. Das sind alles PHP-Codes, die in die "new_attributes_include.php" von Till eingearbeitet werden. Vielleicht reicht Dir aber auch die Version von Till (Link nur für registrierte Nutzer sichtbar.) (Datensicherung nicht vergessen.)