[prinzipiell GELÖST] Update von 1.4.1 auf 1.6.3 möglich

[mkiedels]

Hallo,
wir haben unsere Seite leider länger nicht mehr geupdatet. Was muss ich machen, um ein Update von 1.4.1 auf die aktuelle Version ohne größere Probleme durchzuführen?
Es laufen unter anderem: News, Kalender, Album, Newsletter und diverse andere Module

Kann man eigentlich die gesamte Installation sichern, um notfalls nach dem Update wieder zurückzurudern, sollte es massive Probleme geben?

Über Tipps würde ich mich sehr freuen.

[antibart]

Hallo,
wir haben unsere Seite leider länger nicht mehr geupdatet. Was muss ich machen, um ein Update von 1.4.1 auf die aktuelle Version ohne größere Probleme durchzuführen?
Es laufen unter anderem: News, Kalender, Album, Newsletter und diverse andere Module

Kann man eigentlich die gesamte Installation sichern, um notfalls nach dem Update wieder zurückzurudern, sollte es massive Probleme geben?

Über Tipps würde ich mich sehr freuen.

Ja ... du kannst die Installation lokal sichern und auf JEDEN FALL auch die Datenbank über phpmyadmin exportieren.

Bei großen Versionsspüngen ist eine Neu-Installation einer Aktualisierung vorzuziehen. Das geht am Ende schneller.

Tipp: die neue Version in einen anderen Ordner übertragen und hinterher die Domainweiterleitung einfach umstelllen. Dann gibt es keine Seitenausfälle.

Ansonsten: Einfach die gesamte neue Version auf den Server übertragen, install starten und beim Punkt "Tabellen erzeugen / Beispielinhalte erzeugen" die Häkchen entfernen, damit du die alte DB nicht überschreibst (DB trotzdem unbedingt vorher sichern) ... danach die noch fehlenden Module neu instalieren.

Hier noch die Doku

http://wiki.cmsmadesimple.org/index.php ... grading/de

[cyberman]

Es laufen unter anderem: News, Kalender, Album, Newsletter und diverse andere Module

Auf die Schnelle fallen mir nur das News-Modul und das TinyMCE-Modul ein, die einer separaten Behandlung bedürfen.

Das TinyMCE-Modul musst du einfach nur deinstallieren und dann wieder neu installieren. Die Änderungen sind für den Aktualisierungsmechanismus zu groß.

Beim News-Modul wurde die Datumsformatierung geändert - siehe Modulhilfe:

In der News-Modul-Version 2.9 und höher wurde sowohl das Variablenelement $entry->formatpostdate als auch der Parameter „dateformat“ entfernt. Sie sollten daher anstatt $entry->formatpostdate jetzt $entry->postdate verwenden. Das Datum kann dann mit dem Modifikator „cms_date_format“ formatiert werden (wie in den mitgelieferten Muster-Templates gezeigt).

Der Modifikator kann direkt mit einem speziellen Datumsformat bestückt werden. Ohne Vorgabe (also {$entry->postdate|cms_date_format}) wird die Einstellung aus den Globalen Einstellungen verwendet.

[mkiedels]

Hallo, Ihr fleißigen Helfer!!!
Danke für die schnellen und guten Tipps.
Ich habe upgedatet. Soweit läuft die Seite gut. Aber wenn ich die Seitenübersicht aufrufen möchte, erscheint Error 500 - Internal server error

Ein interner Fehler ist aufgetreten!
Bitte versuchen Sie es zu einem späteren Zeitpunkt.

Woran kann das liegen?

Liebe Grüße aus Lübeck

Michael

[antibart]

Hallo, Ihr fleißigen Helfer!!!
Danke für die schnellen und guten Tipps.
Ich habe upgedatet. Soweit läuft die Seite gut. Aber wenn ich die Seitenübersicht aufrufen möchte, erscheint Error 500 - Internal server error

Hmmm .... was für ein Update hast du gemacht? Komplett neu mit Datenbank-Import und Installation oder nur Dateien überschrieben? config.php schon richtig eingestellt? Stimmt der CMS-Root?

[cyberman]

Verwendest du eine .htaccess?

An dem URL-Mechanismus bzw. den möglichen Einstellungen in der config.php hat sich etwas geändert. Hilfsweise die .htaccess mal komplett löschen ...

[mkiedels]

Hallo,
danke für die schnelle Hilfe!
Ich habe die Dateien nach vorheriger Sicherung und SQL-Dump einfach überspielt und dann die upgrade.php laufen lassen.
Die Seite selbst läuft gut.
Ich habe die .htaccess gelöscht und die Berechtigungen für die config.php testweise auf 777 gesetzt. Das halft leider auch nichts.
Ich hatte aber unter der 1.4 pretty URLs aktiviert. Ich vermute daher, dass der Fehler aus dieser Ecke stammen könnte. Der entsprechende Abschnitt in der config.php lautet:
#------------
#URL Settings
#------------

#What type of URL rewriting should we be using for pretty URLs?  Valid options are:
#'none', 'internal', and 'mod_rewrite'.  'internal' will not work with IIS some CGI
#configurations. 'mod_rewrite' requires proper apache configuration, a valid
#.htaccess file and most likely {metadata} in your page templates.  For more
#information, see:
#http://wiki.cmsmadesimple.org/index.php ... ty_URL.27s
$config['url_rewriting'] = 'mod_rewrite';

#Extension to use if you're using mod_rewrite for pretty URLs.
$config['page_extension'] = '/';

#If you're using the internal pretty url mechanism or mod_rewrite, would you like to
#show urls in their hierarchy?  (ex. http://www.mysite.com/parent/parent/childpage)
$config['use_hierarchy'] = true;

