Wird es Zeit für was Neues - nach Contao?

[Stefko]

Moin,

zu der (gefühlt) 5000. Diskussion bzgl. Composer&Co muss ich jetzt doch mal aus reiner Neugierde eine Frage stellen:
Habt ihr alle, für die Composer der scheinbare Untergang Contaos darstellt, bis heute ausschließlich das ER genutzt?

Ich habe das ComposerPlugIn im Nov 2013 auf dem Contao Camp im MUC kennengelernt (das muss so 3.2.x gewesen sein) und nutze seit her nichts anderes mehr. Klar gab es da eine gewisse Umstellung und auch eine Anpassung der Arbeitsweise/des WorkFlows. Ja und hin und wieder habe auch ich geflucht. Aber für besonders steil und lang halte ich die Lernkurve nicht - eher n Hügel im Kraichgau und kein Mont Ventoux
Und Lernbereitschaft gehört in diesem , sich ständig weiterentwickelnden, Arbeitsumfeld eh dazu. HTML -> HTML5, inline-style -> CSS3, JS-Frameworks, statisches HTML -> CMS, PHP, ...
Da fallen doch ein paar Konsolenbefehle (die ich mir sicherheitshalber auch notiert habe, weil man sie meist nicht ständig braucht) doch nicht weiter ins Gewicht.

jm2c

[DampfHans]

Aus Gründen der Gerechtigkeit... gegen den Composer habe ich eigentlich gar nichts. Das eigentliche Sorgenkind ist Symfony. Symfony läuft unter Windows nicht (Win 10 schon, aber Win 7 und vor allem Win Server <= 2013 nicht), es ist "fett", die Lernkurve für Entwickler ist heftig -vor allem wenn man nicht wochenlang Zeit hat, sich damit auseinanderzusetzen...- und es bringt gegenüber dem "alten" sehr schlanken Framework Contao keine für mich sichtbaren Vorteile.

Btw.: Grade eben mal wieder eine Installation mit Composer auf Linux machen wollen - leider hängt der Composer in einem endlosen Poll. So macht das mal wieder keinen Spaß...

[Spooky]

Symfony läuft unter Windows nicht (Win 10 schon, aber Win 7 und vor allem Win Server <= 2013 nicht)

Welche Probleme hast du?

Btw.: Grade eben mal wieder eine Installation mit Composer auf Linux machen wollen - leider hängt der Composer in einem endlosen Poll.

Was genau meinst du damit?

[DampfHans]

Das Problem sind die PHP-Symlink-Aufrufe, die unter Win 7 bzw. dem entsprechenden NT-Kernel einfach nicht wie unter Linux funktionieren. Noch etwas konkreter: Symfony nutzt relative Pfade im symlink-Aufruf um assets ins Webverzeichnis einzuspiegeln. Das geht bei Win in die Hose...

Und mit dem endlosen Poll meine ich, dass der Composer -ob nun über cmdline oder über den Manager gestartet- einfach "hängt". Wenn man sich das Ganze dann mit strace etwas näher anschaut, dann sieht man, dass ein Connect nicht terminiert... etwas flappsig formuliert: endlos pollt. Ich weiß, dass IP v6 in Kombi mit https Probleme machen können (hat man ja auch schon bei der Erweiterunsverwaltung von Contao gesehen) aber ich habe einfach keine Lust mir über sowas Gedanken zu machen nur weil ich Contao installieren will.

[Spooky]

Das Problem sind die PHP-Symlink-Aufrufe, die unter Win 7 bzw. dem entsprechenden NT-Kernel einfach nicht wie unter Linux funktionieren. Noch etwas konkreter: Symfony nutzt relative Pfade im symlink-Aufruf um assets ins Webverzeichnis einzuspiegeln. Das geht bei Win in die Hose...

Nein, Symfony hat einen Fallback auf absolute Symlinks für solche Fälle. Und die funktionieren unter Windows einwandfrei. Auch unter Windows 10, Windows 7 und Windows Server 2013 bspw. Die Ausgabe lautet dann zB:

 --------- ------------------------------- ------------------
            Bundle                          Method / Error
 --------- ------------------------------- ------------------
  WARNING   ContaoCoreBundle                absolute symlink
  WARNING   ContaoNewsBundle                absolute symlink
  WARNING   CraffftCssStyleSelectorBundle   absolute symlink
  WARNING   ContaoSwiperBundle              absolute symlink
  WARNING   RockSolidColumnsBundle          absolute symlink
  WARNING   RockSolidCustomElementsBundle   absolute symlink
  WARNING   Terminal42FolderpageBundle      absolute symlink
  WARNING   CodefogNewsCategoriesBundle     absolute symlink
 --------- ------------------------------- ------------------

Das ist übrigens ein Problem von PHP und nicht von Symfony selbst. Das PHP Entwicklerteam hat es leider versäumt dieses Problem in PHP 7.x+ zu beheben - auch deshalb weil es sich hier um eine Nische handelt.

aber ich habe einfach keine Lust mir über sowas Gedanken zu machen nur weil ich Contao installieren will.

Dann kannst du ja (zumindest jetzt noch), wie auch schon bei Contao 3, das Download Archiv benutzen.

[bizon]

Google sagt mir auch wie ich Aliase einrichten kann für die oft benötigten Befehle.

Unter Linux nutze ich auch die .bash_history um mir früher eingegebene Befehle wieder aufzurufen. Das geht auf der Konsole auf verschiedenen Wegen:

1. Pfeiltasten rauf oder runter
geht schrittweise durch die letzten Befehle
2. Eingabe von history
zeigt die komplette Liste aller eingegebenen Befehle
3. Strg+R Suchberiff
sucht den Suchbegriff direkt ab Zeilenanfang - Groß-/Kleinschreibung beachten
mit erneuter Eingabe von STRG+R kann man im Suchbegriff weiterblättern
TAB wählt den Befehl aus

Ich weiß nicht, ob das auch in Putty funktioniert. Das kann vielleicht mal ein Windows/Putty user testen. Auf jeden Fall erleichtern diese Suchmethoden das Wiederauffinden von Konsolen-Befehlen enorm.

