Offizieller Contao Docker Container

Hi zusammen, und danke für die Aufnahme :D

ich wundere mich gerade enorm, warum Contao noch keine fertigen Container anbietet?

Ja, das Motto "it was hard to write, it should be hard to understand" ist lustig, aber nicht zielführend.
Speziell die Einstiegshürde wäre damit sehr leicht zu lösen.

Ich habe viele Container gefunden, aber davon ist:
a) keiner aktuell und
b) keiner davon wirklich zu gebrauchen

Entweder ist die eingesetzte PHP-Version zum Wegwerfen, die Verzeichnis-Mappings falsch, kein SSL drin (ja, ich weiß, nicht so wichtig, aber Chrome zickt ohne https mittlerweile rum, auch die "COD" hat als Standard https), oder der Webserver ist schon komisch vorkonfiguriert.

Offizieller Docker-Hub:
https://hub.docker.com/search?q=cont..._at&order=desc

Speziell in der heutigen Zeit ist das für ein CMS eher ungewöhnlich... :rolleyes:

Contao ist ein Open Source Content Management System. Wenn dir Dinge fehlen, kannst du ohne weiteres dazu deinen Beitrag leisten. Entweder durch eigene Initiative - oder indem du andere damit beauftragst.

Zitat:

---

Zitat von Spooky

Contao ist ein Open Source Content Management System. Wenn dir Dinge fehlen, kannst du ohne weiteres dazu deinen Beitrag leisten. Entweder durch eigene Initiative - oder indem du andere damit beauftragst.

---

Dadurch wird der Container dann aber auch nicht "offiziell"... :rolleyes:

Zitat:

---

Zitat von c3po

Dadurch wird der Container dann aber auch nicht "offiziell"... :rolleyes:

---

Warum nicht?

Es soll schon vorgekommen sein, dass Dinge von externen Entwicklern realisiert wurden, die dann später "offiziell" wurden ;). Eventuell kannst du deinen Wunsch ja auch auf Github als Feature-Request einstellen, damit darüber diskutiert wird. Oder du kannst dir ein Docker Image mit einem LAMP-Stack installieren und darin in kürzester Zeit ein Contao, das dann sogar noch tagesaktuell ist, inklusive aller Abhängigkeiten.

mmmmh...

So, wieder etwas Zeit für Contao ;)

Die Installation in einen Docker-Container klappt reibungslos.

Was mich aktuell noch etwas stört: eine 0815-Site anzulegen klappt tadellos, die offizielle Contao-Demo zu installieren hingegen gar nicht.

Ich habe es auch schon mittels dem Contao Manager (phar) probiert. Das klappt bis zu dem Punkt an dem das Frontend nur per /app.php/ aufrufbar ist.

Daher gehe ich mal davon aus, das es an der .htaccess liegt. (habe hierzu im Forum ja schon zig Einträge gefunden...)
Im web-Ordner liegt folgende Datei, kann jemand bitte validieren ob das eine "originale" oder durch den Manager bereits modifizierte Datei ist?

Danke

Code:

---

<IfModule mod_rewrite.c>
    RewriteEngine On

    <IfModule mod_headers.c>
        # Assets in /assets and /bundles either contain a hash in their filename
        # or are called with a ?version suffix, therefore cache them for 1 year.
        RewriteRule ^(assets|bundles)/ - [ENV=CONTAO_ASSETS:true]
        Header set Cache-Control "max-age=31536000" env=CONTAO_ASSETS

        # Allow CORS on the Contao TinyMCE skin.
        RewriteRule ^assets/tinymce4/js/skins/contao/fonts/ - [ENV=CONTAO_TINYMCE_SKIN:true]
        Header set Access-Control-Allow-Origin "*" env=CONTAO_TINYMCE_SKIN
    </IfModule>

    # Determine the RewriteBase automatically and set it as environment variable.
    # If you are using Apache aliases to do mass virtual hosting or installed the
    # project in a subdirectory, the base path will be prepended to allow proper
    # resolution of the index.php file and to redirect to the correct URI. It will
    # work in environments without path prefix as well, providing a safe, one-size
    # fits all solution. But as you do not need it in this case, you can comment
    # the following 2 lines to eliminate the overhead.
    RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
    RewriteRule ^(.*) - [E=BASE:%1]

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect to URI without front controller to prevent duplicate content
    # (with and without `/index.php`). Only do this redirect on the initial
    # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
    # endless redirect loop (request -> rewrite to front controller ->
    # redirect -> request -> ...).
    # So in case you get a "too many redirects" error or you always get redirected
    # to the start page because your Apache does not expose the REDIRECT_STATUS
    # environment variable, you have 2 choices:
    # - disable this feature by commenting the following 2 lines or
    # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
    #  following RewriteCond (best solution)
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
    RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

    # If the requested filename exists, simply serve it.
    # We only want to let Apache serve files and not directories.
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule ^ - [L]

    # Rewrite all other queries to the front controller.
    RewriteRule ^ %{ENV:BASE}/index.php [L]
</IfModule>

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /index.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule>

---

Hmm, gibts die app.php überhaupt noch in der aktuellen Installation? Wenn ja, ist es wahrscheinlich nur eine Weiterleitung auf die index.php. Welche Stelle ist das denn bei dir, sagt mir jetzt nämlich nichts, weil es eben bei mir so nicht passiert. Obwohl ich das jetzt auch nicht schwören würde, weil ich die Demo schon lange nicht mehr installiert habe. mod_rewrite hast du in deinem Container? Die document root der Domain verweist auf das web-Unterverzeichnis? Und open_basedir ist deaktiviert oder erlaubt den Zugriff auf das Verzeichnis oberhalb von web? Ok, wenn das letztere nicht gegeben wäre, dann wäre die Installation schon sehr früh gescheitert.

Zitat:

---

Zitat von tab

Hmm, gibts die app.php überhaupt noch in der aktuellen Installation? Wenn ja, ist es wahrscheinlich nur eine Weiterleitung auf die index.php.

---

Jupp, require index.php
Schon mehrfach hier gelesen, aber noch immer nicht gefixt :p

Rewrite: check
openbasedir: check

Ich habe mal getestet: index.html geht auch.
Da muß ich dann wohl IRGENDWO noch sagen, mach mal das .html weg...?
(oder der Apache muß wissen, wo er anfangen soll...)

Wie weit bist du denn gekommen bzw an welcher Stelle der Installation klemmt's?
Ich habe mir jetzt eben mal ein Contao 4.13.5 installiert mit Official Demo, da läuft es auf den ersten Blick wie es soll. Ich vergleiche mal die .htaccess, die mir gerade installiert wurde, mit deiner. Aber ich wüsste jetzt nicht warum deine anders sein sollte als meine.

Edit: Also beim visuellen Vergleich der beiden Dateien sieht deine .htaccess für mich aus wie das Original, das auch bei mir jetzt installiert ist.

Die Installation ist durch, aber ich komme nur auf das Frontend, wenn ich entweder /app.php/ oder /index.html eingebe.
Ein Zugriff über / direkt funktioniert allerdings nicht.

Kommst du ins Backend? Dann checke mal die Seitenaliase. Es gab mal einen Fall, bei dem da überall ein index/ am Anfang drinstand. War glaube ich dieser Thread: https://community.contao.org/de/show...-ein-index-bei. Bei mir passiert es nicht und meine Demo funktioniert auch tadellos, was dir aber leider nicht weiterhilft.

Jupp, Backend lüppt.
Seiten selbst sind auch über /content-elements.html aufrufbar.
NUR die Startseite geht nicht.

Anhang 25629

Das ist aus einer frisch importierten Demo.

