vereinfachung eines updates von D6.x auif D 6.y

Ich persönlich deaktiviere nie Module beim updaten.

mfg Cyberschorsch

_________
Mei is des schee

hier gibts nochmal die gleiche Diskussion.

Cyberschorsch - kannst du bitte mal deine Steps auflisten wie du z.B. von 6,14 auf 6.15 gehst.
Ich denke das hilft dem Themenersteller am meisten - mich würds auch interessieren wie es andere machen....
Ich habe mich bisher auch immer an die upgrade.txt gehalten, die scheint aber mehr für 5.x auf 6.x Schritte gedacht zu sein.
danke schonmal.

Hier zu lesen http://drupalbasic.de/einsteigerhandbuch/drupal-kern-update, das ist allerdings der Änfänger-Weg. Wenn man genau weiß wie man ggf. dann Fehler beseitigt kann man einfach die neue Drupalversion über die bestehende Version entpacken/überschreiben lassen.

----------------------------------------
Gelöste Forenbeiträge mit [gelöst] im Titel ergänzen
Das Verhältnis anderen zu helfen muss höher sein, als von anderen Hilfe zu erfragen/erwarten.

Hi,
habe den anderen erwähneten Thread über das Upgraden gestartet, möchte aber eher hier weitermachen um die grundlegende Problematik zu beleuchten:

Soweit ich mich bisher eingelesen habe, gibt es den Terminus "Update" im Bezug auf den Kern einfach nicht, sondern nur Upgrades, sei es nun auf einen minor oder major release.

Über Updates wird nur bei neuen Modulversionen gesprochen.

Wenn also Teile des UPGRADE.txt irrelevant für das upgraden der Kern-Versionen bei Zwischenversionen sind, dann frage ich mich aber warum man bisher 15 mal eine unpassende Anweisung herausgibt, wenn sie doch nur für den einen Fall des "grossen" Upgrades gültig sein sollte.
Ich gehöre zwar nicht dem "Bund Bibeltreuer Christen" an, aber was soll ich davon halten, wenn schon die grundlegendsten Anweisungen einer Exegese unterzogen werden müssen, und jeder was anderes rausliest?

Wie aus meinem anderen Thread ersichtlich, mühte ich bis bis dato, den Anweisungen folgend, stundenlang mit dem fehlerbehafteten Ab- und Anschalten der Module ab. Deswegen habe ich ja auch versucht, das sql-Skript zu rekonstruieren, das diese Sache in 2 Minuten erledigt.

Aber der Rest der ganzen Angelegenheit dauert trotzdem noch ziemlich lang.
Und bisher habe ich auch noch keine vernünftige "Best-Practice"-Lösung für die Schritte gefunden.
Würde mich also auch wie wahrscheinlich viele andere freuen, wenn jemand mal versuchen würde, seine Schritte detailliert aufzuzeichnen. Die Tutorials kratzen ja immer nur an der Oberfläche und beschreiben bevorzugt wie man etwas "einfach" macht.
Doch für viele ist das eben nicht "einfach".

Wenn du einen eigenen Server hast, ist drush deine Lösung :)

Die Jungs und Mädels von http://3281d.com/ arbeiten für D7 btw an einem Updatemanager der es ermöglicht, über die UI seine Drupalinstallation zu updaten.

mfg Cyberschorsch

_________
Mei is des schee

drush ist eben nicht DIE Lösung.
ich habe, wie die meisten anderen, shared hosting. und sogar mit shell.
aber da funktioniert drush nicht wegen veralteter php version der shell(scheint auch relativ weit verbreitet zu sein). da muss man dann rumpfriemeln und irgendwelche aliase auf php5 setzen bis es funzt (Also Zeitaufwand zur Inbetriebnahme von drush schon mal krass).

Und dann schmiert mir drush einfach regelmäßig ab (hats in der Vorgängerversion auch schon getan) und ich darf die shell neu starten.

Also, drush ist definititv keine LÖSUNG, sondern maximal ein WERKZEUG, das im besten Falle funktioniert.
Eine LÖSUNG hat normalerweise LÖSUNGSSCHRITTE, und an denen mangelt es meistens und nach denen wird hier auch explizit gefragt!