[DampfHans]

@spooky: Schön wärs... Aber das hier ist die Ausgabe des Installers:

Contao-Installtool

Es ist ein Fehler aufgetreten
Eine Installationsaufgabe konnte nicht abgeschlossen werden!

------- ------------------------ -----------------------------------------------------------------------------------------------------------------------------------------------------------------
Symlink Target / Error
------- ------------------------ -----------------------------------------------------------------------------------------------------------------------------------------------------------------
ERROR system/themes/flexible Failed to create symbolic link from "D:\wwwroot\hnd\vendor\contao\core-bundle\src\Resources\contao\themes\flexible" to "D:\wwwroot\hnd\system\themes\flexible".
ERROR web/assets Failed to create symbolic link from "D:\wwwroot\hnd\assets" to "D:\wwwroot\hnd\web\assets".
ERROR web/system/themes Failed to create symbolic link from "D:\wwwroot\hnd\system\themes" to "D:\wwwroot\hnd\web\system\themes".
ERROR system/logs Failed to create symbolic link from "D:\wwwroot\hnd\var\logs" to "D:\wwwroot\hnd\system\logs".

Unnötig zu erwähnen, dass die Rechte gereicht hätten...

Und falls irgend jemand aus Zufall durch Google oder so auf diesen Thread kommt, weil sie/er "IPv6, https und contao" gesucht hat: Wenn man die IPv4-Adressen von packagist.org und contao.org vorübergehend in der hosts-Datei einträgt (und damit IPv6 "aushebelt") dann läuft auch der Composer...

[Stefko]

Ich weiß nicht, ob das auch in Putty funktioniert. Das kann vielleicht mal ein Windows/Putty user testen. Auf jeden Fall erleichtern diese Suchmethoden das Wiederauffinden von Konsolen-Befehlen enorm.

Ist eine gute Dekade her, dass ich Win/Putty nutzte, aber damals ging zumindest das „back“ über die Pfeiltasten.

Aber wenn man schon einen Rechner nutzt (und ich nehme an, das geht hier stramm gegen 100%), spricht ja auch nix dagegen sich die fraglichen Befehle, Kommandos, usw. digital zu sichern.
Ich persönlich nutze zB Evernote als Notizbuch, auch um mir zB Einträge aus dem Forum hier zu sichern, nach dem Motto, „ist, oder kann mal interessant werden“ und „g‘scheit getaggt“ finde ich’s lokal besser [emoji6]


Gesendet von iPhone mit Tapatalk

[tab]

Ich weiß nicht, ob das auch in Putty funktioniert. Das kann vielleicht mal ein Windows/Putty user testen. Auf jeden Fall erleichtern diese Suchmethoden das Wiederauffinden von Konsolen-Befehlen enorm.

Ja, funktioniert mit putty 0.67 unter Windows 10 alles genau so wie von dir geschrieben.

[Spooky]

Unnötig zu erwähnen, dass die Rechte gereicht hätten...

Bist du dir da sicher? Damit ein Prozess under Windows Symlinks erstellen kann, muss der Prozess entweder mit Administrator Rechten ausgeführt worden sein, oder der User unter dem der Prozess läuft, muss die SE_CREATE_SYMBOLIC_LINK_NAME Berechtigung haben.

Wie gesagt, sofern alles richtig konfiguriert ist, sollte es in allen Windows Versionen, wo Symlinks angelegt werden können, funktionieren.

Und falls irgend jemand aus Zufall durch Google oder so auf diesen Thread kommt, weil sie/er "IPv6, https und contao" gesucht hat: Wenn man die IPv4-Adressen von packagist.org und contao.org vorübergehend in der hosts-Datei einträgt (und damit IPv6 "aushebelt") dann läuft auch der Composer...

Das sollte nicht notwendig sein. Beide domains haben einen korrekten AAAA Record.

[DampfHans]

Ja, mit den Rechten bin ich sicher - ich habe das testweise mit Admin-Rechten versucht. Gleiches Ergebnis.

Bzgl. der AAAA-Einträge: Sicher gibt es die - nur das hilft nichts wenn ein DNS-Server in der Kette auf AAAA-Queries einfach nicht reagiert - und das gilt leider bis heute für ziemlich viele. Dann läuft der Client in's Timeout... und versucht erst dann einen A-Query. Bei einem Timeout von 10 Minuten und z.B. drei AAAA-Queries macht das dreißig Minuten... das hält kein PHP-Prozess durch.

In diesem Falle begann die DNS-Chain übrigens bei Hetzner und nicht in irgendeiner dunklen Kaschemme :-)

[Spooky]

Ja, mit den Rechten bin ich sicher - ich habe das testweise mit Admin-Rechten versucht. Gleiches Ergebnis.

Wie gesagt, ich hatte damit weder unter Windows 7 noch heute unter Windows 10 damit Probleme.

In diesem Falle begann die DNS-Chain übrigens bei Hetzner und nicht in irgendeiner dunklen Kaschemme :-)

Dann würde ich das mal bei Hetzner beanstanden . An Composer liegt das ja offensichtlich nicht.

[Samson1964]

Stimmt, bei Contao 3.5 brauchst du keine Konsole.
Dafür konntest du durch Installation einer nicht kompatiblen Erweiterung dein Contao zerschiessen.

Bei Contao 3.5 habe ich mir nur ein einziges Mal die Installation "zerschossen" - als ich auf Composer als ER-Ersatz umgestellt habe. Der hat nicht funktioniert und die Rückkekhr zum ER war trotz gegenteiliger Versprechen nicht mehr möglich. Aber auch mit MetaModels und EFG gab es Probleme. Aber nur bei der Deinstallation.

Das lässt Composer gar nicht erst zu.

