Auf Entwicklungsumgebung ohne https arbeiten

Ja klar gibt's die. Das hängt aber davon ab, welches Modul du installiert hast, um https zu erzwingen. Ich erzwinge das nie, sondern konfiguriere den Server so, dass er auf https umleitet. Dann funktioniert die Seite auf der Entwickler-Umgebung auch ohne https weiter. Warum du lokal https brauchen solltest erschließt sich mir nicht wirklich. Warum jemand eine Seite also so konfiguriiert, dass sie intern auf HTTPS hinweist, wenn kein HTTPs vorhanden ist erschließt sich mir ergo also auch nicht so ganz. Was hast du denn an Modulen installiert und wie sieht deine Settings.php und deine .htaccess datei aus. Da muss der Fehler ja dann erst mal raus, damit du die Seite lokal nutzen kannst.

Alternativ kannst du lokal ein nicht zertifiziertes Test-Zertifikat installieren, wenn du es unbedingt brauchst.

Danke für deine Antwort.

Ich verstehe sie aber nicht ganz, weil .....

.... ich möchte kein Testzertifikat und kein https auf meiner Entwicklungsumgebung haben, das brauche ich nicht, ist nur zusätzlicher Aufwand und ich möchte es vermeiden.
.... daher ist eine andere Lösung unbedingt nötig
.... ich habe KEINE Module installiert. Ich habe Drupal 8 ganz frisch installiert und danach möchte ich das erste Modul, das ist bei mir immer Admin Toolbar, installieren. Also mache ich das über das Drupal-Menü unter "Extend" oder "Erweitern" und dann kommt sofort die FEhlermeldung, wenn man die URL vom Modul eingibt und das Modul installieren will.
.... sprich das ist ein generelles Problem und hat nichts mit meinen Einstellungen etc zu tun.
.... wenn es ginge über htaccess oder settings das Problem zu lösen, wäre das sehr gut, dann würde ich das machen. Aber wie?
.... ich habe also gar nichts konfiguriert und auch gar nichts gemacht.

Ich möchte nur Drupal 8 installieren und lokal damit arbeiten ohne diese im ersten Posting genannte Fehlermeldung.

Übrigens hier gibt es einen Screenshot von dem Problem. Die dort angesprochene Lösung funktioniert aber nicht, tut gar nichts.

Weitere Ideen für eine Lösung?

Wenn Du die Installation über Composer durchführst, wie das ja bei Drupal 8 empfohlen wird, hast Du das Problem nicht.

Das weiß ich!

Du kannst also bestätigen, dass dieses Problem immer auftritt, wenn man lokal entwickelt und lokal kein https (SSL) installiert/aktiviert hat.

Die Frage ist ja, warum diese Fehlermeldung nur beim Installieren von Modulen kommt, nur wenn man Module installiert und nur wenn man es über die Drupal Oberfläche macht.

Drupal will, dass https verwendet wird. Aber warum die Fehlermeldung nur beim Installieren von Modulen kommt und alles andere, egal was es ist, auch ohne https gemacht werden kann, ist nicht klar. Wer weiß, warum das so ist?

Man kann Module mit Composer installieren, man kann MOdule auch runterladen und in das Verzeichnis kopieren, es gibt mehrere Möglichkeiten (wohl auch Drush), die das Problem umgehen, TROTZDEM suche ich eine Lösung, weil die Fehlermeldung in dieser Form wie sie jetzt ist, unlogisch ist.

Und dann wird man aufgefordert, FTP-Zugangsdaten einzugeben (siehe Fehlermeldung, im letzten Posting verlinkt). FTP-Zugangsdaten vom lokalen Server, wenn man lokal arbeitet? Was ist denn das ..?

Dieses Verhalten ist doch nicht neu, das war auch schon vor D8 so. Beim Download über das Browser Interface wird das ftp-Protokoll verwendet. Wenn der Browser jetzt, warum auch immer, keine Berechtigung hat, in das Modul-Verzeichnis zu schreiben, vermutet er, daß es eine User-ID dazu braucht und die wird abgefragt. Kann er schreiben ist alles in Butter. Sieht Dir darauf noch mal die lokalen Berechtigungen an.

