Backup Update allgemein

[gera]

Hallo an alle,
um eine manuelle Aktualisierung des Systems für Lernzwecke vornehmen zu können, habe ich mir eine Testinstallation direkt auf einem Server angelegt.

Dazu habe ich diese Anweisung befolgt.
Der Ordner tl_files/* soll auch gesichert werden, da in diesem Ordner z.B. Bilder oder andere Dateien, die hochgeladen wurden, liegen.

Gibt es da keine andere Lösung, da dieser Ordner doch im Laufe der Zeit auch immer größer wird und ist es vielleicht möglich, einzelne Ordner von einer Synchronisation auszuschließen?

Was gibt es noch zu beachten?

Unter Dateien ersetzen steht noch zu lesen:
Achtung: wenn Sie Third-Party-Erweiterungen installiert haben, müssen Sie diese ebenfalls sichern und nach dem Update wiederherstellen oder darauf achten, sie gar nicht erst zu überschreiben. Andernfalls müssen diese Module neu installiert werden, was bei einigen Erweiterungen zu Datenverlust führen kann!

Was ist hier noch zu beachten?

Wie kann man bei Third-Party-Erweiterungen die Daten oder die Erweiterung selber sichern?

Kann das ganze manuelle Update Procedere bitte jemand noch etwas konkretisieren und/oder näher erläutern?-VIELEN DANK!
Gibt es zum Thema manuelles Update eine Tuto oder weitere Links die ich nicht gefunden habe?

Im Übrigen, Webseiten die aktiv sind, lasse ich alle mit dem Live Update Service aktualisieren und es gab noch nie Probleme.

MfG Gera

[xchs]

Hallo gera,

Gibt es da keine andere Lösung, da dieser Ordner doch im Laufe der Zeit auch immer größer wird und ist es vielleicht möglich, einzelne Ordner von einer Synchronisation auszuschließen?

Mit der Erweiterung "xcontaobackup" kannst Du die Daten auf Deinem Webspace sichern. Neuerdings gibt es zudem auch noch die Möglichkeit, einzelne Dateien und Ordner explizit vom Backup auszuschließen.

[gera]

@xchs

Vielen Dank für Deine Nachricht

Mehr muß man scheinbar also nicht beachten ??????

MfG Gera

[xchs]

Mehr muß man scheinbar also nicht beachten ??????

Selbstverständlich gibt es noch mehr Dinge zu beachten! Das hängt aber immer auch davon ab, welchen Versionssprung Du mit dem beabsichtigten Update vollziehst, ob Du Templates geändert hast, ob Du Erweiterungen verwendet hast, welche unter der neuen Version (noch) nicht lauffähig sind usw. usf.

[kubjo]

Hi Leute,
aus aktuellem Anlaß (geplantes Updatevon 2.9.3 => 2.9.4) stellt sich mir folgende Frage:
Ich habe meine Webseiten ebenfalls mit der von Gera verlinkten Methode installiert, dabei habe ich die Dateien via SSH geladen und entpackt. Jetzt würde ich es beim Update wieder genauso machen. Funktioniert das? Gibt es einen SSH Befehl, der Dateien/Ordner von einem Verzeichnis ins andere Kopiert?

Grüße aus Ludwigsburg
Jochen Kubik

[Sebastian]

HI

http://de.wikipedia.org/wiki/Cp_%28Unix%29

Sebastian

[soletan]

Hallo,

ich habe seit geraumer Zeit ein Skript entwickelt, welches mir unter anderem Upgrades einer Contao-Installation erleichtern soll. Ich habe dieses nun auch freigegeben und vielleicht kann es hier auch weiterhelfen:

http://www.toxa.de/installationspflege.html

[folkfreund]

Hallo soletan,

alle Achtung für dein Skript.
Ich bitte aber folgendes zu bedenken:
Es gibt mit dem Online-Update eine offizielle Version eines solchen Update-Skripts von Leo Feyer!
Zugegeben: dein Aspekt der Rechtevergabe wird dabei nicht behandelt (sollte aber eigentlich auch nicht nötig sein). Dafür werden die ggf. notwendigen DB-updates automatisch durchgeführt!

Das Online-Update ist ein nicht kostenloser aber erschwinglicher Service. Aber gerade wer professionell viele Webseiten betreut sollte bitte bedenken, welche Gegenleistung mit Contao kostenfrei zur Verfügung steht! Versteht die Gebühr für das Online-Update als Dankeschön für die Entwicklung!

Gruß, folkfreund

[soletan]

Hallo folkfreund,

erlaube mir, auf deine OffTopic-Reaktion mit einer weiteren OffTopic-Reaktion zu kontern. Ohne das LiveUpdate verteufeln zu wollen, sehe ich Einwände gegen deine Argumentation - in puncto Sicherheit wie auch in puncto Gebühren.

Zur Sicherheit: Ich programmiere nicht erst seit gestern und habe bereits Erfahrungen gemacht, wie schwer es ist, sich zur (Weiter-)Entwicklung von OpenSource ohne jede Bezahlung als Gegenwert zu motivieren. Auch in den Contao-Code habe ich schon manchen Blick geworfen. Ich bin schnell zur Überzeugung gelangt, dass die Oberfläche weit aufgeräumter ist als die Sourcen aus Sicht eines sauberen Softwaredesigns. Die meiner Meinung nach oft recht mangelhafte Präsenz einer API, die letztlich doch fehlende Umsetzung einer sauberen MVC-Struktur ist nicht nur für die Entwicklung von Erweiterungen ärgerlich, sondern auch Anlass für manche Erweiterung, mehr oder weniger viel Schindluder zu treiben. Etwa das leider nur simulierte Parameter Binding für SQL-Datenbankanfragen wird noch nicht mal in allen Erweiterungen stringent genutzt. Ebenso nutzen sogar Core-Module mal die Input-API, mal greifen Sie doch direkt auf die Eingabeparameter direkt zu, weil die Input-Klasse keine geeignete Funktionalität für eine Prüfung liefert.
Diesem Code blind zu vertrauen, mag für eine kleinere Site akzeptabel sein. Doch als professioneller Anbieter müsste ich haften, wenn einem größeren Kunden Schäden bspw. durch ein Hijacking der eigenen Website entstehen. Da ist es meiner Meinung nach nicht im Geringsten akzeptabel, für den Komfort per Live Update die Skripte meiner Website allen Nutzern und Diensten oder nur der Web-Öffentlichkeit lesbar oder gar schreibbar zur Verfügung zu stellen.

Es reicht ein Fehler in einem Skript oder nur eine bestehende Macke in PHP selbst, um dank der Schreibrechte für den Webserver auch zentralere Dateien von Contao manipulieren zu können, so dass Einbrüche letztlich besser versteckt werden können. Ich glaube, dass Contao derzeit noch die allgemeine Aufmerksamkeit fehlt, um ähnlich oft Security Updates generieren zu müssen, wie bspw. Wordpress oder Joomla.

Contao wagt sich mit Isotope (einmal mehr) in den Bereich der Online Shops. Es bewirbt die Einsatzfähigkeit für Unternehmen. All das impliziert Haftungsfragen für den Betreiber, die irgendwann beim Entwickler (also eher bei mir als gewerbetreibendem Nutzer von Contao als bei Leo Feyer) auflaufen. Kundendaten zu schützen ist eine große Herausforderung, die man nicht zu blauäugig in Angriff nehmen sollte.

Zu den Gebühren: Das Contao Open Source und damit kostenlos ist, begrüße ich. Wenn ich aber nicht spende, sondern für einen Service zahle, dann entsteht ein gewerbliches Verhältnis. Ja, die Service Gebühren implizieren keine gewerbliche Haftung für die ausgelieferten Sourcen. Das allein finde ich schon schräg.
Hinzu kommt, dass die Kosten schnell wachsen, wenn ich "professionell viele Websites" betreue, da pro Domain und auch pro Jahr gezahlt wird. Diese Kosten dann als "Dankeschön" für die tolle Entwicklung zu interpretieren, empfinde ich nach diesem Vorbericht als frech. Sie sind kein Dankeschön, Spenden wären es.

Wenn Leo für den Betrieb des Erweiterungskatalogs oder des Live Updates Kosten entstehen (und dem ist natürlich so), würde ich eher eine jährliche Spendengala unterstützen, als einen Service zu buchen, der dann diese Mehrkosten querfinanziert. Zwei Root Server "EQ4" eines Nürnberger Anbieters kosten im Jahr 1200 € ... und einer wäre vielleicht bereits ausreichend. Oder man unterstützt bei so viel Zuspruch eine Verteilung der Last auf gewillte Partner mit freien Kapazitäten.

Desweiteren sind inzwischen viele Personen neben Leo an der Entwicklung von Contao beteiligt und diese erhalten durch die Gebühren des Live Updates auch keinen nennbaren Gegenwert für ihr Engagement. Open Source ist eben oft nicht sauber auf eine Person zurückzuführen und darum sollte man Zahlungen an diese Person nicht mit der Entwicklungsarbeit am Produkt als Ganzem verbinden.

Am konkreten Beispiel besehen hatte sich das Live Update für mich im vergangenen Jahr erledigt, als ich mal bei einem Kunden die tinyMCE.php anpassen musste. Diese wurde vom LiveUpdate ersetzt, doch das LU-Backup enthielt die vorherige Version nicht. Ich musste darum meine Arbeit rekapitulieren und wiederholen. Den dadurch entstandenen Schaden habe ich gegenüber Leo nicht beansprucht und könnte eher dafür ein Dankeschön erwarten.

Ein Service mit Fehlern ist mir kostenlos lieber als wenn ich dafür auch noch Gebühren zahlen muss.

Und was das LiveUpdate auch nicht bietet sind saubere Backups. Als Betreiber eines Servers ist mir ein nächtlich per Cron gestartetes automatisiertes Backup lieber, das ein Archiv außerhalb des DocumentRoot mit ausschließlicher Sichtbarkeit für einen Nicht-Web-Nutzer verwaltet und damit sensible Daten sicherer verwahrt, als noch eine Erweiterung, welche wieder nur mit den Lese/Schreibrechten und Verzeichnisfreigaben eines Webservers agieren kann und dabei auf die sichere Konfiguration des Webservers angewiesen ist, um die archivierten Daten zu schützen.

Komfort bietet das Live Update, doch Komfort sollte nicht auf Platz 1 des Anforderungskatalogs stehen, den man im professionellen Umfeld sich selbst als Anbieter von Dienstleistungen setzt.


Viele Grüße!

[BugBuster]

Hallo Soletan,
ihrgendwie habe ich das Gefühl, Du hast einige Prinzipien von Contao nicht verstanden.
Warum sollte ein Update Mechanismus ein Vollbackup tun? Das es nur ein Backup von den Dateien anlegt die es selber updatet ist völlig normal.

Nicht updatesichere Änderungen am Core vorzunehmen, ist natürlich gefährlich, darauf wird auch hingewiesen.
Ich konnte aber diesen von Dir geschilderten Umstand noch nicht feststellen, und ich habe öfters ein Backup zurückgespielt.
Wurde der Fehler von dir gemeldet?

Desweiteren sind inzwischen viele Personen neben Leo an der Entwicklung von Contao beteiligt und diese erhalten durch die Gebühren des Live Updates auch keinen nennbaren Gegenwert für ihr Engagement.

Wieso auch? Ich bezahle ja nicht um ein Gegenwert meiner Tätigkeiten zu bekommen, sondern für das Liveupdate selbst.

Alternativen gibt es auch, sowohl für das Backup (auch komplett) als auch für das Update jeweils als Erweiterungen.
Die Frage ist doch, ob man den Kunden selbst gestatten will/muss ein Update durchzuführen oder ob man das als Betreiber selbst tun will per Service Vertrag o.ä.

Und zu Deinen Sicherheitsbedenken, wieso nutzt Du dann Open Source?

Ich habe mir auch einige Shellscripte geschrieben, aber die brauchen keine Root Rechte, Dank Apache mit suPHP, welches selber schon drauf achtet, das z.b. keine Gruppenschreibrechte vorhanden sind.

[soletan]

Warum sollte ein Update Mechanismus ein Vollbackup tun?

Das allein ist noch kein "Prinzip von Contao", oder? Ich erwarte nicht vom LiveUpdate die Funktion, Backups zu erstellen. Ich habe nur genannt, dass diese zusätzliche Unterstützung durch das Skript mit erfüllt wird. Mehr nicht.

Das es nur ein Backup von den Dateien anlegt die es selber updatet ist völlig normal.

...Diese wurde vom LiveUpdate ersetzt, doch das LU-Backup enthielt die vorherige Version nicht. ...

(ohne Worte)

Nicht updatesichere Änderungen am Core vorzunehmen, ist natürlich gefährlich, darauf wird auch hingewiesen.

Und doch sind sie mitunter unumgänglich, wenn ein Kunde eine Funktion braucht, die nur darüber realisierbar ist. Argumente wie "das kann das CMS dann doch wieder nicht" kann man mitunter schlecht kommunizieren. Und wenn ich dann dem Kundenwunsch nachkomme zählt kein "Nun können Sie aber keine Updates mehr erwarten!" ... darin sehe ich die Qualität eines professionellen Service.

Ich konnte aber diesen von Dir geschilderten Umstand noch nicht feststellen, und ich habe öfters ein Backup zurückgespielt.

Es war mit Sicherheit ein Einzelfall. Doch kann ich dir versichern, dass es ihn gab. Du lieferst schon den Beleg für eine der Fragen im nächsten Absatz, ob nicht Zweifel an einer Situation leichter fallen als die Annahme, der Fehler sei tatsächlich aufgetreten. Dass er dir nicht begegnet ist, kann wenig verwundern, da die Situation sehr speziell war und vielleicht einfach nicht in deinen Fällen auf passende Umstände als Ursache traf.

Wurde der Fehler von dir gemeldet?

Meldest du jeden Fehler an Microsoft? Oder an Apple, Adobe oder wen auch immer? QA ist eine Aufgabe des Anbieters. Ich zahle für den Service und erwarte dessen Qualität. Eine Option im gegenteiligen Fall ist die Reklamation, ja. Nur welchen Zweck hätte es in dieser Situation gebracht? Wäre mein Einwand glaubhaft angekommen oder wäre er nur mit Reaktionen wie "Haben sie mal den Stecker geprüft?" abgewehrt worden? (s.o.) Wo hätte ich ihn melden sollen? Wie lange hätte ich auf eine Lösung warten müssen? Welchen Sinn hätte diese im genannten Fall gemacht?

Ich musste den Verlust meiner Anpassungen durch deren Wiederholung beseitigen. Das war im Interesse meines Kunden, demgegenüber ich zur Haftung verpflichtet bin. Danach ist das Thema für mich gegessen. Die Umstände für das fehlerhafte Update sind dann auch nicht mehr gegeben. Ergo: abhaken und lieber in Zukunft eine Alternative einplanen (die obendrein auch bei Backups hilft).

Wieso auch? Ich bezahle ja nicht um ein Gegenwert meiner Tätigkeiten zu bekommen, sondern für das Liveupdate selbst.

welche Gegenleistung mit Contao kostenfrei zur Verfügung steht! Versteht die Gebühr für das Online-Update als Dankeschön für die Entwicklung!

Wer kriegt das Geld? Wer ist an der Entwicklung von Contao beteiligt? Die Divergenz der beiden Ergebnismengen dieser Fragen ist es, die mich zu meinen Äußerungen veranlasste. Das hast du anscheinend überlesen.

Und zu Deinen Sicherheitsbedenken, wieso nutzt Du dann Open Source?

Hier scheine ich den Zusammenhang nicht erkennen zu können. Was soll die Frage? Was ist falsch daran, wenn ich die Skriptdateien vor Schreibrechten durch den Webservice schütze? Was hat das mit meiner Nutzung von Open Source zu tun.

Ich nutze nebenbei bemerkt auch WordPress und andere CMS, mal von Joomla abgesehen. Und mit wenigen Umstellungen eignet sich mein Skript auch für deren Backups und Upgrades. Diese Breite an Anwendungsfällen trug auch zur Motivation bei, überhaupt ein solches Skript zu schreiben.

Ich habe mir auch einige Shellscripte geschrieben, aber die brauchen keine Root Rechte, Dank Apache mit suPHP, welches selber schon drauf achtet, das z.b. keine Gruppenschreibrechte vorhanden sind.

Wir lernen: viele Wege führen nach Rom. Einen davon bietet mein Skript, dass einen anderen Ansatz verfolgt als deine Sammlung. Ein anderer ist das LiveUpdate ... das ich zu keinem Zeitpunkt anderen ausreden möchte. Doch zurück zur Anfrage im ersten Post, zusammengefasst: "Wie kann ich manuell upgraden?"

Zu meinem Skript: die Prüfung auf Root-Rechte ist zentral für eine spontan breite Einsetzbarkeit. Wenn du diffizilere Rechtevergaben in einem System unterstützt, dann sollte es leicht fallen, die drei Zeilen zu entfernen und das Skript so "minimalinvasiv" anzupassen, damit es auch ohne Root-Rechte seine Arbeit verrichten kann. Ja, ich tendiere dazu, oft als root zu arbeiten. Seit 10 Jahren ist mir dabei noch nie die ganze Platte formatiert worden oder dergleichen ... und natürlich muss man der SW selbst trauen, das muss man im Fall von mod_suPHP auch, welches immerhin auch erst root werden muss, damit es in den Kontext des Nutzers deines Skripts wechseln kann. Nur leider scheitert es in einem lighttpd+fastcgi-Setup, richtig? Und damit muss ich auch umgehen können ...

Alternativen gibt es auch, sowohl für das Backup (auch komplett) als auch für das Update jeweils als Erweiterungen.

Auch das habe ich nicht ausgeschlossen, im Ansatz sogar angedeutet. Ich sehe nur ein Designfehler, wenn die Erweiterung einer Software die Software selbst sichert. Es mag problemlos gehen, doch bleibt mir der Beigeschmack der Haltung, dass ein Segelschiff mit einem Ventilator an Bord fahren könnte.
Hypothetisch bliebe auch: Jedes damit erstellte Backup bleibt - abgesehen von komplexeren Setups - in Reichweite der Erweiterung, damit des Webservers und damit auch in Reichweite einer kompromittierten Webanwendung ... wie bekämpft man die Kompromittierung einer Contao-Installation, wenn der kompromittierende Code sich in alle Backups gefressen hat? Mit einem separaten Skript kann man mit wenig Aufwand auch so vermutlich unwahrscheinliche Szenarien an einem frühen Punkt bekämpfen.

Darf ich mir dieses Fazit erlauben und damit die meiner Meinung nach unnütze Debatte etwas verkürzen? ... LiveUpdate zu nutzen bleibt jedem offen, doch der Preisgabe einer Alternative mit Lobgesängen auf das LiveUpdate zu begegnenm, wirkt auf mich fehl am Platze.

PS: Ich mag Contao, werde es auch weiterhin nutzen und empfehlen, obgleich ich Schwächen im System sehe, die IMHO aber geringere Übel als bei anderen Produkten darstellen.

[BugBuster]

Das allein ist noch kein "Prinzip von Contao", oder? Ich erwarte nicht vom LiveUpdate die Funktion, Backups zu erstellen.

Doch, und das tut es ja auch wie beschrieben. Da die Liste der Dateien für das Backup aus der Liste der Dateien für das Update generiert wird, kann ich das nicht ganz nachvollziehen. Aber nun lässt sich das ja nicht mehr reproduzieren denke ich mal.

Und doch sind sie mitunter unumgänglich, wenn ein Kunde eine Funktion braucht, die nur darüber realisierbar ist. Argumente wie "das kann das CMS dann doch wieder nicht" kann man mitunter schlecht kommunizieren. Und wenn ich dann dem Kundenwunsch nachkomme zählt kein "Nun können Sie aber keine Updates mehr erwarten!" ... darin sehe ich die Qualität eines professionellen Service.

Und was hätte es gebracht, hätte das Update funktioniert?
Nehmen wir mal an, was ich vermute, es kam eine neue Version von tinyMCE mit, ich kann mich da an einen Fall erinnern wo die Pfade sich geändert haben, und du hättest das Backup dieser einen Datei zurückgespielt.
Dann kann es funktionieren, muss aber nicht (inkompatible). Mir wäre es dann lieber einen funktionierenden tinyMCE zu haben als einen gepatchten der nicht mehr will.

Schon klar, auch ich habe einige Core Module bei der ersten Installation von mir angepasst und habe dafür aber andere Mechanismen die mir nach einem Update eine Anpassung der neuen Datei generiert.

Meldest du jeden Fehler an Microsoft? Oder an Apple, Adobe oder wen auch immer?

Nein, aber an die Contao Community wenn ich auf einen stoße. Denn das weiß ich,
a) es schaut jemand drauf ob das wirklich eine Fehler ist oder ob das mein eigenes Problem ist (bisher 50/50)
b) der Fehler recht schnell behoben wird
c) ich auf dieser Art und Weise neben meinen Entwicklungen helfen kann das System zu verbessern

Mein Prinzip ist es, den Open Source Projekten die ich nutze etwas zurück zu geben, ist es auch noch so klein. Denn der Open Source Bewegung habe ich meinen Job zu verdanken.
Du machst das mit deinem Script, andere melden Fehler, wieder andere entwickeln Module.

Wo hätte ich ihn melden sollen? Wie lange hätte ich auf eine Lösung warten müssen? Welchen Sinn hätte diese im genannten Fall gemacht?

Zuerst mal im Forum / Chat, da wird normalerweise recht schnell geholfen.
Und zuletzt im offiziellem Ticket System.

lieber in Zukunft eine Alternative einplanen (die obendrein auch bei Backups hilft).

Heißt, bei jedem Update Teile von Backups (die eigenen Änderungen) wieder zurückspielen?
Könnte das nicht dazu führen ein gelieferten Security Patch wieder rückgängig zu machen? Hmm, dann patche ich doch lieber meine Änderungen erneut am neuen Original und schaue mir vorher an was geändert wurde.

Wer kriegt das Geld? Wer ist an der Entwicklung von Contao beteiligt? Die Divergenz der beiden Ergebnismengen dieser Fragen ist es, die mich zu meinen Äußerungen veranlasste. Das hast du anscheinend überlesen.

Nö, ganz wie du selber sagst, ich bezahle für einen Service. Punkt.
Da manche das als Dankeschön sehen, was solls? Ich unterstütze nebenbei damit das Projekt, ist doch OK. Das geht auch über andere Dinge die Leo anbietet klar, aber ich als Privat Person nehme ebend das.
Da das auch recht preiswert ist, ist der nette Nebeneffekt, das auch Privatpersonen wie ich das nutzen. Das wiederum führt dazu, das die Contao Installationen von denjenigen recht schnell ein Update bekommen sobald öffentlicht. Besonders dann, wenn es sich um ein Security Update handelt. Das kommt wiederum dem Projekt zugute (wenig ungepatchte im Umlauf). Joomla Updaten? Ja habe ich auch mal gemacht, nun läuft eine alte Seite von mir schon 2 Jahre ohne Update, keine Lust dazu. Das ist der Unterschied, der Mensch ist bequem.

Doch zurück zur Anfrage im ersten Post, zusammengefasst: "Wie kann ich manuell upgraden?"

Mit easyupdate, und wenn man ganz vorsichtig ist, generiert man sich eigene updatepakete die nur die Files enthalten die sich geändert haben (und könnte seine eigenen darin auch noch einbauen). Nebenbei, auch diese gibt es bereits von einem Contao Fan.

Nun, ich denke mal Contao ist nicht für Hoster mit 1-Klick-Installer geschrieben worden um den Kunden nun noch weniger Arbeit zu machen.
Wenn man diese ganzen Dinge die entweder eine Agentur per Service Vertrag leistet oder der Eigentümer mit genug Ahnung selbst, dann muss man natürlich dazu weitere Software einsetzen.
Nun vertraue ich da beispielsweise wiederum auf Open Source und nehme für größere Installationen MySQL Dumper, für die Backups meiner Gigabyte Datenbanken sehr nützlich, und rsync+ssh für die Files in Verbindung mit SVN. (noch ein Weg nach Rom)
Sicherlich nichts für Admins/Hoster, ok, aber bevor ich da was selber schreibe für komplette Sicherungen und dabei vielleicht noch Fehler mache bzw. bestimmte Situationen nicht bedenke...

PS: Ich mag Contao, werde es auch weiterhin nutzen und empfehlen, obgleich ich Schwächen im System sehe, die IMHO aber geringere Übel als bei anderen Produkten darstellen.

Wenn du dafür detailierte Anregungen hast, sind die hier gern willkommen.

[soletan]

Doch, und das tut es ja auch wie beschrieben.

Dann habe ich wohl einen anderen Begriff von "Prinzip" als du.

Und was hätte es gebracht, hätte das Update funktioniert?
Nehmen wir mal an, was ich vermute, es kam eine neue Version von tinyMCE mit, ich kann mich da an einen Fall erinnern wo die Pfade sich geändert haben, und du hättest das Backup dieser einen Datei zurückgespielt.
Dann kann es funktionieren, muss aber nicht (inkompatible). Mir wäre es dann lieber einen funktionierenden tinyMCE zu haben als einen gepatchten der nicht mehr will.

Du scheinst den entscheidenden Punkt zu übersehen: Ein Backup hilft nicht nur beim Zurückspielen. Ein Backup bei einem Upgrade erlaubt mir auch, noch einmal die letzte Version einzusehen, bspw. um einen diff anzulegen. Das fehlte mir im Fall des damaligen Kunden. Das Upgrade erforderlich sind, bestreitet doch niemand.

Nein, aber an die Contao Community wenn ich auf einen stoße. Denn das weiß ich,
a) es schaut jemand drauf ob das wirklich eine Fehler ist oder ob das mein eigenes Problem ist (bisher 50/50)
b) der Fehler recht schnell behoben wird
c) ich auf dieser Art und Weise neben meinen Entwicklungen helfen kann das System zu verbessern

Hier kommt für mich wieder die eigentliche Haftungsfrage ins Spiel. Auch wenn ich nur 0,79 € für eine Software bezahle, dann habe ich dort was gekauft und erwarte vom Anbieter eine Sachmängelhaftung oder Gewährleistung - je nachdem, welche Grundlage greift. Da erwarte ich keine Hilfe von einer OpenSource Community. Und die ist auch nicht zur Hilfe verpflichtet.

Zuerst mal im Forum / Chat, da wird normalerweise recht schnell geholfen.
Und zuletzt im offiziellem Ticket System.

Ich hatte mal einen Fehler in einem Modul der Core Distribution im Ticketsystem gemeldet. Wurde als invalid abgewiesen. Einziger Kommentar, der Link ins Wiki. Dort stand, dass bspw. keine Module dort behandelt werden. Also vermute ich diesen Umstand als Ursache. Ich habe dazu im Forum gefragt, doch letztlich weder im konkreten Fall noch allgemein zur Vorgehensweise beim Fehlermelden in Core-Modulen eine endgültige Antwort erhalten - und das seit mehreren Wochen ...

Mit easyupdate, und wenn man ganz vorsichtig ist, generiert man sich eigene updatepakete die nur die Files enthalten die sich geändert haben (und könnte seine eigenen darin auch noch einbauen). Nebenbei, auch diese gibt es bereits von einem Contao Fan.

Dann verstehe ich erst nicht recht nicht die Aufregung um dieses Skript.

Sicherlich nichts für Admins/Hoster, ok, aber bevor ich da was selber schreibe für komplette Sicherungen und dabei vielleicht noch Fehler mache bzw. bestimmte Situationen nicht bedenke...

Nun, deine genannten Beispiele sind doch auch geschrieben und können Fehler enthalten. Und gegen Fehler helfen heutzutage viele Tests. Das man gleich alle Wege mit abdeckt, erwarte weder ich noch irgendjemand sonst, der die Materie kennt.

Wenn du dafür detailierte Anregungen hast, sind die hier gern willkommen.

Siehe oben. Ein weiterer Post schlug eine überarbeitete ModuleSearch.php vor. Bis heute ist in dem Thread seit Wochen auch wenig passiert. Sehr früh mal habe ich im Ticketsystem angemahnt, dass die mangelnde Nutzung von gekapselten Datenmodellen eher hinderlich sei. Das Ticket wurde von Leo missverstanden, anhand einer kleinen Unstimmigkeit in meinem Post lapidar als invalid abgestempelt, ein Folgekommentar meinerseits dazu ist seit mehreren Monaten ohne Reaktion dort.

Ich stoße bei meiner Arbeit dauernd über solche Macken. Wie gesagt, ModuleSeach etwa nutzt die API in $this->Input, greift zugleich auf $_POST bzw. $_GET zu. APIs sollte man nutzen. Wenn man sie nur gelegentlich nutzt und sonst umgeht, ist damit niemandem geholfen.
Eine saubere Schicht an Modellen gut gekapselten in Klassen ist eines der obersten Mankos, dass ich anführte.

Die DCA-Technik ist an sich recht prima. Leider störe ich mich am Umstand, dass sie oft gut normalisierte Tabellen verhindert und damit schnelle Datenbankabfragen, die obendrein auch den Code im PHP vereinfachen könnten, weil mehrfache Abhängigkeiten lieber in serialisierten PHP-Arrays als BLOB gespeichert werden, anstatt in korrekte m:n-Abbildungstabellen abgelegt zu werden.

Transaktionen vermisse ich auch. Das korrekte Parameter Binding wäre mir auch lieber, als ein Code, dem ich vertrauen muss, dass er alle Fälle sauber abdeckt. Die API der PDO ist einfach super, doch in Contao lieber nachgebaut. Ich vermute im Interesse einer Unterstützung von DBMSn, die nicht durch die PDO abgedeckt werden. Dennoch schade. Seit 2005 ist PHP5 auf dem Markt und meines Wissens setzt Contao seither auf diese Version. Da wäre aus meiner Sicht die Nutzung der PDO für die Masse an LAMP- und LAPP-Systemen geeigneter. Oder wie oft werden Access-Datenbanken oder MSSQL-Server für den Betrieb von Contao eingesetzt? In diesen Fällen wäre IMHO die Simulation der PDO-API in einer dann ebenfalls von der PDO abgeleiteten Klasse sinnvoller, als von Grund auf eine eigene API als Ersatz der PDO zu bauen. So habe ich es selbst oft genug praktiziert.

Die Kombination aus fehlenden Modellen und der sehr spartanischen Modul-API führen dazu, dass man als Erweiterungsentwickler mitunter die gesamte Originalklasse nachbauen muss, um seine Erweiterung zu integrieren. Noch unangenehmer wird der Part, wenn man optional eine andere Erweiterung, die das gleiche Originalmodul ableitet, mit berücksichtigen möchte. Oder auch wenn man es nicht berücksichtigen möchte, aber durch die synchrone Umleitung der gleichen Basisklasse dessen Funktionalität stört. Auch ist meines Wissens nicht hinreichend nachvollziehbar, nach welchen Kriterien dann diese Module zum Zuge kommen. Geht's echt nur nach Modulnamen? Die Erweiterungs-API als solche krankt da reichlich.

Das reicht durchaus für ein eigenes Forum ...

[BugBuster]

Ein Backup bei einem Upgrade erlaubt mir auch, noch einmal die letzte Version einzusehen, bspw. um einen diff anzulegen. Das fehlte mir im Fall des damaligen Kunden.

Da waren wir uns doch schon einig, das es scheinbar ein Fehler war, nicht ein fehlendes Feature. Mach ich eine Core-Änderung gehört ein Backup vom Original dazu. Und den Diff würde ich vorher machen um zu entscheiden, ob ich das Update überhaupt einspielen kann oder nicht.

Da erwarte ich keine Hilfe von einer OpenSource Community.

Äh, dazu sage ich mal nichts.

Ich habe dazu im Forum gefragt, doch letztlich weder im konkreten Fall noch allgemein zur Vorgehensweise beim Fehlermelden in Core-Modulen eine endgültige Antwort erhalten - und das seit mehreren Wochen ...

Im alten Wiki (das müsste der Link von Leo sein) steht aber auch, das er eine Anleitung haben will wie man diesen Fehler im Demo System nachvollziehen kann.
Ja, das geht nicht immer, weil nicht alles im Demo System machbar ist.
Feature Request sollten vorher im Forum diskutiert werden ob sinnvoll. Ich selber hatte da auch einen Fall wo ich dachte ich hätte an alles gedacht, dann kam ein Schweizer und nahm die Illusion :-) (auch auf der DevCon, Grüße in die Schweiz)
Haste mal den Link vom Ticket?

Und gegen Fehler helfen heutzutage viele Tests.

Ich habe noch nie eine fehlerfreie Software gesehen. Entweder man testet nur Fehler auf die man selber kommt und übersieht dabei Randbedingungen die andere Nutzer haben, oder man müsste eine recht aufwendige Test getriebene Entwicklung durchziehen. Auch hier ist man nicht fehlerfrei wie ich merken musste.

Sehr früh mal habe ich im Ticketsystem angemahnt, dass die mangelnde Nutzung von gekapselten Datenmodellen eher hinderlich sei. Das Ticket wurde von Leo missverstanden, anhand einer kleinen Unstimmigkeit in meinem Post lapidar als invalid abgestempelt, ein Folgekommentar meinerseits dazu ist seit mehreren Monaten ohne Reaktion dort.

Das Problem ist bekannt und glaub mir, daran wird gearbeitet.
Jedoch kann das nicht von heute auf Morgen passieren. So ein System wie Contao hat auch die Verpflichtung in den höheren Versionen nahezu kompatibel zu bleiben.

Eine DB Abstraktion völlig neu zu implementieren, z.B. über PDO, würde nicht vor Version 3.x.y passieren.
Auch muss dabei beachtet werden, ob das die Masse an Nutzer überhaupt nutzen kann (technisch). Ebenso würde das eine Anpassung aller Erweiterungen zur Folge haben. Solche Schritte sind also sorgfältig zu überlegen und zu planen. (genau das wird derzeit getan)

Die DCA-Technik ist an sich recht prima. Leider störe ich mich am Umstand, dass sie oft gut normalisierte Tabellen verhindert und damit schnelle Datenbankabfragen, die obendrein auch den Code im PHP vereinfachen könnten, weil mehrfache Abhängigkeiten lieber in serialisierten PHP-Arrays als BLOB gespeichert werden, anstatt in korrekte m:n-Abbildungstabellen abgelegt zu werden.

Das ist nun mal eines der Prinzipien von Contao, es gibt da ebend 2 Haupttechniken.
Beide haben Vorteile und Nachteile.
Normalisiertes DB Modell hätte haufenweise Joins zur Folge. Mag man gut finden, aus meiner Erfahrung musste ich bei Performance Projekten feststellen, das in so einem Fall oft die Indexe nicht mehr nutzbar waren / genutzt wurden.

Und auf die von dir auch angesprochenen Transaktionen kann ich nur sagen, das in meinem Falle ich bis vor kurzen gar nicht die Möglichkeit gehabt habe diese nutzen zu können. Auch hier wieder, kann das die Masse an Nutzer nutzen?

Bedenke auch, das Contao mit MySQL 4.1 läuft. Wenn die Anforderungen mal erhöht werden auf 5.x kann man wieder über so etwas nachdenken.
Mittlerweile habe es ja auch die letzten Hoster begriffen 5 anzubieten.

Seit 2005 ist PHP5 auf dem Markt und meines Wissens setzt Contao seither auf diese Version. Da wäre aus meiner Sicht die Nutzung der PDO für die Masse an LAMP- und LAPP-Systemen geeigneter.

Aber nicht bei den meisten Hostern, da kam PHP5 erst viel später. (Ich rede hier nicht von Root Servern)

Geht's echt nur nach Modulnamen?

Derzeit ja, alphabetisch. Auch das Problem bzw. das dies nicht optimal ist ist bekannt.

Auf der Developer Conference wurden solche Dinge wie auch die DB Abstraktion angesprochen.

Contao ist,aus meiner Sicht, ein recht junges System und wird größtenteils in der Freizeit entwickelt. Dafür kann es schon recht viel und die Entwicklung geht weiter.

Es muss den Massen gefallen, nicht wenigen mit speziellen Anforderungen.
Ich selber merke das auch bei meinen Modulen, viele Feature Requests sind recht interessant, aber für die Masse völlig uninteressant.
Merken tut man sich die trotzdem, das tut auch Leo, könnte ja mal mehr Interesse werden.

[soletan]

Äh, dazu sage ich mal nichts.

Wäre eh am Ziel vorbei, denn der Fokus meiner Aussage lag auf "erwarte" ... und im Grunde darf man von einer Open Source Community nie etwas erwarten, oder!? Das heißt nicht, dass man nie etwas von ihr erhält.

Im alten Wiki (das müsste der Link von Leo sein) steht aber auch, das er eine Anleitung haben will wie man diesen Fehler im Demo System nachvollziehen kann.
Ja, das geht nicht immer, weil nicht alles im Demo System machbar ist.

Im genannten Fall des Moduls ModuleNavigation ging es um eine fehlende Funktion. Diese ist leicht einzubinden und da ich inzwischen fitter in puncto DCA bin als damals, werde ich demnächst den Patch auch fertig bauen. Im Forum wurde der Vorschlag abgewehrt mit "sowas braucht man doch nicht" und "das Problem kann man ja auch umgehen" ... beides IMHO unpassende Haltungen.

Haste mal den Link vom Ticket?

http://dev.contao.org/issues/2739

Ich habe noch nie eine fehlerfreie Software gesehen.

Herrje, auch das implizierte ja meine Aussage nicht. Tests sind derzeit der gegebene Weg, um zahlreiche Fehler zu finden. Punkt. Nicht alle Fehler. Gibt es bei Contao denn Unit-Tests? Wen dem so wäre, würde mich das mit Blick auf die meisten Klassen in system/modules und deren mangelnden "Unit-Charakter" eher wundern ... klar helfen Unit-Tests nicht immer und müssen auch wohlüberlegt gebaut werden, doch mir haben Sie für gewöhnlich um ein Vielfaches mehr Fehler vor Augen geführt als einfache Funktionstests innerhalb der fertigen Anwendung. Und wenn es schwer fällt, Unit-Tests zu schreiben, ist es ein guter Hinweis, dass was mit dem Software-Design nicht stimmen könnte.

Das Problem ist bekannt und glaub mir, daran wird gearbeitet. Jedoch kann das nicht von heute auf Morgen passieren.

Das erwartet niemand, doch manche dieser Sachen hätten doch auch von Anfang an eingebunden werden können. PDO ist bspw. seit Herbst 2005 Teil der offiziellen PHP-Releases in Majorversion 5.1. Man hätte da frühzeitiger reagieren können.

Auch muss dabei beachtet werden, ob das die Masse an Nutzer überhaupt nutzen kann (technisch).

Das galt natürlich auch für die bisherigen Datenbanktreiber ...

Normalisiertes DB Modell hätte haufenweise Joins zur Folge. Mag man gut finden, aus meiner Erfahrung musste ich bei Performance Projekten feststellen, das in so einem Fall oft die Indexe nicht mehr nutzbar waren / genutzt wurden.

Solche Erfahrungen kann ich schwer teilen. Natürlich bräuchte man dafür mitunter bessere Indizes als jene, die aktuell von DCA geboten werden. Das daran gearbeitet wird, ist mir aber auch schon aufgefallen.

Bedenke auch, das Contao mit MySQL 4.1 läuft. Wenn die Anforderungen mal erhöht werden auf 5.x kann man wieder über so etwas nachdenken.

Als Anregung für eine solche Anhebung verweise ich gern auf http://www.mysql.com/support/eol-notice.html und ergänze, dass man durch Ableiten einer Mysql41-Klasse von der PDO die entsprechenden Transaktions-Methoden funktionsleer gestalten könnte.

Aber nicht bei den meisten Hostern, da kam PHP5 erst viel später.

Klar das Thema ärgerte mich auch jahrelang.


So, wie wäre es mit einem Ende dieser Debatte zum Thema "Backup". Ich werde gewiss mein Skript ausbauen, bspw. würde ich es auch gern nutzen, um Sites umziehen zu können - etwa so wie es bspw. auch VMWare macht. Und auch das wird sich mit dem LiveUpdate und seinen Nutzern nicht stören.

[andreas.schempp]

Das Thema ist nun doch etwas lange geraten, finde ich. Zwei kleine Dinge möchte ich dazu sagen:

1: Das Framework ist, wie es ist. Es können nicht einfach so grundlegende Änderungen vorgenommen werden, da es kompatibel bleiben muss. Es hat Schwächen im MVC, aber dafür/dadurch ist es extrem kompatibel.

2: Das Live-Update hat nichts mit Contao oder eine "Unterstützung" zu tun. Du bezahlst eine Gebühr an Leo, damit sein Aufwand für Hosting & Erstellen des Update-Pakets gedeckt ist. Deshalb geht das Geld auch direkt an ihn, und nicht an Contao.

[neueplaneten]

Also ich halte das für keine Gebühr, der Live-Update ist jeden Cent wert und spart Zeit sowie Ärger. Auch kann davon ausgegangen werden, dass mit diesem Entgeld das Projekt weiter unterstützt wird. Denn eines ist sicher, Zeit kann man sich nicht kaufen und diese steckt in dem CMS Contao um ein Vielfaches drin.

Ich spreche hiermit allen Beteiligten, sei es Programmierer, Modaratoren, Autoren, Selbstständigen oder Usern die mit Hingabe und Fleiß das Wissen und können mit uns allen teilen, meinen Dank und Respekt aus.

Es gibt keine EierlegendeWollMilchSau, aber mit Contao legt man gute Eier, kriegt dafür viel Wolle, kann sich reichlich Milch kaufen und Sau viel Spaß damit haben.

Mit Grüßen...holt euch die Live-ID...