Composer selbst ist dumm und führt nur das aus was in den Einstellungen von zu installierenden Erweiterungen als Systemvoraussetzung mitgeliefert wird. Wenn die Erweiterung eine falsche Abhängigkeit liefert oder eine Abhängigkeit vergißt, zerschießt Composer halt die Installation. Das ist nicht mehr oder weniger Sicherheit als mit dem ER, wobei Composer sicher noch genauer die Abhängigkeiten zwischen den Erweiterungen prüft. Außerdem verhindert der Composer - im Gegensatz zum ER - die Installation von Erweiterungen, die nicht zum System passen. Aber wie gesagt - es hängt von der Erweiterung ab.

[BugBuster]

Naja logisch, wenn die Erweiterung ein Fehler hat kann auch Composer nicht helfen. Aber wenn nur eine Abhängigkeit fehlt, kannste einfach die Erweiterung wieder deinstallieren lassen und gut ist.
Oder die fehlenden Abhängigkeit selber per requiere installieren lassen. Sprich, du kannst es reparieren.

[Samson1964]

Naja logisch, wenn die Erweiterung ein Fehler hat kann auch Composer nicht helfen. Aber wenn nur eine Abhängigkeit fehlt, kannste einfach die Erweiterung wieder deinstallieren lassen und gut ist.
Oder die fehlenden Abhängigkeit selber per requiere installieren lassen. Sprich, du kannst es reparieren.

Oder in Contao 3 einfach den Ordner system/modules/Erweiterungsname löschen. Das reicht ja bei den meisten Erweiterungen. Komplexer wird es bei Avisota, Isotope, MetaModels o.ä.
In Contao 4 führt das einfache Löschen von system/modules/Erweiterungsname (also einer 3er Erweiterung) dagegen zu zahlreichen Folgeproblemen. Das Löschen von var/cache bewirkte nichts. Erst ein Cache aufbauen im Contao Manager machte die Installation wieder lauffähig.

[BugBuster]

Das hast du unter Contao 3 + Composer auch. Ist ja nicht so, als wenn es Composer erst ab Contao 4 gibt.

Composer Umgebungen sind halt nichts für manuellen Eingriff. Das muss auch so sein, sonst verliert Composer ja die Kontrolle.
Und ein composer remove ... eintippen ist ja nun auch nicht das Problem. (Da ist sie wieder, die Konsole )

[DampfHans]

Eine Geschichte von Heute - nur mal als Beispiel einer "Real-Life-Erfahrung". Wahrscheinlich wird der eine oder andere sagen, dass ich einfach bloß zu blöd bin - stimmt ja vielleicht...

Ausgangssystem: frisch installiertes, aktuelles, "nacktes" LAMP-System auf dediziertem Server bei Hetzner. Software - ich würde sagen Standard: PHP7.01, mysql, Apache 2.4 etc.

Schritte zum "Erfolg":
1. apt-get update / upgrade
2. apt-get install composer
3. Webverzeichnis angelegt
4. User in Gruppe www-data angelegt
5. Composer gestartet

Ich hätte gedacht, das müsste passen... weit gefehlt.

6. composer "hängt" wegen IPv6-Problemen irgendwo in der DNS-Chain, also die IPv4-Adressen in der hosts-Datei eingetragen. Jetzt läuft der Composer aber...
7. composer create-project contao/standard-edition scheitert - Doctrine braucht PHP7.1. Leider ist PHP7.1 nicht im Repository von Hetzner, also...
8. PHP7.0 deinstallieren (dabei geht wegen der Dependency phpmyadmin flöten - egal)
9. PHP7.1 händisch installieren bzw. entsprechendes Repo. (sury) ergänzen und authent.
10. composer create-project contao/standard-edition scheitert erneut: Durch das PHP-Update sind (natürlich) alle ".so-Module" weg, also...
11. mit apt-get install php7.1-... alle nötigen Module nachinstallieren. Die erfährt man natürlich erst nach und nach - bei jedem composer install-Aufruf ein paar...
12. letztlich ist composer install erfolgreich, ABER...

http://url/contao bzw. http://url/contao/install.php führen zu 404er Fehlern - im Moment keine Ahnung warum (mod_rewrite ist natürlich geladen...). Ist aber auch (noch) nicht so wichtig, weil http://url zu einem 500er-Fehler führt. Also schnell mal ins Log von Apache geschaut und das hier entdeckt:

PHP Parse error: syntax error, unexpected 'const' (T_CONST), expecting variable (T_VARIABLE) in /var/www/html/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php on line 72

Da const-member seit PHP 7.1 erlaubt sind (Btw: Kann mir mal jemand erklären, warum die Entwickler von Doctrine wegen sowas lächerlichem wie const members auf PHP7.1 bestehen - und dann auf etwas wirklich Sinnvolles wie Typisierung komplett verzichten???) habe ich mir mal phpinfo() angesehen. Und siehe da: apt-get purge php hatte zwar alle von PHP abhängigen Module entfernt - aber PHP7.0 selber nicht. Also war das immer noch 7.0. Also...

13. In /etc/apache2/mods-available PHP 7.0 gegen 7.1 getauscht. Und schon war der PHP-Fehler weg. Allerdings auch der Rest - http://url führt jetzt zu einem 403er Fehler - als wenn das web-Verzeichnis leer ist.

Offwnsichtlich wird die .htaccess nicht geladen bzw. interpretiert - warum auch immer. http://url/app.php führt jedenfalls zur richtigen Fehlerseite (Unvollständige Installation bla bla) und http://hnd.xxx.de/app.php/contao/install zum Installationstool (warum steht in der offiziellen Doku eigentlich: "Um das Contao-Installtool aufzurufen, hängen Sie einfach install.php an die URL Ihrer Contao-Installation an."?)

In der Summe: seit Stunden am Basteln, Googeln, Logfiles lesen, Pakete installieren usw. usw.

Kann ja sein, die Hetzner-Server sind mit PHP 7.01 hoffnungslos veraltert, oder ich bin wirklich zu blöd und kann auch sein, dass Contao selber ja gar nicht "schuld ist" - aber das ändert nichts daran, dass es auf einem gängigen System bei einem großen Hoster nicht möglich ist, Contao 4.4 einfach mal so zu installieren. Im Gegenteil ist das eine üble Fummelei - bis jetzt ohne Erfolg... Ach ja: Vor einigen Tagen habe ich auf einem identischen System contao 3.5 installiert - dauerte einige Minuten (hochkopieren, entpacken, fertig) und lief auf Anhieb.