Lokale Berechtigungen?

Der Browser läuft unter Windows 10, die Dateien befinden sich unter Ubuntu in einer Virtual Machine. Das läuft sehr gut und problemlos und hat sehr viele Vorteile.

Wie kann ich also die Berechtigungen so setzen, dass der Windows Browser Berechtigungen in Ubuntu in der VirtualBox hat?

Na dann ist doch alles gut. Der Warnhinweis, dass das Passwort unverschlüsselt übermittelt wird, weil die Seite eben nicht hinter einem Zertifikat liegt ist ja an sich nicht schlimm und nur nett gemeint. Klar werden die Daten ohne Verschlüsselung durch https im Klartext übertragen. Da die aber nur aus der Virtuellen Maschine hin zu Windows übertragen werden und dazuwischen keiner das unverschlüsselte Passwort abfangen kann, gibt's doch eigentlich gar kein Problem,

Ach so und bitte sei so gut und gewöhne dir hier im Center ab sofort das du an. Wenn ich Community-Mitglider in Zukunft siezen muss, dann fall ich um. Du darfst gerne du sagen. Das steht im Code of Conduct sogar so drin.,

Was der Werner da mit Berechtigungen schreibt verstehe ich allerdings auch nicht.

Ich entwickle meine Seiten auch immer auf Ubuntu 18.04 mit virtueller Maschine auf einem Windows host. Die angegebene Fehlermeldung ist mir so allerdings noch nicht aufgefallen. Ich geh aber davon aus, dass es sich hier nicht um einen Fehler, sondern um einen freundlichen Hinweis des systems an den Nutzer handelt.

Ah das geht um die Verbindung zum FTP-Server. Vielen Dank für den Screenshot. Ich nutze das Modul nie. hab ja nen Composer. Aber da könnte man libssh2 für PHP installieren und dann ist gut. Dann sollte die Fehlermeldung weg sein. Ich hab noch nie Drupal mit nem FTP-Server hochgeladen. Das hat man um 1990 so gemacht ich bin erst 86 geboren. Für sowas bin ich einfach zu jung :-D

Mach das so https://duraturk.wordpress.com/2014/04/30/update-manager-with-ssh/ Dann ist das Problem weg

Ja, unverschlüsselt ist es auf der Entwicklungsumgebung überhaupt kein Problem, das sollte eigentlich Drupal auch akzeptieren und es zulassen, tut es aber nicht.

Es kommt nämlich keine Warnung, wie Du schreibst, sondern ein Error und dieser Fehler lässt es dann NICHT zu, dass man neue Module über die Oberfläche installiert. Man wird sozusagen gezwungen, SSL zu aktivieren. Das finde ich nicht nett von Drupal, weil es ja keine Live-Site ist, dort wäre das schon okay.

Ich habe übrigens niemanden per Sie angesprochen. Wenn ich schreibe "Ich verstehe sie aber nicht ganz", dann bezieht sich dieses sie doch auf den letzten Satz und damit auf den Satz "Danke für deine Antwort", also auf die Antwort bezieht sich das sie. Andernfalls müsste man das Sie ja groß schreiben, wenn man eine Person per Sie anspricht, was ich hier in fast 13 Jahren noch nie getan habe.

Und wie gesagt, es ist kein freundlicher Hinweis von Drupal, sondern es verhindert das Installieren von Modulen auf die herkömmliche Weise vollkommen!

In meiner Ubunto Box ist SSH natürlich installiiert, ich kann jedenfalls SSH tippen und schon erscheint "usage: ssh ...." und die ganzen Optionen. Trotzdem schreint Im Borwser SSH nicht als Option auf. Außerdem steht auf der Seite, die Du verlinkt hast, als Kommentar, dass man dann jedesmal die SSH-Zugangsdaten eingeben müsste. Das will doch auch keiner. Außerdem wie komme ich zu SSH user und passwort?

