Ich brauche dringen Hilfe zu Updates oder ggf. wwie geht Composer?

Keiner der mir weiterhelfen kann?

Soweit ich gelesen habe ist es relevant unter welchen Drupal die seite ursprünglich erstellt wurde.
Ich erinnere mich nicht mehr genau, aber ich glaube die erste Version wurde sogar noch unter Drupal 7 erstellt und dann immer wieder upgedatet.

Composer nachträglich zu installieren, macht m.E. wenig Sinn weil composer nur die Komponenten findet, die über composer installiert wurden. Es ist da deutlich einfacher, eine komplette Neuinstallation (mit composer) zu machen.
So installiest du composer:
curl -sS https://getcomposer.org/installer -o composer-setup.php
composer-setup.php --filename=composer
Grundsätzlich ist der composer eine Riesenerleichterung, weil er automatisch Zusatz-Librairies etc. mit hochlädt und du das ncih talles selber zusammensuchen musst. Mit dem Befehl "composer update" kannst du am Ende bewquem das Gesamtpaket aktuell halten.

Die Probleme mit den fehlenden Modulen und dem fehlenden Theme wirst du dann allerdings auch noch haben. Der Wechsel einer Core-Basis ist immer eine Herausforderung. (Es überrascht mich, dass das mit dem Einkopieren der Core-Dateien überhaupt lauffähig geworden ist!)
So weit, wie du mit dem core update schon gekommen bist, ist es vielleicht einfacher die angezeigten Module auch noch von Hand nachzuinstallieren, dann das update.php laufen zu lassen. Danach kannst du die Module wieder deinstallieren.

Langfristig solltest du aber auf composer umstellen.

Hallo,

mittlerweile habe ich es geschafft Composer auf dem Webserver zu installieren, habe die alten Dateien und Datenbank wieder eingespielt.

Danach habe ich das Theme Seven und die Module die nicht mehr unterstützt wurden deinstalliert und ein anderes Theme für die Verwaltung gewählt. Glaube Claro.
Vom Theme was die User sehen sowie den Modulen die Drupal automatisch per Oberfläche updaten konnte die neueste Version eingespielt.

Das ist aktuell der Stand der Dinge.

Ich hatte auch zwischendurch bevor ich alles zurück gesichert hatte Composer gestartet er zeigte mir die Module an und die neuen Versionen davon aber nachdem er durch war (glaube er brachte ne Fehlermeldung, kann ich später am PC raus suchen falls nötig) brachte die Seite Fehler 500 wenn ich drauf wollte.

Außerdem kann er in der Zeit niemals ein Update des Drupal gemacht haben

Wenn ich Deine Antwort richtig verstehe, sollte es also möglich sein, die Seite weiterhin per FTP upload und update.php zu pflegen? Also ohne Composer? Das wäre mir ehrlich gesagt am liebsten, weil ich das immer hinbekommen habe bis jetzt. Da das die einzige Seite ist um die ich mich aktuell kümmere wäre das daher für mich am einfachsten.

Die Seite ist ja aktuell auf 9.4. Müsste ich also nun die letzte 9er installieren, danach die erste Zehner oder kann ich jetzt direkt die erste Zehner danach die letzte 11er (jeweils per update.php fall tatsächlich noch möglich) installieren?

Wenn ich die Seite mit Composer neu aufsetzen würde, müsste ich ja sämtliche Einstellungen die in der alten Datenbank liegen neu einstellen, oder verstehe ich das falsch?

Sorry ich sehe gerade ich habe sämtliche Kommata vergessen auf dem Handy....