Ah so, nur bei der Startseite geht es nicht. Hmm, ich glaube mich dunkel zu erinnern, dass es einen solchen Fall schon mal gab. Finde aber den Thread nicht, ich mag mich aber auch einfach irren. :(

Zitat:

---

Zitat von tab

Ah so, nur bei der Startseite geht es nicht. Hmm, ich glaube mich dunkel zu erinnern, dass es einen solchen Fall schon mal gab. Finde aber den Thread nicht, ich mag mich aber auch einfach irren. :(

---

Das glaube ich eher nicht... :D bei den vielen Sachen, die es schon mal gab, aber noch immer nicht gefixt sind...

Gibt es evtl. noch irgendwas beim Apachen für die conf zu berücksichtigen? :rolleyes: ich meine, ich suche den Fehler ja nicht woanders, sondern eher in der Konfiguration.
Woanders klappt es ja auch.

Ja, mein Testsystem vorhin war ein Debian 11.3 Server mit Apache 2.4.53 und MariaDB 10.5.15, also kein nginx oder auch nginx Proxy. PHP-FPM, PHP 8.0.20. Installiert habe ich das aktuelle 4.13 und contao/official-demo. FollowSymlinks oder SymlinksIfOwnerMatch sollte halt gesetzt sein. AllowOverrideAll?!? Ansonsten müssen wir wohl auf @Spooky hoffen

Zitat:

---

Zitat von c3po

Gibt es evtl. noch irgendwas beim Apachen für die conf zu berücksichtigen? :rolleyes: ich meine, ich suche den Fehler ja nicht woanders, sondern eher in der Konfiguration.
Woanders klappt es ja auch.

---

Ja, du musst dafür sorgen, dass Apache die .htaccess Dateien verarbeitet (AllowOverride).

AllowOverride All
steht in der site-config drin. :(

Ich nutze lokal einen fertigen Docker Stack wie devilbox,
damit ich mich nicht auch noch um derartige Configs kümmern muß.

Zitat:

---

Zitat von Franko

Ich nutze lokal einen fertigen Docker Stack wie devilbox,
damit ich mich nicht auch noch um derartige Configs kümmern muß.

---

Das mag sein, aber ich stehe nunmal nicht auf bloated stuff.
PostgreSQL UND MariaDB? Wozu?
Bind...?

Welches Docker Image nutzt du denn überhaupt für den Web Server?

Zitat:

---

Zitat von c3po

Das mag sein, aber ich stehe nunmal nicht auf bloated stuff.
PostgreSQL UND MariaDB? Wozu?
Bind...?

---

Schon klar - aber lokal ist es mir gleich. Soll nur laufen damit ich mich auf Contao konzentrieren kann :-)

Zitat:

---

Zitat von Spooky

Welches Docker Image nutzt du denn überhaupt für den Web Server?

---

Self-built.
FROM php:7.4-apache

Zitat:

---

Zitat von c3po

Self-built.
FROM php:7.4-apache

---

Ich würde empfehlen eher was fertiges zu nehmen.

Zitat:

---

Zitat von Spooky

Ich würde empfehlen eher was fertiges zu nehmen.

---

Weil?
Contao mehr als PHP7.4 und Apache2 braucht?

Es ist ja nicht so, das ich nach Rocket-Science fragen würde.
Aber wenn Contao so mimimi ist, dann erklärt das natürlich sehr gut, warum es dazu kein offizielles Image gibt/warum das keiner pflegen will.

Ich würde ja nix sagen, wenn ich nicht schon ein paar Jahre Anwendungs-Entwicklung, Systemintegration und Co. hinter mir hätte.

Aber das symptomatische Problem mit index.php und app.php wurde hier im Forum ja auch schon mehrfach bewiesen, und die Tatsache das es noch immer Probleme mit web/ vs. public/ gibt ...
Das erklärt auch, warum Contao international eher unbedeutend ist.

Na gut, dann geben wir das mal auf, Contao abgehakt als Hobbyprojekt :D

Ich liebe es immer, wenn hier Leute ihre allgemeinen Kenntnisse als Entwickler in den Vordergrund schieben und dann ohne genauere Erfahrung mit Contao über das CMS anfangen zu wettern.
Für mich ist das einfach anmaßend und unqualifiziert.

Zitat:

---

Zitat von c3po

Aber das symptomatische Problem mit index.php und app.php wurde hier im Forum ja auch schon mehrfach bewiesen.https://community.contao.org/de/imag...es/biggrin.png

---

Ich nutze Contao auf den verschiedensten Shared Hostern und lokal unter Windows und Mac, allerdings nicht mit Docker. Ich kenne damit kein wirkliches Problem.

Zitat:

---

Zitat von c3po

die Tatsache das es noch immer Probleme mit web/ vs. public/ gibt ...
Das erklärt auch, warum Contao international eher unbedeutend ist.

---

Was ist das denmn für ein Quatsch. In Contao wurde bis zur Version 4.9 der Ordner web genutzt, Contao 4.13 verwendet standardmäßig public (mal nur die LTS-Versionen betrachtet). Aus Gründen der Backwards-Kompatibility kann auch 4.13 mit dem Ordner web umgehen. Was ist daran jetzt Deiner Meinung nach falsch?

Zitat:

---

Zitat von mlweb

Ich liebe es immer, wenn hier Leute ihre allgemeinen Kenntnisse als Entwickler in den Vordergrund schieben und dann ohne genauere Erfahrung mit Contao über das CMS anfangen zu wettern.
Für mich ist das einfach anmaßend und unqualifiziert.

---

Wenn das System SO toll ist, das es mit 0815-Settings eines Webservers und PHP nicht klar kommt...
Ich meine, das hat NICHTS mit den Systemeinstellungen zu tun, das der offizielle Installationsweg total vermurkst ist (Commandline vs. Install-Manager).
Und von Updates fangen wir mal gar nicht an.

Ich habe, bevor ich hier gepostet habe, eine Menge Posts im Forum gelesen.
Aber Du darfst ja gerne erklären, warum Contao das noch immer nicht gebacken bekommt mit app.php
Anstelle auf MEINE fachliche Qualifikation einzugehen, darfst Du Dich fachlich zu diesem Problem einbringen.

Tust Du das nicht, disqualifizierst DU DICH.

PS: auf der offiziellen Partnerseite sind auch paar "Kaputte" dabei, habe ich freundlicherweise schon per Email gemeldet. Passiert is da bisher auch nix...

Zitat:

---

Zitat von c3po

Weil?
Contao mehr als PHP7.4 und Apache2 braucht?

---

Nein, aber damit du dich nicht mit der Grundkonfiguration eines Web Servers beschäftigen musst.

Zitat:

---

Zitat von c3po

Aber das symptomatische Problem mit index.php und app.php wurde hier im Forum ja auch schon mehrfach bewiesen

---

Welches Problem genau?

Zitat:

---

Zitat von c3po

und die Tatsache das es noch immer Probleme mit web/ vs. public/ gibt ...

---

Welche Probleme gibt es mit web/ vs. public/?

Zitat:

---

Zitat von c3po

.
Ich meine, das hat NICHTS mit den Systemeinstellungen zu tun, das der offizielle Installationsweg total vermurkst ist (Commandline vs. Install-Manager).

---

Warum ist der vermurkst?

• Weil er mit dem Contao Manager auch den Nutzern eine Installationsmöglichkeit bietet, die mit der Konsole nicht auf Du und Du stehen?
• Weil er mit dem Contao Manager und der Nutzung des Cloud Resolvers die Möglichkeit bietet, auch bei Hostingpaketen mit weniger RAM Contao zu installieren?
• Weil er mit dem Contao Manager die Möglichkeit bietet Contao auch auf Hostingpaketen zu instalieren, die keinen Zugriff auf die Konsole ermöglichen?
• Weil er über die Commandline allen Entwicklern die Möglichkeit bietet schnell und effektiv zu arbeiten?

Vielleicht kannst Du mich mal aufklären, worauf Deine Einschätzung beruht.

Zitat:

---

Zitat von c3po

Und von Updates fangen wir mal gar nicht an.

---

Stimmt über die Updates brauchen wir nicht groß zu reden, die regelmäßigen Updates innerhalb der Contao 4-Version mache ich für meine Kunden-Installation in der Regel in 5 Minuten.

Zitat:

---

Zitat von c3po

Ich habe, bevor ich hier gepostet habe, eine Menge Posts im Forum gelesen.

---

Es liegt in der Natur der Sache, dass Du in einem Hilfeforum - egal um welches CMS oder Software es geht - in der Regel über die Probleme liest.

Zitat:

---

Zitat von c3po

Aber Du darfst ja gerne erklären, warum Contao das noch immer nicht gebacken bekommt mit app.php

---

Ich weiss ehrlich gesagt nicht welches Problem genau Du meinst?

Zitat:

---

Zitat von c3po

PS: auf der offiziellen Partnerseite sind auch paar "Kaputte" dabei, habe ich freundlicherweise schon per Email gemeldet. Passiert is da bisher auch nix...

---

Du meinst Partnerseiten die nicht erreibar sind oder was? Was hat das mit der Qualität von Contao zu tun?

Zitat:

---

Zitat von Spooky

Nein, aber damit du dich nicht mit der Grundkonfiguration eines Web Servers beschäftigen musst.

---

Nun, die "Grundkonfiguration" ist aber genau das, was es ausmacht: einen sauber funktionierenden Docker-Container, der wirklich nur das Minimum an Overhead mitbringt.
Wenn ich etwas mache, dann versuche ich das Optimum zu liefern. 0815 kann jeder (oder auch nicht...).

Zitat:

---

Zitat von Spooky

Welches Problem genau?

---

Angeblich sollte keine app.php mehr ausgeliefert werden... ist aber über den Install-Manager standardmäßig da.
Und index.php geht nicht, app.php lustigerweise schon. Default .htaccess.

Zitat:

---

Zitat von Spooky

Welche Probleme gibt es mit web/ vs. public/?

---

Äääääh, echt jetzt? symphony sagt ja schon immer "public", Install-Manager macht aber die Installation nach wie vor nach "web"
https://github.com/contao/contao/pull/3084
Wieso? Wenn man das offiziell jetzt schon seit 1 Jahr weiß, aber noch immer nicht sauber/konsequent umgesetzt wird...

Und da sind noch so ein paaaar Kleinigkeiten über die ich gestolpert bin...

Was ich persönlich aber besonders traurig finde:
es sind hier im Forum Leute unterwegs, die einem WIRKLICH helfen wollen (@Spooky und @tab DANKE nochmals :cool: ) aber es gibt hier noch immer Benutzer wie @mlweb, die das auf ein persönliches Problem runterzuziehen versuchen. In anderen Foren sortiert man diese Art von Mitgliedern SEHR schnell aus, da sie bsp. nicht zu einer lösungsorientierten Fehlersuche beitragen.

Zitat:

---

Zitat von c3po

Angeblich sollte keine app.php mehr ausgeliefert werden... ist aber über den Install-Manager standardmäßig da.
Und index.php geht nicht, app.php lustigerweise schon. Default .htaccess.

---

Was meinst du mit "Install Manager"?

Um die index.php nicht mehr in der URL zu haben bzw. haben zu müssen liefert Contao eine Default .htaccess mit, wo die URLs umgeschrieben werden. Falls mod_rewrite enabled und AllowOverride All im VirtualHost aktiv ist, muss also nichts weiter getan werden. Falls du aber eine hoch-optimierte Seite betreiben und daher AllowOverride None setzen willst kannst du die Anweisungen natürlich auch direkt in die VirtualHost Definition aufnehmen.

Zitat:

---

Zitat von c3po

Äääääh, echt jetzt? symphony sagt ja schon immer "public", Install-Manager macht aber die Installation nach wie vor nach "web"

---

Falls du mit "Install Manager" den Contao Manager meinst: ja, der nutzt by default noch den web/ Ordner als Einstiegspunkt bei der Installation über den Contao Manager (ansonsten kann auch public/ verwendet werden). In zukünftigen Versionen wird das auswählbar sein (und für neue Contao 4.13 Installationen auch der Default sein). Unabhängig davon spielt es keine Rolle, beides wird unterstützt und kann daher einfach persönliche Präferenz sein. Seit Contao 4.13 ist es halt public/ um mit dem Symfony Standard Schritt zu halten (davor war Symfony Standard web/).

Zitat:

---

Zitat von mlweb

Stimmt über die Updates brauchen wir nicht groß zu reden, die regelmäßigen Updates innerhalb der Contao 4-Version mache ich für meine Kunden-Installation in der Regel in 5 Minuten.

---

Damit Du mal merkst, das persönlich werden NIEMANDEM weiterhilft... ich aber Deine fachliche Expertise zurecht anzweifeln könnte:
https://www.webdesign-marenlange.de/referenz.html

Wer in seinen Referenzen bei den meisten Projekten "anderes Template/Theme angepaßt" stehen hat... hat bisher noch nicht so viel Eigenes geleistet ;)

Nein, das war gemein. Und das Traurige: sagt möglicherweise NICHTS über Deine Qualifikation aus.
Aber war nur mal um zu demonstrieren, das ich das auch kann.

Oder doch?
https://mobile.twitter.com/ml_webdesigner
Du brauchst Popcorn...? :rolleyes:

Zitat:

---

Zitat von c3po

Was ich persönlich aber besonders traurig finde:
... aber es gibt hier noch immer Benutzer wie @mlweb, die das auf ein persönliches Problem runterzuziehen versuchen. In anderen Foren sortiert man diese Art von Mitgliedern SEHR schnell aus, da sie bsp. nicht zu einer lösungsorientierten Fehlersuche beitragen.

---

Vorsichtig. Ich glaube mit dieser Aussage bewegst Du Dich gerade auf ganz dünnem Eis.

Mir geht es einfach gegen den Strich, wenn jemand der das System noch nicht besonders gut kennt (meine persönliche Einschätzung) dieses auf Grund des Lesens von verschiedenen Forenposts herunter putzt.

Für mich gehören dazu solche Aussagen wie:

Zitat:

---

Zitat von c3po

Aber wenn Contao so mimimi ist, dann erklärt das natürlich sehr gut, warum es dazu kein offizielles Image gibt/warum das keiner pflegen will.

---

Zitat:

---

Zitat von c3po

Aber das symptomatische Problem mit index.php und app.php wurde hier im Forum ja auch schon mehrfach bewiesen, und die Tatsache das es noch immer Probleme mit web/ vs. public/ gibt ...
Das erklärt auch, warum Contao international eher unbedeutend ist.

---

Zitat:

---

Zitat von c3po

Ich meine, das hat NICHTS mit den Systemeinstellungen zu tun, das der offizielle Installationsweg total vermurkst ist (Commandline vs. Install-Manager).
Und von Updates fangen wir mal gar nicht an.

---

Zitat:

---

Zitat von c3po

Oder doch?
https://mobile.twitter.com/ml_webdesigner
Du brauchst Popcorn...? :rolleyes:

---

Ja brauche ich bei solchen Beiträgen.

Zitat:

---

Zitat von mlweb

Vorsichtig. Ich glaube mit dieser Aussage bewegst Du Dich gerade auf ganz dünnem Eis.

Mir geht es einfach gegen den Strich, wenn jemand der das System noch nicht besonders gut kennt (meine persönliche Einschätzung) dieses auf Grund des Lesens von verschiedenen Forenposts herunter putzt.

Für mich gehören dazu solche Aussagen wie:

---

Whoa, gleich brauche ICH Popcorn...
Warum sollte ICH mich auf dünnem Eis bewegen?
Symfony kann ich. Contao sollte also nicht soooo viel komplizierter sein.
Kannst Du auch Symfony? Oder doch nur Templates anpassen? (ja, DER war unter die Gürtellinie, bewußt. Wer mir unterstellt auf dünnem Eis zu gehen, obwohl ich genügend Belege bringe...)

Und leider hast Du es ja noch immer nicht verstanden, aber:
das mit dem LESEN war gemeint als: ich lese VORHER sehr viel, bevor ich was poste. Vielleicht hat ja schon mal jemand den gleichen Fehler wie ich gemacht, und ich kann durch Lesen lernen.
Kann nicht jeder.

Also: nochmal von vorne...

Ist es so schwer, einen Docker-Container aufzusetzen, der auf Apache2+PHP(welche Version auch immer) basiert, darin die Demo per Contao Manager zu installieren?

Nein, denke ich nicht.

Also bin ICH dazu nicht fähig.

Daher suche ich hier Hilfe. Zur Not auch Step by step.

Gefällt Dir das nicht: nimm nicht an der Diskussion teil.


Danke

Zitat:

---

Zitat von c3po

Warum sollte ICH mich auf dünnem Eis bewegen?

---

Weil Du schreibst:

Zitat:

---

Zitat von c3po

aber es gibt hier noch immer Benutzer wie @mlweb, die das auf ein persönliches Problem runterzuziehen versuchen. In anderen Foren sortiert man diese Art von Mitgliedern SEHR schnell aus, da sie bsp. nicht zu einer lösungsorientierten Fehlersuche beitragen.

---

Ich bin Frontendentwickler und ich kenne mich mit Contao sehr gut aus. Ich bin kein Backendentwickler, deshalb reichen mir in Symfony rudimentäre Kenntnisse.

Ich finde es auch nicht persönlich, wenn ich Dir auch als Forenmoderatorin sage, dass ich die von Dir geäußerte unbegründete Kritik (Zitate siehe oben) an dem CMS Contao überhaupt nicht angemessen finde.

Zitat:

---

Zitat von Spooky

Falls du mit "Install Manager" den Contao Manager meinst: ja, der nutzt by default noch den web/ Ordner als Einstiegspunkt bei der Installation über den Contao Manager (ansonsten kann auch public/ verwendet werden). In zukünftigen Versionen wird das auswählbar sein.

---

Ist im aktuellen Contao Manager auch jetzt schon wählbar wenn man zuvor nicht schon einen Ordner web oder public (mit darin liegendem Contao Manager) angelegt hat.
Dabei ist web die Empfehlung für Contao 4.9+ und public die Empfehlung für Contao 4.13+

Anhang 25632

Zitat:

---

Zitat von c3po

Wenn das System SO toll ist, das es mit 0815-Settings eines Webservers und PHP nicht klar kommt...

---

ich schlage immer die Hände über dem Kopf zusammen, wenn irgendeine IT-Bude von mir eine Webseite haben will und dann irgendein Chef meint, das hosten wir selber... das bisschen Webserver macht unser Admin einarmig mit Kaffetasse...

Nach meiner Erfahrung ging das IMMER zu 100% schief... typischer Fall: Rechte von PHP und FTP/SSH-User passten nicht, so dass der eine dem anderen auf die Füße trat u.v.a.m.

Das gerade zu biegen hat am Ende so viel gekostet, wie etwa 20 Jahre bei einem mittelmäßigen Paket der üblichen-verdächtigen-Provider.

Das hat nix mit Contao zu tun. Wer dem aus dem Weg gehen will, sollte zu DreamWeaver wechseln ;-)

