Viele laden Drupal noch als ZIP-Archiv herunter, entpacken es lokal und laden tausende Dateien per FTP hoch. Das funktioniert, ist aber unnötig umständlich. Der Standardweg in der Drupal-Community ist Composer: Funktionen wie der Project Browser sind im Hintergrund auf diesen Paketmanager angewiesen. Wer Drupal ernsthaft betreiben will, kommt an Composer nicht vorbei.

Um Befehle direkt auf dem Server auszuführen, brauchst du SSH-Zugriff. In Plesk steht dieser oft standardmäßig auf "Forbidden". Das änderst du in den Hosting-Einstellungen der Subscription: SSH-Zugriff auf eine Shell wie /bin/bash oder /bin/sh umstellen.

Lädst du Drupal über Composer, landet es häufig in einem Unterverzeichnis, etwa /cms/web. Plesk schaut standardmäßig aber in httpdocs. Damit Besucher nicht ins Leere laufen, muss der Dokumentenstamm in Plesk entsprechend angepasst werden – etwa von httpdocs auf httpdocs/cms/web.

Drupal braucht eine eigene Datenbank, die sich bequem im Plesk-Backend anlegen lässt. Sicherheitstipp: Beschränke den Zugriff auf "Localhost" – die Datenbank muss nur mit dem Server sprechen, nicht mit dem gesamten Internet.

Bei den PHP-Einstellungen ist Drupal anspruchsvoll:

• Mindestens 512 MB RAM (memory_limit)
• open_basedir-Beschränkung entfernen (auf "none" setzen) – sie blockiert sonst Composer und Drush

Ein häufiger Frust-Moment: Alles ist vorbereitet, aber Drupal meldet Fehler. Der Grund liegt oft daran, dass Plesk zwar gut für WordPress optimiert ist, Drupal aber eher stiefmütterlich behandelt – viele Plesk-Server liefern eine veraltete Composer-Version aus.

Fazit: Die Basis steht, aber ein veralteter Composer bremst noch aus. Im nächsten Teil lösen wir genau das mit einem Update-Skript.