Bis D9 habe ich auch ausschließlich über FTP gearbeitet. Das ging irgendwie, war aber am Ende sehr mühsam. Composer macht da vieles einfacher.
D10/11 würde ich ohne Composer nicht aufsetzen.
Zum upgrade auf D10/11 würde ich auf keinen Fall einfach Core und Vendor mit den aktuellen Versionen überschreiben. Das geht mit hoher Wahrscheinlichkeit schief, danach kommst du an nichts mehr ran.
Der sicherste Weg ist über das Modul backup and migrate ein Backup der Datenbank zu erstellen und zusätzlich den Ordner files mit allen Unterordnern zu sichern. Dann setzt du mit composer eine Neuinstallation mit allen von dir verwendeten Modulen auf. Soltest du Module verwenden, die unter D10/11 nicht laufen, musst du sie vor dem Backup in D9 durch aktuelle Lösungen ersetzen. Wenn die neue Version läuft, kannst du mit drush das Backup einlesen und damit alle Daten aus der alten Datenbank übernehmen. Dazu den Ordner files mit FTP einlesen und die Seite sollte wieder aussehen wie vorher.

Ja, das mit Mühselig hab ich inzwischen auch gemerkt.....

Ich habe inzwischen alle altem Module etc. deinsalliert oder geupgradet und dann die 10.2 eingespielt und das Update.php lief nach einigen Problemen die ich gelöst habe dann irgendwann problemlos durch.

Die Startseite läuft auch generell aber sobald ich auf ne andere Seite der Website wechsle bringt er mir Serverfehler.
Ich vermute das liegt an der settings.php, habe aber noch nicht geguckt was sich geändert hat oder die Änderungen übertragen.

Falls jemand ne Idee hat woran es noch liegen könnte immer raus damit, dann kann ich morgen weiter gucken falls es nicht an meiner Vermutung liegt.

Und ja, vermutlich wäre es auf lange Sicht sinnvoll alles umzustellen, aber wer weiß wie lange ich diese einzige alte Seite noch pflege. Und mittlerweile sitze ich schon ne Woche dran Composer und diese neuen Methoden zu verstehen ohne groß weiter zu kommen. Daher solange es per FTP möglich ist, würde ich gerne so weiter machen, falls möglich, um nicht noch mehr Zeit zu verschwenden.

Der Fehler kann in der .htaccess-Datei liegen. Beim Punkt "# RewriteBase /" das # entfernen, damit diese Bedingung scharf wird. Das ist bei manchen Providern notwendig.

Danke. Es scheint jetzt ENDLICH geklappt zu haben und unter D10.02 zu laufen.
Jetzt steht testen und das upgrade auf 11 an.

Ok es scheint zu laufen ABER:

Wenn ich mance Seiten aufrufe bekomme ich folgende warnung:

Warning: file_get_contents(themes/drupal8_custom_theme/css/sm-core-css.css): Failed to open stream: No such file or directory in Drupal\Core\Asset\CssCollectionOptimizerLazy->generateHash() (line 43 of core/lib/Drupal/Core/Asset/AssetGroupSetHashTrait.php).
Drupal\Core\Asset\CssCollectionOptimizerLazy->generateHash(Array) (Line: 120)
Drupal\Core\Asset\CssCollectionOptimizerLazy->optimize(Array, Array, Object) (Line: 179)
Drupal\Core\Asset\AssetResolver->getCssAssets(Object, 1, Object) (Line: 321)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAssetLibraries(Object, Array) (Line: 165)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object) (Line: 97)
Drupal\big_pipe\Render\BigPipeResponseAttachmentsProcessor->processAttachments(Object) (Line: 45)
Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object, 'kernel.response', Object)
call_user_func(Array, Object, 'kernel.response', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.response') (Line: 214)
Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object, Object, 1) (Line: 202)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Nach dem neu laden der Seite verschwindet diese Warnung jedoch bis ich den Cache leere, dann taucht sie wieder auf.
Ansonsten scheint es aber zu laufen.

Jemand ne Idee was es mit der Warnung auf sich hat oder warum diese verursacht wird?