Zitat:

---

Zitat von zonky

ich schlage immer die Hände über dem Kopf zusammen, wenn irgendeine IT-Bude von mir eine Webseite haben will und dann irgendein Chef meint, das hosten wir selber... das bisschen Webserver macht unser Admin einarmig mit Kaffetasse...

Nach meiner Erfahrung ging das IMMER zu 100% schief... typischer Fall: Rechte von PHP und FTP/SSH-User passten nicht, so dass der eine dem anderen auf die Füße trat u.v.a.m.

Das gerade zu biegen hat am Ende so viel gekostet, wie etwa 20 Jahre bei einem mittelmäßigen Paket der üblichen-verdächtigen-Provider.

Das hat nix mit Contao zu tun. Wer dem aus dem Weg gehen will, sollte zu DreamWeaver wechseln ;-)

---

Da gebe ich Dir Recht, deswegen ja auch die Frage: wie macht man es richtig?
So sehr ich Docker persönlich auch nicht gut finde, mit einem eigenen Dockerfile kannst Du Dir den Container so zurechtbauen, wie es sein soll.
Daher: es würde VIELEN geholfen sein, wenn man so etwas EINMAL sauber/richtig macht; denn selbst wenn das dann jemand kopiert und damit Geld verdient... es ist wenigstens sicher.
Und deswegen habe ich mir ja die Mühe gemacht, so einen Container zu basteln.

