Composer und Drush für shared Webhosting

a) Composer
b) User Verzeichnis

Hier mal eine Anleitung für Shared Hosting am Beispiel des Schweizer Hosters Hostpoint:

http://stevenschulz.net/blog/composer-und-drush-installieren-auf-schweiz...

also, wenn ich mich via ssh anmelde bekomme ich folgende Meldung:

wenn ich curl -sS https://getcomposer.org/installer | php eingebe dann kommt folgende Meldung

Also ich überliste meinen Webhoster und lade mit Filezilla die Datei composer.phar hoch

.bashrc und .bash_profile kennt mein Webspace nicht, weil ich bekomme nach der Eingabe von composer global require drush/drush:dev-master zur Antwort

Gebe ich händisch über das Terminal folgendes ein php composer.phar global require drush/drush:dev-master kommt folgendes

wenn ich die ENTER-Taste drücke kommt noch mehr hinterher

na ich habe dann erst mal abgebrochen. Kann damit jemand etwas anfangen, weil für mich sind das alles böhmische Dörfer? Oder hat jemand von Euch vielleicht bei Strato das ganze erfolgreich installiert?

Gibt es bei hostpoint.ch auf einem Standard-Sever irgendeine Möglichkeit Drupal Upgrades schneller/komfortabler durchzuführen, als alle weit über 10.000 Dateien per FTP hochzuladen?

Bei Drupal 8 gibt es jetzt anscheinend alle paar Tage/Wochen ein neues Upgrade, da wird es schon etwas unkomfortabel per FTP upzugraden:

Nicht nur das Hochladen der weit über 10.000 Dateien (es kommen auch noch die Module hinzu ..) sondern auch das Löschen der bestehenden Drupal-Installation per FTP dauert lange.

Gibt es eine Möglichkeit?
Wie löscht ihr 10.000 Dateien per FTP am effizientesten?

das von deinem Provider zur Verfügung zu stellen ist, kannst du einiges etwas komfortabler durchführen.

Solltest du PLESK haben, kannst du dessen Oberfläche benutzen, um Dateien zu löschen, zu verschieben, zu kopieren etc., und sogar ZIP-Archive zu entpacken.

Sollte dein Provider etwas anderes anbieten, brauchst du dafür die entsprechende Anleitung.

Auch beispielsweise CPanel kann einiges - ich weiß aber ncht, was damit alles möglich ist.

Meist sind diese Tools Webaufrufe auf Skripte, die direkt auf dem Server laufen, und deshalb keine zusätzlichen Daten übertragen müssen.

Module lassen sich ganz gut aus Drupal selbst heraus aktualisieren. Her wird der Download vom Server ausgeführt, der die Daten direkt aus dem Repository holt.
Da sind ganz andere Geschwindigkeiten möglich als per DSL Down - und Upload.

Bei entsprechender Einrichtung kann auch die Sicherung im Backbone passieren, was auch erheblich schneller läuft, als auf einen Client.

Hi Drupalfan,

ja das geht effizienter, aber dazu benötigst Du Shell Zugriff zum Server(SSH).

Lade das ganze ZIP/Tar per FTP auf den Server, log Dich per SSH ein und entpacke die gepackte Datei direkt auf dem Server.

Auch hier log Dich per SSH ein und mach rm -r [Verzeichnissname].
Das dauert nur Sekunden im Gegensatz zu FTP, bei dem jede Datei einzeln gelöscht werden muss.

Gruss

Robert

Hallo Robert,

meine Frage war, ob auf einem Standard-Server (!) bei hostpoint.ch Möglichkeiten existieren ...

Was Du schreibst, wäre schön, setzt aber voraus, dass man SSH-Zugang hat (ist das eigentlich das gleiche wie ein Shell-Zugang?).

Du kennst hostpoint vielleicht bessser als ich, aber ich habe nur kurz gegoogelt und herausgefunden, dass es Shellzugang und SSH-Zugang nicht bei den Standard-Servern gibt bei hostpoint.

Wie kannst Du diese Befehle wie von Dir beschrieben auf einem Standard-Server von hostpoint ausführen?

Einfach drush installieren wie in der Anleitung
Und dann

drush up

Damit werden dann alle Module und Core Updates eingespielt und vorher macht das eine Sicherung von den geänderten Modulen.

Vorher besser auch die Datenbank sichern!

Danke, auch hier die gleiche Frage:

Wie geht das auf einem Standard-Server von hostpoint? (So hat die Frage gelautet weiter oben).

Das kleinste Webhosting Paket Standard für CHF 9.90 / Monat hat _kein_ SSH

Alle größeren Pakete ab Smart für CHF 14.90 / Monat haben SSH

Ohne SSH kein Drush und auch keine praktischen Dinge wie fix Ordner löschen / bewegen usw.

Updates manuell via FTP zu machen ist langwierig da jede Datei einzeln gelöscht und neu hochgeladen werden muss.

Je nachdem wie häufig du Updates einspielen willst macht es ggf. Sinn auf das nächst höhere Paket upzugraden.

Welches Paket ein Kunde nutzt ist Sache des Kunden.

Hehe. Dann musste mehr Zeit abrechnen für Updates.

Mit dem Argument meines Stundensatzes rechne ich meistens meinen Kunden vor, daß Ihnen allein schon darüber das zu kleine Webspace-Pakte zu teuer kommt, wenn man mich fürs Warten bezahlt. Aber eine sinnvolle Administrationsarbeit fängt erst beim Shell-Zugang an.
Dazu benötigt man in der Commandline noch PHP-CLI, mysql/mysqldump und wget Commands, da auch drush nur "mit Wasser kocht". Und Patche möchte man auch schnell mal einspielen können, wenn ein Gesamt-Update nicht klappt. Neben GIT geht wird Composer ohnehin immer mehr zum Standard. Aber in einem Shared Hosting ohne Shell-Zugang wäre es auch aus Sicherheitsgründen nicht wirklich sinnvoll, da der Webserver eigentlich die Webanwendung nicht selbst verändern können sollte. Auch wenn ich nicht wirklich zur Benutzung dieses Moduls raten kann, so kann man mit dem Shell-Modul tatsächlich etwas tricksen in diese Richtung.
Aber in einem Produkt-System muss einfach schnell mal Backups erstellen und wieder einspielen können. Diese ganzen PHP-Helfer zum Umgang mit der Datenbank sind Krücken, die schnell mal streiken können, wenn es darauf ankommt, bei der nächsten SQL-Injection Lücke im Core ...

Und für Drupal 8 gibt es auch so ein "hilfreiches" Modul?

Man könnte es auch so machen:

Drupal lokal mit drush updaten und dann die geänderten Dateien / Module via FTP hochschieben.

drush up

Das erspart zumindest das manuelle herunterladen und entpacken der Module

Dann einfach die update.php auch nochmal auf dem Live Server ausführen um die notwendigen Datenbank Änderungen durchzuführen.

Das geht aber auch nicht so einfach. Denn von weit über 10.000 Dateien bei Drupal 8 (Verzeichnisse /core, /vendor, eventuell /modules, ...) kann man nicht so einfach feststellen, welche sich geändert haben.

Schließlich will man am Ende 100% sicher sein, dass keine einzige geänderte/neue Datei der neuen Drupal-Version eventuell nicht hochgeladen wurde.

Vorher in git einchecken. Dann weiß man exakt welche.