Druckbare Version
Hallo Forum,
die Installation der 4.4.1 verlief problemlos. Allerdings erscheint der TinyMCS nicht bei Artikelbearbeitung. Im Developer Toolkit des Browser erscheint folgende Meldung:
Failed to load resource: the server responded with a status of 500 (Internal Server Error)
tinymce.gzip.js:1 Failed to load: http://contaoinstallation.de/assets/...n&languages=de
Dieser Ordner enthält aber die "tinymce.gzip.js" und der Ordner ist auch lesbar.
Hat jemand eine Idee?
Danke und Gruß
HAL
Möglicherweise ist die gzip compression auf deinem Server nicht aktiviert.
Der Fehler tritt in tinymce.gzip.js auf und gesagt wird, dass beim Laden von tinymce.gzip.php ein Fehler 500 zurück kommt. Möglicherweise erlaubt Dein Hoster keine Ausführung von PHP-Dateien oberhalb des Web-Roots. Es ist ja so, dass in Contao 4 web/assets ein Symlink auf das darüber liegende assets ist, wodurch in diesem Fall der Web-Root verlassen wird.Zitat:
Zitat von hal2000
gzip compression ist aktiviert.
Leider gibt es hier nur eine rudimentäre Parallels Confixx Oberfläche auf der ich so gut wie nichts einstellen kann.
Das heißt für die Ausführung von PHP-Dateien kann ich nichts ändern.
Ob es mit .htaccess eine Möglichkeit gibt?
Vermutlich nicht, denn Du wirst nicht mit der .htaccess aus dem web-Ordner nach oben hin ausbrechen können. Der saubere Weg wäre meiner Meinung nach, mit dem Hoster in Kontakt zu treten und ihm das Problem einschließlich der vermuteten Ursachen zu schildern.Zitat:
Zitat von hal2000
Falls Du bis das geklärt ist eine Übergangslösung brauchst, kannst Du die tinymce.gzip.php aus assets/tinymce4/js/ in einen neuen Ordner web/assets-phpexecfix/tinymce4/js/ kopieren. Dann in der .htaccess:
Das heißt Du leitest von der ursprünglichen Lage der Datei im assets-Ordner nach web/assets-phpexecfix weiter, wo sie ja ausgeführt werden darf, weil sie in web liegt.Code:RewriteRule ^assets/tinymce4/js/tinymce.gzip.php(.*)$ web/assets-phpexecfix/tinymce4/js/inymce.gzip.php$1 [L]
Das setzt natürlich voraus, dass meine Vermutung mit der PHP-Ausführung stimmt.
Danke. Ich denke ich versuche erst einmal vom Hoster Informationen zu erhalten...
Aber nur mal für mein Verständnis:
Kein Mensch will oberhalb des Roots öffentlichen Zugang haben. Also macht für mich eine solche Hoster-Einstellung Sinn.
Ist dann nicht eher das Konzept con Contao 4 mit dem Unterverzeichnis "web" als Root unglücklich?
Es gab hier irgendwo einen oder mehrere Threads, in denen das erklärt bzw darüber diskutiert wurde. Letztlich ersetzt das ja das alte Konzept, bei dem per Default alles unterhalb des document root freigegeben war - inklusive Systemverzeichnisse - und bei Bedarf per .htaccess im jeweiligen Verzeichnis gesperrt werden musste. Das neue Konzept ist auch mit nginx kompatibel, .htaccess ist ja eigentlich ein Apache-Ding ;):). Außerdem ist es vom Sicherheitsaspekt her konzeptionell besser. Denn es ist leichter zu vergessen einen Ordner mit einer .htaccess zu schützen oder diese versehentlich zu löschen, als versehentlich aktiv einen per Default vorhandenen Zugriffsschutz durch gezieltes Anlegen eines SymLinks auszuhebeln. Wie immer im Leben gibt es natürlich Risiken und Nebenwirkungen ;), so dass sich über Sinn oder Unsinn trefflich streiten lässt.
Ja, aber wäre ich bzw. der Hoster, der Einzige, bei dem TinyMCE auf Grund dieses Problems nicht geladen werden kann?
Da müssten doch die Hälfte aller 4.4.1 Installationen dieses Problem haben.
So hat sich Dein Hoster das wahrscheinlich auch gedacht. Aber das gibt dem Entwickler eben nicht die Freiheit, per Symlink sonst nicht öffentliche Ressourcen verfügbar zu machen.Zitat:
Zitat von hal2000
Das Konzept allgemein ist auf jeden Fall nicht unglücklich, besonders nicht für Verzeichnisse wie app und vendor, aus den Gründen, die tab ja schon angesprochen hat. Was mir jedoch auch nicht ganz klar ist, ist, warum assets nicht einfach direkt in web liegt, obwohl die Managed Edition von Contao ja eine Symfony-Applikation ist und die Symfony-Doku zum web-Ordner sagt:Zitat:
Ist dann nicht eher das Konzept con Contao 4 mit dem Unterverzeichnis "web" als Root unglücklich?
https://symfony.com/doc/current/quic...-web-directoryZitat:
The web root directory is the home of all public and static files like images, stylesheets and JavaScript files.
Ich weiß auch nicht, woher die Idee kommt, assets im Project-Root und dann einen Symlink web/assets -> assets anzulegen – von Symfony anscheinend jedenfalls nicht.
Nein, Dein Hoster ist nicht der einzige mit dieser Konfiguration. Ein Kunde von uns hatte das gleiche Problem, dort hatte der Hoster keine PHP-Ausführung oberhalb des Web-Roots erlaubt und die Erinnerung daran hat meine Vermutung ausgelöst. Es kann natürlich auch zufällig der gleiche Hoster sein, bei uns war es PixelX – was rückblickend etwas schräg ist, denn ich habe im Zusammenhang dieser Antwort erst herausgefunden, dass die Premiumpartner im Bereich Hosting sind. Vielleicht läufts dort inzwischen…Zitat:
Zitat von hal2000
Es ist ja übrigens noch nicht zu 100% sicher, dass es bei Dir wirklich ebenfalls daran liegt, wenn Du noch nicht mit Deinem Hoster gesprochen hast.
Mein Eindruck ist generell, dass größere/bekanntere Hoster in der benannten Hinsicht anders konfigurieren und die Häufigkeit des Problems sich deswegen im Rahmen hält.Zitat:
Da müssten doch die Hälfte aller 4.4.1 Installationen dieses Problem haben.
Der Hoster nennt sich übrigens Domain-Offensive und er sagt, dass PHP-Dateien bei ihnen oberhalb des Root aufgerufen werden dürfen.
Na ja. Nun bin ich so schau wie vorher. Ich habe mich jetzt entschlossen wieder die alte 3.5 zu nehmen und warte bis die 4'er LTS-Status hat.
Danke für eure Anteilnahme.
Für alle hier nochmal diese Dummy-URL in lesbarer Form.
http://example.org/assets/tinymce4/js/tinymce.gzip.php?js=true&plugin%E2%80%A6paste,sear chreplace,tabfocus,table,visualblocks&themes=moder n&languages=de
Hallo,
ich bekomme die gleiche Fehlermeldung.
gzip compression ist aktiviert.
Außerdem bekomme ich bei der Installation des Contao Managers die Meldung, dass proc_open und proc_close nicht verfügbar sind. Kann das auch für den Fehler mit dem TinyMCE verantwortlich sein oder betrifft das nur den Manager?
Vielen Dank und viele Grüße
Tina