Offizieller Contao Docker Container

[tab]

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.

[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.

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)

[c3po]

@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.

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.

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.

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

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

[mlweb]

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

[zonky]

@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

[c3po]

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!

[Franko]

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/)?

[c3po]

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

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

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

* 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
Die haben aber einfach ein andere Repo geforkt und dann nicht wirklich besser gemacht.

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

Veraltet, und total aufgebläht.

* 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.

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

Auch kaputt (und veraltet)

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

Ubuntu 17

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

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

* 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.

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

Contao 3.5? Seriously???

* 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 )

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.

[c3po]

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!

[Franko]

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/)

Liegt alles in den entsprechend gemounteten Verzeichnissen.

Ebenso die Vorgehensweise bei der devilbox

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

[Spooky]

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).

[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.

[Franko]

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
(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:

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:

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

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

und dann

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

Die Domains dann im Contao BE setzen und schon:

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

[c3po]

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

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.

[Franko]

... 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?

[c3po]

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.

[Spooky]

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.

[Franko]

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:

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

[mlweb]

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

[nubi]

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

[Spooky]

Diese liefen ohne Probleme auf dem LAMPP-Stack!

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

[nubi]

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!

[Spooky]

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

[tab]

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 .

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.

[nubi]

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

[Spooky]

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.

[tab]

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.

[nubi]

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!

[Franko]

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.

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.

[zonky]

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