Nur: irgendwo klemmt es. Entweder an der Apache-Config oder an Contao. Ersteres will und kann ich nicht ausschließen, andererseits finde ich 0 Einträge im Error-Log :(

Zitat:

---

Zitat von mlweb

Ist im aktuellen Contao Manager auch jetzt schon wählbar wenn man zuvor nicht schon einen Ordner web oder public (mit darin liegendem Contao Manager) angelegt hat.
Dabei ist web die Empfehlung für Contao 4.9+ und public die Empfehlung für Contao 4.13+

Anhang 25632

---

Das ist toll, wenn DU den Screen angezeigt bekommen hast, ich sehe den reproduzierbar nicht :D

Den Screen siehst Du nur, wenn der Contao Manager (wie oben geschrieben) nicht schon im Ordner web oder public liegt. Liegt Deine Datei contao-manager.phar.php im Ordner web oder im Ordner public, das übergeordnete Verzeichnis ist leer und der Contao Manager hat alle für die Installation von Contao notwendigen Rechte, dann wird Contao so installiert, dass der entsprechende Ordner in dem der Contao-Manager abgelegt ist, für die öffentlichen Dateien genutzt wird.
Für Contao 4.13+ funktionieren der Ordner web oder der Ordner public. Für Contao 4.9 und älter musste es der Ordner web sein.
In Contao 4.13 kannst Du nach meiner Erfahrung aber später auch ohne weiteres auf den Ordner public umsteigen, falls Du ursprünglich in web installiert hattest oder falls es sich um ein Update von einer älteren Contao Version handelt.

Wäre dann halt der Sache förderlich, wenn du deinen Docker Container mal etwas detaillierter beschreiben würdest. Dann hätte man viellleicht eine Chance herauszufinden, an welcher Einstellung von Apache oder PHP es scheitert. Besonders exotische Voraussetzungen liegen nicht (mehr) vor. Das war vor einigen Jahren noch anders, weil Contao eben sehr früh auf Symfony umgestiegen ist. Mittlerweile gibt es bei den Shared Hosting Paketen der großen Anbieter und auch bei vielen kleineren kein Problem mehr. Sicher gibt es Ausnahmen bei einigen Anbietern, wenn z.B. keine document root festgelegt werden kann.

Ich habe die Demo auf einem von mir gemieteten und installierten vServer installiert, hat mich keine 10 Minuten gekostet. Die meiste Zeit ging dafür drauf, die Datenbank zu erstellen und die Passwörter einzutippen. Nicht, weil ich das so viel besser könnte als du, sondern weil ich eben eine Umgebung benutzt habe, bei der ich weiss, dass es funktioniert. Die Konfiguration ist auch da nicht irgendwie exotisch, eigentlich die Defaulteinstellungen eines Panels, ok ich habe vorsichtshalber noch das memory_limit auf 512MB erhöht, aber 256MB sollten eigentlich auch reichen, wusste nicht, wie anspruchsvoll die Demo sein würde. Vermutlich ist es irgendeine Kleinigkeit in deinen Einstellungen.

@c3po Puh - Nochmals zur Ausgangsfrage.

Zu den von dir auf "Docker-Hub" erwähnten kann ich nichts sagen. Grundsätzlich:
Es existieren keine "offiziellen" images.

Wohl aber die Möglichkeit über "andere" Docker Stacks. Eine Alternative hatte ich genannt: z.B. devilbox
(s.a.: https://docs.contao.org/manual/de/an...-installation/)

Für mich ist da alles drin was ich zur lokalen (Contao) Nutzung benötige:
Neben Datenbank(en), PHP Version(en), Apache/Nginx Auswahl u.a. SSL, Auto-DNS, E-Mail Catch-All, easy override von vhost/php.ini/xDebug per project etc.
und sofortiger Einsatz von Tools ala z.B. php-composer o. node.js im php container).

Darüber könntest du alle Contao features sofort nutzen (Installation via Contao-Manager o. über die Konsole, Contao Debug-Modus, Multidomain-Betrieb usw.)

Falls dir das für die lokale Nutzung allerdings zu viel overhead ist,
kannst du selbstverständlich deine eigenen, schmalen alpine Docker images aufsetzen/composen.
Die entsprechenden Voraussetzungen findest du hier: https://docs.contao.org/manual/de/in...raussetzungen/

Hierzu solltest du aber dann bei Problemen berücksichtigen,
das dies nicht primär eine Contao Frage ist und du daher u.U. nicht ad hoc im Forum Antworten erhälst.

Dennoch versucht die Community hier deine Schwierigkeiten zu lösen.
(Der Ton macht die Musik)

Zitat:

---

Zitat von Franko

@c3po Puh - Nochmals zur Ausgangsfrage.

Zu den von dir auf "Docker-Hub" erwähnten kann ich nichts sagen. Grundsätzlich:
Es existieren keine "offiziellen" images.

---

Ja, und das finde ich wie schon geschrieben: schade.
Es gibt da sehr viele komische Container, wenn man sich dazu das Dockerfile ansieht... da kommt man dann zu dem Punkt, den @zonky schon angesprochen hat... auch in einem Docker-Container sollte man ein Mindestmaß an Sicherheit mitbringen.

Zitat:

---

Zitat von Franko

Wohl aber die Möglichkeit über "andere" Docker Stacks. Eine Alternative hatte ich genannt: z.B. devilbox
(s.a.: https://docs.contao.org/manual/de/an...-installation/)

Für mich ist da alles drin was ich zur lokalen (Contao) Nutzung benötige:
Neben Datenbank(en), PHP Version(en), Apache/Nginx Auswahl u.a. SSL, Auto-DNS, E-Mail Catch-All, easy override von vhost/php.ini/xDebug per project etc.
und sofortiger Einsatz von Tools ala z.B. php-composer o. node.js im php container).

Darüber könntest du alle Contao features sofort nutzen (Installation via Contao-Manager o. über die Konsole, Contao Debug-Modus, Multidomain-Betrieb usw.)

---

Jaein. Ja, da ist alles drin, aber halt auch wirklich ALLES was nicht sein muß.
Und wenn Du EINMAL so wie zonky Server gesehen hast, auf denen einfach wild ALLES installiert wurde, dann stell Dir mal vor, wie viel Angriffsfläche Du dann bietest.
Ja, ist ja NUR lokal... nein, das ist eine Frage von konsequent durchziehen.

Zitat:

---

Zitat von Franko

Falls dir das für die lokale Nutzung allerdings zu viel overhead ist,
kannst du selbstverständlich deine eigenen, schmalen alpine Docker images aufsetzen/composen.
Die entsprechenden Voraussetzungen findest du hier: https://docs.contao.org/manual/de/in...raussetzungen/

---

Wie gesagt, man hat mir ja anfangs geschrieben: mach doch, vielleicht wird das dann ja was Offizielles.
Gut, open source bedeutet ja nicht, is kostenlos kannst nehmen sondern es ist ein Geben und Nehmen.
Daher: machen, GUT machen, kann jeder nutzen und auf seinen Bedarf anpassen. Und sogar für produktiven Einsatz verwenden da wirklich nur das Minimale installiert ist, und auch ansonsten alles passend konfiguriert wurde.

Zitat:

---

Zitat von Franko

Hierzu solltest du aber dann bei Problemen berücksichtigen,
das dies nicht primär eine Contao Frage ist und du daher u.U. nicht ad hoc im Forum Antworten erhälst.

Dennoch versucht die Community hier deine Schwierigkeiten zu lösen.
(Der Ton macht die Musik)

---

Das ist schon richtig, aber:
für Jemanden, der Symfony im Schlaf kann, ist dieser Fehler nicht nachzuvollziehen. Softwareseitig.
Serverseitig allerdings auch nicht, denn jetzt kommts: auf einmal gehts.
Ich habe GAR NICHTS an den jeweiligen Configs verändert, aber heute klappt lustigerweise auch der Aufruf mittels / anstelle /index.html

So, für jemanden wie mich, der das aber gerne verstehen würde... weil man ja aus Fehlern lernen will... das ist suboptimal.
Außerdem, das soll ja ein Docker-Container werden, der IMMER funktioniert.

Und daher habe ich mich persönlich angegriffen gefühlt, wenn eine Frau Dr. die hier im Forum moderiert, mir eine gewisse Inkompetenz unterstellt, obwohl sie mich gar nicht kennt.
Wie schon geschrieben, in anderen Foren fliegen solche Menschen raus. Das ist kein persönlicher Angriff, sondern Realität. Moderation hat eine gewisse Resilienz mitzubringen, ebenfalls nicht aktiv abwertend in einem Forum zu sein. Deswegen bin ich kein Moderator :D

Aber back to topic:
wie bekomme ich jetzt raus, was da schief gehangen hat?
Errorlog: leer (was für Contao spricht)
Config: nicht geändert
Dienste: nicht zwischendrin neu gestartet

Meine Vermutung würde für erste in Richtung Caching gehen oder warst Du im Debugmodus unterwegs beim Testen.

@3cpo - Deiner Aussage entnehme ich, die folgenden Sachen sind Mist - korrekt?

* https://github.com/ctsmedia/docker-contao
* https://github.com/pdir/contao-docker
* https://hub.docker.com/r/psitrax/contao
* https://hub.docker.com/r/binfalse/contao/
* https://raphaelstaebler.medium.com/r...r-96422278ea02
* https://xuad.net/artikel/contao-mitt...ner-einrichten
* https://code-fever.de/artikel/contao...iguration.html
* https://github.com/hiqs-gmbh
* https://d8devs.com/docker-image-for-...l-development/

Devilbox habe ich außenvor gelassen

Zitat:

---

Zitat von mlweb

Meine Vermutung würde für erste in Richtung Caching gehen oder warst Du im Debugmodus unterwegs beim Testen.

---

Hm... da muß ich eine Testreihe für machen.
Ich habe mich "eigentlich" an die Vorgaben gehalten und IMMER artig den Cache geleert.
Aber da kann ich mich auch möglicherweise irren... wird getestet! Guter Ansatz!

Zitat:

---

Zitat von c3po

Jaein. Ja, da ist alles drin, aber halt auch wirklich ALLES was nicht sein muß.

---

Stimmt schon und ist nachvollziehbar. Aber wie gesagt: Solang es LOKAL bleibt ...
Steht im Anschluß alles, bedarf es lediglich der Kopie von composer.json/composer.lock (gegebenenfalls der config.yml) u. Import der Datenbank/Tabellen beim jeweiligen Hoster (Auch hilfreich: Nutzung von .env/.env.local).
Von daher ...

Wie auch immer: Schön das es jetzt funktioniert.
Bin gespannt auf dein Docker Image :-)

