You are here

Projekt 19 - Drupal CMS

Server-Wechsel

Wird z.B. der Web-Hoster gewechselt so muss die Drupal-Website zur Gänze verschoben werden (relocate). Zu Beginn sollte eine Sicherheitskopie von der Website gemacht werden. Der FTP-Ordner kann einfach kopiert und komprimiert (ZIP) werden und die Datenbank wird exportiert (SQL-Export mit ZIP-Komprimierung und utf-8-Kodierung).

Clean URLs deaktivieren (Home > Administer > Site configuration > Clean URLs)
Caches leeren (Home > Administer > Site configuration > Performance)
FTP-Ordner kopieren
Datenbank exportieren (phpMyAdmin > Datenbanken > Datenbank auswählen > Exportieren)

  • SQL-Statements mit utf-8-Kodierung

Datenbank am Zielserver anlegen (phpMyAdmin > Datenbanken > Anlegen)

  • Namen vergeben (z.B. datenbank)
  • utf8_general_ci-Kodierung

Benutzer am Zielserver anlegen (phpMyAdmin > Datenbanken > Datenbank auswählen > Rechte > Neuen Benutzer hinzufügen > OK)

  • Name (z.B. test)
  • Passwort (z.B. test)
  • Host: Lokal
  • keine globalen Rechte
  • gewähre alle Rechte auf Website-Datenbank

Benutzer-Rechte ändern (phpMyAdmin > Rechte > Benutzer-Rechte ändern)

  • global sämtliche Rechte entfernen
  • Rechte für Website-Datenbank: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP, CREATE TEMPORARY TABLES, LOCK TABLES

*.sql-Datei anpassen (exportierte Datenbank-Datei)

  • "C REATE D ATABASE 'alteDatenbank' ...;" entfernen (falls vorhanden)
  • "USE 'alteDatenbank';" entfernen (falls vorhanden)

Daten in Ziel-Datenbank importieren (phpMyAdmin > Datenbanken > Datenbank auswählen > Importieren)

  • *.sql-Datei laden
  • utf-8-Zeichenkodierung
  • Teilweiser Import deaktivieren

Kopierte FTP-Daten anpassen (".../sites/default/settings.php")

  • neue Datenbank angeben: $db_url = 'mysqli://test:test@localhost:3306/datenbank';

Kopierte FTP-Daten auf neuen Server hochladen
Clean URLs aktivieren (Home > Administer > Site configuration > Clean URLs)

 


Drupal Minor-Updates

Damit das Content-Management-System sicher und aktuell bleibt, sollten sämtliche Minor-Updates installiert werden. Die Module sollten auch immer auf aktuellem Stand gehalten werden.

Cache leeren, Clean URLs deaktivieren
Daten kopieren (FTP-Ordner, Datenbank)
Updates downloaden (Home > Administer > Reports > Available updates)

Archive entpacken

  • Drupal Core nach ".../tmp/"
  • Module nach ".../tmp/modules/"

Website-Daten kopieren (Cache ist zuvor zu entleeren und Clean URLs zu deaktivieren)

  • alte noch benötigte Module kopieren (".../websiteKopie/modules/")
  • altes Theme kopieren (".../websiteKopie/themes/")
  • Inhalt kopieren (".../websiteKopie/sites/*" kopieren nach ".../tmp/sites/")

Update ohne Anmeldung erlauben

  • ".../tmp/sites/default/settings.php" > $update_free_access = TRUE;

Alte Daten löschen und neue Daten hochladen
Update durchführen

  • update.php aufrufen (www.domain.at/update.php)
  • Schritt für Schritt durchgehen

Update nicht mehr erlauben

  • ".../tmp/sites/default/settings.php" > $update_free_access = FALSE;
  • settings.php hochladen

 


Drupal Major-Updates

Wird Drupal z.B. von 6.x auf 7.x aktualisiert, so muss zuvor das letzt verfügbare 6.x Minor-Update durchgeführt werden, erst danach kann ein Major-Update erfolgen. Bei einem Major-Wechsel muss man immer genau kontrollieren, ob sämtliche verwendeten Module auch in der neueren Major-Version verfügbar sind. Des weiteren muss auch das verwendete Theme für die neue Version verfügbar sein.

