Drupal - Inhalte nach Benutzerlöschung verschwunden

Falls mal jemand verzweifelt auf der Suche nach Inhalten ist, nachdem er (warum auch immer) einen Benutzer händisch aus seiner Drupal-Datenbank gelöscht hat - es kann geholfen werden. Die Drupal-Inhalte haben in der Datenbank ein Feld uid, in dem die ID des erstellenden Benutzers hinterlegt ist - gibt es diesen nicht mehr, ist auch der Eintrag nicht mehr sichbar.

Die Lösung ist nun diese Einträge durch den Wert eines existierenden Benutzers zu ersetzen. Entweder händisch oder per SQL-Script. Bei mehr als 3 Einträgen empfehle ich letztere Variante ;)

UPDATE node

SET uid = neueUserID

WHERE uid = alteUserID

Die UserID kann einfach in der Tabelle user (wer hätte das gedacht) nachgeschaut werden.

Drupal - Benutzername reserviert

Natürlich ist es wünschenswert, ungewollte Benutzer loswerden zu wollen. Unter Drupal gibt es in der Benutzerverwaltung ja auch die Möglichkeit Benutzer zu sperren. Wenn man das allerdings nicht vorsichtig genug betreibt, kann es passieren, dass man beim nächsten Login mit der Meldung "Der Benutzername xyz ist reserviert" abgewiesen wird. Mit jedem Benutzer.

Hat man Zugriff auf die Datenbank, kann das Problem behoben werden: in der Tabelle access findet sich ein Eintrag, der sämtliche Benutzer sperrt. Wird dieser entfernt, ist das Problem behoben.

Telekom Austria WebAdmin-login

Telekom Austria Business Webspace? Irgendwer? Ich will jetzt nicht ins Detail gehen, das hat ja dieser Artikel auf lookover.at bereits für mich erledigt. Nicht nur für den Business Webspace übrigens... - aber ok, der login.

Hatte da ein wenig Probleme mit dem Login... - erst mal klingt der Eintrag in den FAQ ja viel

versprechend:

"Die Zugangsdaten sind gleich den FTP Zugangs Daten."

Gut, dann hab ich da erst mal zwei Fragen:

• da gibt's ein Feld "Domain". Wo steht das in meinen FTP-Zugangsdaten?
• meine FTP-Zugangsdaten mit schema "kryptischezahlenfolge@meineadresse.at" funktionieren nicht... - warum?

Ganz so kompliziert ist es eh nicht: wird ein Linux-Webspace verwendet, ist der Benutzername der Teil vor dem @, die Domain der Teil nach dem @, das Passwort ist immerhin gleich geblieben. Warum es nicht möglich war das so zu dokumentieren und weshalb diese Verkomplizierung überhaupt gemacht wird entzieht sich meiner Kenntnis. Zumal es unter den FTP-Zugangsdaten dann auch noch einen Host gibt. Der könnte es ja auch sein...

Es ist schon möglich draufzukommen, aber so sonnenklar wie das die Telekom sieht ist es wirklich nicht. Und dass es unter den Windows-Servern angeblich wieder anders ist macht das Spiel auch nicht unterhaltsamer. Aber dafür kostet der Webspace ein bißchen mehr als bei manchen anderen Anbietern.

Immerhin schaut die Konfigurationsoberfläche schön grün aus... - all zu übersichtlich zwar auch nicht, aber gut. Schätze wenn ich in Zukunft wieder die Wahl habe werde ich eventuell einen anderen Anbieter nehmen...

Drupal zügeln - aka Drupal-Migration

Und wieder mal war es so weit: die in mühevoller Kleinarbeit lokal erstellte Webseite sollte gezügelt werden. Alles halb so schlimm, aber damit ich beim nächsten Mal nicht schon wieder ganz von vorne nachdenken muss, hier die wesentlichen Schritte:

Vorbereitungen:

grundsätzlich empfiehlt es sich, vor der Migration die Module zu deaktivieren. Wenn man es vergisst, funktioniert's üblicherweise trotzdem - aber sicher ist sicher.

1. Datenbank sichern. Ich verwende xampp, auf dem Server ist (wie meistens) phpmysql verfügbar, also verwenden wir das. Datenbank auswählen, im exportieren-tab exportieren (als SQL-Skript, die restlichen Einstellungen kann man getrost belassen), fertig.
2. Dateien zügeln. FTP-Tool starten, loslegen. Ich verwende FireFTP, aber da gibt's einige brauchbare Tools. Einfach die gesamte Drupal-Installation kopieren. Bzw. das was man braucht, so sind etwa nicht immer alle Themes und Module notwendig. Muss jeder selber wissen ob er die Sache eher schlank hält oder alles Mögliche zur Verfügung haben möchte im Falle einer späteren Anpassung.
3. Konfiguration anpassen. Die Datenbank auf dem Server tendiert dazu, anders zu heißen. Sprich was in der Art providername_benutzername_benutzerdefinierterteil. Die entsprechende Einstellung findet sich in der Drupalinstallation unter sites/default/settings.php. Unter den Zeilen

    * Database URL format:
   *   $db_url = 'mysql://username:password@localhost/databasename';
   *   $db_url = 'mysqli://username:password@localhost/databasename';
   *   $db_url = 'pgsql://username:password@localhost/databasename';

   befindet sich der aktuelle Datenbankeintrag, diesen einfach entsprechend dem obigen Schema anpassen.
4. Datenbank einspielen. Machen wir wieder mittels phpmyadmin. Die neue Datenbank auswählen, im Importieren-Tab das zuvor erstellte SQL-Skript hochladen, kurz warten, fertig.

Und das war's auch schon. Haben wir alles richtig gemacht (und bei unserer Installation keine absoluten URLs verwendet, die jetzt nicht mehr passen), können wir genau dort weitermachen, wo wir vor der Migration aufgehört haben. Achtung allerdings, es wurden auch sämtliche Benutzer mit kopiert - sollte also aus Bequemlichkeitsgründen der Benutzer admin mit Passwort admin existieren oder generell jeder alle Rechte haben, ist spätestens jetzt der Zeitpunkt gekommen, dies anzupassen - besser vorher.