Evtl. möchtest du dann die finale Vorgehensweise für andere detailliert beschreiben?
Oder evtl. gleich einen PR als "Guide" hierzu in der Contao Doku (de/en) hinterlegen (https://docs.contao.org/manual/de/beitragen/)?

Zitat:

---

Zitat von zonky

@3cpo - Deiner Aussage entnehme ich, die folgenden Sachen sind Mist - korrekt?

---

Zitat:

---

Zitat von zonky

* https://github.com/ctsmedia/docker-contao

---

Ja, und veraltet.
Dockerfile als auch docker-compose entspricht nicht den best-practices.

Zitat:

---

Zitat von zonky

* https://github.com/pdir/contao-docker

---

Hoffnungslos veraltet. Schon mal ins Dockerfile geguckt? xenial. Total out of support. Brauche ich den Rest gar nicht angucken.
Und ja, ich weiß, wer pdir ist :D
Die haben aber einfach ein andere Repo geforkt und dann nicht wirklich besser gemacht. :rolleyes:

Zitat:

---

Zitat von zonky

* https://hub.docker.com/r/psitrax/contao

---

Veraltet, und total aufgebläht.

Zitat:

---

Zitat von zonky

* https://hub.docker.com/r/binfalse/contao/

---

Oh nein, das willst Du WIRKLICH nicht verwenden.
Das kann nicht mal mehr bauen, weil das Dockerfile schon kaputt ist.

Zitat:

---

Zitat von zonky

* https://raphaelstaebler.medium.com/r...r-96422278ea02

---

Auch kaputt (und veraltet)

Zitat:

---

Zitat von zonky

* https://xuad.net/artikel/contao-mitt...ner-einrichten

---

:D Ubuntu 17

Zitat:

---

Zitat von zonky

* https://code-fever.de/artikel/contao...iguration.html

---

Auch hoffnungslos veraltet, und wie überall NULL auf Sicherheit geachtet.

Zitat:

---

Zitat von zonky

* https://github.com/hiqs-gmbh

---

Wenn Du das bei mir als FIAE als Abschlußprüfung einreichst, lasse ich Dich alleine schon für die Tatsache durchfallen, das es ein default root-Pwd für MariaDB10 gibt, das dies NICHT in der .env liegt, und auch ansonsten ist die docker-compose.yml eher nicht soooo prickelnd. Und davon abgesehen, kein Dockerfile, bekommt man also eine Blackbox bei der man nicht weiß was drin ist.
Meh.

Zitat:

---

Zitat von zonky

* https://d8devs.com/docker-image-for-...l-development/

---

Contao 3.5? Seriously???

Zitat:

---

Zitat von zonky

* https://alexandernaumov.de/artikel/docker-grundlagen

---

Wie gesagt, ich kann Docker-Container bauen. Nicht das ich Docker gut finde, aber es hat seine Daseinsberechtigung.
Und die von Dir genannten, nun ja, manche können es definitiv nicht, oder sind eben total veraltet (beste ist wirklich Ubuntu 17 :D )

Von daher kannst Du jetzt vielleicht nachvollziehen, warum ich so erstaunt war, das es da NICHTS Offizielles gibt.
Viele andere open source Projekte haben erkannt, das man mit sowas SEHR SCHNELL interessante Leute anzieht.
Programmierer, Designer, ... das senkt die Einstiegshürde enorm.

Zitat:

---

Zitat von Franko

Stimmt schon und ist nachvollziehbar. Aber wie gesagt: Solang es LOKAL bleibt ...
Steht im Anschluß alles, bedarf es lediglich der Kopie von composer.json/composer.lock (gegebenenfalls der config.yml) u. Import der Datenbank/Tabellen beim jeweiligen Hoster (Auch hilfreich: Nutzung von .env/.env.local).
Von daher ...

Wie auch immer: Schön das es jetzt funktioniert.
Bin gespannt auf dein Docker Image :-)