Theme auf ein Default-Theme umstellen (welches auch in der neuen Major-Version verfügbar ist)
Cache leeren, Clean URLs deaktivieren
Daten kopieren (FTP-Ordner, Datenbank)
Drupal Core und Module für gewünschte Major-Version herunterladen
Archive entpacken

  • Drupal Core nach ".../tmp/"
  • Module nach ".../tmp/modules/"

Website-Daten kopieren

  • Inhalt kopieren (".../websiteKopie/sites/*" kopieren nach ".../tmp/sites/")

Update ohne Anmeldung erlauben

  • ".../tmp/sites/default/settings.php" > $update_free_access = TRUE;

Alte Daten löschen und neue Daten hochladen
Update durchführen

  • update.php aufrufen (www.domain.at/update.php)
  • Schritt für Schritt durchgehen

Update nicht mehr erlauben

  • ".../tmp/sites/default/settings.php" > $update_free_access = FALSE;
  • settings.php hochladen

 


Update Probleme

Datenbank Inkonsistenz

Treten während des automatischen Updates Fehler auf, so sind diese oft schwer zu verstehen und vielleicht auch schwierig zu lösen.

Update Fehler

Der oben dargestellte Fehler ("SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'public://FrontView.jpg' for key 'uri' ... ") entstand z.B. durch einen Upload von zwei fast gleich lautenden Dateien (frontView.jpg und FrontView.jpg). Beim Upload der zweiten Datei wurde die erste gelöscht (damit versucht Drupal einen Konflikt zu umgehen), aber die Datenbank nicht aktualisiert. Somit blieben beide Einträge erhalten. Bei Drupal 6.x war das kein Problem, da der URI Eintrag kein Datenbank-Tabellen-Key war und somit gleich sein konnte. Versucht man aber auf Drupal 7.x zu aktualisieren, so wirft das Update-Script diesen Fehler. Denn bei Drupal 7.x wird der URI-Eintrag auch als Datenbank-Tabellen-Key verwendet.

Die einzige Möglichkeit diesen Fehler zu beheben ist, dass man die Datenbank-Einträge mit phpMyAdmin selbst bearbeitet und zwei separate Datei-Namen verwendet (z.B. FrontView.jpg und FrontView2.jpg). Dann muss man auch noch im Upload-Ordner diese Dateien zur Verfügung stellen.

Admin-Seite nicht mehr verfügbar

Da bei dem Server-Wechsel die Clean-Urls (Lesbare Urls) deaktiviert wurden, erreicht man den Admin Bereich nicht mehr über www.domain.at/admin sondern nur mit www.domain.at/?q=admin. Auch bei allen anderen Seiten muss nach dem Slash ?q= eingefügt werden.

Falls die Clean-Urls am neuen Server nicht aktivierbar sind, könnte der Fehler am fehlenden mod_rewrite Apache-Modul liegen. Zum Aktivieren der Clean-Urls ohne das Admin-Menü zu benutzen können diese Urls verwendet werden:

Drupal 7: www.domain.at/?q=admin/config/search/clean-urls
Drupal 6: www.domain.at/?q=admin/settings/clean-urls

Drupal speichert keine Seiteninhalte mit SQL Statements

Falls nach dem Editieren einer Seite die Vorschau bzw. das Speichern nicht funktioniert (die leere Seite wird wieder gelade bzw. die Drupal-Start-Seite wird geladen) könnte das am mod_security Apache-Modul liegen. Dieses Modul ist eine sogenannte Application-Level-Firewall welche die Web-Seiten schützen sollte (z.B. vor SQL Injection).

Error Reporting aktivieren

Damit laufende Web-Seiten keine unnötigen Fehlermeldungen anzeigen, werden üblicherweise sämtliche Error-Meldungen deaktiviert. Für Debug-Zwecke ist es aber hilfreich genau diese wieder zu aktivieren. Da man oft keinen Zugang zu der PHP-Konfigurations-Datei hat, kann in der php.ini nichts verändert werden. Für allgemeine Änderungen der PHP-Einstellungen kann man in der ".../sites/default/settings.php" die Konfigurations-Werte durch hinzufügen von ini_set('configuration', 'value'); verändern.

Das Error-Reporting sollte aber bereits in der ".../index.php" aktiviert werden. Nach <?php werden folgende Zeilen hinzugefügt:

error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);