Also ich denke, es muss eine besser Lösung geben.

Und warum bei Dir das Problem nicht auftritt, verstehe ich nicht.
Geht doch auf
/admin/modules/install
und gib im Feld "Von einer ULR installieren" das hier ein:
https://ftp.drupal.org/files/projects/coffee-8.x-1.0-beta2.tar.gz

Wenn Du Coffee zuvor schon installiert hast, solltest Du es zuerst deinstallieren und aus dem /modules - Ordner löschen, sonst kommt eine andere Fehlermeldung (schon installiert).
Aber wenn noch nicht installiert, solltest Du dann beim Installieren von Coffee über /admin/modules/install genau die Fehlermeldung bekommen, um die es hier geht:

Also ich suche weiterhin eine Lösung, weil das einfach so wie es jetzt ist nicht sinnvoll in Drupal 8 eingebaut ist.

Natürlich kann man auch mit Composer arbeiten oder mit Drush oder die Module händisch ins Modulverzeichnis kopieren. Wenn es nötig ist, weil Composer benötigt wird (z. Bsp. bei Commerce Projekten), dann verwende ich Composer auch.

Aber TROTZDEM möchte ich eine Lösung für das hier angesprochene Problem finden. Danke an allen,die noch weitere Lösungsvorschläge haben.

Auch wenn man meine vorherige Antwort abgetan hat: Der Browser kann via Webserver nicht in das modules-Verzeichnis von Drupal schreiben. Er erwartet also eine FTP User/PW-Eingabe um auf den Server schreiben zu können. Wie stehen bei Deinem lokalen Unix-Server die Schreibrechte auf dem modules-Verzeichnis. Um über das Browser-Interface schreiben zu können muß der Webserver-Prozess, der meist unter www-data für User und Group läuft, dort Schreibrechte bekommen.

Werner deine Antwort tut doch keiner ab. Du hast natürlich recht. Trotzdem würde ich einfach empfehlen, Module statt per FTP per SSH hochzuladen. Dann ist die Fehlermeldung weg und mein Gelaber von wegen HTTPS obsolet, weil ich schlicht am Thema vorbei geschrieben habe. Schreibrechte braucht dann der FTP-User. und zar dann, wenn dort FTP läuft. Ich nutze kein FTP mehr, aber da bin ich hier offenbar ein Unikum.

Danke für die Antworten.
Obwohl ich das schon oben geschrieben und auch gemacht habe, habe ich jetzt noch einmal folgendes durchgeführt:

In Ubuntu diesen Befahl ausgeführt:

sudo chown www-data:www-data -R /var/www/druipal8/modules

Der Befehlt liefert keine Fehlermeldung und keine sonstige Ausgabe. Sollte also eigentlich die Rechte richtig setzen, oder?

Danach ist das Insratlieren von Drupal Modulen (wie oben besprochen) noch immer nicht möglich. Sprich es hat sich nichts geändert.

Wo liegt also nun in diesem Fall das Problem?
Gibt es den Benutzer www-data in Ubuntu überhaupt?
Wird der obige chown Befehl überhaupt ausgeführt?
Hat danach www-data die entsprechenden Permissions oder nicht?
Kann man das abfragen? Mit dem ls -la Befehl? Besitzer des Verzeichnisses ist nach wie vor der Ubuntu Hauptuser, da hat sich nichts geändert.

Also was genau verändert sich beim modules Ordner nach Ausführung dieses Befehles und wie kann man das abfragen/kontrollieren?

Wenn es geklappt hat, müsste dann nicht das Insratllieren von Modulen sofort funktionieren ohne weitere Maßnahmen?
Derzeit geht es wie gesagt nicht. Wo liegt der Fehler oder was fehlt?

Natürlich gibts den

mach einfach:

und probier noch mal

Hab ich gemacht.

Der chown Befehl wird ignoriert, egal wie man in anwendet.

Liegt es an dem Dateisystem? Hab gelesen, dass bei NTFS Probleme macht bei Permissions usw.