Evtl. möchtest du dann die finale Vorgehensweise für andere detailliert beschreiben?
Oder evtl. gleich einen PR als "Guide" hierzu in der Contao Doku (de/en) hinterlegen (https://docs.contao.org/manual/de/beitragen/)?

---

Das ist ja das Lustige an Docker:
Du mußt danach, wenn man es RICHTIG gemacht hat, gar nichts exportieren oder so.
Liegt alles in den entsprechend gemounteten Verzeichnissen.
Das Ziel dieses Containers soll ja ein sauberer Betrieb von Contao sein.
Best practice.
Alle notwendigen Sachen drin.
Dokumentiert. Sowohl Dockerfile als auch docker-compose.yml.
sample_env beigelegt.

Davor muß ich aber noch rausfinden, ob der Wink mit dem Zaunpfahl von @mlweb wirklich des Pudels Kern ist.
Ich bin mir zwar sicher, das ich das gemacht habe, und das aktuelle Setup geht gerade auch wieder nicht... aber da bleibe ich dran!

Zitat:

---

Zitat von c3po

Das ist ja das Lustige an Docker:
Du mußt danach, wenn man es RICHTIG gemacht hat, gar nichts exportieren oder so.

---

Schon klar - Ist halt abhängig von den jeweiligen Anforderungen/Vorgehensweisen.

Von meiner Seite nutze ich zahlreiche, lokale (nicht nur Contao) Projekte in der devilbox und deploye dann diese entsprechend bei verschiedenen Kunden Hoster.
Auch lesenswert: https://docs.contao.org/manual/de/guides/deployer/)

Zitat:

---

Zitat von c3po

Liegt alles in den entsprechend gemounteten Verzeichnissen.

---

Ebenso die Vorgehensweise bei der devilbox

Zitat:

---

Zitat von c3po

Davor muß ich aber noch rausfinden, ob der Wink mit dem Zaunpfahl von @mlweb wirklich des Pudels Kern ist.
Ich bin mir zwar sicher, das ich das gemacht habe, und das aktuelle Setup geht gerade auch wieder nicht... aber da bleibe ich dran!

---

Nice

Zitat:

---

Zitat von c3po

wie bekomme ich jetzt raus, was da schief gehangen hat?
Errorlog: leer (was für Contao spricht)
Config: nicht geändert
Dienste: nicht zwischendrin neu gestartet

---

Für welches Problem genau? Wenn es um die Rewrite Thematik geht gibt es (unter der Verwendung von Apache als Web Server) ja eigentlich nur genau zwei Möglichkeiten: im VirtualHost war AllowOverride All nicht aktiviert (bzw. du hattest die Anweisungen der .htaccess nicht in die VirtualHost Definition kopiert) oder mod_rewrite war nicht aktiviert (RUN a2enmod rewrite).

Oder eventuell eine dritte Möglichkeit: Es war alles korrekt eingetragen, aber der Apache hatte die Konfiguration noch nicht neu eingelesen. Das passiert nur bei einem restart oder reload des Apache/httpd
Das würde möglicherweise auch die "Selbstheilung" erklären, falls das System so konfiguriert ist, dass es den Apachen regelmässig neu startet.

Nebenbei, weil ich es gerade brauchte:
Lokaler Contao Multidomain-Betrieb & devilbox

Mit dem AUTO-DNS feature
benötigt man nur ein Verzeichnis mit bel. Namen "website-a" und darin dann wahlweise ein Verzeichnis web o. public :cool:
(egal wie angelegt: Im Container oder über den Host)

Letzteres konfigurierbar in der .env über Angabe der Variable HTTPD_DOCROOT_DIR, bzw. zusammen mit TLD_SUFFIX (default loc).
Ermöglicht dann z.B. autom. sowas wie:

Code:

---

https://website-a.loc
https://website-a.loc/contao
https://website-a.loc/contao-manager.phar.php

---

Benötigt man jetzt eine zusätzliche (Sub-)Domain erstellt man lediglich ein neues Verzeichnis.
Darin dann ein Symlink auf obiges web/public Verzeichnis. Am einfachsten dazu direkt in den Container:

Code:

---

docker-compose exec --user devilbox php bash -l

---

(hier legacy mit "docker-compose" sonst "docker compose" s. compose v2)

und dann

Code:

---

mkdir xyz.website-a
cd xyz.website-a
ln -s ../website-a/web web

---

Die Domains dann im Contao BE setzen und schon:

Code:

---

https://website-a.loc
https://website-a.loc/contao

https://xyz.website-a.loc
https://xyz.website-a.loc/contao

---

Will man mehr könnte man (per Project) auch spezifisch vhost settings (apache/nginx) überschreiben:
https://devilbox.readthedocs.io/en/l...or-one-project

Zitat:

---

Zitat von Spooky

Für welches Problem genau? Wenn es um die Rewrite Thematik geht gibt es (unter der Verwendung von Apache als Web Server) ja eigentlich nur genau zwei Möglichkeiten: im VirtualHost war AllowOverride All nicht aktiviert (bzw. du hattest die Anweisungen der .htaccess nicht in die VirtualHost Definition kopiert) oder mod_rewrite war nicht aktiviert (RUN a2enmod rewrite).

---

Kann ich beides ausschließen. Habe den Container ja neu gestartet ;)

Zitat:

---

Zitat von tab

Oder eventuell eine dritte Möglichkeit: Es war alles korrekt eingetragen, aber der Apache hatte die Konfiguration noch nicht neu eingelesen. Das passiert nur bei einem restart oder reload des Apache/httpd
Das würde möglicherweise auch die "Selbstheilung" erklären, falls das System so konfiguriert ist, dass es den Apachen regelmässig neu startet.

---