[Stefko]

4.4 oder 4.5? Letztere benötigt tatsächlich PHP7.1. Die 4.4er LTS aber nicht.


Gesendet von iPhone mit Tapatalk

[Spooky]

6. composer "hängt" wegen IPv6-Problemen irgendwo in der DNS-Chain, also die IPv4-Adressen in der hosts-Datei eingetragen. Jetzt läuft der Composer aber...

Das hat aber nichts mit composer zu tun. Und ich würde das an deiner Stelle auch nicht so lösen.

7. composer create-project contao/standard-edition scheitert - Doctrine braucht PHP7.1. Leider ist PHP7.1 nicht im Repository von Hetzner, also...
8. PHP7.0 deinstallieren (dabei geht wegen der Dependency phpmyadmin flöten - egal)
9. PHP7.1 händisch installieren bzw. entsprechendes Repo. (sury) ergänzen und authent.
10. composer create-project contao/standard-edition scheitert erneut: Durch das PHP-Update sind (natürlich) alle ".so-Module" weg, also...
11. mit apt-get install php7.1-... alle nötigen Module nachinstallieren. Die erfährt man natürlich erst nach und nach - bei jedem composer install-Aufruf ein paar...


Und siehe da: apt-get purge php hatte zwar alle von PHP abhängigen Module entfernt - aber PHP7.0 selber nicht. Also war das immer noch 7.0. Also...

13. In /etc/apache2/mods-available PHP 7.0 gegen 7.1 getauscht. Und schon war der PHP-Fehler weg. Allerdings auch der Rest - http://url führt jetzt zu einem 403er Fehler - als wenn das web-Verzeichnis leer ist.

Offwnsichtlich wird die .htaccess nicht geladen bzw. interpretiert - warum auch immer. http://url/app.php führt jedenfalls zur richtigen Fehlerseite (Unvollständige Installation bla bla) und http://hnd.e-h.de/app.php/contao/install zum Installationstool (warum steht in der offiziellen Doku eigentlich: "Um das Contao-Installtool aufzurufen, hängen Sie einfach install.php an die URL Ihrer Contao-Installation an."?)

Die neueste Contao Version benötigt PHP 7.1, was grundsätzlich völlig normal ist. Und alle Dinge die du dafür tun musst sind auch normal, wenn man seinen eigenen Webserver betreibt, anstatt von einem Hoster verwalteten oder vorkonfigurierten Webserver. Das hat nichts mit Contao oder Composer zu tun.

Kann ja sein, die Hetzner-Server sind mit PHP 7.01 hoffnungslos veraltert, oder ich bin wirklich zu blöd und kann auch sein, dass Contao selber ja gar nicht "schuld ist" - aber das ändert nichts daran, dass es auf einem gängigen System bei einem großen Hoster nicht möglich ist, Contao 4.4 einfach mal so zu installieren.

Ich kann auf unserem Root Server bei Hetzner "einfach so" mal installieren .

Wenn dein System die Anforderungen der Webapplikation, die du darauf verwenden möchtest, nicht erfüllt, dann darf es dich, als Systemadministrator, ja auch nicht verwunden, dass du erst mal das System dahingehend anpassen musst.

[DampfHans]

Version 4.47 - und aus einer composer.json von Doctrine:
"require": {
"php": "^7.1",
"doctrine/lexer": "1.*"
}

Das ist zwar im konkreten Fall der Auslöser - aber letztlich nur ein Symptom: Die Contao-Installation ist vor allem wegen den zahlreichen Abhängigkeiten kaum noch zu kontrollieren. Wenn es läuft - gut. Wenn nicht (und diesen Fall gibt es -wie gezeigt- unter ganz normalen Umständen und er wird immer wieder im Forum kritisiert) hast du kaum noch eine Chance... und dieses Vehalten ist nicht das Verhalten einer professionellen Software sondern einer "Bastelanwendung".

[Spooky]

Version 4.47 - und aus einer composer.json von Doctrine:
"require": {
"php": "^7.1",
"doctrine/lexer": "1.*"
}

Das ist zwar im konkreten Fall der Auslöser

Was genau meinst du damit?

hast du kaum noch eine Chance

Kaum eine Chance wofür?

und dieses Vehalten ist nicht das Verhalten einer professionellen Software sondern einer "Bastelanwendung".

Welches Verhalten?

[tab]

Ich bin kein Unix-Admin und habe deswegen auch keinen Root-Server zu administrieren. Oder was für ein Server ist das? Bei mir dauert die Installation einer 4.4 LTS per Contao-Manager ca 3 Minuten plus die Zeit, die ich brauche, um die Datenbank zu erzeugen und die (Sub-)Domain ins passende Verzeichnis zu leiten. Inklusive Installtool. Das ist aber freilich auch nur ein 8 Euro/Monat Allerweltshostingpaket. Warum installierst du dir die Standard-Edition? Das ist doch die Edition für die Fummler nach meinem Verständnis? .

[DampfHans]

Hat das IPv6-Problem (btw.: Wie würdest Du es denn lösen... ohne Zugriff auf die abgefragten DNS-Server?) mit dem Composer zu tun? Nein. Trotzdem nutzt Contao den Composer und deswegen taucht das Problem bei der Contao-Installation auf. Das letztlich irgendwelche Admins mit schlecht konfigurierten DNS-Servern Schuld haben ist mir doch völlig egal. So wie es mir auch egal ist, ob irgendwas beim Composer, bei Symfony oder sonstwo nicht funktioniert - durch die Entscheidung für diese Systeme fällt jedes Problem auf Contao zurück.

Und braucht Contao 4.4 PHP7.1? Kann sein... ABER WO STEHT DAS??? Vielmehr steht in der composer.json von Contao require ^7.0! Ach ja... der Check hat mit 7.0 auch kein Problem... Wenn man PHP 7.0 hat, kann man die Installation also nicht vernünftig planen sondern stolpert von Falle zu Falle.

[tab]