Und Verweise auf D7 können hier wahrscheinlich auch nur wenige Menschen trösten ...

Hallo,

ich bin auch erst kurz dabei und bin, wenn ich mich recht erinnere, mit Drupal 6.12 eingestiegen.
Bis dato habe ich es immer mit den Core-Updates so gehalten.

1. tar.gz Datei heruntergeladen
2. Entpackt bis Ordner angezeigt wurde
3. Website offline gestellt
4. Mit MYSQLDumper Datenbank Backup erstellt
5. Alle Ordner auf Festplatte markiert und per FTP auf den Server kopiert
6. Bei Nachfragen des FTP Programms 'alles überschreiben' ausgewählt
7. Dann als Admin auf Site angemeldet
8. Mit update.php Update gestartet
9. Getestet, ob alles wieder funktioniert (noch nie nicht ein Problem gehabt)
10. Site online gestellt
11. Datenbank Backup gelöscht - fertig!

Gruß,

Kirsten

@bernadotte
Ich möchte erstmal hinweisen, dass deine sehr zynische Schreibweise hier nicht gerade motiviert, dir zu helfen. Aber vielleicht ist das nur ein subjektives Empfinden.

Zualler erst hast du natürlich Recht, das Drush ein Werkzeug ist und wie ich schon in meinem anderen Post erwähnte nur für die Drupaler mit eigenem Server zur Verwendung geeignet. Dann aber ist Drush mit etwas Know-How absolut nützlich und zeitsparend.

Die Zeilen mit dem D7 Update Manager sollte dann lediglich einen Ausblick geben, dass durchaus an der Problematik gearbeitet wird, aber eben nicht mehr für D5 und D6.

Kommen wir nochmal zu D6:

Von einem Update sprechen wir bei Minor Releases, von Upgrade bei Major Releases.

Vorgehensweise bei einem Update:

1. Backups machen
2. Website in Wartungsmodus setzen
3. Neue Versionsdateien herunterladen und auf dem Server überschreiben
4. Update.php im Browser aufrufen
5. Überprüfen des Statusberichtes
6. Funktionstest
7. Wartungsmodus ausschalten

mfg Cyberschorsch

_________
Mei is des schee

@cyberschorsch
Ein wenig Zynismus soll auch drin sein, ansonsten ist das mein Schreibstil.
Ich wollte damit etwas zugespitzt aufzeigen, dass deine Antwort sowohl an der ersten Frage wie auch an meinen weiteren Ausführungen vorbeiging, und somit den wenigsten was nützt.

Die Ausgangsfrage wird wohl von einem Noob gestellt worden sein, der mit drush, wenn der Kommandozeile noch nicht mächtig (und davon ist erstmal auszugehen), schon bei der Einrichtung verloren ist. (Zusätzlich zu den von mit aufgeführten Problemen). Ein "eigener Server" ist also nicht das Kriterium für den Einsatz, sondern die Einsetzbarkeit durch den Anwender. (wobei man ja nochmal unterschieden werden müsste zwischen "eigenem Server" mit einfacher shell, und solchen mit root-Zugriff, was ja wohl bei den allerwenigsten hier nach Hilfe Suchenden der Fall sein wird)

Auch hilft drush nicht wirklich beim Deaktivieren der Module, da hier ja alle Paketnamen eingegeben werden müssen, man also immer hin und her klicken muss um die richtige Schreibweise zu finden.
Weiterhin merkt sich drush auch nicht, welche Module und Submodule denn vorher aktiviert waren, man muss also dies irgendwie händisch dokumentieren, will man keine Fehler machen und was vergessen.

Da aber viele ihre Module offensichtlich gar nicht zu deaktivieren scheinen, Anfänger die sich noch an den UPGRADE.txt halten aber wohl, ist weiterhin zu klären wie ihr darauf kommt, dass man das nicht tun soll/muss.
Von einem Update sprechen wir bei Minor Releases, von Upgrade bei Major Releases.
Wer ist Wir? In den englischen Quellen finde ich zu dem Thema keine Unterscheidung, sondern da sind alles Upgrades.