Ja, das dachte ich initial auch, aber dummerweise ist das ja auch bei einem frischen Setup so. :rolleyes:

Zitat:

---

Zitat von Spooky

... ja eigentlich nur genau zwei Möglichkeiten: im VirtualHost war AllowOverride All nicht aktiviert (bzw. du hattest die Anweisungen der .htaccess nicht in die VirtualHost Definition kopiert) oder mod_rewrite war nicht aktiviert (RUN a2enmod rewrite).

---

Bist du sicher das a2enmod verfügbar ist bzw. mod_rewrite in jedem Fall aktiviert ist?

Zitat:

---

Zitat von Franko

Bist du sicher das a2enmod verfügbar ist bzw. mod_rewrite in jedem Fall aktiviert ist?

---

Jupp.
Kannst Du gerne selbst testen. ;)
Wie gesagt, ich würde gerne auf Cache tippen, weil das die EINFACHSTE und plausibelste Lösung wäre, aber selbst wenn ich auf der Konsole den Cache leere wird es nicht besser.
(zuvor über den Contao Manager gemacht, dachte, vielleicht hat der da einen Bug...)

Ich habe aber am Wochenende mehr Zeit zu testen, dann komme ich hoffentlich drauf.

Der Symfony Application Cache hat damit nichts zu tun, da es sich ja um ein Problem der Web Server Konfiguration handelt und unabhängig von der dahinter stehenden Applikation ist.

Zitat:

---

Zitat von c3po

Jupp.
Kannst Du gerne selbst testen. ;)
Wie gesagt, ich würde gerne auf Cache tippen, weil das die EINFACHSTE und plausibelste Lösung wäre, aber selbst wenn ich auf der Konsole den Cache leere wird es nicht besser.
(zuvor über den Contao Manager gemacht, dachte, vielleicht hat der da einen Bug...)

Ich habe aber am Wochenende mehr Zeit zu testen, dann komme ich hoffentlich drauf.

---

Wie hast du denn bisher den Cache im Dockerfile behandelt?
Evtl. versuchsweise nach der Contao LTS Inst:

Code:

---