Wer weiß da mehr und wie löst man es dann?

Hab ich gemacht.

Der chown Befehl wird ignoriert, egal wie man in anwendet.

Liegt es an dem Dateisystem? Hab gelesen, dass bei NTFS Probleme macht bei Permissions usw.

Wer weiß da mehr und wie löst man es dann?

Das scheint weltweit niemand lösen zu können.

Ach komm die Lösung ist so einfach. Wenn es auf Ntfs Datensystemen Probleme mit so grundlegenden Dingen wie Berechtigungen unter Linux gibt dann benutzt man mit Linux eben kein Ntfs sondern ext3 oder ext4.

Problem weg.

So machen deine Antworten wenig Sinn, wenn Du einfach ignorierst, was bereits oben als sehr wichtig angesprochen und besprochen wurde:

Wie schon gesagt, wird eine Drupal Virtual Machine verwendet, die läuft in einer VirtualBox.
Das geniale daran ist, dass alles unter Windows läuft, man trotzdem ein vollständiges Ubuntu-System hat und die Vorteile von Ubuntu total nutzen kann. Gleichzeitig kann man auf alle Deteien (das gesamte Drupal-Projekt) auch über Windows zugreifen. Windows Explorer, und Browser (Chrome ...) laufen also unter Windows mit all den vielen Vorteilen ...

Man hat also die Vorteile von Linux/Ubuntu und die Vorteile von Windows gleichzeitig! Man kann natürlich auch mit Composer, Drush und all den anderen Tools direkt aus der Ubuntu Komandozeile arbeiten. Man arbeitet aber gleichzeitig unter Windows ....

Ganz viele Entwickler machen das und verwenden irgendwelche VirtualBoxen oder Virtual Machines. So eine Entiwicklung sumgeung ist ganz schnell aufgebaut und kann jederzeit wieder entfernt oder neue erstellt werden usw. Ideal zum Entwickeln ....

Also versuche niemanden, das auszureden, was oben schon erwähnt wurde. Drupal VM ist und bleibt gut.

Daher ist deine Lösung hier nicht möglich, weil von Windows aus könnte man meines Wissens nach ja nicht auf ext3 oder ext4 Dateisysteme zugreifen.

Sprich,l wenn Du obige Infos berücksichtigt hättest, hättest Du das ja auch erkannt und eine andere Lösung vergeschlagen.

Es geht also darum, all das zu lösen, ohne das Dateisystem zu ändern!
Auch dafür gibt es bestimmt Lösungen und wenn für dich immer alles so einfach ist, vielleicht findest Du auch dafür eine einfache Lösung. Genau das ist das Ziel, eine einfache Lösung, die tatsächlich funktioniert und mit den oben angegebenen Ausgangspunkten übereinstimmt.

Merci.

Das ist mir schon klar. Allerdings kannst du auch dann auf Windows Dateien zugreifen, wenn du über die Virtual Guest Extensions und shared Folders arbeitest. Aber ich sehe das Problem. Ich habe allerdings bis jetzt immer die Standardpartitionierung über ext4 verwendet.

Pass auf. Ich setze jetzt mal eben eine Virtualbox mit NTFS auf. einfach um nachvollziehen zu können, ob das wirklich am NTFS-Datensystem liegt. Ehrlich gesagt kann ich mir das nämlich nicht vorstellen. Das wird aber etwas dauern. Ich melde mich weider, wenn ich damit fertig bin. Vielleicht finde ich eine Lösung, wenn ich das Problem nachbaue.

Hast du den irgendeine bestimmte Drupal Distribution in Verwendung. Ein Paar Detailinfos wären hilfreich.

Mittlerweile habe ich das mal im Installer Geprüft Ubuntu 18.04.3 Dort ist die Formatierung des Datensystems in NTFS nicht vorgesehen. Siehe Screenshot.

Gib mir bitte mal den Output von

sudo df -Th / deines Systems, damit wir sehen können, ob du wirklich NTFS in der virtuellen Maschine nutzt.