Das Verzeichnis "Drupal/Core/Asset/" existiert auch nicht. das Verzeichnis was vorhanden ist heißt "assets" und darin sind auch nur 2 Ordner.
Hängt das vielleicht damit zusammen, das die Seite erst auf 10.2 ist? auf 9.4 hatte ich das zumindest nicht.

Das ist für mich das typische Problem, wenn man mit FTP arbeitet. Durch die schiere Anzahl von Dateien kann es dazu kommen, daß sich das FTP-Programm verhaspelt und ganze Ordner verschluckt. Deshalb immer nur -zip, -tar oder -tar.gz Dateien benutzen und die Datei auf dem Zielsystem auspacken. Mit composer passiert das nicht, da der nur Pakete herunterlädt und dann auf dem Server auspackt.
Ich selbst habe in den Anfängen von Drupal 8 auch meine Schwierigkeiten mit composer gehabt, aber inzwischen habe ich gelernt, daß die Verwendung von composer und drush die Arbeit auf den Server erheblich vereinfacht. Der Update einer punkt-Release ist ein Einzeiler. Drupal und alle Module werden mit dem Befehl "composer update" auf einmal auf den aktuellen Stand angehoben. Man muß "nur" bereit sein, sich auf die Kommandozeile einzulassen.

Naja ich achte immer drauf on das FTP Dateien meldet die nicht Übertragen werden konnten und das ist nicht der Fall gewesen.
Ich habe inzwischen ein anderes Theme getestet und damit habe ich das Problem nicht.

Ich kann mir nur vorstellen, dass ich beim übertragen meiner früheren Änderungen am Originaltheme in die neue Version davon einen Fehler gemacht habe.
Das werde ich dann später nochmal überprüfen.

Aber es ist ja unlogisch, dass er nen Pfad sucht der garnicht existiert und mit dem meine Änderungen auch nie was zu tun hatten.

Und ja, sicher wird es mittels composer später leichter gehen, wenn man alles eingerichtet hat und sich eingearbeitet hat.
Eingerichtet habe ich Composer ja schon, aber da die Seite haufenweise Änderungen hat wird ein simples Update eh nicht gehen ich muss eh viele Dateien von Hand ändern. Und dazu kommt, dass ich bis auf das Einrichten auf dem Webserver mit composer nich absolut nichts gemacht habe und erstmal verstehen muss, was da wann wie gemacht wird etc.'
Und das Einarbeiten wird vermutlich genauso lange dauern wie dieses Update jetzt nach glaube 4 Jahren. Ist halt die einzige Seite die ich noch für nen Freund betreue.

Sollte ich mal wieder mehr mit Drupal machen wird das wohl dann mit Composer laufen.

Oh, der Klassiker unter den Drupal-Fehlermeldungen! Keine Sorge, das sieht schlimmer aus, als es ist. Im Grunde sagt dir Drupal gerade: „Du hast mir gesagt, ich soll diese CSS-Datei laden, aber ich kann sie beim besten Willen nicht finden.“

​Was genau passiert hier?

​Die Fehlermeldung Failed to open stream: No such file or directory bedeutet, dass der PHP-Prozess versucht, die Datei sm-core-css.css im Ordner deines Themes zu lesen, diese dort aber nicht existiert.
​Der Stacktrace (die Liste der Zeilen unter der Meldung) zeigt, dass der Fehler beim CssCollectionOptimizer auftritt. Das ist der Teil von Drupal, der deine CSS-Dateien zusammenfasst (Aggregation), um die Ladezeit zu optimieren. Da er die Datei nicht findet, kann er keinen "Hash" (einen digitalen Fingerabdruck) für das Paket erstellen.
​
Mögliche Ursachen & Lösungen

​Hier sind die üblichen Verdächtigen, die du checken solltest:
​Datei fehlt oder Pfad ist falsch:
Prüfe in deinem Theme-Ordner (themes/drupal8_custom_theme/css/), ob die Datei sm-core-css.css wirklich dort liegt. Achte extrem auf die Schreibweise (Case Sensitivity!). SM-core-css.css ist unter Linux nicht dasselbe wie sm-core-css.css.