RUN rm -r /tmp/* \
  && rm -fr var/cache/*

---

Vielleicht kannst Du noch mal meine Zusammenfassung bestätigen/ergänzen/abändern

• die Seiten deinedomain.com/xbeliebige_seite.html kann korrekt aufgerufen werden
• die Startseite ist über deinedomain.com ist nicht erreichbar
• die Startseite ist über deinedomain.com/app.php erreichbar
• die Startseite ist über deinedomain.com/index.html erreichbar
• Edit/Ergänzung: die Startseite ist nicht über deinedomain.com/index.php erreichbar

Wollte nur mal kurz reingrätschen, da ich diesen Thread aus eigenem Interesse intensiv verfolge.

Zum ersten möchte ich sagen, dass @C3po inhaltlich nicht unrecht hat. Der Post auf den er sich bezog (bzgl. app.php) könnte meiner gewesen sein: https://community.contao.org/de/show...238#post558238. Die Form, wie das geschah finde ich allerdings durchaus fragwürdig. Resilienz einzufordern und selbst anmaßend zu reagieren ... - naja egal - zurück zum Inhalt.

Wie gesagt, ich muss @C3Po beipflichten, die Installation von Contao ist selbst für Computeraffine leider gar nicht so leicht wie es die Doku vermittelt. Wäre meine Abneigung gegenüber Joomla und Wordpress aufgrund früherer Erfahrungen nicht derart hoch, würde ich heute vermutlich kein Contao nutzen. Ich bin bei meiner lokalen Installation übrigens exakt nach Doku vorgegangen, leider funktionierten die Backendlinks (Contaomanager, Preview, ...) nicht, da man immer mal wieder (ja tatsächlich!) dieses app.php in die URL einfügen musste, damit man überhaupt was sehen konnte. Ich als Webdevelopment-Laie habe mich dann an den virtual Host Einstellungen versucht - habe ich aber nie hinbekommen. Da ich im Herbst ein fertiges CMS gebaut haben muss blieb ich hartnäckig, recherchierte und bin letztlich bei devilbox gelandet. Aber auch hier war ne gehörige Portion Installatioinsarbeit nötig.

Für Webentwickler wie euch mag das unverständlich erscheinen, aber das Argument des Nischendaseins von Contao liegt meiner Meinung nach höchstwahrscheinlich auch an den Hürden der Installation. Gerade im Vergleich zu den üblen - äähh - üblichen Verdächtigen WP, Joomla und Co. Diese liefen ohne Probleme auf dem LAMPP-Stack! Ich finde das schade, denn Contao ist nach meinem Empfinden das deutlich bessere CMS.

Die Dokumentation ist für mich deshalb ungenügend, denn mit dieser konnte ich kein lauffähiges Contao auf LAMPP aufsetzen. konstruktive Kritik sollte ja immer mit Vorschlägen zur Verbesserung einhergehen, aber da ich den Fehler nicht mal nachvollziehen konnte, weiß ich auch gar nicht wie die Doku zu ergänzen wäre.

Grüße

Zitat:

---

Zitat von nubi

Diese liefen ohne Probleme auf dem LAMPP-Stack!

---

Welche Probleme gibt es mit Contao auf dem von dir erwähnten LAMPP Stack?

Zitat:

---

Zitat von Spooky

Welche Probleme gibt es mit Contao auf dem von dir erwähnten LAMPP Stack?

---

Genau die, welche bereits in dem obengenannten Thread aufgetreten sind, jene die auch @C3Po beschreibt: die Seltsamkeiten rund um app.php! Das konnte ich als Laie nicht beheben!

Nur zum Vergleich: Die Installation der übl(ich)en Kandidaten war simpel, LAMPP drauf, Download der Files und lokal installieren, loslegen. Bei denen ist das Lesen der Doku eigentlich überflüssig!

Hast du verifiziert, dass die .htaccess greift und auch die RewriteRule Anweisungen greifen?

Von vornherein ausschliessen möchte ich grundsätzlich gar nichts. Also bitte nicht böse sein, wenn die Idee zu trivial erscheinen sollte ;). Jedenfalls kostet es nicht viel, mal die Directiven DirectoryIndex und überhaupt Direktiven für das Apache Modul mod_dir zu checken. Dass der Aufruf mit index.php nicht klappt obwohl es mit app.php funktioniert könnte, wenn es denn doch letztendlich an Contao liegen sollte, eventuell durch die Sonderbehandling des Alias "index" erklärbar sein. Ist aber pure Vermutung, basierend auf dem vorliegenden Fehlerbild und der zunehmenden Ratlosigkeit meinerseits :rolleyes:.

Bei meiner normal laufenden Official Demo führt die Sonderbehandlung jedenfalls dazu, dass das app.php in der vom Browser angezeigten URL erhalten bleibt, währen das index.php dort nicht erscheint. Insofern gibt es da prinzipiell schon einen Unterschied. Ob der überhaupt dazu führen könnte, dass index.php nicht funktioniert, das weiss ich offen gestanden nicht.

Zitat:

---

Zitat von Spooky

Hast du verifiziert, dass die .htaccess greift und auch die RewriteRule Anweisungen greifen?

---

Ich bin - wie bereits beschrieben - den Weg über DevilBox gegangen, und es läuft. Aber an der von @C3Po angesprochenen Problematik und der u. U. damit einhergehenden geringen Verbreitung von Contao ändert das ja nichts! Dass es dabei klemmen kann (scheinbar nicht muss), sehe ich als Problem! Wenn es eben zwickt, wie bei mir und @C3Po, dann und davon bin ich überzeugt, klappen die meisten Laien das Buch Contao bereits zu.

Diese dabei auftretenden Hürden müsste man daher im Vorfeld durch eine angepasste Doku ausräumen. Wie ich bereits schrieb, weiß ich nur leider nicht woran es hakte und kann daher auch nichts beisteuern, was man in die Doku schreiben müsste. Nachvollziehen kann ich es auch nicht mehr, da ich ja auf DevilBox umgestiegen bin.

Edit: ich setze nochmals einen Lampp/Xampp auf, vielleicht können wir ja gemeinsam - step by step - herausfinden was schief läuft und ich so meinen Beitrag leisten ;)

Dies aber dann im Fred des Ausgangsproblems: https://community.contao.org/de/show...tioniert-nicht

Zitat:

---

Zitat von nubi

Diese dabei auftretenden Hürden müsste man daher im Vorfeld durch eine angepasste Doku ausräumen. Wie ich bereits schrieb, weiß ich nur leider nicht woran es hakte und kann daher auch nichts beisteuern, was man in die Doku schreiben müsste.

---

Nichtsdestotrotz gehst du davon aus, dass es ein Dokumentations-Problem ist (und nicht ein Problem mit der Applikation an sich) und in so fern musst du ja auch wissen, was in der Dokumentation fehlt und kannst das ggf. ja zur Verfügung stellen.

Aus den Informationen hier im Thread wüsste ich ansonsten noch nicht, was an Contao oder der Contao Dokumentation verbessert werden soll.
Zu sagen "es funktioniert nicht, also hat Contao ein Problem" reicht leider nicht aus um tatsächlich eine Verbesserung herbei zu rufen.

Zitat:

---

Zitat von Spooky

Zu sagen "es funktioniert nicht, also hat Contao ein Problem" reicht leider nicht aus um tatsächlich eine Verbesserung herbei zu rufen.

---

Das sehe ich auch so. Zuallererst muss ja einmal festgestellt werden, woran das in den aufgetretenen Fällen liegt. Ob das jetzt beim Apache oder bei Contao liegt ist für die Dokumentation zweitrangig. Man kann sie nur ändern, wenn man weiss, woran das Problem liegt bzw wie es vermieden/umgangen werden kann. "Es funktioniert nicht, also hat Contao ein Problem" kann es nicht sein. Da könnte ich genauso gut sagen "Auf meinen Webhostings bei 3 Hostern funktioniert es, auf meinen Servern funktioniert es auch. Also haben die anderen LAMP-Stacks offensichtlich ein Problem". Beides kann es nicht unbedingt sein. Man muss die Ursache ergründen, dann kann sie vielleicht sogar seitens Contao umgangen werden. Wäre auch nicht das erste Mal. Oder, wenn das nicht möglich ist, kann man auf die Hoster zugehen - was momentan wohl mangels Problemen unnötig ist - und dann auch schauen, wie man das Problem bei lokalen Installationen oder Docker-Containern ;) lösen kann. Nichts von alledem kann aber funktionieren, ohne zuerst die Ursache(n) zu finden.

Zitat:

---

Zitat von Spooky

Nichtsdestotrotz gehst du davon aus, dass es ein Dokumentations-Problem ist (und nicht ein Problem mit der Applikation an sich) und in so fern musst du ja auch wissen, was in der Dokumentation fehlt und kannst das ggf. ja zur Verfügung stellen.

Aus den Informationen hier im Thread wüsste ich ansonsten noch nicht, was an Contao oder der Contao Dokumentation verbessert werden soll.
Zu sagen "es funktioniert nicht, also hat Contao ein Problem" reicht leider nicht aus um tatsächlich eine Verbesserung herbei zu rufen.

---

Das stimme ich absolut mit dir überein, das ist ja mein Dilemma! Es klemmte - und zwar gewaltig - aber mir fehlten die Kenntnisse um dem Fehler auf die Fährte zu kommen! Nach ein paar Stunden Fehlersuche habe ich einfach mal WP installiert. Nur um zu sehen, ob am Lampp prinzipiell was falsch läuft. Ging aber anstandslos! Es mag sein, dass Contao nicht das Problem ist, aber Out-of-the-box funktionierte es eben nicht!.

Eigentlich nur weil ich unbedingt bei Contao bleiben wollte habe ich überhaupt weiter recherchiert und nicht aufgegeben. Mich dann auch ans Forum gewandt (siehe Thread: https://community.contao.org/de/show...238#post558238). Die Tipps dort habe ich versucht nachzuvollziehen und umzusetzen, soweit mir das möglich war, konnte das Problem aber letztlich nicht lösen.
Dann schon etwas in Zeitnot habe ich nach grundsätzlichen Alternativen Ausschau gehalten - beispielsweise Docker, deswegen bin ich auch auf diesen Thread gestoßen - und landete so bei DevilBox.

Also nicht dass hier der falsche Eindruck entsteht, ich starte mit Unterstützung in naher Zukunft gerne noch mal von ganz vorne, um dieser Backendlinkproblematik auf die Schliche zu kommen, man lernt ja gerne dazu.

Nebenbei bemerkt, ich habe nirgends erwähnt, dass die Doku das Problem ist, es fehlen mMn lediglich Hinweise wie solche Untiefen umschifft werden können. Es ist mir natürlich bewusst, dass man solche nur anbieten kann, wenn die Probleme bekannt, erkannt und analysiert wurden. War scheinbar bisher nicht der Fall!

Ein paar Anmerkungen zur Einordnung.
Wir reden hier von lokalen Installationen über unterschiedliche Umgebungen.

Kleiner Ausflug:
Grundsätzlich ist die Contao Installation auf zahlreichen Hostern ohne Probleme möglich (über die Konsole o. via Contao-Manager). Historisch (»php composer«) anfänglich mit Schwierigkeiten, dann mit Einführung des CM und vor allem der »Composer Resolver-Cloud« bis dato einmalig. Mittlerweile, auch Dank Yanick Witschi, benötigt »php composer« immer weniger Speicherressourcen und somit sind Installationen auch auf Hostern ohne die »Resolver-Cloud« möglich.
(Lesenswert: The long journey of making PHP’s Composer memory-efficient and fast)

Lokale Installation
Die Systemvoraussetzungen sind nicht außergewöhnlich (sagen wir mal Symfony typisch). Fertige Lösungen wie devilbox, Laragon und selbst XAMPP (s. Contao Doku) können genutzt werden. Mit z.B. XAMPP ohne weiteres auch ohne eigene vHost Konfig (Mit einmaliger vHost Konfiguration fällt das Arbeiten dann halt leichter).

@nubi Laut deiner Aussage klappt es ja mit der devilbox. Klar das man sich da auch einmalig einlesen muß, allerdings reduziert sich das letztlich auf wenige Umgebungsvariablen ohne weitere vHost Konfigurationen (Ok, zumindest bei Nutzung des Apache. Für nginx evtl. mit Anpassungen.).

Möchte man andere oder eigene Stacks nutzen, muß gegebenenfalls die vHost Config angepaßt werden. Aber auch hier wird nichts außergewöhnliches erwartet (wie hier von Spooky bereits erwähnt). Ihr könnt ja mal die finalen configs z.B. von XAMPP o. der devilbox checken (In der devilbox ganz einfach im Dashboard im Register »Virtual Host«).

@c3po möchte einen eigenen Stack via Docker aufsetzen. Wie erwähnt muß über den Webserver die Contao .htaccess bzw. die eigene vHost Config greifen und dazu u.a. das Apache mod_rewrite Modul aktiviert sein. Das "Problem" ist nun, das laut seiner eigenen Aussage es "mal" klappt und dann mal wieder nicht. Und das ohne weitere Fehlermeldungen - Schwierig nachzuvollziehen.

Wenn ich mir die default devilbox Apache Images (z.B. das alpine Dockerfile) anschaue findet da, in diesem Zusammenhang, auch nichts außergewöhnliches statt das irgendwie »Contao spezifisch« wäre.

Zitat:

---

Zitat von nubi

Für Webentwickler wie euch mag das unverständlich erscheinen, aber das Argument des Nischendaseins von Contao liegt meiner Meinung nach höchstwahrscheinlich auch an den Hürden der Installation.

---

Dies sollte man daher differenziert(er) betrachten.
Hinsichtlich lokaler Umsetzungen kann es nie schaden so viele Infos wie möglich für verschiedene Umgebungen bereit zu stellen.
Bin mir sicher, das diesbezüglich weitere Lösungen auch zukünftig hier o. in der Doku Einzug finden.

noch einen gefunden: https://github.com/menatwork/devbox