Das IPv6 Problem habe ich nicht, meine Subdomain ist bei Webgo nur per IPv4 erreichbar. Eigentlich suboptimal, zumal mein Internetzugang bei UnityMedia keine IPv4 Adresse hat. Die frickeln da irgendeinen Mist zusammen, keine Ahnung warum das funktioniert. Wenn mal was nicht damit geht bin ich halt alternativ nur per Surfstick unterwegs, was allerdings auch einwandfrei funktioniert. Momentan benutze ich PHP 7.1, habe gerade mal eine 4.4 managed edition per Manager installiert. Ich habe aber auch schon mit PHP 5.6 und PHP 7.0 eine der ersten 4.4 Versionen erfolgreich installiert. Mit PHP 7.1 ist es halt einfach deutlich schneller und braucht weniger RAM als mit PHP 5.6.
Ich gehe davon aus, in der composer.json steht einfach die bei der Installation verwendete PHP-Version drin, weil ja unter Umständen andere PHP-Versionen andere Komponenten/Versionen ziehen. Das heißt dann halt: Diese spezielle Installation hat PHP 7.1 als Abhängigkeit.

[tl_richard_user]

Und braucht Contao 4.4 PHP7.1? Kann sein... ABER WO STEHT DAS???

Das steht hier: https://github.com/contao/managed-ed...m-requirements in der README.

10. composer create-project contao/standard-edition scheitert erneut: Durch das PHP-Update sind (natürlich) alle ".so-Module" weg, also...

Damit installierst du die latest stable version, also 4.5. Und auch wäre die managed-edition besser geeignet. Also: `composer create-project contao/managed-edition:4.4.*`

[Spooky]

Hat das IPv6-Problem (btw.: Wie würdest Du es denn lösen... ohne Zugriff auf die abgefragten DNS-Server?) mit dem Composer zu tun? Nein. Trotzdem nutzt Contao den Composer und deswegen taucht das Problem bei der Contao-Installation auf.

Das Problem würde vermutlich nicht nur bei Composer oder Contao auftreten.

Das letztlich irgendwelche Admins mit schlecht konfigurierten DNS-Servern Schuld haben ist mir doch völlig egal. So wie es mir auch egal ist, ob irgendwas beim Composer, bei Symfony oder sonstwo nicht funktioniert - durch die Entscheidung für diese Systeme fällt jedes Problem auf Contao zurück.

Nach deiner Logik würdest du auch die Schuld auf die Webapplikation schieben, wenn dein ISP ein Problem hat und du dich nicht mehr auf den Server verbinden kannst - da die Webapplikation dich ja dazu zwingt einen Webserver zu verwenden. Nach deiner Logik würdest du ja behaupten, egal welches Problem mit deiner Serverumgebung, deiner Netzwerk Infrastruktur oder auch nur deinem Computer besteht: Typo3/Joomla/Contao/WordPress/PicoCMS/Contentful/Drupal etc. ist schuld.

Du musst doch einsehen, dass das eine dämliche Einstellung ist?

Und braucht Contao 4.4 PHP7.1?

Nein, Contao 4.4 benötigt mindestens PHP 5.6.

Vielmehr steht in der composer.json von Contao require ^7.0!

Nein, in der composer.json des core-bundle steht ^5.6|^7.0 respektive ^7.1.

Ach ja... der Check hat mit 7.0 auch kein Problem...

Der Check prüft momentan noch nur die Anforderungen für Contao 4.4.



Die contao/standard-edition verlang aber tatsächlich auch schon für 4.4 nach PHP 7.1: https://github.com/contao/standard-e...poser.json#L13

[webstar]

Anderen Kunden muss ich schonend beibringen, dass Erweiterungen nicht mehr funktionieren und deswegen ein Update auf 4 nur mit großem Aufwand (oder überhaupt nicht) machbar ist. Die Begeisterung für Contao bei den Kunden fällt schlagartig gegen Null...

Auch wenn das ärgerlich ist, ist es kein neues Phänomen. Geschweige denn nur ein Contao Problem. Ist leider bei der Entwicklung von Software so, dass neue Versionen nicht immer 100% kompatibel sind. Ob Windows, andere CMS (Drupal o.ä.), überall verursachen Updates Inkompatibilitäten.

Auch wenn der Umstieg auf die 4er erst einmal schmerzhaft - in dem Sinne, dass man gezwungen wird zu lernen - sein sollte, so hat man mit Symfony zum Glück ein Framework gewählt, welches Rückwärtskompatibilität groß schreibt. Auch da gibt es andere Konsorten auf den Framework Markt.

Wie auch immer, die Situation ist nun mal so, dass Erweiterungen nicht immer weiterentwickelt werden. Aber es gehört doch zur Professionalität mit dazu die eingesetzen Erweiterungen zu evaluieren, ggf. Kontakt mit den Entwicklern aufzubauen und wenn nötig die Weiterentwicklung zu finanzieren. Es ist nun mal ein Open-Source Projekt, wo nur durch die Zusammenarbeit aller ein Fortschritt möglich ist.

Ich empfehle daher vor dem Einsatz einer Erweiterung

• zu evaluieren, wie lang die Erweiterung existiert, wie regelmäßig Updates kommen
• zu evaluieren, wer die Erweiterung bereitstellt und wie lang er mit Contao arbeitet / zuverlässig Updates zur Verfügung stellt
• zu evaluieren, ob der Entwickler bei Beauftragung schnell reagiert
• Entwickler im Team/Netzwerk zu haben, die ggf. den Maintainer einer Extension zuarbeiten können
• Alternativen zu überprüfen

Eigentlich alles kein Hexenwerk. Meines Erachtens notwending bei der Arbeit mit Open Source.

Ich will auch die Entwickler nicht darum bitten, irgendwelche Erweiterungen anzupassen - der Punkt ist, dass die allermeisten Entwickler es nicht von sich aus machen. Es geht nicht (nur) um Verfügbarkeit, es geht um Akzeptanz. Und die Frage, warum die Akzeptanz selbst bei Entwicklern so gering ist.