Ist das blos "Faulheit" der Maintainer, dass sie seit 2008 immer den selben Text benutzen, oder kriegen die gar nicht mit, dass das viele Leute verwirrt?

Es sind eben diese kleinen Widersprüche, die vor allem Anfänger verwirren und das Leben schwer machen.

Wenn das Deaktivieren der Module tatsächlich nicht notwendig ist, warum steht das dann nicht im UPGRADE.txt, der ja dann eigentlich UPDATE.txt heissen müsste, sondern wird in diversen Tutorials lediglich so ausgelegt. Da ist doch der Wurm drin.

Nochmal zu D7: Wenn man sieht wie viele noch immer auf D5 sitzen, weil z.T. die benötigten Module immer noch nicht für D6 da sind, kann man doch nicht ernsthaft auf ne Alternative in D7 warten wenn man sich grade mühevoll was in D6 zusammengebastelt hat.

Das Problem liegt doch ganz einfach darin, dass die Unterscheidung zwischen Upgrade und Update nicht korrekt getroffen wurde, oder?

Update wäre innerhalb einer Drupal-Version, also z.B. von Drupal 6.14 auf Drupal 6.15

Ein Upgrade wäre z.B. von Drupal 5 auf Drupal 6

Und nur bei einem UPGRADE (also z.B. von Drupal 5 auf Drupal 6) müssen die Module deaktiviert werden, weil man sonst eine Drupal-Version installiert und hat dafür Module aktiviert, die mit dieser Version nicht kompatibel sind.

Ergo müssen beim Updaten eines Moduls oder auf 6.15 keine Module deaktiviert werden.

Mir konnte bisher keiner schlüssig erklären, wie man denn zu der Unterscheidung von Update und Upgrade kommen kann.
In den englischen Orginaldokus gibt es die einfach nicht:
Der UPGRADE.txt, in dem das Deaktivieren der Module genannt wird ohne zu erwähnen dass es dafür Ausnahmen gibt, verweist für weiterführende Infos auf den Pfad http://drupal.org/upgrade

Dort wir zwar auf den Unterschied von major und minor releases hingewiesen, für weitere Infos aber wieder zurück auf den UPGRADE.txt verwiesen. Spitze!

In den folgenden References gibt es einen Link zu einem Videotutorial, in dem der Autor seine contributed modules deaktiviert (was ihm auch nicht sonderlich schwer fällt bei den paar Modulen)

Im Folgenden werden verschiedene Buchseiten angeboten, darunter: http://drupal.org/upgrade/tutorial-introduction
Hier wird zwar nicht vom Deaktivieren der Module gesprochen, sondern in Punkt 3. nur wieder auf den UPGRADE.txt verwiesen, doch werden sie in Punkt 7. wieder aktiviert. Aha!

Da man bei einem major release sowieso davon ausgehen kann, das erstmal fast keine contributed modules für die neue Version da sind, was soll man dann bitte reaktivieren, wenn nicht die Module bei einem minor release?

In den Release notes zu den neuen Versionen findet man zum Teil nichts über das deaktivieren, dafür wird aber immer wieder auf den UPGRADE.txt hingewiesen, und das stehts nun mal schwarz auf weiß.

Also, entweder ist die ganze Doku einschließlich UPGRADE.txt einfach nur veraltet und verschludert und es hat sich auf anderen Kanälen herumgesprochen dass man nix deaktivieren muss, oder aber das alles ist so zu nehmen wie es da steht, dann gibt es eben nur Upgrades und keine Updates und die contributed modules müssen deaktiviert werden.

Kann mir noch jemand folgen?

Ich will hier ja nicht Korinthen kacken, aber wenn die Doku nicht stimmt, dann sollte man dafür sorgen dass das geändert wird.
Aber auf Bauchgefühl und "hat schon immer so geklappt" kann und will ich mich einfach nicht verlassen, und es ist halt ziemlich verwirrend besonders für Newbies.