​Eintrag in der .info.yml:

Hast du die Datei in deiner DEIN_THEME.libraries.yml definiert? Wahrscheinlich steht dort ein Pfad, der nicht (mehr) stimmt.

​Fix: Korrigiere den Pfad in der .libraries.yml oder lösche den Eintrag, falls du die Datei entfernt hast.
​
Veralteter Cache:

Manchmal hast du die Datei gelöscht oder verschoben, aber Drupal „glaubt“ noch, sie sei Teil eines Asset-Pakets.
​
Fix: Leere den Drupal-Cache gründlich. Entweder über das Interface (/admin/config/development/performance) oder via Drush:

drush cr

​Dateiberechtigungen:

Es könnte sein, dass die Datei da ist, aber der Webserver (z. B. Apache oder Nginx) keine Leserechte dafür hat.

​Fix: Stelle sicher, dass die Dateirechte korrekt gesetzt sind (meistens 644 für Dateien).
​
Quick-Tipp für die Fehlersuche

​Wenn du gerade lokal entwickelst, schalte die CSS-Aggregation kurzzeitig aus (/admin/config/development/performance). Wenn die Seite dann ohne Fehlermeldung lädt (nur eben ohne das Styling dieser einen Datei), weißt du sicher, dass es an der Bibliotheks-Definition in deinem Theme liegt.

Wenn du den Fehler ausmachen könntest, sag bescheid. In den meisten Shared-Hosting-Umgebungen kommt sowas zustande, weil die schreibrechte nicht passen. Bzw weil die Besitzrechte nicht mit dem Benutzer auf dem Server übereinstmmen, unter dem PhP ausgeführt wird.

Zur Composer-Thematik: Composer macht nix weiter als für dich all dass runterzuladen, was die Entwickler oder du als Abhängigkeit definiert haben. Beispiel: Du installiert dass Modul Colorbox und brauchst dafür die colorbox.js von GitHub. Dann sagst du Composer: Guck mal hier ist die Quelle für Colerbox.js auf GitHub..Lad bitte die ZIP Datei runter und entpacken sie an der entsprechenden Stelle. All dass, was du also früher mühsam mit FTP einzeln hochgeladen hast lädt der Composer, eine sauber definierte composer.json vorausgesetzt, jetzt für dich herunter. Damit gehen keine Dateien beim Upload per FTP mehr verloren oder kaputt, es geht schneller und es ist auf beliebig vielen Servern wiederholbar. Auch dass Update besucht nur noch einen simplen Befehl. Gibt's neue Updates sieht Composer in die Composer Jason, aktualisiert die einzelnen Versionsnummern deiner Komponenten und orüft für dich, in die jeweils so zusammenpassen, dass Drupal funktioniert. Wenn nicht sagt er dir dass und teilt dir meist sogar mit, warum es nicht geht, wenn dass der Fall ist.

Wichtig: Composer macht auf Shared-Hosting-Plattformrn, die im Grund nur billige Einzimmerwohnung für deine Website sind oft Probleme. So ähnlich wie wenn der Wasserdruck in deiner Dusche nicht stimmt, wenn du gleichzeitig mit dem Nachbarn duschrt.

Deswegen Drupal niemals beim Shared Hoster betreiben, wenn es nicht unbedingt sein muss. Nicht, weil es nicht ginge, sondern weil die Arbeit mit deiner Website sonst keinen Spaß macht.

Du installiert ja auch keine Android-App wie Netflix auf einem Taschenrechner, nur, weil es theoretisch möglich ist. Das ist bäh.

Bei Fragen, einfach wieder hier melden.

Vielen Dank für diese sehr ausführliche Hilfe!
Aktuell kann ich das leider nicht prüfen, aber ich denke mit der Hilfe werde ich es später hoffentlich hinbekommen.