Die meisten Erweiterungen werden kostenfrei von Entwicklern zur Verfügung gestellt. Als Entwickler aktualisiere ich dann meine Erweiterungen, wenn ich diese selbst benötige oder wenn ich beauftragt werde oder es irgendwie anders refinanziert bekomme. Wenn man nicht bereit ist mit den Entwicklern der Erweiterungen zusammenzuarbeiten, dann ist man meines Erachtens in einem Open-Source Projekt an der falschen Adresse. Dann ist es wohl wirklich besser, etwas Neues zu suchen.

Ehrlich gesagt, die allermeisten Erweiterungen, die ich benötige, sind schon auf Contao 4 verfügbar oder werden von den Entwicklern schnell zur Verfügung gestellt, wenn man entweder einen PR stellt, sich bereit erklärt zu testen und/oder den Entwickler beauftragt. Als Entscheidungshilfe, welcher Entwickler noch am Ball ist, lässt sich ironischerweise oft daran feststellen, wer seine Extension bereits unter Contao 3 für Composer vorbereitet hat.

Letztlich zeigt doch auch dieses Forum was ich vermute: Einige "harte Burschen" (ganz nett gemeint :-) ) aus dem innersten Contao-Zirkel mit 10.000 und mehr Beiträgen verstehen nicht, was "Normalos" eigentlich für Probleme mit Contao 4 haben.

Ich gebe zu, dass einige Diskussionen in der Community den Eindruck erwecken, dass nicht immer versucht wird die Argumentation der Gegenseite zu verstehen. Was aus meiner Sicht nicht verständlich ist, warum "Normalos" - wie du es sagst - sich über Contao 4 so aufregen, wo doch

• Contao 3.5 noch über ein Jahr supported wird
• Mit dem Contao Manager die Contao Assocication und die "harten Burschen" alles daran setzen den "Normalos" die Verwendung so einfach wie möglich zu gestalten?

Das Web-Business ist nun mal so, dass sich permanent Sachen ändern. Software, Standards, Browser, Geräte. Gewissermaßen kann ich es verstehen, wenn einem das ankotzt. Bringt halt nichts, zu lamentieren. Augen auf bei der Berufswahl, Ärmel hoch krempeln, lernen und Freude an den neuen technischen Möglichkeiten entwickeln.

[Spooky]

Das IPv6 Problem habe ich nicht, meine Subdomain ist bei Webgo nur per IPv4 erreichbar.

WebGo unterstützt leider generell noch kein IPv6 - daher kannst du auch keine Probleme mit IPv6 haben .

Eigentlich suboptimal, zumal mein Internetzugang bei UnityMedia keine IPv4 Adresse hat. Die frickeln da irgendeinen Mist zusammen, keine Ahnung warum das funktioniert.

Doch, du hast vermutlich ganz sicher eine IPv4 Adresse. Dein ISP verwendet dafür evt. DualStack-Lite - wo du eine eigene IPv6 Adresse hast und eine IPv4 Adresse, die du mit mehreren Teilnehmern teilst.

[DampfHans]

Noch eine Erfahrung (basiert zu 100% auf eigener Dummheit - aber könnte man auch als Contao-Manager-Issue durchgehen lassen)

Da ich ja lernbereit bin und eigentlich ja nichts anderes will als Contao (deswegen auch das Gemecker...) habe ich nochmal einen Server fertig gemacht - diesmal gleich mit PHP7.1 (und den Einträge in die hosts-Datei... :-) )