Sprachlich gesehen gibt es bestenfalls eine dünne Linie zur Unterscheidung von "update" und "upgrade" die man durchaus dahingehend sehen kann, dass das Upgraden eher ein Vorgang ist um etwas funktionell zu erweitern, wie eben beim Wechsel auf ein Major Release. Im allgemeinen Sprachgebrauch gehen solche Feinheiten aber unter, weswegen es wenig Sinn macht hier beim lesen zu unterscheiden, wenn es beim schreiben eh kaum einer tut.

Die offizielle Anleitung beinhaltet nunmal erstmal alle Module vor dem Update / Upgrade zu deaktivieren. In der Praxis wird das aber nur gemacht wenn von auf ein neues Major Release geupdatet / geupgradet wird. Für Zwischenupdates des Core sowie sonstiger Module ist dies in meiner Praxis (und der vieler anderer) nie nötig gewesen. Mir ist auch kein Fall eines Zwischnupdates von Core oder Modulen bekannt, wo dies zwingend notwendig gewesen wäre. Wem anderes wiederfahren ist möge sich nun melden oder aber für immer schweigen ;)

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

wozu ist dann bitte eine Anleitung und dazugehörige Doku gut, wenn sie mit der Praxis nicht übereinstimmt?
Habe dembezüglich mal einen Issue zur Doku auf drupal.org erstellt, gehe aber davon aus, dass das bei den Maintainern kein S....n jucken wird, wenn ich schon sehe wie relative gleichgültig hier mit dem Thema umgegangen wird.

Ich persönlich finde solche Schludrigkeiten absolut fatal und man lässt sehend Auges Leute stundenlang in ihren Installationen rumbasteln, obwohls absolut für die Katz ist?

Also können wir zusammenfassen?:
1. Im offiziellen englischen Sprachgebrauch gibt es keine Updates, sondern nur Upgrades.
(Begründung: Konnte keiner das Gegenteil aufzeigen)

2. Für "minor upgrades" von Zwischenversionen wie z.B. 6.14 auf 6.15 braucht man, entgegen der Anweisung im UPGRADE.txt, NICHT seine zusätzlichen Module deaktivieren.
(Begründung: hat schon immer so funktioniert)

3. Können wir weiterhin festhalten, dass der Hinweis auf das Reaktivieren der (zusätzlichen) Module bei einem Upgrade in einer "major release" in der PRAXIS ebenfalls nutzlos ist, da die Module mit an Sicherheit grenzender Wahrscheinlichkeit inkompatibel sind, und sowieso erst gegen eine neue, kompatible Version (wenn überhaupt schon vorhanden, die Geschichte von D6 lehrt uns aber was anderes) ausgetauscht werden müssen ?

Halte das Thema damit für beendet und sozusagen [gelöst] obwohl ja die Ursache der Frage, die aus der einfach schlechten Doku resultiert, bestehen bleibt.

hast ja Recht. Aber im allgemeinen Sprachgebrauch, wie er auch von anderen Software-Herstellern benutzt wird, ist ein Update eine Funktion, um up-to-date, also fehlerfrei und aktuell zu sein. Windows-XP-updates kennen wir wohl alle. Ein Upgrade gibt es dagegen für Vielflieger z.B. vom Gold zum Platinum-Albatros, von Windows 7 Pro auf Ultimate... Aber auch von XP auf Vista oder von Adobe CS2 auf CS3. Verwirrend.
Persönlich habe ich beim update noch nie Module deaktiviert, weil eventuelle Fehlermeldungen bei genauem Lesen schon aussagekräftig sind (hab übrigens auch noch nie wegen update db gesichert..)
Der Text zum Modul-deaktivieren kann hier wirklich geändert werden.
Beim Wechsel von Dx auf Dy gehe ich aber fast strikt nach Anleitung vor. Das Dokumentationsmodul (wie heißt das noch..) wäre spätestens beim Crash eine Hilfe, sollte ich mal..

Welche Module vermisst Du denn bei D6? Für D6 gibt es ja einige Module, die für D5 nicht mehr entwickelt wurden.
Grundsätzlich bin ich der Meinung, dass ein cms nur für leidensfähige und lernbereite Noobs geeignet ist. So wie mich ;-)

Die Doku ist nicht schlecht, sondern eben ausführlich und geht auf Nummer sicher. Darin ein Manko zu sehen, dazu gehört schon was..

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

