Seit etwa einer Woche haben wir bei einem Kunden (webEdition Version 5.1.1.1.) folgendes Problem:
Wenn bestimmte Objekte (scheint von der Klasse abzuhänge) zum Bearbeiten geöffnet werden (oder auch neu erstellt), kann die "Bearbeiten"-Seite nicht dargestellt werden. Es kommt zu einem Serverfehler 500. An den Klassen hat sich seit ihrer Erstellung nichts geändert, es wurde auch kein webEdition-Update eingespielt. Sobald das Problem aufgetreten ist, kann man auch nicht mehr auf einen anderen Reiter wechseln.
Da sich andere Objekte (mit weniger Feldern!) einwandfrei darstellen und bearbeiten lassen, vermute ich einen Bug in webEdition.
Ist da etwas in dieser Richtung bekannt, was hier Auslöser sein könnte?
Auf Version 6 will ich nicht updaten, da uns ein Update von V5 auf V6 schon ein anderes Projekt komplett zerlegt hat.
Danke und Grüße
Christian Brandl
Objekte: Bearbeiten-Modus bricht mit Server-Fehler 500 ab
Hast Du mal versucht die Klasse nicht zukopieren, sondern nachzubauen? Ist natürlich keine Lösung, aber grenzt das Problem vielleicht weiter ein.
Wie gross ist denn die problematische Klasse (Anzahl Felder)? In Zusammenhang mit einem niedrigen memory_limit kann es da sicher auch zu Problemen kommen.
Wie gross ist denn die problematische Klasse (Anzahl Felder)? In Zusammenhang mit einem niedrigen memory_limit kann es da sicher auch zu Problemen kommen.
-
- Senior Member
- Beiträge: 420
- Registriert: Mo 13. Nov 2006, 12:23
- Wohnort: Olsztyn, zuvor Warszawa
- Kontaktdaten:
So ein drastische Problem habe ich nicht, aber ähnlich.
In einer Klasse komme ich im Bearbeiten-Modus bei einem Objekt nicht mehr an ein Textfeld (Typ Textarea wysiwyg=false) heran. Es betrifft aber bislang nur einen Artikel. Mit phpmyadmin schaue ich in den Datensatz, der sich nicht von den anderen unterscheidet.
Ich verwende bislang 64 Klassen mit -zig Objekten, aber so ein Fall tritt jetzt erstmals auf (Mit allen Browsern auf WIN und MAC)
In den Textfeldern dieser einen Klasse arbeite ich aber mit Links, die als html-Code per Hand geschrieben werden (das war aber noch nie ein Problem).
Kopiere ich das Objekt, tritt der Fehler ebenfalls auf. Lege ich ein neues Objekt an, ist alles normal.
Verwendete WE-Version 5.1.1.9
Nachtrag 1: gehe ich in die Vorschau, ist der Text da.
Nachtrag 2: In meinem Fall habe ich den Fehler gefunden, aber noch nicht die Ursache.
Um nicht am offenen Herzen zu operieren (dem Online-Projekt), suchte ich in einem gespiegelten Inhalt (mit WE-Version 6.0.0.1).
Schrittweise habe ich bei dem betroffenen Feld die Inhalte eingesetzt. Irgendwann trat der Fehler wieder auf. Durch die Versionierung (eine feine Sache!) konnte der vorherige Zustand wieder hergestellt werden. Die Versionierung zeigte auch die Änderungen an: -Inhalt, -Ist durchsuchbar, -Sprache, -Zeichensatz
Das ist interessant, weil ich nur einen Textblock dazu gegeben hatte. Da das Textfeld vom Typ Textarea mit wysiwyg=false ist, sollte eigentlich keine Textformatierung, gleich recht nicht Sprache und Zeichensatz mitgegeben werden. Oder?
Aber genau da lag der Fehler.
In einer Klasse komme ich im Bearbeiten-Modus bei einem Objekt nicht mehr an ein Textfeld (Typ Textarea wysiwyg=false) heran. Es betrifft aber bislang nur einen Artikel. Mit phpmyadmin schaue ich in den Datensatz, der sich nicht von den anderen unterscheidet.
Ich verwende bislang 64 Klassen mit -zig Objekten, aber so ein Fall tritt jetzt erstmals auf (Mit allen Browsern auf WIN und MAC)
In den Textfeldern dieser einen Klasse arbeite ich aber mit Links, die als html-Code per Hand geschrieben werden (das war aber noch nie ein Problem).
Kopiere ich das Objekt, tritt der Fehler ebenfalls auf. Lege ich ein neues Objekt an, ist alles normal.
Verwendete WE-Version 5.1.1.9
Nachtrag 1: gehe ich in die Vorschau, ist der Text da.
Nachtrag 2: In meinem Fall habe ich den Fehler gefunden, aber noch nicht die Ursache.
Um nicht am offenen Herzen zu operieren (dem Online-Projekt), suchte ich in einem gespiegelten Inhalt (mit WE-Version 6.0.0.1).
Schrittweise habe ich bei dem betroffenen Feld die Inhalte eingesetzt. Irgendwann trat der Fehler wieder auf. Durch die Versionierung (eine feine Sache!) konnte der vorherige Zustand wieder hergestellt werden. Die Versionierung zeigte auch die Änderungen an: -Inhalt, -Ist durchsuchbar, -Sprache, -Zeichensatz
Das ist interessant, weil ich nur einen Textblock dazu gegeben hatte. Da das Textfeld vom Typ Textarea mit wysiwyg=false ist, sollte eigentlich keine Textformatierung, gleich recht nicht Sprache und Zeichensatz mitgegeben werden. Oder?
Aber genau da lag der Fehler.
Da auf dem Server eine selbstentwickelte Community-Lösung läuft und sich das System aus der Kombination 1 Webserver, 1 DB-Master, 2 DB-Slaves zusammensetzt, schließe ich das mal aus.deemes;49788 hat geschrieben:Wie gross ist denn die problematische Klasse (Anzahl Felder)? In Zusammenhang mit einem niedrigen memory_limit kann es da sicher auch zu Problemen kommen.
Aber danke für den Hinweis.
Ich werde eine der betroffenen Klassen mal nachbauen .. mal sehen ob es dann auftritt. Wenn ich die Objekte erst als "Vorschau" anzeigen lasse, sind die Inhalte da und auch der externe Aufruf innerhalb der Website funktioniert einwandfrei.
Ich kann nur keine neuen Objekte anlegen oder alte bearbeiten, weil der Bearbeiten-Modus den 500er Fehler verursacht.
Grüße
Christian Brandl
Re: Objekte: Bearbeiten-Modus bricht mit Server-Fehler 500 ab
Hallo allerseits,
was ist denn nun die Lösung? Bei mir tritt der Fehler mit dem nicht bearbeitbaren Textfeld in einem Objekt auch auf.
Viele Grüße
joschi81
was ist denn nun die Lösung? Bei mir tritt der Fehler mit dem nicht bearbeitbaren Textfeld in einem Objekt auch auf.
Viele Grüße
joschi81
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast