TinyMCE speichert nicht, Bildschirm wird nicht upgedatet

**Piet** · 11.10.2009, 16:10

Hallo

Ich habe bei einer neuen Installation bei all-Inkl ein seltsames Verhalten im Backend. (Meine erste bei All-Inkl)

Beispiel: Ich will einen Artikel anlegen. Fenster kommt, ich wechsle von Text auf Überschrift im Elementtyp, aber keine Änderung der Eingabefelder.

Ich gehe auf Text, gebe im TinyMCE Text ein, aber TL behauptet beim Speichern ständig, dass ich ohne Inhalte verlassen will.

Ich dachte zuerst an den Browser und habe verschiedene Browser ausprobiert. Gleicher Effekt.

Dann mit dem gleichen Fenster auf einer anderen Domain bei 1&1-Installation. Tut einwandfrei.

Dann Test mit veränderten Parametern für die Firewall. Gleiches Problem.

Es liegt wohl an der Installation auf all-inkl.

Hat jemand einen Hinweis, dem ich gerade noch folgen kann. Bitte schnell.

Piet

**MacKP** · 11.10.2009, 16:18

Hallo Piet,
mit der Suche wärst du noch schneller gewesen..
aber hier die passenden Threads für dich :
https://community.contao.org/de/showthread.php?t=66
https://community.contao.org/de/showthread.php?t=42

Du hast die Einstellungen einfach noch nicht CMS gerecht vorgenommen bei all-inkl....

Viel Erfolg noch

**planepix** · 11.10.2009, 16:21

Hallo Piet,

und einmal nachschauen, ob in den Einstellungen das URLs umschreiben aktiv ist und die htaccess Datei anstatt .htaccess noch ._htaccess lautet.

**Piet** · 11.10.2009, 16:34

Hallo

Ich hatte schon gesucht und ich habe bei All-Inkl schon vor der Installation den PHP-FastCGI - Mode eingeschaltet. (ohne SMH)

Ich wäre davon ausgegengen, dass es klappt, aber ....

Ich habe auch gzip nun mal ausgeschaltet, ohne Erfolg.

Den gesamten TinyMCE-Bereich habe ich nochmal neu "upgeloaded".

Muss ich wirklich nochmal komplet neu installieren? Würde mich nerven. Ein Teil der Daten ist nämlich schon drin.

Weitere Tipps zur Fehlersuche?

Piet

Ergänzung 18:05; neuer Stand
Datenbank belassen, komplette Neuinstallation von TL, localconfig angepasst, .htaccess angepasst. FastCGi-Mode müsste laufen.

Arbeit ohne TinyMCE möglich, aber dass die Umschaltung der Elementtypen im Backend nicht zu einer Anpassung der weiteren Felder führt, muss doch einen Grund haben. So tut man sich richtig schwer.

Das sind doch Ajax-Funktionalitäten -oder? Warum tut das hier bei All-Inkl nicht?
Was mache ich noch falsch?

Piet

**MacKP** · 11.10.2009, 17:20

Hallo Piet,
auf jeden Fall brauchen wir erst mal viel mehr Infos...
Wie sehen die Rechte der Dateien aus? eventuell mit typolight-check.php mal testen und uns nen link geben...
Ist die htaccess umbenannt?

Werden andere Änderungen gespeichert (wie zum Beispiel in den Einstellungen)?

Viele Grüße

**Piet** · 11.10.2009, 18:10

Hallo MacKP

Ich möchte das erkannte Problem gerne zweiteilen.

Ich fahre nun ohne TinyMCE und stelle dies mal zurück.
Änderungen werden nun gespeichert.

Aber die Umschaltung im Backend unter z.B. Artikel des Elementtyps geschieht nach wie vor nicht. Es tut aber nur mit dieser All-Inkl-Installtion nicht. Die anderen Installationen bei Strato, 1&1, WebhostOne laufen.

Die User und Zugriffsrechte sollten stimmen, wurden alle über den KAS-Server von All-Inkl neu gesetzt.

PHP ist 5.x, die TL-Checktools zeigen alles in grün an, es sollte alles tun.

Ich kann Dir leider aktuell keinen Zugriff oder Links auf das Backend geben. Vor dem 1.11. geht da gar nichts.

Im entsprechenden Code-Bestandteil werden Ajax-codes angesprochen. Ich nehme gerade mal an, dass diese nicht greifen. Ich bin nun die Memberarea von All-Inkl durch, ich bin die Bedienelemente des Servermanagements durch, keine weiteren Erkenntnisse.

.htaccess und localconfig.php nochmals gechecked: sieht gut aus.

Javascript, als ein Bestandteil von Ajax, läuft hier gut und sauber.

Wo hakt das? Es ist zum Heulen.

Piet

**Piet** · 11.10.2009, 19:38

Hallöchen

Scheint gelöst.
Ich beschreibe morgen "warum und wie".

**MacKP** · 11.10.2009, 19:45