sorry, aber die doku ist diesem fall schon schlecht, weil sie versucht, zwei verschiedene fälle in einen erläuterungsablauf zu wursteln. aber mit einer trennung der schritte für die einzigen zwei anzunehmenden fälle minor oder major upgrade in zwei blöcke wäre jedem zu dem preis von 5 zusätzlichen zeilen geholfen und alle unklarheiten beseitigt.

@silvesterd:
oh du ahnst ja gar nicht wie leidensfähig ich bin.
ich versuche mich jetzt seit fast zwei jahren dem komplex drupal zu nähern, bislang mit mässigem erfolg, was nicht zuletzt an schlicht fehlenden, veralteten oder sonstwie schrägen infos liegt. (neben fehlendem talent meinerseits natürlich)

und bisher habe ich ja auch devot geschwiegen.
aber die geschichte mit diesem UPGRADE.txt hat bei mir jetzt irgendwie nen schalter umgelegt.

wo ich mich jetzt mit der doku wieder mehr beschäftige, schwillt mir nur noch pausenlos der kamm.
ist euch z.b. schon mal aufgefallen, dass schon während der installation von drupal bei fehlern immer vielversprechende links zur problemlösung erscheinen, die aber immer auf der selben landing page enden, wo weit und breit nix davon zu sehen ist wie der fehler zu beseitigen ist?
da kannste dich dumm und dabbelig klicken, aber das thema ist nicht zu finden.
sowas kostet völlig unnötig zeit und nerven und ist einfach nur grottig. da kann man auch gleich den link weg lassen und sagen "such in google".

aber das ganze ist nur sympthomatisch für grosse teile der doku und beginnt eben schon im UPGRADE.txt

Die Schritte sind praktisch identisch, daher ist eine Trennung nicht nötig.

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

da sie ja PRAKTISCH im bezug auf das deaktivieren der module eben NICHT identisch sind (der grund für diesen thread!), und nicht jeder eine kristallkugel zuhause rumstehen hat, würde eine trennung eben schon sinn machen.

ich gebs auf.

Ich habe gerade das UPDATE von 6.14 auf 6.15 durchgeführt.
Ich bin fälschlicherweise auch davon ausgegangen, dass das Upgrade von 6.14 auf 6.15, wie in der Upgrade.txt beschrieben, notwendig ist.
Das UPGRADE hat aber nicht funktioniert. Seiten wie "Mein Konto" wurden nicht mehr gefunden. Zugegeben, die Module habe Ich nicht deaktiviert. Dachte, das muss doch auch so gehen.
Danach habe Ich auf dem Testserver einfach die alten Dateien mit den neuen überschrieben und es hat problemlos funktioniert.
Wäre schön gewesen wenn es in der Upgrade.txt wenigstens ein Hinweis gegeben hätte.
Ich muss aber auch sagen, dass ein Upgrade tatsächlich einem Versionsprung wie 5 auf 6 eher entspricht und ein Update der Aktualisierung eines Versionstandes (Bsp. 6.14 auf 6.15). Leider gibt es in der Upgrade.txt keinen Hinweis zum Update. Deshalb bin Ich automatisch davon ausgegangen, dass es auch für ein Update zutrifft.

5 Zeilen mehr in der Upgrade.txt hätten echt nicht geschadet. Ich habe das Update immer wieder hinausgezögert, weil mir die beschriebene Prozedur einfach zu kompliziert erschien. Irgendwann habe Ich den IIS7-Testserver installiert und die Seite inkl. Datenbank von meinen Provider auf den loakalen PC übertragen nud es getestet. Die Zeit hätte ich mir echt sparen können wenn Ich gewusst hätte, dass ein einfaches Überschreiben völlig ausreichend ist. Naja, jetzt habe ich wenigstens einen Testserver. Wäre aber schön wenn man die Upgrade.txt vervollständigt. Vielleicht hat ja ein User mehr Einfluss auf das Drupal-Projekt und kann das mal ansprechen. Gerne stelle ich auch die 5 Zeilen auf Englisch zur Verfügung! ;-)