Bist du sicher, dass dein System in der Virtualbox mit NTFS formatiert ist. Deine Windowsplatte sicher, aber die hat mit dem Datensystem in der Box nichts zu tun.

Auch die Meldung, um die es dir eigentlich geht, dürfte mit dem Datensystem nichts zu tun zu haben. Wenn du das noch mal testen willst, kann ich dir auch Zeigen, wie du Drupal unter Ubuntu richtig aufsetzt. Ich hab diese Meldung noch nie gehabt und kann sie tatächlich so nicht nachvollziehen. Villeicht hilft dir folgendes:

https://www.youtube.com/watch?v=nbZoIeeCi-w

Wie schon oben angesprochen, verwende ich die Drupal VM , also https://www.drupalvm.com/.

Da muss man nichts manuell einrichten, oder fast nichts. Läuft über vagrant.

sudo df -Th liefert folgendes:

Es handelt sich also nicht um NTFS sondern um vboxsf, Virtual Box Shared Folders.

Verwende die neueste Version von Drupal 8.
Aber hier in der Drupal VM, wenn die mal installiert ist und läuft, braucht man um ein weiteres Drupal-Projekt hinzuzufügen, nur die Konfiguration für die shared folders und die Datenbank usw. hinzufügen. Drupal installisiert man dann in den entsprechenden Order manuell, ganz normal über Download oder mit Composer usw.

Sprich die Drupal VM enthält eine Drupal-Installation, aber ich füge weitere Drupal Installationen hinzu für weitere Projekte und kann so die shared folders nutzen, kann Ubuntu nutzen, Adminer und MailHog nutzen und so sowohl in Ubuntu als auch in Windows arbeiten am gleichen Projekt.

Ah du verwendest die Drupal VM. Das ist die Info die mir gefehlt hat. Mir ist allerdings immer noch nicht bekannt, dass dort beim Zugriff über den Webbrowser diese Meldung auftaucht. Aber gut das bringt uns weiter. Dann also die Drupal VM. Neue VirtualBox und neue Test-Umgebung. Mal schauen, ob ich dann den gleichen Fehler sehen kann wie du. Bleibt spannend.

Nein, KEINE neue VirtualBox!

Einfach die Drupal VM installieren. Diese installiert eine Drupal-Installations laut config.yml.

Danach, wenn alles läuft, nichts anderes machen, als in der config.yml die Bereiche vervielfältigen, die nötig ist, damit eine weitere Drupal-Installation verwendet werden kann, also shared folders, Drupal settings, vhosts, mysql, memory limit erhöhen.

Keine neue VirtualBox erstellen. Mit dem Oracle VM VirtubalBox Manager brauchst Du gar nichts zu machen. Alles läuft in der VirtualBox die von der Drupal VM erstellt wird.

Das hab ich schon verstanden. Drupal VM erstellt doch Virtuelle Boxen. Selber. Aktuell bin ich noch im installationsprozess. Drupal VM gibt in der Standrardvorlage nämlich gerade mal 2 GB ram und einen Prozessor her. Das dauert. Ich pass schnell das Vargant-File an. Tatsächlich sehe ich nämlich nicht so ganz ein, warum mir die Drupal VM 2 GB Speicher gibt, wenn ich doch theoretisch 30 GB Hauptspeicher haben könnte oder mindestens 10.

Ich weiß schon, warum ich immer alles selbst mache. Dann finde ich hinterher auch meine Konfiguration und kann meine Probleme selbst fixen. Ich helf dir aber trotzdem und melde mich noch mal, sobald ich die Installation abgeschlossen habe. Hoffentlich mit mindestens 10 GB Hauptspeicher und 6 Prozessorkernen innerhalb der Drupal Vm. Sonst sitz ich ja morgen noch hier rum.

Wow zwischenzeitlich hat mein Virenscanner ruby.exe als Virtus eingestuft, und Vagrant zerschossen. Also ich lös ja gern Probleme, aber wie kann man nur so einen Mist zusammenbauen,

