Druckbare Version
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.Zitat:
Zitat von f.basara
Für Sachen, wo Flatfile reicht als Datenstruktur, könnte man mal checken.Zitat:
Zitat von f.basara
Ist mir von Namen bekannt, aber noch nie gecheckt. Gut zu sehen, dass auch hier Symfony, Doctrine und Composer die Basis bilden.Zitat:
Zitat von f.basara
Pico CMS http://picocms.org/Zitat:
Zitat von f.basara
wäre hier wohl auch noch erwähnenswert.
Nicht nur das, es wird auch komplett über composer gemanaged :)Zitat:
Zitat von webstarMuss 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.Zitat:
Zitat von 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.
Vielleicht könnten sich auch alle, die gern 3.5 behalten mögen, zusammentun und dieses System in einem Fork weiterentwickeln? ;)
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 :)
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.Zitat:
Zitat von tab
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.
Hm, war nicht ein Kritikpunkt hier immer die Kommandozeile?Zitat:
Zitat von f.basara
Gesendet von iPhone mit Tapatalk
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.Zitat:
Zitat von f.basara
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.
... und für node.js braucht’s auch nen Paketmanager - nennt sich halt anders: npm...
Gesendet von iPhone mit Tapatalk
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.
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).Zitat:
Zitat von DampfHans
Ganz unabhängig davon, dass ich Updates auf Live-Systemen "etwas" kritisch betrachte - bin aber auch bekennender Warmduscher ;)
Siehe auch: https://getcomposer.org/doc/06-config.md#platformZitat:
Zitat von Stefko
Gesendet von iPhone mit Tapatalk
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
@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...
Sorry, could not resist ...
https://youtu.be/YSMCC4sGkSo
@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.
Richtig, man möchte das sich die Admins weiterbilden und weiterentwicklen, genauso wie es fast jede Software tut.Zitat:
Zitat von thesweetg
Das sollte auch im eigenem Interesse sein, wenn man sein Job noch ne Weile behalten will.
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
Geht mir genauso.
Nur ein CMS und pures HTML.
Bei Netto läuft das nicht ;). Aber z.B. bei Netcup und uberspace. Sinnigerweise läuft da auch Contao 4 inklusive Manager ohne irgendwelche Klimmzüge. Zufall?Zitat:
Zitat von DampfHans
Edit: Ach so, zu der Hosterliste ... Warum kommt mir bei solchen Statistiken nur immer der alte Spruch in den Kopf: "Leute esst Sch***sse, Millionen Fliegen können nicht irren."
1&1 - dort haben einige bei neueren Paketen schon erfolgreich installiert (hängt wohl sehr vom konkreten Paket ab), soweit ich gehört habe ist 1&1 gar nicht abgeneigt das ganze grundsätzlich zum Laufen zu bekommenZitat:
Zitat von DampfHans
Strato - haben einige gerade erfolgreich getestet, weil in PHP 7.2 nun auch php_intl zur Verfügung steht (https://community.contao.org/de/show...l=1#post464313), etwas was Ende letzten Jahres noch vehement als absolut unmöglich fürs Shared Hosting bekannt gegeben wurde, MyISAM steht da scheinbar auch wieder zur Verfügung
Mittwald - funktioniert nach meinem Kenntnisstand, hatten früher (aktuell bin ich da überfragt) auch Contao 4 als vorinstalliertes Paket. Ist zwar nicht mein Ding, aber zeigt dass es funktioniert
Alle drei haben zumindestens in den neueren Paketen auch ssh-Zugang. Man kann also bei Speicherproblemen fix lokal oder auf einem Entwicklungsserver updaten und die composer.json und composer.look hochschieben und braucht dann nur noch composer install.
Gerade an 1&1 und Strato sieht man, dass es bei den großen Hostern zwar lange dauert, aber auch die passen sich an die neuen Gegebenheiten an. Die wollen ja schließlich nicht reihenweise Ihre Kunden an netcup oder webgo verlieren.
Nachtrag: KasServer? - ist das nicht zufällig AllInkl. - dort läuft Contao 4 auch fehlerfrei, in den kleineren Paketen gibt es nur kein ssh
Nachtrag 2: Alphahosting - auch hier hat m.E. jemand darüber berichtet, dass er Contao 4 erfolgreich installiert hat. https://community.contao.org/de/show...l=1#post463374
Hm, die Gedanken sind frei.Zitat:
Zitat von lucina
Sitze im Zug u. habe Zeit - daher:
Anhand der Aufrufe diese Threads ist das Thema wohl nicht unwichtig. Strukturelle Kritik sollte Ok sein - aber auch müßig. Systemvoraussetzungen sind gestiegen - aber es bewegt sich immer was ...
(Die erste Anfrage zur php Cli Version bei 1&1 ist Monate her und doch hat man nun auch hier eine aktuelle )
Unabhängig davon ist die Inst. der 4er via zip, composer o. CM gegeben.
Eine 3er auf die 4er heben ebenfalls. Ein Transfer via .lock von Lokal -> 1&1 steht an und werde es dann hier mal beschreiben.
Windows/Xampp und auf meiner NAS geht. Eine zusätzl. Testumgebung werde ich auf uberspace anlegen - min. 1 EUR/Mon..
Nach den umfänglichen, strukturellen Veränderungen werden bald sicher auch weitere inhaltliche Funktionen folgen. Insofern kann ich manch Angaben hier nicht nachvollziehen.
Übrigens, gerade unterwegs ein paar Inhalte auf einer 4er geändert - mit nem iPhone 7s im Contao Backend -
Geht Super ...
Lieben Gruß
Frank
Gesendet von iPhone mit Tapatalk
Ich meine ja eher einen gewissen Mangel an Benutzerfreundlichkeit.Zitat:
Zitat von BugBuster
Ein Beispiel*:
Wenn ich der kurzen Installationsanleitung unter "www.contao.org/de/download.html" folge,
bekomme ich beim lokalen Aufruf der "contao-manager.phar.php" zuerstmal eine "Seite nicht gefunden"-Fehlermeldung.
Grund dafür: Es muss zuerst ein VHost konfiguriert werden.
Das zu wissen wird offenbar vorausgesetzt, denn es wird bei der Anleitung nicht erwähnt.
Jemand der Contao zum ersten mal bei sich am Rechner ausprobieren möchte, stößt hier schon auf die erste Hürde.
Für viele Hobby-Admins reicht diese Erfahrung wahrscheinlich schon um Contao den Rücken zu kehren.
... und das ist schade :)
Denn die Leute wissen ja nicht was ihnen entgeht.
* zumindest hab ich das mit den VHost's so verstanden.
Keine Ahnung was du da für einen Installation hast, aber wenn ich Apache installiere, bringt der eine Default Konfiguration mit, in der ein VirtualHost definiert ist.
Ich muss dazu nichts anlegen.
Sorry, was hat das mit Contao zu tun.Zitat:
Zitat von thesweetg
Wenn Du lokal was aufsetzen möchtest, so habe ich es verstanden, muss man halt dies konfigurieren. In Deinem Beispiel könntest Du dann ja nicht mal eine einfache Index.html aufrufen können ...
( und sowas kann - aber muss - eine Cms Doku nicht berücksichtigen )
Gesendet von iPhone mit Tapatalk
Und ansonsten wird hier im Forum hierzu umfänglich geholfen ...Zitat:
Zitat von Franko
Gesendet von iPhone mit Tapatalk
Gesendet von iPhone mit Tapatalk
Na - es geht wohl um eine 4er die eine Umleitung auf das Web Verzeichnis benötigt. Ist dokumentiert -Zitat:
Zitat von BugBuster
Wie man es macht im Forum hinlänglich ...
Gesendet von iPhone mit Tapatalk
Es gibt /gab hier kürzlich auch mal nen längeren Fred, der das Thema Doku betraf.Zitat:
Zitat von thesweetg
Ich glaube die Quintessenz war, jeder darf gerne mitarbeiten/sich beteiligen und diese besser machen ;)
Gesendet von iPhone mit Tapatalk Pro
Genau um die geht es.Zitat:
Zitat von Franko
... und es wäre benutzerfreundlicher bereits beim Download darauf hinzuweisen das diese benötigt wird.
[QUOTE=Stefko;465347]Es gibt /gab hier kürzlich auch mal nen längeren Fred, /QUOTE]
Fred - find ich gut [emoji3]
Eben - wenn irgendwo steht man braucht dies und das - kann man nicht alle pers. Eventualitäten abfangen...
Oder man hat Leute die derartig umfänglich dokumentieren ...
Dafür ist das Forum da und dieses hier ist in dieser Sicht erstklassig...
Gesendet von iPhone mit Tapatalk
Habe gerade auf den docs nachgeschaut - da steht
Laden Sie sich zunächst das aktuelle Contao-Archiv herunter und entpacken Sie es auf Ihrem lokalen Rechner. Verschieben Sie die Dateien in das htdocs-Verzeichnis
Also - mea culpa
Dennoch - ne kurze Suche im Forum hilft
Alles wird gut
Gesendet von iPhone mit Tapatalk
‚Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.‘
[Rick Cook]
;)
Gesendet von iPhone mit Tapatalk Pro
Grad gesehen das die Sache eh bereits angeregt/diskutiert wurde:
https://community.contao.org/de/show...t=contao+vhost
... siehe Ende des Threads.
"Besser ist gläubige Unwissenheit als vermessenes Wissen."Zitat:
Zitat von Stefko
[Augustinus Aurelius]
Web Development hat nichts mit Religion zu tun. Der Thread scheint einen neuen Tiefstand erreicht zu haben ;).Zitat:
Zitat von thesweetg
"glauben" -> "meinen, der Ansicht sein"Zitat:
Zitat von Spooky
Nix Religion.
Wie bitte? In wie fern?Zitat:
Zitat von thesweetg
Das Zitat stammt von Augustinus von Hippo, Bischof, Philosoph und Theologe. In meinen Augen wirkt die Aussage mehr theologisch als philosophisch. Paraphrasiert: Besser nur einen Glauben (an Gott und die Religion) zu haben, als vermeintliches bzw. anmaßendes Wissen.Zitat:
Zitat von thesweetg
Hi bjarke,
irgendwas stimmt mit Deinem Link nicht:
Bei mit kommt eine weiße Seite mit "22 Gründe für Contao 4.4" in der Mitte sonst nichts! :D Gar nichts!Zitat:
Zitat von bjarke
Grüße
JK
Mit Pfeiltasten kannst du Blättern
Das Zitat war so von mir gemeint:
"Besser man handelt im Glauben das Richtige zu tun, als den richtigen Weg zu kennen und alle Nichtwissenden als Idioten zu bezeichnen."
Ich dachte das geht aus dem Zusammenhang mit dem bisherigen Thread hervor.
Der wie ich finde nicht "an seinem Tiefpunkt angekommen ist", wie auch immer du das gemeint hast.
Ich wollte hier nur (aus meiner Sicht) verbesserungswürdige Dinge aufzeigen.
Man möge mir das entschuldigen, wird nicht wieder vorkommen ;)
Ich habe hier auch nicht bemerkt, dass man Nichtwissende als Idioten bezeichnet hat.Zitat:
Zitat von thesweetg
Das einzige was ich bemerkt habe, ist, dass man dezent oder durch die Blume gesagt hat:
Niemand zwingt Euch Contao 4 zu benutzen. Contao 3 wird bis Mai nächsten Jahres noch mit Sicherheitsupdates versorgt. Bis dahin wird sich noch einiges bewegen und verändern - auch bei den Hostern.
Auch danach müsst ihr nicht Contao 4 benutzen, wenn andere Systeme für Euch besser geeignet sind dann könnt ihr sie nutzen. Das muss jeder für sich entscheiden.
Das ein Forum für Contao, Beiträge nicht "zensiert", die sich damit beschäftigen die Vorteile anderer CMS auszutauschen, finde ich ganz große Klasse. Das kenne ich aus dem Domainfactory-Forum ganz anders. Da reichen schon kleine Andeutungen auf andere Hoster aus, damit der Beitrag verschwindet. Einen: "Dann geh doch zu Concrete5" muss man sich aber irgenwann schon gefallen lassen, finde ich.
Außerdem auch mal eine Frage an all die, die hier so vehement über die Schwierigkeiten mit Contao 4 sprechen: Schon mal beim öffentlichen Mumble Call dabei gewesen? Dort werden auch Eure Probleme diskutiert.
Moderation:
Naja, wir haben schon überlegt, ob wir das Thema so lassen und uns dann dafür entschieden, dass es möglicherweise für welche, die an ihre technische Grenze kommen, durchaus interessant sein kann, sich auch über andere Systeme informieren zu können.
Als Nachtrag also hier noch ein Link auf das CMS-Garden-Projekt, in dem verschiedene Open Source-Systeme seit Jahr und Tag prima nebeneinander gedeihen und zusammenarbeiten: http://www.cms-garden.org/de
Zitat:
Zitat:
Welches ist das beste CMS, welches CMS passt zu Ihnen? Haben Sie auch schon recherchiert und alles, was Sie herausgefunden haben, ist, dass jedes Content-Management-System behauptet, das beste zu sein, das am einfachsten zu bedienende, das modernste und jeweils mit unerschöpflichen Möglichkeiten?
Im CMS-Garden hat Ihr Irrweg ein Ende: Alle relevanten Open-Source-CMS sind hier versammelt. Vergleichen Sie und entscheiden Sie. Die hier versammelten Informationen kommen direkt von uns: von den Communities. Wir laden Sie herzlich ein, diese noch zu verbessern. Willkommen im Garten, in dem alle Pflanzen friedlich beieinander wachsen!
Ja ich! Leider verpasse ich den Termin allzu oft. Gestern habe ich ihn mal nicht verpaßt. Die Entwickler-Crew verfolgt sehr wohl das Forum und kennt die Nöte und Sorgen. Aber das hindert sie ja nicht daran, in neue Sphären vorzustoßen und die Anforderungen für Contao 4 in die Höhe zu schrauben. Mitte der 90er Jahre wäre der Composer-Entwickler wahrscheinlich gesteinigt worden. Damals kämpften wir noch um jedes Byte konventionellen Arbeitsspeicher unterhalb der 640-kB-Schallmauer. Die Programmierer mußten sich noch den Kopf zerbrechen, wie sie solche Datenmengen (wie bei der Abhängigkeitsprüfung des Composer) möglichst schnell und effizient verarbeiten. Mit den immer schnelleren Prozessoren und größeren Speichermöglichkeiten hat Meister Schlendrian Einzug in der Programmiererei gehalten. Heute wird geklotzt anstatt den Code so effizient wie möglich zu gestalten. Mit Composer kämpfen wir jetzt schon im Gigabyte-Bereich. Der Composer-Entwickler auf der CK in Potsdam gesagt, daß das nicht anders lösbar ist. Sein Programm bleibt weiter speicherhungrig. Vor rund 25 Jahren undenkbar.Zitat:
Zitat von mlweb
Sorry, aber diese Ansicht kann doch nicht produktiv sein. Egal ob du "Nichtwissende als Idioten bezeichnest" oder nicht, es ist doch sicherlich niemals besser zu handeln im Glauben das Richtige zu tun, als den richtigen Weg zu kennen.Zitat:
Zitat von thesweetg
Das mag in einigen Fällen so sein. In welchen Fällen das tatsächlich so ist, kann ich als Nichtprogrammierer nicht beurteilen.Zitat:
Zitat von Samson1964
Damals haben die Entwickler aber auch die vorhandenen technischen Möglichkeiten ausgereizt. Warum willst Du den heutigen Entwicklern vorwerfen, dass Sie die technischen Möglichkeiten von heute ausnutzen.Zitat:
Zitat von Samson1964
Ich kann sogar noch weiter zurückdenken. Da gab es keine PCs, da gab es Großrechner und ablauforientierte Programmiersprachen wie Fortran, Pascal ..., gestanzt auf Lochkarten oder Lochstreifen. Die zur Verfügung stehende Rechenzeit war stark limitiert ... auch da wurde versucht alle Möglichkeiten auszuschöpfen, die diese Technik hergab.
Ich glaube nicht, dass der Entwickler von Composer gesteinigt worden wäre. Ich glaube eher, das solche Datenmengen damals aus objektiven Gründen nicht hätten in dieser Zeit verarbeitet werden können. Damals steckte das Internet übrigens noch in den Kinderschuhen :D. Niemand hätte darüber nachgedacht solche Abhängigkeiten beim Provider aufzulösen... Da war man froh wenn man seine statische Website im Tabellenlayout in Netz bekam.Zitat:
Zitat von Samson1964
Bist Du Dir sicher, dass der Composer Entwickler sein Programm nicht schon optimiert hat. Vielleicht wäre der Speicherbedarf ohne Optimierung um ein vielfaches höher.Zitat:
Zitat von Samson1964
Es wird aber auch kontinuierlich an der Weiterentwicklung des Contao Managers gearbeitet und an Lösungen das Speicherproblem in den Griff zu bekommen. So etwas bekommt man natürlich nicht mit, wenn man es gar nicht wahrnehmen will. Dazu muss man nicht einmal bei Mumble sein. Solche Informationen findet man auch in den zahlreichen Forendiskussionen und m.E. auch in News oder auf den Veröffentlicheten Beiträgen von Konferenz bzw. Camp.Zitat:
Zitat von Samson1964
Wenn Entwickler so etwas nicht tun würden, wären wir in der Steinzeit geblieben.Zitat:
Zitat von Samson1964
Freut mich, dass es auf Anhieb geklappt hat. In der heutigen Zeit können auch Content Management Systeme anständige On-Boarding Prozesse anbieten, finde ich. Und es scheint als ob viele Software-Pakete, ob CMS oder nicht, auf verbesserte UX setzen. CMS Nutzer sind auch Nutzer, ob sie Entwickler sind, oder nicht tut garnichts zur Sache. Man nutzt ein CMS, um sich die Arbeit zu erleichtern, und wenn ein CMS viele Probleme bei einem anscheinend großen Teil der Userbase verursacht, finde ich Threads wie diese äußerst wichtig.Zitat:
Zitat von DampfHans
Habe nun auf ProductHunt gestöbert und paar weitere Alternativen zusammengestellt, manche von den Beispielen sind zwar nicht SaaS, aber kosten einmalig / pro Seite
https://www.netlifycms.org/
https://craftcms.com/
https://www.pulsecms.com/pulse5/
https://www.simplajs.org/
http://keystonejs.com/
http://apostrophecms.org/
https://www.endurojs.com/
Sind alle sehr unterschiedlich, aber eventuell interessant die wenigstens mal anzuschauen.
Na, da kannst Du dann ja auch eine Googlesuche nach 'CMS' verlinken. 'Open Source' sollte schon im Fokus stehen. Bitte.
ja, früher war alles besser - sogar die Zukunft ;)Zitat:
Zitat von Samson1964
Mitte der 90er wurde an der autoexec.bat und hymem.sys herumgedoktert wie blöde und versucht das letzte Byte zusammen zu kratzen. Ich will mich nicht mehr erinnern, was ich damals für Klimmzüge veranstaltete um WingCommander zum Laufen zu bewegen ... ich dachte ich werde zum Eichhörnchen.
Internet und Foren wie wir es heute gewohnt sind waren noch in den Kinderschuhen und man hat sich die entsprechenden Tipps aus diversen Computerzeitschriften zusammen gesucht.
Also ich sehe da jetzt nicht wirklich den großen Unterschied oder gar einen Grund die Vergangenheit zu verklären.
Bis auf Craft und Pulse sind alle open-source.Zitat:
Zitat von lucina
Usenet, nicht zu vergessen. Verklären würde ich die Vergangenheit nicht wollen. Aber, wenn man anschaut, was mit den damaligen Ressourcen möglich war, kann man natürlich schon ins Grübeln kommen. Auf einem Multi-User System mit 384KB Hauptspeicher Bilder zu verarbeiten, die ein Vielfaches davon an Gesamtgröße hatten? Alles kein Problem! Damals war der knappe Speicher eben eine Rahmenbedingung für die Optimierung eines Programms. Zeitbedarf wichtig, aber letztlich doch sekundär. Über die Speicherbegrenzung gab es nicht viel zu diskutieren, das war eben ein Fakt. Ob das Programm dann eine Sekunde gebraucht hat oder zwei, das war auch damals wichtig, aber im Zweifelsfall nicht in Stein gemeißelt. Was nicht geht, geht nicht ... Was nicht besonders gefällt, ist vielleicht doch akzeptabel, wenn es partout nicht anders geht.Zitat:
Zitat von Stefko
Die Optimierung eines Programms zur Lösung einer vorgegebenen Aufgabe hängt immer auch von den Rahmenbedingungen ab. Sind die Rahmenbedingungen "möglichst schnell, Speicherbedarf egal" dann sieht das optimale Programm anders aus als wenn unter der Prämisse "Speicherbedarf < 128 MB, Zeit egal" optimiert wird. Je nach Rahmenbedingung mag es auch gar kein optimales Programm geben, das alle Rahmenbedingungen einhält (z.B. Zeit < 60 Sekunden, Speicherbedarf < 128 MB). Dann kommt natürlich hinzu, dass die Algorithmen in der Regel einfacher werden, wenn mehr Speicher zur Verfügung steht. Damit auch weniger fehleranfällig, leichter zu testen usw. Und dann kann man natürlich auch davon ausgehen, dass ein Programm meist zur Lösung einer relativ konkreten Aufgabe geschrieben wurde. Das lässt sich oft nicht beliebig skalieren.
Konkret, was mit 10 Paketen noch gut funktioniert ist mit 100 oder 1000 Paketen halt unter Umständen nicht mehr praktikabel oder nur noch unter großen Schmerzen. Es ist völlig klar, dass man für jede Hardware (egal wieviel RAM sie zur Verfügung stellt, 32MB oder 32TB) eine Kombination aus Paketen finden kann, wo Composer wegen zu hohen RAM-Bedarfs aussteigen wird. In gewissem Sinne wird hier eben auch die an sich wünschenswerte Modularität zum Fluch. Viele relativ kleine Module, übersichtlich und gut zu testen. Aber daraus resultierend eine schnell kombinatorisch explodierende Anzahl von Kombinationen der Module in unterschiedlichen Versionen. Die Konsequenz daraus sollte eigentlich aus Anwendersicht sein, die in Frage kommenden Versionen der einzelnen Module möglichst sinnvoll zu begrenzen. Das geht ja auch durchaus mit Composer. Man kann z.B. nur stabile Versionen zulassen oder nur (mindestens) Beta-Versionen. Oder Entwickler-Versionen bzw genau spezifizierte Versionen nur für bestimmte Pakete. Allein das kann die Aufgabe für Composer - und damit auch den RAM-Verbrauch - schon gewaltig reduzieren.
Die Installation von Contao und aller dort mitgelieferten Abhängigkeiten funktioniert ja mittlerweile nach Überwindung der Kinderkrankheiten (intl-Erweiterung usw.) mit dem Contao-Manager recht gut. Aber warum verweigert der integrierte Composer wegen Speichermangel danach die Installation des m17-sticky-backend-footer, der bekanntermaßen keine Abhängigkeiten benötigt. Es ist doch schließlich schon alles bei der Contao-Installation geprüft worden. Nun kommt ein klitzekleines Tool hinzu, wo der Composer maximal den m17-sticky-backend-footer mit den installierten 10-15 Komponenten vergleichen muß und der Composer raucht ab.Zitat:
Zitat von tab
Geht denn das mittlerweile mit dem Contao-Manager lokal? Ich dachte eigentlich nicht, zumindest unter Windows.Zitat:
Zitat von thesweetg
Habe übrigens gestern mal inspiriert durch die anscheinend einfache Installation anderer CMSe mit Contao auch mal die simpelste aller Methoden ausprobiert. Manuelle Installation. XAMPP 7.2.1 installiert, zu ladende Module angepasst in der php.ini, Zip-Datei der neuesten 4.4.x in ein Unterverzeichnis von htdocs entpackt (d:\xampp\htdocs\test), localhost/test/web/contao/install aufgerufen, Datenbankzugangsdaten eingetragen usw. Läuft. Backend ist soweit eingerichtet, die ersten Inhalte werden bereits ausgegeben. Heute abend werde ich dann mal versuchen, mit Composer Erweiterungen zu installieren.
Auch die Installation von Erweiterungen klappt problemlos. Composer-Installer von getcomposer.org runtergeladen und ausgeführt, bei der Installation php.exe aus dem php-Verzeichnis ausgewählt. composer require und composer update funktioniert prima. Jetzt probiere ich heute noch, die lokale Installation mit Hilfe des Symlink-Skripts von BackupDB auf den Online-Webspace umzuziehen. Ist da etwas Besonderes zu beachten, wenn man lokal im Unterverzeichnis installiert hat? Wenn das auch noch klappt, dann war das aber echt einfacher als ich erwartet habe. Dann brauche ich nur noch ein Hostingpaket mit wenig RAM, damit ich von der dann möglichen lokalen Entwicklung mit anschliessendem Deployment auch profitieren kann.;)
Edit: Und auch noch alles, ohne einen vHost einrichten zu müssen...
Eigentlich sollte das Symlink-Script von BackupDB die Quell- und Zielpfade berücksichtigen, auch die Unterschiede Windows und Linux.
Du kannst dann ja mal Feedback geben, ob alles so geklappt hat.
Ich arbeite bisher ohne das script. Immer mit Neuinstallation und Übertragung der DB und von files und templates (ggf. manuell installierte Erweiterungen) und entweder nur composer.json (wenn genug RAM da ist) oder mit composer.lock.
Übrigens die neue Version des Managers erlaubt auch bei Neuinstallation eine composer.json und composer.lock im root der Installation.
Als kleiner Nachtrag: Ich habe mal Symfony 4 installiert und ein bischen rumprobiert. Nachteil: Es hat sich ganz schön viel geändert (Es gibt kein web-Verzeichnis mehr :eek:). Vorteil: Eigentlich ist alles besser geworden. Insbesondere ist Symfony jetzt VIEL ressourcenschonender - ein Composerlauf ist schon mit 100M oder weniger machbar. Das liegt vor allem daran, dass ein "nacktes" Symfony so gut wie keine Bundles mitbringt - man also nur die Bundles "nach-required", die man auch wirklich braucht.
Ich weiß nicht, welche der ganzen Bundles in Symfony 3 Contao tatsächlich braucht und was nur Totholz ist (da Contao ja eine ganze Menge "Framework-Funktionen" mitbringt könnte das eine ganze Menge sein...) aber es besteht die Hoffnung, dass -sobald Contao dann auch Symfony 4 nutzt- auch die Speicherprobleme mit dem CM der Vergangenheit angehören und das ganze Contao dann logischerweise auch wieder deutlich schlanker wird. Hoffentlich recht bald.
P.S.: Symfony 4 ist auch sonst viel besser als 3 :)
Symfony 4 website skeleton:Zitat:
Zitat von DampfHans
Code:composer create-project symfony/website-skeleton . --profile
Memory usage: 191.27MB (peak: 448.02MB)
Code:composer update --profile
Memory usage: 194.1MB (peak: 362.97MB)
Symfony 3 standard edition:Code:composer create-project symfony/framework-standard-edition . --profile
Memory usage: 8.05MB (peak: 94.72MB)
Die peak memory usage ist bei einem create-project des Symfony 4 website skeletons prinzipiell höher. Ein composer update desselbigen verbraucht zwar tatsächlich weniger Speicher - aber das ist nicht weiter verwunderlich, da die direkten Abhängigkeiten geringer sind und da Symfony 4 sehr neu ist, existieren auch noch nicht so viele verschiedene Versionen der jeweiligen Abhängigkeiten.Code:composer update --profile
Memory usage: 189.07MB (peak: 515.14MB)
Das klingt schon mal gut. Bin bisher leider doch noch nicht zum Testen gekommen, hoffe aber, es klappt wenigstens diese Woche noch. Ich werde dann in jedem Fall berichten...Zitat:
Zitat von do_while
Das werde ich bei den meisten Projekten wohl auch so machen. Aber ich will zumindest mal den "worst case" ausprobieren. Kein SSH-Zugang, Installation über Manager oder Composer läuft nicht. Also lokale Entwicklung und Deployment auf den Kundenwebspace nur per FTP möglich. Datenbank-Import sollte ja normalerweise überall irgendwie möglich sein :rolleyes:.Zitat:
Zitat von mlweb
Wirkt das direkt nach erstmaligen Aufruf des Managers und Vorhandensein der beiden Dateien?Zitat:
Zitat von mlweb
Oder sollte ich hierzu über Systemwartung/Composer Abhängigkeiten gehen ...
Du könntest die lokal erstellen composer.json und composer.lock hochladen und den Manager aufrufen, der dann erkennt, was er installieren soll, ohne die RAM-intensive Auflösung der Abhängigkeiten zu machen. Praktisch und ressourcenschonend.
Gerade noch einmal mit der neuen beta 16 getestet. Installiert wird alles wie es in der composer.lock hinterlegt ist, d.h. man muss ggf. auf die Serverumgebung (PHP-Version) achten.
Wenn ich hier noch meinen Senf zu diesem doch schon ein paar Wochen alten Thread geben darf:
Auch ich benutze Contao 4 sehr ungern - jeder Aufruf von Contao Manager ist ein Zittern, ob er wohl startet, denn manchmal endet es einfach mit
Tja... keine Ahnung, was da dann wieder schief lief, denn sonderlich kommunikativ ist der Contao Manager ja nicht: er kennt eigentlich nur ja oder nein. :mad:Zitat:
ERROR 500 The Contao version could not be determined
Klar, die Profis machen das über SSH, aber für doch viele ist das schon eine Herausforderung, die sich unter Contao 2 bis 3 nie stellte.
Contao 3.5 läuft herrlich; bis jetzt haben wir (in unserem natürlich einfachen Standard-Kundenumfeld ohne großartigen Anforderungen) alles damit erledigen können, was gefordert war.
Warum dann überhaupt Contao 4?
Hier zeigten sich bei mir bisher nur zwei Gründe in der Praxis:
- die Möglichkeit der Blacklist beim Newsletter (obwohl das wohl über eine Erweiterung auch in 3.5 realisierbar wäre)
- die Zukunftssicherheit, nachdem es für 3.5 bereits ein Enddatum gibt :eek:
Ich weiß, das ist jetzt ein Gesudere von einem technisch nicht so eloquenten Webdesigner, wie es manche hier im Forum sind, aber Contao stand mal für ein schnelles, praktibles und flexibles System, das für 99 % der Anforderungen an ein CMS ausreichte und auch von Nicht-Linux-Fachleuten installiert werden konnte.
Heute muss ich leider feststellen, dass bereits die Suche nach einem Webhoster zu einem Drama wird - oft stellt man erst nach einem langwierigen Prozess fest, dass doch irgendwas nicht passt. Dann geht das Drama in die nächste Runde: dem Kunden erklären, warum sein bisheriger Hoster nicht ausreicht und er kündigen muss, neuen suchen, umziehen (wieder mit dem Zittern vor Symfony, Composer usw.), beim nächsten Update wieder schlaflose Nächte kriegen...
Ist denn das wirklich alles notwendig? Kann man das nicht aufteilen in eine Pro-Edition (mit dem ganzen Contao 4 Zeugs für jene, die es wirklich brauchen und dafür auch 100+ Euro pro Monat an ihren Hoster zahlen) und eine Standard-Edition (die auf 3.5 basiert und weiterentwickelt wird)?
Notwendig aus meiner Sicht: Ja. Nur so wird die Entwicklergemeinde um Contao weiter wachsen (was enorm wichtig ist für Contao selber). Auch wird nur so gesichert sein, dass Contao nicht verschwindet, sondern weiterhin am Puls der Zeit bleibt und auch in Zukunft eingesetzt werden kann.Zitat:
Zitat von eixi
Das geht bei OpenSource ganz einfach. Nennt sich Fork -> https://de.wikipedia.org/wiki/Abspal...reentwicklung)Zitat:
Zitat von eixi
Jeder der will kann sowas machen. Oder du suchst dir jemanden und tust dich mit dem zusammen um die Arbeit zu erledigen. Oder du bezahlst jemanden, der das dann für dich macht.
Oder Du bildest mit allen anderen, die nicht klar kommen und nichts dazu lernen wollen eine eigene Gemeinschaft und packt das alle gemeinsam an. Geht alles ;-)
Viele Grüße
Ich habe mal gerade Deine Beiträge im Forum angeschaut um herauszubekommen, wo es denn bei Dir nicht funktioniert, und dabei bin ich eigentlich nur auf zwei relevante Beiträge gestossen. Einer drehte sich um die Frage zum PHP-Pfad bei Mittwald - sollte gelöst sein, nachdem Mittwald auch hier im Forum Fragen beantwortet -, der andere um eine inkompatible Rocksolid-Erweiterung (sollte ja ebenfalls gelöst sein).
Der Manager ist mit Grund noch Beta, aber jede Version beinhaltet Verbesserungen. Das ist also nur eine Frage der Zeit. Der Manager ist die Komponente, die es auch Nicht-Fachleuten ermöglicht, mit Composer zu arbeiten. Andere CMS beneiden uns bereits jetzt darum.
Wie dem auch sei: Bitte schildere Deine konkreten Probleme mit bestimmten Webhostings, damit das Team dem abhelfen kann - oder den entsprechenden Hoster darauf hinweisen kann, wie Webserver besser konfiguriert werden können. In den allermeisten Fällen liegt das Problem beim Hosting, nicht beim Manager, und auch nicht bei Contao, das aufgrund der PHP 7.2-Kompatibilität wesentlich ressourcensparender ist als der 3er-Zweig. Es gibt eine Reihe von Hostern, die sich im Laufe des Jahres darauf einstellen werden (beispielsweise Hosteurope, die mir gegenüber neue Produkte angekündigt haben) , und mir ist bisher nur ein Hoster aus der Schweiz bekannt (Hoststar), der kommuniziert hat, dass er sein Hosting nicht anders konfigurieren wird.
Deinen Vorschlag bzgl. Contao 3.5 / Pro-Edition auf Basis Contao 4 gegen Zahlung eines Monatsbeitrags finde ich nicht wirklich ausgegoren. Dir steht frei, Contao 3 zu forken und dann allerdings auch für die Weiterentwicklung von veraltetem Programmcode & Konzepten und zu sorgen. Das wird sonst niemand für Dich machen. Für Contao 4 ist es ja die Frage, ob ein Hosting EUR 100,- kosten muss. Ich habe das auf diversen Hostings laufen, und das allerteuerste, das mir da untergekommen ist liegt bei EUR 30. Die Spanne beginnt bei ca. EUR 5. Das ist für einen Kunden auch kein Aufwand, den er nicht bei Kosten für eine Webseite im mindestens vierstelligen Bereich auch leisten könnte.
Ich mache da jetzt einfach mal den Gegenvorschlag, die Weiterentwicklung des Managers mit einem festen Betrag zu fördern. Wenn 100 Menschen EUR 100 zahlen, dann sollte das ja wohl für's erste reichen. Wenn sie das monatlich täten, dann hätten wir keine Sorgen mehr.
Tja, Contao 4 bei Mittwald hat wirklich funktioniert - nur war deren SQL-Server derart langsam, dass wir umziehen mussten.
Beim neuen geht's wesentlich schneller - dafür treten nun die Probleme aus dem anderen Thread auf.
Aber du wirst wohl recht haben: es liegt an den Providern.
Und da liegt es doch wieder an Contao: Contao-Check mag ja ein liebes kleines Programm sein, das schnell mal überall Grün liefert, aber ob dann doch alles 100%ig passt, kann man nicht wissen (so musste ich es zumindest bei 2 Providern bereits feststellen).
Es wäre schön, wenn Du Dein Wissen teilst.Zitat:
Zitat von eixi
Ja, es wird Zeit für etwas Neues nach Contao 4. Es wird Zeit für ein neues, vernünftiges Hosting oder für eine neue Arbeitsweise. Weg vom Update direkt in der produktiven Installation, hin zum Update in einer Kopie, sei es auf einem etwas "kräftigeren" Server oder auf einem lokalen Rechner, falls der produktive Server die notwendigen Ressourcen dafür nicht hat ;).
Contao-Check bewertet den Server nur qualitativ, welche Module sind vorhanden, welche nicht. Können Dateien geschrieben werden oder nicht usw. Er macht keine Performance-Tests. Und natürlich wird auch nur auf das getestet, was als Voraussetzung von vornherein klar ist oder auf Dinge, wegen denen es schon mal Probleme gab, über die dann auch berichtet wurde. Extensions wie intl, die defaultmäßig da sein sollten, aber es bei manchen Hostern doch nicht sind. Sonst würde der Check so lang brauchen, dass die max_execution_time überschritten würde :D.
Nein, es ist halt einfach auch so, dass an der Entwicklung niemand hauptberuflich arbeitet und es nicht immer so einfach ist vorauszusehen, was für wirre Serverkonfigurationen sich manche Hoster so alles einfallen lassen. Und es ist auch nicht so, dass derjenige grundsätzlich bei jedem Hoster über alle Hostingpakete verfügt, um mal eben nachzuprüfen, was denn jetzt bei Hoster X wirklich die Ursache für die berichteten Probleme ist. Da ist man halt auf die Mithilfe der Betroffenen angewiesen. Wenn sich rausstellt, dass irgendein bestimmtes Konfigurationsproblem für deine Probleme verantwortlich ist und sich das auch mit vertretbarem Aufwand sinnvoll testen lässt, dann wird sich das sicher in einer künftigen Version des Check irgendwann wiederfinden. @Spooky hat da schon sehr viel geleistet und hat den Check schon um einiges weitergebracht.
eixis Fragen hörten sich für mich eher nach Grundsatzfragen an. Ich zähle mich auch zu den C4-Unzufriedenen, sehe aber ein, dass diese Entwicklung notwendig ist und sich weiter verbreiten wird, so dass auch die Hoster nachziehen werden - bekanntlich sehr langsam. Die Hauptprobleme sehe denn auch bei diesem ewig langsamen Nachziehen der Hoster, in noch nicht rund laufenden Neuentwicklungen (Lucina: "Der Manager ist mit Grund noch Beta, aber jede Version beinhaltet Verbesserungen. Das ist also nur eine Frage der Zeit.") und darin, dass es keine Upgraderoutine von C3 auf C4 gibt.
Diesen Punkten würde ich noch hinzufügen: "Den Upgradeaufwand nicht vorher abschätzen können."Zitat:
Zitat von eixi
Vielleicht hätte man den LTS für C3.5 verlängern können, bis der Contao Manager zuverlässig läuft und auch alle Nicht-Nerds damit klar kommen. Contao mausert sich - zu einem CMS für Agenturen, die Experten mit unterschiedlichen Schwerpunkten im Haus haben. Da hilft Solo-Freelancern mit einem Kundenstamm ohne besondere Anforderungen an ihre Websites langfristig nur, nach Alternativen zu schauen - die gibt es ja.