Da fällt mir dann gerade auch nicht viel zu ein...
Ich weiß das es im alten Forum auch mal das Problem gab. Die Lösung kenne ich auswendig auch nicht mehr. In der Regel sinds aber Dateien die nicht ausgeführt werden können...
Nur wenn du sagst, das alles in Ordnung ist wirds schwer...

Ist TL vllt in einem Unterordner installiert und eine .htaccess vom Übergeordneten Ordner funkt dir dazwischen?

Viele Grüße

**Piet** · 12.10.2009, 03:45

Hallo MacKP

Deine letzte Zeile ging in die richtige Richtung.
Tatsächlich hatte ich versucht eine TL-Installation in einem Unterordner zu betreiben. Im Frontend scheint das im Regelfall auch keine Probleme zu geben, aber das Backend tut sich damit schwer.

Die Mootools werden damit nicht mehr angezogen und auch tinyMCE tut damit nicht mehr korrekt. Verständlich, denn der Pfad wird in TL abgelegt. TL achtet darauf, aber nicht die eingebundenen Codebestandteile.

Wieder etwas gelernt. TYPOlight ist (noch) nix für eine Installation in einem Unterordner.

Ich habe nun eine Sub-Domain auf diesen Unterordner gesetzt und damit funktioniert es. Dies kann bei Nutzung als Multidomain-Installation natürlich wieder andere Probleme aufwerfen, aber ...

Hauptsache Kunde sieht die ersten Schritte, wenn er heute aufwacht. :-)

Danke an die Community.

Piet

p.s. Damit ist natürlich auch All-Inkl von jeglicher Schuld befreit.

**Thomas** · 31.10.2009, 10:58

Ich habe gerade das selbe Problem!

Interessanter Weise, habe ich über das Backend schon einige Inhalte eingepflegt, nur aus heiterem Himmel geht es nicht mehr.

Ob es etwas mit dem Update auf 2.7.5. zutun hat?
Vorher betrieb ich 2.7.4 und hatte augenscheinlich keine Probleme.

Den Tip mit der Subdomain werde ich jetzt testen.

**MacKP** · 31.10.2009, 12:56

Wieder etwas gelernt. TYPOlight ist (noch) nix für eine Installation in einem Unterordner.

Dem muss ich mal eben wiedersprechen.. wenn alles richtig eingestellt ist sollte das überhaupt kein Problem sein.
Mit Subdomains ist nur die allgemeine Handhabung viel einfacher. Vor allem auch bei einer Live schaltung etc.

@Thomas,
aus heiterm Himmel ist immer schwierig.. in der Vergangenheit waren es meist Serverumstellungen die Probleme bereitet haben.. schau bitte einmal genauer nach was sich geändert haben könnte.
Eventuell wurde auch die localconfig.php neu geschrieben und da stimmt nu was nicht.... oder oder oder ;-)

Viele Grüße

**Thomas** · 31.10.2009, 13:26

Hallo, MackP,

Daran habe ich auch schon gedacht.
Ich habe zunächst nur Lokales synchronisiert, was unter Umständen schief gegangen sein könnte. Ich hatte darauf geachtet, das die üblichen Dateien nicht mit synchronisiert werden, aber eine Garantie ist das ja nicht.

Jetzt habe ich mir eine Live ID besorgt, was die Sache ansich einfacher gestaltet.

Eine Subdomain ist auch nicht weiter das Problem, ich hatte wenige Tage vorher schonmal darüber nachgedacht. Da ich diese als Liveumgebung für diesen Kunden nehmen wollte, um Ihm Änderungen und Erweiterungen schmackhaft zu machen.

Um mich damit wirklich näher zu beschäftigen fehlt mir leider Momentan die Zeit.
Im Laufe der nächsten Woche bilde ich eine Horde Hausfrauen im Umgang mit Windows, Word und Exel aus, so dass ich nur in Pausen an Webseiten arbeite.

Wenn etwas mehr Ruhe einkehrt und ich es nicht vergesse, schaue ich mal genauer hin.

**dl1ely** · 04.12.2009, 12:27

Leider keine Neuigkeiten an dieser Front. Bei einem ganz anderen Hoster (klein + individuell) passiert mir genau das gleiche, auch die Lösung mit der Subdomain funktioniert. Versuche gerade, ein Ticket dafür zu eröffnen. Wahrscheinlich ein Wechselwirkungsproblem mit der Serverkonfiguration, die Frage ist nur welches.

MfG
Stefan

**dl1ely** · 11.12.2009, 12:32

Nun gut, mein erstes Ticket wurde als "Nicht reproduzierbar" ungültig gemacht, ein zweites mit Hinweis auf diesen Thread hier ist spurlos im System verschwunden. Es scheint also kein Interesse zu bestehen das zu fixen. Wenn man den Thread hier findet ist der Workaround ja auch leicht machbar...

Stefan

**MacKP** · 11.12.2009, 20:00