#If using none of the above options, what should we be using for the query string
#variable?  (ex. http://www.mysite.com/index.php?page=somecontent)
$config['query_var'] = 'page';



und die neue .htaccess, die ich aus dem htaccess.txt im Doc-Verzeichnis übernommen habe lautet:

# To deny PHPs
                                                                             
  order deny,allow                                                                                                           
  deny from all                                                                                                             
 


Wo liegt der Fehler??

Danke für Eure kompetente Hilfe!!

[NaN]

Code: Select all

# To deny PHPs
<Files ~ "\.(php|php3|php4|php5|phtml|pl|cgi)$">                                                                              
  order deny,allow                                                                                                            
  deny from all                                                                                                               
</Files>

Wo liegt der Fehler??

Genau hier liegt der Fehler.
Du verbietest den generellen Zugriff auf PHP Scripte.
Im Root sollte eigentlich nur der Zugriff auf die config.php verboten werden.

[antibart]

Außerdem: wenn du pretty url mit mod_rewrite benutzt, muss du natürlich eine .htaccess mit dementsprechenden rewrite-regeln haben.

Deine alte aus der funktionierenden 1.4. Version sollte eigentlich auch bei der neuen Installation funktionieren.

[mkiedels]

Hallo Antibart,
danke für den Hinweis. Ich hatte diese .htaccess genommen, weil in einem Tutorial zur 1.6.2 davon die Rede war. Nun klappt der Zugriff auf die Seiten wieder einwandfrei. Ich kann aber nach wie vor keine Seiten editieren und erhalte immer Fehler 500. An der .htaccess sollte es nicht mehr liegen, die config.php hat z.Zt. sicherheitshalber mod 777, da kann also auch kein Rechteproblem auftreten...
Wo kann der Fehler noch liegen?

Michael

[NaN]

die config.php hat z.Zt. sicherheitshalber mod 777, da kann also auch kein Rechteproblem auftreten...

Daran sollte es nicht liegen.
Ändere die mal lieber wieder auf 444 und verbiete via .htaccess den Direktzugriff.

Was genau meinst Du mit Di kannst keine Seiten editieren?
Geht der gesamte Backendzugang nicht, oder nur die Seite "Inhalte->Seiten"?

[mkiedels]

die config.php hat z.Zt. sicherheitshalber mod 777, da kann also auch kein Rechteproblem auftreten...

Daran sollte es nicht liegen.
Ändere die mal lieber wieder auf 444 und verbiete via .htaccess den Direktzugriff.

Was genau meinst Du mit Di kannst keine Seiten editieren?
Geht der gesamte Backendzugang nicht, oder nur die Seite "Inhalte->Seiten"?

Es geht nur um die Seite "Inhalte->Seiten.
Ich setze die Rechte wieder zurück.
Wie verbiete ich denn den Direktzugriff in der .htaccess?

Michael

[NaN]

Wie verbiete ich denn den Direktzugriff in der .htaccess?

So wie es in der Beispiel .htaccess beschrieben war.
Nur, dass Du da nicht einfach nur Dateien, die auf ".php" etc. enden verbietest, sondern einen konkreten Dateinamen angibst:

Code: Select all

<Files "config.php">
  order deny,allow
  deny from all
</Files>

Hast Du evtl. irgendwo noch weitere .htaccess Dateien?
Z.B. im AdminVerzeichnis?
Apropos Adminverzeichnis... hattest Du das evtl. umbenannt?

Hast Du mal die .htaccess Datei komplett gelöscht und in der config.php "$config['url_rewriting'] = 'none';" probiert?
Oder mal das Adminverzeichnis aus dem Installationsarchiv komplett neu hochgeladen?
Das sind so die grundlegenden Dinge, die ich jetzt erstmal probieren würde.

[mkiedels]

Wie verbiete ich denn den Direktzugriff in der .htaccess?

So wie es in der Beispiel .htaccess beschrieben war.
Nur, dass Du da nicht einfach nur Dateien, die auf ".php" etc. enden verbietest, sondern einen konkreten Dateinamen angibst:

Code: Select all

<Files "config.php">
  order deny,allow
  deny from all
</Files>

Hast Du evtl. irgendwo noch weitere .htaccess Dateien?
Z.B. im AdminVerzeichnis?
Apropos Adminverzeichnis... hattest Du das evtl. umbenannt?

Hast Du mal die .htaccess Datei komplett gelöscht und in der config.php "$config['url_rewriting'] = 'none';" probiert?
Oder mal das Adminverzeichnis aus dem Installationsarchiv komplett neu hochgeladen?
Das sind so die grundlegenden Dinge, die ich jetzt erstmal probieren würde.

Hallo,
danke für die schnelle Hilfe. Ich hab es aber noch nicht geschafft:
Ich habe jetzt die .htaccess gelöscht und die Einstellung in der config.php auf 'none' gesetzt. Das Adminverzeichnis habe ich neu hochgeladen. Nun kann ich nur noch die Startseite (www.bonifatiusschule.org) erreichen. Alle anderen Seiten erscheinen mit Fehler 404. Allerdings steht in der Adresszeile auch noch die Pretty-URL-Schreibweise. Habe ich eine Einstellung vergessen?

Michael

[NaN]

Steht in der config.php (die auf dem Server) wirklich $config['url_rewriting'] = 'none'; (evtl. auch einfach mal '' - also leer lassen) ?
Denn, wenn Du die Berechtigungen vorher auf 444 gesetzt hast, dann wirst Du sie nicht überschreiben/ändern können.