Dann habe ich einen web-Ordner angelegt, den Manager rein kopiert und geöffnet - und siehe da: Er lief sauber durch. Keine Fehlermeldung, grüne Meldung "alles gut" - jetzt Installtool öffnen! Rauf geklickt... 404 :-(

Was war passiert? Ich hatte den "web"-Ordner mit einem Shell-User angelegt und nicht www-data. Deswegen hatte der Manager kein Schreibrecht und konnte app.php und .htaccess nicht anlegen. Wie gesagt: Eigene Dummheit.

Jetzt wundere ich mich nur, dass der Manager nicht meckert - selbst im Logfile steht drin, dass die Dateien im web-Ordner aktualisiert wurden. Und ein weiterer Manager-Aufruf (mit geändertem Verzeichnis-Owner) hilft auch nicht weiter... Das könnte der Manager dann doch noch besser machen (Bei einem Server mit SSH-Zugang ist der Fehler ja nicht gänzlich unwahrscheinlich...). Aber immerhin: Bei einem Hosting ohne SSH und mit PHP7.1 inkl. Extensions ist der Manager eine elegante Methode der Installation.

Bzgl. des DNS-Themas: Die Domaine packagist.org hat eine TTL von 120(!) und wird also effektiv nicht gecached (Anscheinend läuft packagist bei Amazon). Ich kann mir vorstellen, das kann den einen oder anderen DNS-Server schon "verwirren" - zumindest muss die IP jedesmal neu von einem authoritären Server geholt werden. Insofern ist der Eintrag in die Hosts-Datei nicht so schlecht... andererseits spricht die kleine TTL dafür, dass Amazon auch gerne mal neue IPs setzt - bei einer Cloudanwendung ja nicht unwahrscheinlich. Und also ist der Eintrag eher doch nicht so gut... Im Moment (wenn das Problem auftaucht) trage ich die IP diekt vor der Nutzung in die hosts-Datei ein (die IPv6-Adresse geht übrigens auch) und lösche sie hinterher wieder. Besser als zuzusehen, wie der Manager nach maximaler Ausführungszeit abgebrochen wird...

[mlweb]

Einige Dinge die Du in diesem Thread als Real-Life-Erfahrungen beschreibst, haben nach meinem Verständnis etwas mit der Konfiguration der Server zu tun und sind mir als Windows-Nutzer bei meinen Versuchen auch eine lokale Linux-Entwicklungsumgebung aufzusetzen aus Unerfahrenheit und Nichtwissen untergekommen. Haben auch grundsätzlich nichts oder nur wenig mit Contao zu tun.

Der "Normalo" wie Du ihn nennst, wird sich ein den allermeisten Fällen in Shared-Hosting-Paket oder für gehobene Ansprüche einen Managed Server nehmen und keinen Server selbst administrieren. Wenn er den Empfehlungen des Wikis zu mit dem Contao-Manager getesteten Hostern folgt, wird er ohne all die von Dir beschriebenen Probleme ganz einfach über den Contao Manager installieren/aktualisieren und Erweiterungen installieren können.
Erst in Problemfällen ist dann definitiv die Konsole zu empfehlen, damit ggf. auch externe Hilfe möglich ist, falls man selbst gar nicht an die Kommandozeile ran will.

Wer mit der Kommandozeile keine Berührungsängste hat (ohne deswegen gleich ein Nerd oder Hardcoreentwickler zu sein), der wird sich mehr oder weniger viele Befehle für den eigenen Gebrauch aufschreiben/merken, vielleicht auch mal häufiger zur Kommandozeile als zum Manager greifen und sich je nach Mentalität entweder damit beschäftigen was hinter den Befehlen und Optionen steckt oder diese nur nach Vorlage einfach eintippen.

Das was Du hier schreibst, fühlt sich für mich nach Problemen an, die nur jemand hat der Server betreibt/administriert bzw. für seine Kunden selbst hostet. Ich glaube schon, dass es in dem Umfeld etwas mehr Anstrengungen bedarf seine Serverumgebung an all die neuen Gegebenheiten und notwendigen Ressourcen anzupassen. Aber das sind doch nicht wirklich die Probleme die ein "Normalo" mit Contao 4 hat den Du hier auch zur Untermauerung Deiner Argumentation heranziehst.

[Spooky]

Bzgl. des DNS-Themas: Die Domaine packagist.org hat eine TTL von 120(!) und wird also effektiv nicht gecached (Anscheinend läuft packagist bei Amazon). Ich kann mir vorstellen, das kann den einen oder anderen DNS-Server schon "verwirren" - zumindest muss die IP jedesmal neu von einem authoritären Server geholt werden. Insofern ist der Eintrag in die Hosts-Datei nicht so schlecht... andererseits spricht die kleine TTL dafür, dass Amazon auch gerne mal neue IPs setzt - bei einer Cloudanwendung ja nicht unwahrscheinlich. Und also ist der Eintrag eher doch nicht so gut... Im Moment (wenn das Problem auftaucht) trage ich die IP diekt vor der Nutzung in die hosts-Datei ein (die IPv6-Adresse geht übrigens auch) und lösche sie hinterher wieder. Besser als zuzusehen, wie der Manager nach maximaler Ausführungszeit abgebrochen wird...

Die niedrige TTL sollte ja nicht zu diesem Problem führen. Du solltest dem Problem selbst auf den Grund gehen - bzw. von Hetzner auf den Grund gehen lassen.

[tab]

Doch, du hast vermutlich ganz sicher eine IPv4 Adresse. Dein ISP verwendet dafür evt. DualStack-Lite - wo du eine eigene IPv6 Adresse hast und eine IPv4 Adresse, die du mit mehreren Teilnehmern teilst.

Das vermutlich kannst du getrost weglassen. Ansonsten würde ich mich nicht mit meinem Webspace verbinden können. Ist in der Tat wohl ein ds-Lite, was halt manche Dinge etwas komplizierter bzw unmöglich macht. Im Zusammenhang mit Contao ist mir da aber bisher nichts dergleichen aufgefallen, das betrifft andere Anwendungen. Es funktioniert aber auch z.B. mit uberspace, wo "mein" Server sowohl per IPv4 als auch IPv6 erreichbar ist. Hier läuft meine Verbindung zum Server komplett über IPv6. Allerdings ist das ja nicht das eigentliche Problem hier im Thread. Aber auch der Composer hat ja bei uberspace kein IPv6-Problem. Liegt also wohl schon an der Netzwerkkonfiguration des Servers.

[DampfHans]

Jetzt war ich doch schon fast glücklich... und will mal eine Extension über den Manager installieren. Und da war die ganze Begeisterung dahin. Composer (im Manager) stürzt beim Updaten der Dependencies wegen Speichermangel ab:

Updating dependencies
Error: "Out of memory (allocated 1073731976) (tried to allocate 4096 bytes)" in phar:///var/www/html/web/contao-manager.phar.php/vendor/composer/composer/src/Composer/DependencyResolver/RuleWatchGraph.php on 52


mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory


Process terminated with exit code 255
Reason: Unknown error 

Wohl gemerkt: "Nur" Symfony, Contao und eine Erweiterung... aber das kommt davon, wenn man so wenig Speicher hat. 1G als max mem für PHP - wie soll das auch reichen??? Ein bischen Googeln zeigt das Problem: Composer braucht so viel. Is halt so. Punkt.

Was machen eigentlich alle die, die hier angeblich mit jedem billigen Hosting zu recht kommen??? Strato und Konsorten haben meines Wissens üblicherweise 256 MB??? Den Composer einfach nie starten? Ohne Erweiterungen arbeiten?

Und dann lese ich, man soll die Installationen doch bitte auf einem lokalen Server durchführen (Website und DB mal kurz "lokal holen") und dann wieder auf den Prod.-Server zurück kopieren... Im Ernst?

Ich wäre sehr glücklich, wenn jetzt einer der hier aktiven Profis sagen würden, dass ich nur was falsch verstanden oder konfiguriert habe und der Composer doch eigentlich nur 200MB braucht. Dann bin ich auch gerne bereit, mich weiterhin für 4.4 zu begeistern... naja.... zu erwärmen. Aber SO ist das Ganze doch einfach nicht zu gebrauchen...

[Stefko]

Und dann lese ich, man soll die Installationen doch bitte auf einem lokalen Server durchführen (Website und DB mal kurz "lokal holen") und dann wieder auf den Prod.-Server zurück kopieren... Im Ernst?

Ja!
Ich mache Updates grundsätzlich NIE auf einem Produktiv-System - schiefgehen kann immer was, auch ohne Composer

Ich mache das folgender maßen:

• DB sichern (mit DB-Backup)
• mit tar das Verzeichnis auf der Konsole packen und anschließend auf meinen lokalen Rechner laden
• entpacken, DB-einspielen, localconfig.php anpassen
• Lokal die Updates ausführen (composer update)
• testen ob alles ok ist
• lokale DB sichern
• lokales Verzeichnis mit tar packen und hochladen
• auf Server entpacken, DB-einspielen, localconfig.php anpassen

[tab]

Hmm, also ich habe mit 1GB durchaus mehrere Erweiterungen installiert. Welche hattest du denn versucht zu installieren, ich hab ja sowieso noch die Testinstallation von gestern übrig.

[DampfHans]

Tatsächlich! 2GB reichen! Aber jedesmal die Installation hin- und her kopieren? Ein Paketmanager muss auch mal (oder grade) dazu benutzt werden, zwischendurch die Dependencies zu prüfen um auf dem neuesten Stand zu bleiben. Das ist doch grade einer der wesentlichen Vorteile! Man stelle sich nur mal vor, dass man eine komplette Linuxinstallation erstmal durch die Gegend kopiert jedesmal wenn man mit apt-get nur mal kurz ein Paket aktualisiert... Mal abgesehen davon, dass einige meiner Kundeninstallationen gar nicht mal so einfach hin- und her zu kopieren sind.

Ach ja... nach der Installation der ersten Extension (und dem Update der Dependencies...) kam das hier:

Using version ^2.2 for madeyourday/contao-rocksolid-custom-elements
/var/www/html/composer.json has been updated
Loading composer repositories with package information
Updating dependencies
Package operations: 1 install, 0 updates, 0 removals
  - Installing madeyourday/contao-rocksolid-custom-elements (v2.2.3): Downloading (100%)
Writing lock file
Generating optimized autoload files
ocramius/package-versions:  Generating version class...
ocramius/package-versions: ...done generating version class
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication
Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-update-cmd event terminated with an exception
--------------------------------------------------------
Exception occured: Could not delete /var/www/html/var/cache/prod/ContainerWndbyxk/getConsole_Command_AssetsInstallService.php: 

Der Composer kann also eine Datei, die er selber angelegt hat, nicht mehr löschen. Aber ich soll den Composer ja sowieso nicht auf dem Server ausführen... bin ich wohl selber schuld.

Nach acht glücklichen Jahren mit Contao war es das dann wohl für mich. Schade. Aber ich bin für Contao 4 offensichtlich keine ausreichende Ressource.

[Bennie]

@Stefko

entpacken, DB-einspielen, localconfig.php anpassen

Das bezieht sich aber auf Contao 3.5 oder nicht? In CTO 4 (wovon doch hier die Rede ist) sind die DB Einstellungen doch in app/config/parameters.yml oder hab ich da jetzt wieder etwas falsch verstanden?

[tab]

Also ich habe mit 1GB folgende Erweiterungen installiert:

bugbuster/contao-visitors-bundle
do-while/contao-backupdb-bundle
hofff/contao-opengraph
madeyourday/contao-rocksolid-columns
madeyourday/contao-rocksolid-custom-elements
madeyourday/contao-rocksolid-frontend-helper
madeyourday/contao-rocksolid-icon-picker
madeyourday/contao-rocksolid-slider

So viele Erweiterungen habe ich noch nie gleichzeitig benutzt. Normalerweise mache ich Dinge, die ohne Erweiterungen machbar sind, auch wirklich ohne eine Erweiterung. Gut, BackupDB habe ich überall drin, ist einfach bequemer ohne extra phpMyAdmin bemühen zu müssen und die passende DB auszuwählen. Ich hätte ja Metamodels probiert, aber extra deswegen jetzt ins early-adopter Programm einzusteigen ...

Edit: Gibt es eigentlich eine Möglichkeit rauszubekommen, wieviel RAM und Skriptlaufzeit tatsächlich gebraucht wurde?

[Stefko]

@Stefko


Das bezieht sich aber auf Contao 3.5 oder nicht? In CTO 4 (wovon doch hier die Rede ist) sind die DB Einstellungen doch in app/config/parameters.yml oder hab ich da jetzt wieder etwas falsch verstanden?

Erwischt, Du hast natürlich völlig recht, in der 4er ist‘s die parameters.


Gesendet von iPhone mit Tapatalk

[MacKP]

Tatsächlich! 2GB reichen! Aber jedesmal die Installation hin- und her kopieren? Ein Paketmanager muss auch mal (oder grade) dazu benutzt werden, zwischendurch die Dependencies zu prüfen um auf dem neuesten Stand zu bleiben. Das ist doch grade einer der wesentlichen Vorteile! Man stelle sich nur mal vor, dass man eine komplette Linuxinstallation erstmal durch die Gegend kopiert jedesmal wenn man mit apt-get nur mal kurz ein Paket aktualisiert... Mal abgesehen davon, dass einige meiner Kundeninstallationen gar nicht mal so einfach hin- und her zu kopieren sind.

Es reicht, wenn du lokal (oder auf einem anderen Server) das update machst und dann die composer.json und composer.lock hoch lädst und dann auf dem Zielsystem nur noch ein composer install machst. Dann hast du dort nicht mehr die Speicherhungrigen Abhängigkeitsprüfungen. Bei dem ganzen muss nur auf die passende PHP Version geachtet werden.
Das alles und noch viel mehr wirst du auch hier im Forum finden, da es schon öfter erklärt wurde.
Ich verstehe diesen Thread inzwischen eigentlich nur noch als Sammelsurium, damit du nicht selber suchen musst. Zu jedem deiner Probleme gibt es durchaus schon hilfreiche Threads (solange die mit Contao und Composer zu tun haben.. die anderen Dinge kannst du besser wo anders klären).

So langsam wäre ich fast dafür, dass dieser Thread geschlossen wird, da es hier ja eh nicht wirklich um die Grundsatzfrage 'Contao oder was anderes' geht, sondern um viele kleine Probleme, die auch seit Jahren schon längt hätten gelöst sein können, wenn man mal im Forum sucht (oder wahlweise auch wo anders).

Viele Grüße