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

[DampfHans]

Über die Konsole ist das memory_limit by default 0 oder es wird ansonsten von composer selbst auf 1.5 GiB erhöht. Unabhängig davon sind die Zahlen die du genannt hast wie schon erwähnt die memory_limit Einstellung des PHP Prozesses für den Web Server. Direkt auf der Konsole bzw. für die geforkten Prozesse die der Contao Manager macht gelten andere Umgebungsbedingungen.

Stimmt - es gelten andere Limits - in Linux gesprochen /etc/php/apache2 vs. /etc/php/cli. Ich kann mir nur nicht vorstellen, dass die Hoster in der cli-Datei signifkant höhere Werte einstellen. Mein erster Kontakt hiermit war übrigens ein 1&1-Hosting (512MB), das mit der bekannten Speicherfehlermeldung (z.B. hier erwähnt: https://community.contao.org/de/show...-aktualisieren) den MC bzw. den Composer "abschoss". Das Speicherlimit wird auch nicht erhöht -das kann der Prozess gar nicht über das PHP-Limit hinaus- , der Composer versucht es nur.

Solange Contao (oder streng genommen Symfony 3) so "fett" sind (oder es einen "schlaueren" Composer gibt) wird das Speicherproblem m.E. nicht verschwinden.

[Spooky]

Stimmt - es gelten andere Limits - in Linux gesprochen /etc/php/apache2 vs. /etc/php/cli. Ich kann mir nur nicht vorstellen, dass die Hoster in der cli-Datei signifkant höhere Werte einstellen.

Auch wenn du es dir nicht vorstellen kannst ist das in den meisten Fällen so.

Mein erster Kontakt hiermit war übrigens ein 1&1-Hosting (512MB), das mit der bekannten Speicherfehlermeldung (z.B. hier erwähnt: https://community.contao.org/de/show...-aktualisieren) den MC bzw. den Composer "abschoss".

In restriktiv eingestellten Shared Hosting Umgebungen reicht der zur Verfügung gestellte Speicher oft nicht.

-das kann der Prozess gar nicht über das PHP-Limit hinaus-

Doch, das geht. Es gibt aber viele beeinflussende Faktoren, nicht nur die schlichte memory_limit Einstellung.

[do_while]

Warum braucht der Composer so viel Speicher?

Das kann man am Besten den Composer mal selbst fragen.
Ich habe hier eine Installation ohne viele Erweiterungen (fast nur die eigenen), das sind schon 122 installierte Pakete!

F:\MAMP\htdocs\contao44lts>composer -v update --dry-run

Loading composer repositories with package information
Updating dependencies (including require-dev)
Dependency resolution completed in 2.041 seconds
Analyzed 15210 packages to resolve dependencies
Analyzed 1189901 rules to resolve dependencies
Package operations: 0 installs, 1 update, 0 removals
Updates: do-while/contao-pdfforms-bundle:1.0.2
  - Updating do-while/contao-pdfforms-bundle (1.0.0) to do-while/contao-pdfforms-bundle (1.0.2)

Nun muss man sehen, dass es von jedem Paket verschiedene Versionen und Stände gibt, die jeweils eigene Anforderungen und Abhängigkeiten haben können.
Der Composer muss das alles berücksichtigen, so kommt er schon auf 15210 Pakete, aus denen er die beste und aktuellste Kombination finden soll, die möglich ist.

Dazu muss er in meinem Fall 1189901 Regeln prüfen um diese Kombination zu finden oder um eine Fehlermeldung auszugeben, dass es keine lauffähige Kombination gibt.
Ich denke bei der Prüfung sind dann die composer.json-Dateien aller 15210 Pakete in einer Entscheidungsmatrix im Speicher notwendig.

Bei diesen Größenordnungen, die übrigens deutlich von den verwendeten Erweiterungen und Modulen abhängen, kann man sich leicht die lange Laufzeit und den Speicherbedarf erklären.
Das hat aber alles nicht mit Contao zu tun, nur in sofern, dass man sich vor einigen Jahren für diesen zukunftsträchtigen Weg für Installation und Updates entschieden hat.

[mlweb]

Etwas mehr Mut zur eigenen Leistung und etwas weniger "Wenn alle das machen, dann wir auch" hätte Contao seine Sonderstellung behalten lassen.

Der Mut zur eigenen Leistung fehlt da sicher nicht. Es ist eher die Einsicht, dass man nicht jedes Rad mehrfach erfinden muss.

[Pinkman]

Aber trotzdem ärgert es mich maßlos, dass ausgerechnet Contao, das bis dahin mit schlanken, pfiffigen Lösungen und einem eigenen, ebenfalls schlanken Framework daher kam und so alles richtig machte, sich jetzt diese Klötze Composer und Symfony ans Bein bindet - und dann gleich so maßlos Module nachlädt und so den Composer zum Speichermonster macht. Sorry - das waren für mich die falschen Entscheidungen. Etwas mehr Mut zur eigenen Leistung und etwas weniger "Wenn alle das machen, dann wir auch" hätte Contao seine Sonderstellung behalten lassen.

Mich persönlich ärgert viel mehr das die gleiche Diskussion hier zum xten mal geführt wird. Die Zeit die wir alle damit verschwenden könnten wir auch nutzten Doku zu schreiben etc. da hätten alle viel mehr von.

Contao hat eben diesen Weg als erstes CMS beschritten ich garantiere dir aber das die anderen nachziehen werden. Weil es einfach die logisch beste Entscheidung ist. Contao 4.4 ist die beste LTS die es von Contao jemals gegeben hat. Das entwicklen ist im Vergleich zur 3.5 er um Welten besser.

Das Contao jetzt nicht mehr überall läuft ist schade aber lässt sich nicht vermeiden, wenn die Hoster zeitgemäße Pakete bereitstellen funktioniert es auch. Das tun viele eben noch nicht, das wird aber kommen. Da drüber hinaus wird es auf absehbare Zeit sicherlich auch eine Lösung geben um die Abhängigkeiten extern aufzulösen und damit ist das Problem dann sowieso erledigt.

Der Contao Manager zeigt doch das genau die Zielgruppe die Contao mit GUI nutzen will nicht egal ist. Für die prof. Anwender würde die Kommandozeile vollkommen ausreichen. Der Manager ist zurzeit eben auch noch Beta, ihr müsst halt auch bedenken das Contao Open Source ist und alle freiwillig daran arbeiten da finde ich es etwas unangemessen mit sowas wie „mehr Mut in die eigene Leistung“ zu kommen.

Warum sollen sich die ehrenamtlichen um Probleme kümmern die schon gelöst sind? So kann doch viel effizienter gearbeitet und fokussierter entwickelt werden und das kommt am Ende Contao und allen Nutzern zu Gute.

[Franko]

Mich persönlich ärgert viel mehr das die gleiche Diskussion hier zum xten mal geführt wird. Die Zeit die wir alle damit verschwenden könnten wir auch nutzten Doku zu schreiben etc. da hätten alle viel mehr von.

Warum sollen sich die ehrenamtlichen um Probleme kümmern die schon gelöst sind? So kann doch viel effizienter gearbeitet und fokussierter entwickelt werden und das kommt am Ende Contao und allen Nutzern zu Gute.

Dito - Meine Sorge wäre vielmehr das derartige threads hier o. auf GitHub dazu führen das sich womöglich all die Core-Entwickler, Erweiterungs-Entwickler oder hiesige Forums-Moderatoren zukünftig nicht mehr so enthusiastisch ins Zeug legen und Ihre Zeit für dieses Projekt daher einschränken werden ...

Nicht falsch verstehen: Kritik (wie von DampfHans u.a. hier formuliert) muß auch erlaubt sein und kann weiterhelfen ...

[kubjo]

Hallo mlweb,
das ist für Dich ein gewichtiger Punkt:

Ich kann den Kunden den Updatservice oder Einzelupdates günstiger anbieten weil bei Contao 4 ein Update für mich wesentlich schneller von statten geht...

Wenn das aber der einzige Vorteil von C4 ist, dann ist das ganz schön mager, oder?

Grüße
JK

[Samson1964]

Ich glaube die meisten Vorteile liegen eher auf Entwicklerseite. Wobei ich mich damit noch gar nicht beschäftigt habe, weil ich nur für Contao 3 Erweiterungen programmiert habe. Ich sehe also noch nichts von den Vorteilen, weil ich jetzt erstmal viel Neues als Entwickler dazulernen muß.

[mlweb]

Wenn das aber der zeinzige Vorteil von C4 ist, dann ist das ganz schön mager, oder?

Nein nicht wirklich. Du hattest explizit gefragt welche konkreten Vorteile der Betrachter oder Kunden hat.

Dem Betrachter einer Website ist es m.E. vollkommen egal welche Technik hinter eine Website steht. Er möchte das finden was er gerade sucht (Übersichtlichkeit, logischer Aufbau etc.), erwartet das die Website fehlerfrei funktioniert und freut sich wenn sie auch noch hübsch anzuschauen ist. Je nach Mentalität bekommen einzelne Punkte unterschiedliche Gewichtung.

Bei den Kunden hast Du das Backend in Deiner Frage schon fast ausgeschlossen. Damit fällt der Vorteil der Verbesserungen im Backend schon weg. Außerdem ist es bei meinen kleinen Kunden häufig so, dass sie zwar viel Wert auf die Möglichkeit legen, Inhalte einpflegen zu können, in der Praxis aber doch häufig darauf verzichten. Bei Kunden die Inhalte einpflegen, das sind bei mir z.B. Print- bzw. Werbeagenturen, die gern Ihren Kunden auch eine Website anbieten möchten, aber die Einrichtung des CMS und die Umsetzung des Layouts nicht selbst übernehmen wollen sieht das etwas anders aus. Die schauen schon auch aufs Backend.
Was als System dahinter liegt ist auch denen weitestgehend egal. Wichtig ist nur, dass ich die Funktionalitäten umsetzen kann, die gewünscht sind und das Sie möglichst komfortabel und flexibel die Inhalte eingeben können, die sie brauchen.

Was man bei der ganzen Diskussion einfach auch berücksichtigen muss ist, dass sich auch Erweiterungen weiter entwickeln (auch in der Funktionalität), die wie z.B. bei [calender_extended] nur noch im contao 4 bundle weitergepflegt werden, wenn ich es richtig gelesen habe. Wenn ich die Funktionalität nicht benötige und der Sicherheitsaspekt noch gewährleistet ist, wäre es kein konkreter Vorteil für den Kunden, wenn ich aber irgenwann in einigen Jahren doch updaten müßte und der Sprung dann über mehrere Versionen geht, könnte das ein Nachteil für den Kunden sein.

Wenn man ganz provokant ist, darf man auch die Frage stellen welchen konkreten Vorteil bringt das CMS dem Betrachter einer Website bzw. welchen Vorteil bringt es dem Kunden, wenn der Kunde eine statische Präsenz wünscht, ohne Kontaktformular oder sonst irgendwelche Funktionalität.

Das ist zum Beispiel auch ein Grund warum Kunden bei mir eine Webvistenkarte durchaus auch als reine HTML-Seite bekommen können.

[Spooky]

Siehe auch: https://contao.org/de/news/contao_4-4-0.html

[Stefko]

Siehe auch: https://contao.org/de/news/contao_4-4-0.html

und der Vollständigkeit halber
https://contao.org/de/news/contao_4-0-0.html
https://contao.org/de/news/contao_4-1-0.html
https://contao.org/de/news/contao_4-2-0.html
https://contao.org/de/news/contao_4-3-0.html

[bjarke]

... und noch 22 Gründe für Contao 4.4 von Leo.

[Spooky]

und der Vollständigkeit halber
https://contao.org/de/news/contao_4-0-0.html
https://contao.org/de/news/contao_4-1-0.html
https://contao.org/de/news/contao_4-2-0.html
https://contao.org/de/news/contao_4-3-0.html

Naja ich meinte eher wegen der Auflistung der Vorteile und den Folien der Keynote . Mittlerweile sind für Contao 4.5 ja noch weitere Vorteile hinzugekommen. Siehe dazu auch:

https://contao.org/de/news/contao_4-5-0-beta1.html
https://contao.org/de/news/contao_4-5-0-beta2.html
https://contao.org/de/news/contao_4-5-0-beta3.html

[mlweb]

Vielleicht habe ich die Frage ja auch falsch verstanden. Für mich hatte @kubjo die Verbesserungen im Backend eigentlich ausgeschlossen. Die sind dem Betrachter der Website ja auch völlig egal und in meinem Fall auch vielen Kunden. Mir allerdings nicht, aber das war ja nicht die Frage.

[Spooky]

Naja, ob eine Website Typo3, Drupal, WordPress, Contao, Joomla, pure Symfony, etc. benutzt ist dem Besucher sowieso egal. Indirekt ergeben sich aus den Möglichkeiten im Backend und in der Programmierung dann Vorteile für den Benutzer im Frontend.

[mlweb]

Ja genau.

[Franko]

Ich habe eben Updates zweier Testinstallationen auf Contao 4.4.14 und Contao 4.5.4 via CM durchgeführt (jeweils mit einer Erweiterung).
Habe noch nicht einmal die Tasse Kaffee geschafft so schnell war das durch.

Das zum Thema "Benutzerfreundlichkeit: One Klick Button "Pakete aktualisieren" - man sieht also wohin die Reise geht ...
Ist auch eine Tatsache ( Ok - unter idealen Bedingungen hoster: hostingwerk ).

Lieben Gruß
Franko

[Hagord]

Wo/wie kann man am besten (an einer zentralen Stelle?) feststellen, welche der Erweiterungen, die man bislang unter C3.5 nutzt, schon für C4.4 zur Verfügung stellen? Oder muss man da mit jedem Entwickler von 3.5-Erweiterungen Kontakt aufnehmen?

[webstar]

Wo/wie kann man am besten (an einer zentralen Stelle?) feststellen, welche der Erweiterungen, die man bislang unter C3.5 nutzt, schon für C4.4 zur Verfügung stellen? Oder muss man da mit jedem Entwickler von 3.5-Erweiterungen Kontakt aufnehmen?

Über die Suche von https://packagist.org/ geht es wohl am besten. Man kann hier explizit nach Contao-Bundles (Für Contao 4 entwickelt) und Contao-Modulen (Meistens für Contao 3 entwickelt, ggf. Contao 4 fähig) suchen:

https://packagist.org/?q=&p=0&hFR%5B...=contao-bundle
https://packagist.org/?q=&p=0&hFR%5B...=contao-module

[f.basara]

Bin auch seit längerem auf der Suche nach einem Ersatz, möchte mir jedoch nicht Typo3 oder WP antun.

Eventuell könnten dich folgende CMSe interessieren:


Sulu CMS: https://sulu.io/de

Ähnliches Content-Management Konzept, wie Contao, finde ich.
Ebenfalls deutsche Entwickler, falls das für dich wichtig ist.


Grav CMS https://getgrav.org/

Sehr modernes, flat-file CMS. Content wird hauptsächlich über Markdown gepflegt, es gibt aber auch einen WYSIWYG Editor für End-Kunden.
Leider ist die ganze Modularität, wie bei der Contao Content Pflege nicht geben. Mann muss seine individuellen Content Elemente selber mit Hilfe von Twig zusammenstellen.
Das optionale Backend ist extrem feature-reich und die Community ist relativ groß.


concrete5 https://www.concrete5.org/

Sehr einsteigerfreundlich, riesen Community, viele Themes + Plugins.
Das Ökosystem erinnert mich ein bisschen an WP, ist aber von Haus aus ein viel überzeugenderes CMS.

Ich persönlich bin immer noch auf der Suche, nach einem idealen Ersatz.
Vielleicht wirds am Ende gar kein PHP basiertes CMS sein, die letzten 3-4 Jahre haben einen Großen Umschwung in der Welt der Webentwicklung ergeben, und es lohnt sich den letzten Trends und Neuerungen zumindest ein wenig Aufmerksamkeit zu schenken.

[webstar]

Bin auch seit längerem auf der Suche nach einem Ersatz, möchte mir jedoch nicht Typo3 oder WP antun.

Eventuell könnten dich folgende CMSe interessieren:


Sulu CMS: https://sulu.io/de

Ähnliches Content-Management Konzept, wie Contao, finde ich.
Ebenfalls deutsche Entwickler, falls das für dich wichtig ist.

Muss man sich mal anschauen. Ein CMS basierend auf Symfony, CMF und PHPCR klingt sehr vielversprechend. Sieht man, dass Contao mit der 4 den richtigen Weg geht.

Grav CMS https://getgrav.org/

Sehr modernes, flat-file CMS. Content wird hauptsächlich über Markdown gepflegt, es gibt aber auch einen WYSIWYG Editor für End-Kunden.
Leider ist die ganze Modularität, wie bei der Contao Content Pflege nicht geben. Mann muss seine individuellen Content Elemente selber mit Hilfe von Twig zusammenstellen.
Das optionale Backend ist extrem feature-reich und die Community ist relativ groß.

Für Sachen, wo Flatfile reicht als Datenstruktur, könnte man mal checken.

concrete5 https://www.concrete5.org/

Sehr einsteigerfreundlich, riesen Community, viele Themes + Plugins.
Das Ökosystem erinnert mich ein bisschen an WP, ist aber von Haus aus ein viel überzeugenderes CMS.

Ist mir von Namen bekannt, aber noch nie gecheckt. Gut zu sehen, dass auch hier Symfony, Doctrine und Composer die Basis bilden.

[Spooky]

Grav CMS https://getgrav.org/

Sehr modernes, flat-file CMS. Content wird hauptsächlich über Markdown gepflegt, es gibt aber auch einen WYSIWYG Editor für End-Kunden.
Leider ist die ganze Modularität, wie bei der Contao Content Pflege nicht geben. Mann muss seine individuellen Content Elemente selber mit Hilfe von Twig zusammenstellen.
Das optionale Backend ist extrem feature-reich und die Community ist relativ groß.

Pico CMS http://picocms.org/

wäre hier wohl auch noch erwähnenswert.

[Spooky]

Sulu CMS: https://sulu.io/de

Ähnliches Content-Management Konzept, wie Contao, finde ich.
Ebenfalls deutsche Entwickler, falls das für dich wichtig ist.

Muss man sich mal anschauen. Ein CMS basierend auf Symfony, CMF und PHPCR klingt sehr vielversprechend. Sieht man, dass Contao mit der 4 den richtigen Weg geht.

Nicht nur das, es wird auch komplett über composer gemanaged

[tab]

Ist schon auffallend, dass einige der "Ersatz-CMSe" ebenfalls auf Symfony basieren, teilweise sogar auch mit Composer arbeiten. Wenn man mit den Features von Contao nicht zufrieden ist oder auf der Suche nach etwas, was besser für die eigenen (Privat-, Vereins-, Kunden-)Projekte geeignet ist, ok. Warum nicht das Optimum suchen? Auf der Flucht vor den Systemanforderungen und Problemen von Contao 4/Symfony/Composer, worum es hier im Thread letztlich geht, bringt einen das allerdings auch nicht weiter. Da sollte man dann schon Alternativen suchen, die auch in einigen Jahren noch garantiert ohne Symfony und Composer auskommen.

Node-basierte Systeme? Hochinteressant. Da könnte ich dann aber auch einwenden: "Nicht jedes Hosting bietet node.js". Wenn selbst selbstverständliche Dinge wie PDO schon als NoGo dargestellt werden, braucht man an node.js erst gar keinen Gedanken zu verschwenden.

[mlweb]

Vielleicht könnten sich auch alle, die gern 3.5 behalten mögen, zusammentun und dieses System in einem Fork weiterentwickeln?

[thesweetg]

Ich hab das "concrete5" jetzt mal kurz ausprobiert:
Auf den ersten Blick sehr überzeugend.

Die lokale Installation ist angenehm einfach:
- Zip runterladen
- Zip entpacken
- Ordner im Browser über "localhost" aufrufen

Ich muss:
- keinen Sub-Ordner anlegen
- keinen Virtual-Host erstellen
- keine Datei umbenennen

... einfach sehr Benutzer- und Einsteigerfreundlich.
So ködert man neue - nicht ganz so professionelle - Admins.

Das ist es was mir bei Contao 4 ein wenig fehlt.
Aber vielleicht will man ja diese Admins nicht mehr

[f.basara]

Ist schon auffallend, dass einige der "Ersatz-CMSe" ebenfalls auf Symfony basieren, teilweise sogar auch mit Composer arbeiten. Wenn man mit den Features von Contao nicht zufrieden ist oder auf der Suche nach etwas, was besser für die eigenen (Privat-, Vereins-, Kunden-)Projekte geeignet ist, ok. Warum nicht das Optimum suchen? Auf der Flucht vor den Systemanforderungen und Problemen von Contao 4/Symfony/Composer, worum es hier im Thread letztlich geht, bringt einen das allerdings auch nicht weiter. Da sollte man dann schon Alternativen suchen, die auch in einigen Jahren noch garantiert ohne Symfony und Composer auskommen.

Node-basierte Systeme? Hochinteressant. Da könnte ich dann aber auch einwenden: "Nicht jedes Hosting bietet node.js". Wenn selbst selbstverständliche Dinge wie PDO schon als NoGo dargestellt werden, braucht man an node.js erst gar keinen Gedanken zu verschwenden.

Auf nem lokalen oder Node kompatiblen System mit NodeJS und z.b KeystoneJS als CMS entwickeln und auf den server per webpack nur noch statische Seiten ausliefern.
Ist nicht nur sicherer, sondern auch besser im Sinne der Performance, zumindest habe ich diese Erfahrung gemacht.
Symfony hat sich auf jeden Fall behauptet, dennoch gibt es mehr als genug Systeme die auf Laravel setzen.

[Franko]

...Node kompatiblen System

Hm, war nicht ein Kritikpunkt hier immer die Kommandozeile?



Gesendet von iPhone mit Tapatalk

[tab]

Auf nem lokalen oder Node kompatiblen System mit NodeJS und z.b KeystoneJS als CMS entwickeln und auf den server per webpack nur noch statische Seiten ausliefern.
Ist nicht nur sicherer, sondern auch besser im Sinne der Performance, zumindest habe ich diese Erfahrung gemacht.
Symfony hat sich auf jeden Fall behauptet, dennoch gibt es mehr als genug Systeme die auf Laravel setzen.

Alles prima, aber. Laravel setzt auch auf Composer -> Kein Vorteil gegenüber Contao 4/Symfony im Sinne dieses Threads. Lokal entwickeln und dann auf den Webserver hochladen? Durchaus sehr sinnvoll. Aber das kann ich auch mit Contao 4, da hindert mich nichts dran. Also wiederum kein Vorteil gegenüber Contao 4/Symfony im Sinne dieses Threads.

Bitte nicht missverstehen. Das können alles prima Systeme sein, die echte, vielleicht sogar bessere Alternativen zu Contao 4 sein mögen. Aber im ursprünglichen Kontext dieses Threads bieten sie keine Vorteile gegenüber Contao 4. Laravel wird dank Composer auch nicht weniger RAM brauchen. Lokale Entwicklung + Deployment ist auch mit Contao 4 möglich.

[Franko]

... und für node.js braucht’s auch nen Paketmanager - nennt sich halt anders: npm...


Gesendet von iPhone mit Tapatalk

[DampfHans]

Sehe ich genauso wie tab - das Problem ist Composer mit seinem unglaublichen Ressourcenhunger (oder Symfony mit seinem Riesenpack Erweiterungen - weswegen Composer so gierig wird).

Insofern macht es auch keinen Sinn auf Systeme zu schielen, die die gleiche Kombi Symfony/Composer nutzen. Da gibt es genau das gleiche Problem (Einfach mal "symfony composer memory" googlen...)

Da ich meinen Kunden kein Hosting vorschreiben kann -schon gar nicht bei bestehenden Verträgen- und die zehn wichtigsten Hoster in Deutschland (https://de.hostadvice.com/marketshare/de/) mit zusammen über 60% Marktanteil durch die Bank nicht genug Prozess-Speicher zur Verfügung stellen (Ja, auch dem PHP-CLI-Prozess), ich aber auch nicht einfach mal so von Contao wegkomme (wenn man über 100 Kunden erzählt, wie toll Contao ist, dann macht man sich schnell unglaubwürdig, wenn man auf einmal was anderes empfiehlt) werde ich wohl bei dem alten Spiel bleiben: Alles auf einem Entwicklerserver fertig machen, hochkopieren und nach Möglichkeit nie wieder rangehen.

So stelle ich mir den Nutzen eines Packetmanagers eigentlich nicht vor - der sollte Updates auch (und grade) im laufenden Betrieb hinbekommen. So müsste ich nicht hunderte von MB hin- und herkopieren (und meinen Kunden sagen muss, dass sie sich in der Zeit bitte nicht in Contao anmelden sollen). Bei einer Bäcker- oder Tischler-Homepage mag das gehen - aber einige meiner Kunden sind darüber "nicht glücklich". (Bei 3.5 ist es an sich natürlich genauso - aber die Datenmengen sind viel kleiner und man hat das ganze System viel besser im Überblick)

Aber vielleicht kommt ja mal das CMS, das ich mir wünsche (In-Place-Editing, PHP nur für Model, Controller und natürlich View über Javascript, ggfls. Angular im Hintergrund und -träum, träum- node.js statt PHP auf dem Server). Und bis dahin bleibt es wohl bei Contao ohne Manager - zumindest bei "ducrhschnittlichen" Hosting-Paketen.

[Stefko]

Alles auf einem Entwicklerserver fertig machen, hochkopieren und nach Möglichkeit nie wieder rangehen.

Warum denn das? Wenn Du doch eh einen Entwicklungsserver nutzt, was spricht dann dagegen die Auflösung dort auszuführen und auf dem Zielsystem nur noch ein composer install? Dazu musst Du lediglich zwei Dateien kopieren (composer.json und die composer.lock).
Ganz unabhängig davon, dass ich Updates auf Live-Systemen "etwas" kritisch betrachte - bin aber auch bekennender Warmduscher

[Franko]

Dazu musst Du lediglich zwei Dateien kopieren

Siehe auch: https://getcomposer.org/doc/06-config.md#platform


Gesendet von iPhone mit Tapatalk

[Franko]

Würden denn Paket Installationen via npm in einer Node Umgebung auf dem Server auf Hostern laufen die zur Zeit hinsichtlich der Abhängigkeits Auflösung via Composer Probleme machen? Und warum?
Danke
Franko


Gesendet von iPhone mit Tapatalk

[DampfHans]

@f.basara: Vielen Dank für Deine Vorschläge! Vor allem Conrete5 gefällt mir super! Es kann -aber muss nicht- mit Composer installiert werden, es versteht sich selber als Framework (so wie Contao früher), es übernimmt von Symphony nur das allernötigste (z.B. den Class-Loader, so eine schlanke composer.json hab' ich noch nie gesehen ;-) ), man kann es auf jeden Webspace kopieren und es läuft (so wie Contao 3.5), der Quelltext ist sofort lesbar, das ganze Paket hat knapp 40MB und es braucht -angeblich- nur 64MB Mem-Limit (ob das für ein Composer-Install gilt wird sich zeigen). Werde ich auf jeden Fall mal ausführlich testen...

[lucina]

Sorry, could not resist ...

https://youtu.be/YSMCC4sGkSo

[DampfHans]

@Franko: Das weiß ich nicht... ist ja nicht vergleichbar... Nur mit npm habe ich so einen Stress noch nie gehabt. Nun laufen die "node.js-Geschichten" auch nicht bei irgendwelchen Hostern sondern (in meinem Fall) immer auf dedizierten Servern. Ich glaube auch, dass node.js bei Hostern sobald nicht kommt... wer weiß. Es war ja auch kein Systemvergleich sondern nur meine Erfahrung mit anderen Packet-Managern.

Aber ich hab' jetzt keine Zeit mehr, ich muss zu Netto.

[BugBuster]

Aber vielleicht will man ja diese Admins nicht mehr

Richtig, man möchte das sich die Admins weiterbilden und weiterentwicklen, genauso wie es fast jede Software tut.
Das sollte auch im eigenem Interesse sein, wenn man sein Job noch ne Weile behalten will.

[Franko]

Ich habe aufgehört Systeme nach Anforderungen auszuwählen. Installieren u. Einige Inhalte setzen geht immer irgendwie. Wichtig ist wenn es mal hakt. Da muss man akut reagieren können und ich habe Zeit für permanente Recherche fest im Workflow. Das auch noch f. multiple Systeme aufzuteilen geht für mich als Einzelkämpfer nicht - man hat ja auch noch andere Baustellen. Wenn jemand partout z.B. Drupal haben will gebe ich ihn vertrauensvoll an einen Kollegen und umgekehrt...
Da bin ich der Warmduscher [emoji3]


Gesendet von iPhone mit Tapatalk

[mlweb]

Geht mir genauso.
Nur ein CMS und pures HTML.