Hallo dl1ely,
das Problem an eurem Problem ist, das es kein allgemeines Problem ist, was jeder hat.
Es sind ausnahmefälle wo das nicht so funktioniert. Bisher habe ich hier auch noch keine Inforamation gesehen, die mir sagen würde wodrann das nun liegt. In der Regel ist das durch .htaccess Dateien gekommen die in einem Übergeordneten Ordner sind. Dann ist das ganze Verhalten aber kein Bug und was noch viel besser ist: man kann es schnell und einfach beheben (wie schon beschrieben).

Wenn es ein Bug wäre, dann würde auch interesse bestehen das zu fixen.

Also: entweder Ihr schaut wodrann es genau liegt und könnt das Problem reproduzierbar machen... oder eben nicht.
So kann keiner etwas daran ändern.
Es liegt ganz in deiner / eurer Hand.

Viele Grüße

**Thomas** · 11.12.2009, 21:12

Das Nachladen der Backendseiten funktioniert bei All-Inkl. durchaus vorzüglich.

**lindesbs** · 11.12.2009, 21:24

Was genau meinst du mit "Nachladen der Backendseiten" ?

**Thomas** · 11.12.2009, 21:30

Der Thread bezieht sich ja auch auf das nachladen der Backendseiten, sobald man z.B. in einem Artikel eine Mosdulausgabe wählt.

Beispiel: Ich will einen Artikel anlegen. Fenster kommt, ich wechsle von Text auf Überschrift im Elementtyp, aber keine Änderung der Eingabefelder.

Ich kann das aber reproduzieren, sobald man keinen titel angibt.

**MacKP** · 11.12.2009, 21:39

Ich kann das aber reproduzieren, sobald man keinen titel angibt.

Das liegt in der natur der Sache. daher ist ein Titel ja auch ein Pflichtfeld.

Viele Grüße

PS: für mehr Infos warum das ohne Titelangabe nun mal so ist -> Suchen (das hat selbst leo schon einige male erläutert)

**Thomas** · 11.12.2009, 21:42

Mir ist das bewußt, ob es Piet auch bewußt ist, weiß ich nicht.

**MacKP** · 11.12.2009, 21:45

Dann schreibs beim nächsten mal doch direkt mit hin... dann kann ich mir die Mühe ersparen und allen anderen noch 2 oder mehr Posts deswegen...

Viele Grüße

**Thomas** · 12.12.2009, 08:34

Schlecht geschlafen?

**MacKP** · 12.12.2009, 10:52

Nein, ich steh nur nicht auf unnötige Posts, die eigentlich mehr Verwirrung stiften als helfen.

**dl1ely** · 14.12.2009, 15:57

Hallo!

Erstmal vielen Dank für eure Reaktionen. Es ist sicherlich so, daß das fehlerhafte Verhalten der AJAX-Elemente im Backend und im TinyMCE "irgendwie" mit der Systemkonfiguration zu tun haben muss. Schließlich gibt es offensichtlich genügend Anwender, bei denen alles einwandfrei funktioniert. Und auch Leo hat mein Ticket mit "Nicht reproduzierbar" abgeschmettert :-).

Natürlich kann man das Thema damit abhaken und sagen "Irgendwas stimmt mit deiner Konfiguration nicht". Aber das bringt den Anwender nicht weiter, ich habe ja noch nichtmal eine Idee, WAS genau ich ändern muss, damit es funktioniert. Aus meiner Sicht gibt es 2 Möglichkeiten:

1. Irgendwas im Backend basiert auf einer bestimmten Voraussetzung, was die Konfiguration angeht. Bei bestimmten (seltenen) Konfigurationen geht die Annahme schief, und es kommt zum Fehler. Dann könnte man vielleicht rausfinden, was die zu optimistische Annahme ist, und vielleicht lässt sich ein Workaround IN TYPOLIGHT finden, um trotzdem die Ajax-Elemente und die TinyMCE-Funktionalität einwandfrei zu laden.

2. Falls es einfach informatisch nicht möglich ist, bei der "falschen" Konfiguration trotzdem das richtige Verhalten zu produzieren, könnte man vielleicht im Install-Check-Tool eine Überprüfung einbauen, die die Voraussetzung, die im Backend gemacht wird überprüft, und den Admin wenigstens auf das sich ankündigende Problem hinweist, oder gar Hinweise gibt, welche Einstellung man ändern muss.

So war für mich als Neu-Anwender leider der Eindruck: Ich habe etwas gemacht, was ich als wenig problemträchtig angesehen habe (Installation in Unterverzeichnis), und an sehr zentraler Stelle (TinyMCE) gibt es ein Problem, was mich daran hindert, einen neuen Artikel zu erzeugen. Erst durch Suchen in diesem Forum und zufälliges Reinstolpern in diesen Thread könnte ich einen Workaround (keine Lösung!) finden. Ist halt nicht so optimal. Aber gut, wenns nur so wenige Leute betrifft...

Stefan