Ich melde mich, sobald ich Drupal unter drupalvm.test aufrufen kann.

Also, ob nun 2 GB oder fast 2 TB (wie man bei meinem Posting oben ja sehen kann) ist jetzt vollkommen egal, das Problem kannst du später lösen, weil darum geht es jetzt ja nicht und es ist bestimmt nicht viel langsamer deswegen.

Dann hast Du aber einen Mist Virenscanner, könnte man so einfach mal sagen. Virenscanner, die überreagieren, sind Mist. Da vertut man so viel Zeit damit, das ist ein gigantisches Problem der Menschheit. Die Menschheit kann sich ganz anders entwickeln, wenn nicht so viel Zeit mit solchen Mist verschwendet wird, ähnlich wie Milliarden Menschen auf Facebook Milliarden Stunden vergeuden.

Nimm das nicht so ernst, aber deine Postings sind auch nicht immer ganz ernst.

Also nimm die Standard Drupal VM ohne Änderungen, dann geht es schneller.

Also dann hol ich dich mal ab:

1. Ich rede hier nicht von Festplattenspeicher, sondern von Arbeitsspeicher innerhalb des von Vagrant erstellten Containers. Wenn du zu Hause bei dir 2 TB Hauptspeicher in deinem Rechner hättest, würde ich bei dir Rechenleistung kaufen

2. Vagrant hat einen Bug, der verhindert, dass Ansible ordnungsgemäß installiert wird, wenn man die durpalvm nicht auf einem Windows Administrator Konto installiert

3. Aktuell funktioniert der Download der in Vagrant enthaltenen Composer-Vorlage nicht, Ich hab jetzt versucht das alles zu fixen um dein Problem überhaupt nachstellen zu können. Es ist mir trotz Linux-
Kenntnissen nicht gelungen Vagrant dazu zu bewegen Drupal 8 im finalen Schritt herunterladen zu lassen.

Wir haben jetzt 14:27 Angefangen hab ich glaube ich um 12:00. Sei mir nicht böse, aber ich habe Vagrant schon zu Zeiten von Drupal 7 für mist erklärt. Jetzt hab ich mich damit beschäftigt und bin immer noch der selben Meinung.

Was bringt mir denn eine Software, die mir zwar alle notwendigen Datein direkt im Windows-Dattensystem einhängt, bzw einfach den Ordner, in dem der Github-Code liegt, wenn der Rest einfach nur mit Hängen und würgen funktioniert und am Ende doch nichts bei raus kommt.

Lieber Drupal Fan ich würde dir ja gerne helfen, aber selbst ich habe jetzt einfach keine Lust. mehr. Hätte ich Drupal in der Gleichen Zeit in Virtualbox von Hand auf Ubuntu 18.04-minimal installiert, hätte ich inzwischen wahrscheinlich wesentlich mehr geschafft.

Es tut mir wirklich leid, dass ich dein Problem nicht lösen kann. Das liegt aber weder an virtaulbox, noch an Ubuntu- Das liegt einfach nur daran, das jeff gerling irgendwelchen Code schreibt und dann auch noch mitr Vagrant arbeitet, sodass die Logik des Produkts DrupalVM für Einsteiger und auch für Fortgeschrittene Nutzer nicht mehr nachvollziehbar ist.

Vielleicht kann irgend jemand dein Problem reproduzieren.

Ich jedenfalls hab nach 2 Stunden einfach keine Lust mehr. Mich wundert nicht, dass das halbe Drupalcenter den spaß an Drupal verliert, wenn hier Tools verwendet werden, die dazu führen, dass man mehr Bugs suchen und beheben muss, bevor man Drupal überhaupt das erste mal zu Gesicht bekommt, als auf jedem leeren und selbst installierten V-Server.

Sei bitte nicht böse aber Hände weg von dem Ding.
Die Fehlermeldung deiner Orignalfrage ist nicht normal.
Ich schaffe es nicht mal, dass teil richtig zu installieren
und ich sitze seit 2 Stunden vor der Kiste weil ich dir wirklich helfen will.