WEIL.... Gestern ging bis auf das Problen die Seite scheinbar fehlerfrei und heute morgen war ich ausgeloggt und sobald ich versuche mich einzuloggen oder das Kontaktformular aufzurufen, kriege ich nen Fehler bezüglich Datenbank.
Der Provider hatte heute Probleme mit dem Server. Ich kläre gleich mal ob die behoben sein sollten.

Gibt es notfalls ne Option sich einzuloggen oder eingeloggt zu sein ohne die Login-Seite zu nutzen?

Ok ich habe die anderen Probleme jetzt gelöst und wende mich diesem Thema mit dem Theme wieder zu.

Die Datei sm-core-css.css liegt nicht im css Ordner, ich kann mich auch nicht erinnern die da jemals gesehen zu haben und auch in meinen alten Installationen lag sie da nie.
In der drupal8_custom_theme.libraries.yml ist sie tatsächlich unter theme: zu finden. Dort stand sie aber auch schon in der alten Version, genauso wie in der aktuellen.

Jetzt wundere ich mich, dass die css nie da war und auch schon immer so definiert war es aber früher unter 9.4 zuletzt einwandfrei funktioniert hat.
Irgendeine Idee?

Bezüglich Composer:
Den hatte ich zwar auf dem Server installiert, weil ich zuerst Schwierigkeiten hatte das Update manuell zu machen, da ich das später aber hinbekommen habe habe ich jetzt die Updates wieder manuell ohne Composer gemacht.

Und die Seite ist halt bei einem Shared Host Betreiber, Kann ich nichts dran machen.

Zwischenzeitlich habe ich versucht ne leere Datei mit dem Namen im Ordner zu erstellen und der Fehler ist weg.
Aber früher ging es ja auch ohne diese Datei und im Originaltheme ist sie ja auch nicht?

Also was ist die Ursache?

Ich sehe ja dein Theme nicht von innen und kann deshalb nur mutmaßen. Aber vielleicht hast du in der alten Version weniger Debug-Infos anzeigen lassen

Grundsätzlich gibt's in so einem Thene eine *. libraries.yml. da stehen alle Dateien drin, die dass Theme zu laden hat. Vereinfacht gesprochen stehen da die Pfade zu allen CSS und YJs-Dateienbdrin, die du bei einer normalen HTML Seite in den head reinschreiben würdest.

Wenn die Datei nicht auf dem System zu finden ist meckert Drupal und sagt dir: Hey, ich soll hier ne Datei laden die nicht da ist, guck mal was da los ist. Die Ursache ist also, dass der Entwickler, der dass Theme geschrieben hat zwar definiert hat, das die Datei zu laden ist, die Datei aber im Finalen Theme nicht angelegt hat. Wenn du die Teile mit der Definition aus der *.libraries.yml nimmst und mit Drush cr den Cache neu baust, dann sollte der Fehler weg ssein.

Naja ich habe nichts an den Einstellungen verändert, fals sich nicht durch die core updates was verändert hat.
Das theme was ich nutze ist dieses Drupal 8 Custom Theme (8, 9 & 10 Version).

Keine Ahnung warum er neuerdings gemault hat. Ich habe zwar das Theme auf die neueste Version upgegraded als ich von 9.4 auf 10.2 gewechselt habe und dann tauchte der fehler erstmals auf bei 10.2 aber wie gesagt in den relevanten Dateien des Themes hat sich nichts geändert diesbezüglich.

SM dachte ich erst könnte Social Media heißen, weil das Theme auch Social Media links einblenden kann (was ich jedoch anders löse) später dachte ich es könnte auch für Smart Menues stehen, weil das glaube ich theoretisch vom Theme auch genutzt werden kann (ich aber auch nicht tue).

Aber letztendlich hat das erstellen einer leeren Datei mit dem Namen das Problem ja behoben.