Fazit: Virtualbox + Ubuntu + Apache + Mysql + Software X + Drupal geht schneller und nachvollziehbarerer zu installieren, als das Tool, das du da verwendest. Von der Fehlersuche will ich noch gar nicht reden. Ich kann dir so nicht helfen. Sorry. Dieses Werkzeug regt mich einfach nur auf, weil es unnötig viel Zeit frisst. Ich Will mit drupal funktionierende Websites für meine Kunden bauen und keine Fehler suchen. Drupal, also die eigentliche Software kann hier aber gar nichts dafür. Das ist leider das, was bei solchen Fragen immer untergeht.

PS ich hab sogar versucht Drupal manuell mit den Daten aus der drupal.composer.json in die vargantvm zu clonen. Hat auch nicht geklappt.

Wie gesagt, auf der Umgebung würde ich nicht einmal entwickeln, wenn mich jemand dafür bezahlen würde.

Einen Tipp hab ich trotzdem noch. Schreib Jeff auf Github einfach einen Issue. Wenn jemand weiß, wo der Fehler herkommen könnte, dann er selbst und er wird sich für den Hinweis bedanken, da er den Fehler für seine Kunden beheben kann.

Damit Drupal installiert wird, muss in der config.yml drupal_install_site auf true gesetzt sein. Vielleicht war das bei Dir der Fall vielleicht auch nicht.

Warum bei Dir die Drupal VM Probleme macht, kann ich mit den wenigen Informationen nicht sagen. Grundsätzlich ist die Drupal VM sehr gut und es funktioniert alles einwandfrei, man hat alle Einstellmöglichkeiten ....

Drupal VM ist sehr zu empfehlen. Man kann eine volle Eintwicklungsumgebung mit Ubuntu "in einer Box" und gleichzeitig unter Windows in wenigen Minuten erstellen, ohne irgendwelche Ubuntu konfigurationen durchführen zu müssen und ohne Ubuntu selbst installieren zu müssen, ohne den Rechner wechseln zu müssen oder mit Ubunto hochfahren zu müssen usw. Wer das manuell einrichten möchte, braucht viel länger und braucht schon viel Knowhow.

Aber all das sind andere Themen, um die es hier in diesem Thread nicht ging.

Danke für deine Bemühungen und wenn Du positiv zur Drupal VM eingestellt bist, dann wird es auch noch klappen.

Das hier besprochende Problem ist eigentlich ein Problem von Drupal 8 und nicht von der Entwicklungsumgebung. Denn Drupal müsste erkennen, dass es sich um enie Entwicklungsumgebung handelt und dann entsprechend zulassen, dass Modle auch ohne https zu nutzen, installiert werden können (eben nur auf der Entwicklungsumgebung). Oder es sollte ganz bewusst durch eine Konfig-Einstellung umschaltbar sein.

Dies ist und bleibt ein Drupal 8 Problem, auch wenn andere das anders sehen. Drupal 8 muss auch zulassen, dass man auf Entwicklungsumgebungen, egal welche es sind, OHNE HTTPS arbeiten möchte! Solange man über die Oberflächte Module installieren kann, und das kann man ja auch immer noch trotz Composer, trotz Drush und trotz vieler andere Varianten, solange muss das auch auf Entwicklungsumgebungen irgendwie funktionieren, auch wenn man dafür zuvor eine Koniguration in der settings.php oder ähnlich vornehmen muss.

Hab eine Lösung gefunden, die solange niemand eine besser Lösung findet, durchaus funktioniert:

n core/modules/system.module
den folgenden Code zur function system_filetransfer_info() hinzufügen:

Dadurch könnten wir Module mit der Methode "Local" auch installieren und es werden keine FTP-Zugangsdaten benötigt.

Wer findet eine bessere Lösung? (Beachte: Als Dateisystem wird vboxsf, daher funktioniert der chown Befehl nicht, siehe weiter oben).