Beiträge von Arnulf

Mit Hilfe von KI erstellt...

Hallo Peter,

deine Interpretation der Fehlermeldung ist ein verbreitetes Missverständnis, aber die Datei fehlt nicht. Die Angaben file und trace bei einer PHP-Exception zeigen immer die Stelle im Code, an der der Fehler ausgelöst bzw. abgefangen wurde, das ist völlig normal und unabhängig davon, worum es inhaltlich geht. Die eigentliche Fehlermeldung steckt in #message: "No such file or directory" zusammen mit #code: 2002, und das ist ein sehr bekannter, klassischer MySQL-Verbindungsfehler, kein PHP-Dateisystemproblem.

Fehlercode 2002 bedeutet konkret: "Kann keine Verbindung zum lokalen MySQL-Server über den Socket herstellen." Das passiert, wenn deine configuration.php als Datenbank-Host localhost einträgt, denn bei "localhost" verwenden MySQL-Clients standardmäßig eine Unix-Socket-Datei statt einer normalen Netzwerkverbindung, und der Pfad zu dieser Socket-Datei steckt in der jeweiligen php.ini.

Der entscheidende Punkt bei dir: Der PHP-Prozess, der deine Website über den Webserver ausliefert, und der PHP-Interpreter, den du per SSH über die Kommandozeile aufrufst, nutzen häufig zwei unterschiedliche php.ini-Dateien, mit unterschiedlich konfiguriertem oder ganz fehlendem Socket-Pfad. Das erklärt, warum die Seite im Browser normal läuft, das CLI aber genau diesen Fehler wirft.

Die gängige, meist zuverlässigste Lösung: Trag in deiner configuration.php statt $host = 'localhost'; stattdessen $host = '127.0.0.1'; ein. Das erzwingt eine normale TCP/IP-Verbindung anstelle des Sockets und umgeht damit das ganze Problem unterschiedlicher Socket-Pfade. Das solltest du vorsichtshalber erst auf einer Kopie oder nach einem Backup testen, auch wenn diese Änderung in aller Regel unproblematisch ist.

Falls 127.0.0.1 aus irgendeinem Grund bei dir nicht funktioniert oder gesperrt ist, wäre die Alternative, deinen Hoster (Metanet.ch) nach dem korrekten MySQL-Socket-Pfad für die CLI-PHP-Umgebung zu fragen und diesen explizit in der CLI-php.ini unter mysqli.default_socket einzutragen.

Mit Hilfe von KI erstellt.

Hallo HoSe,

das erklärt sich, warum du in der edit.php nicht fündig wirst: Die Passkey-Tabelle gehört gar nicht zum regulären Fieldset-Mechanismus von com_users. Sie wird von einem eigenständigen Systemplugin erzeugt und eingebunden, dem "System - Passkey (Passwordless) Login" Plugin (früher als "WebAuthn Passwordless Login" bezeichnet, seit der Umbenennung in Richtung des inzwischen gebräuchlicheren Begriffs "Passkey"). Das Plugin klinkt sich separat in die Profilseite ein und bringt sein eigenes Layout-Template mit, unabhängig von den Feldsets, die edit.php aus deinem Code durchläuft.

Für Layouts, die von Plugins auf diese Weise eingebunden werden, funktioniert der Override-Mechanismus etwas anders als bei Komponenten-Templates: Du kopierst die Layout-Datei nicht in einen Komponenten-Override-Ordner, sondern in den generischen Layout-Override-Pfad deines Templates, nach dem Schema:

templates/<dein-template>/html/layouts/plg_system_webauthn/<layoutname>.php

Um den exakten Ursprungspfad und Dateinamen zu finden, schau am besten direkt im Ordner plugins/system/webauthn/ (bzw. plugins/passkey/ je nachdem, wie das Plugin bei dir intern noch heißt) nach einem Unterordner layouts oder tmpl. Die dort liegende Datei ist die, die du kopierst und dann in deinem Template anpasst.

Poste gerne den genauen Ordnernamen, den du dort findest, dann lässt sich der exakte Zielpfad für den Override bestätigen.

Mit Hilfe von KI erstellt...

Hallo crazy-to-bike,

das erklärt sich technisch ziemlich klar: Das Icon bei .uk-divider-icon wird nicht über color eingefärbt, sondern als background-image mit einer fest eingebetteten SVG-Grafik dargestellt. Eine CSS-Variable wie --uk-divider-icon-color funktioniert nur, wenn UIkit direkt aus dem SCSS-Quellcode neu kompiliert wird und diese Variable dabei in die generierte SVG einfließt. Im fertigen, kompilierten CSS ist diese Verknüpfung meist gar nicht mehr vorhanden, die Farbe steckt dann fest codiert in der URL-kodierten SVG selbst, weshalb dein Override wirkungslos verpufft.

Um das zu prüfen: Öffne die Entwicklertools, klick auf das Icon in der Mitte des Dividers, und schau im Reiter "Berechnet" (Computed) nach dem tatsächlichen Wert von background-image. Dort solltest du eine lange data:image/svg+xml...-Zeichenkette mit einem eingebetteten Hex- oder RGB-Farbwert finden.

Zwei Wege, das trotzdem zu ändern:

1. Eigene SVG als Ersatz: Überschreib background-image komplett mit deiner eigenen, passend eingefärbten SVG-Grafik:

[data-bs-theme="light"] .uk-divider-icon::before {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='20' height='20'%3E%3Ccircle cx='10' cy='10' r='4' fill='%23212529'/%3E%3C/svg%3E") !important;
}

(Form und Größe des Icons musst du an dein Original anpassen, das ist nur ein Platzhalter-Kreis.)

1. Prüfen, ob currentColor genutzt wird: Falls im gefundenen SVG-Code fill='currentColor' steht statt eines festen Hex-Werts, reicht es, statt der Custom-Property einfach die normale color-Eigenschaft zu setzen:

[data-bs-theme="light"] .uk-divider-icon {
  color: #212529 !important;
}

Poste am besten den gefundenen background-image-Wert aus den Entwicklertools hier, dann lässt sich genau sagen, welcher der beiden Wege bei dir greift.

Zitat

Diese Antwort wurde mithilfe von KI erstellt.

Hallo,

dein bisheriger Code trifft eigentlich gar nicht die einzelnen Streifen, sondern die komplette Tabelle als Hintergrund, das erklärt auch, warum es zufällig wie "jeder 2. Streifen" aussieht.

Laut UIkit-Quellcode gilt für uk-table-striped nämlich nur diese eine Regel:

css

.uk-table-striped tbody tr:nth-of-type(odd) {
  background: /* Streifenfarbe */;
}

UIkit färbt also grundsätzlich nur die ungeraden Zeilen ein, die geraden Zeilen bekommen von Haus aus überhaupt keinen eigenen Hintergrund, sie bleiben schlicht transparent. Dein Code .uk-overflow-auto > :last-child zielt auf das letzte Kind-Element des Wrapper-Divs, in der Praxis also auf die komplette Tabelle. Da die ungeraden Zeilen aber bereits von UIkit blickdicht eingefärbt sind, wird dieser Tabellen-Hintergrund nur dort sichtbar, wo UIkit selbst nichts hingemalt hat, nämlich bei den geraden Zeilen.

Die sauberere, direkte Lösung ist, die geraden Zeilen genauso gezielt anzusprechen wie UIkit es bei den ungeraden tut:

css

/* Gerade Streifen im Dark Mode */
[data-bs-theme="dark"] .uk-table-striped tbody tr:nth-of-type(even) {
  background: rgba(33, 37, 41, 0.2) !important; /* Wert nach Wunsch anpassen */
}

/* Gerade Streifen im Light Mode */
.uk-table-striped tbody tr:nth-of-type(even) {
  background: rgba(0, 0, 0, 0.05) !important; /* Wert nach Wunsch anpassen */
}

Die konkreten rgba-Werte kannst du natürlich frei anpassen, wichtig ist nur nth-of-type(even) statt odd, das ist das Gegenstück zu UIkits eigener Regel.

Antwort mithilfe von KI erstellt.

Jetzt seh ich das Problem: Das ist gar kein Bootstrap-Dropdown, sondern die MetisMenu-Bibliothek (erkennbar an mm-collapse, mm-show), die für das Layout "Collapsible Dropdown" zum Einsatz kommt. Meine vorherige Regel mit .dropdown-menu/.dropdown-item zielte damit ins Leere, das war der falsche Klassenname für dieses Layout, sorry dafür.

Mit den Klassen aus deinem Screenshot sollte das jetzt greifen:

css

.footer li.metismenu-item.level-2 {
    background-color: #a63232;
}

.footer li.metismenu-item.level-2 a {
    color: #ffffff;
}

.footer li.metismenu-item.level-2 a:hover,
.footer li.metismenu-item.level-2 a:focus {
    color: #ffffff;
    background-color: #8a2727;
}

Falls das immer noch nicht greift: Klick in den Entwickler-Werkzeugen statt auf "Layout" auf den Reiter "Berechnet" (Computed) und such dort gezielt nach background-color. Dort steht dann auch die genaue Quelldatei und Zeile, aus der die aktuelle Blau-Färbung tatsächlich kommt, das zeigt uns, welche Regel wir noch überstimmen müssen.

Danke Rolf für die Korrektur, das war tatsächlich noch der alte Pfad aus der J3-Zeit, seit J4 liegt das Verzeichnis wie du schreibst unter media/templates/site/.

Dani74, gut zu sehen, dass die Datei laut Quelltext korrekt eingebunden wird, das Ladeproblem ist damit ausgeschlossen. Dann bleibt tatsächlich die Spezifität übrig, und Stefs Klasse .metismenu-item.item-300.level-2 ist ein guter Ansatzpunkt. Probier mal diese kombinierte Regel:

css

.footer .metismenu-item.level-2 {
    background-color: #a63232;
}

.footer .metismenu-item.level-2 a {
    color: #ffffff;
}

.footer .metismenu-item.level-2 a:hover,
.footer .metismenu-item.level-2 a:focus {
    color: #ffffff;
    background-color: #8a2727;
}

Ich hab die item-300 bewusst rausgelassen, die ist vermutlich nur die zufällige ID deines konkreten Menüpunkts und würde die Regel unnötig auf genau diesen einen Eintrag einschränken, während level-2 alle Dropdown-Einträge gleichermassen erfasst.

Hallo Dani74

Mit dem Bild ist klar, was du meinst: Footer und Hauptlinks sind bereits rot bzw. weiss, nur das aufgeklappte Dropdown unter "Member+" ist noch dunkelblau mit kaum lesbarer Schrift. Genau diese Fläche und deren Text willst du auf rot mit weisser Schrift bringen.

Versuch dafür mal folgende Regel in deiner user.css:

css

.footer .dropdown-menu {
    background-color: #a63232; /* dein Footer-Rot */
}

.footer .dropdown-menu .dropdown-item {
    color: #ffffff;
    background-color: transparent;
}

.footer .dropdown-menu .dropdown-item:hover,
.footer .dropdown-menu .dropdown-item:focus {
    color: #ffffff;
    background-color: #8a2727; /* etwas dunkleres Rot für den Hover */
}

Den Rot-Wert #a63232 ersetzt du am besten durch genau den, den du auch für den restlichen Footer nutzt, dann wirkt es einheitlich.

Wenn sich damit nichts ändert, sind zwei Ursachen am wahrscheinlichsten:

Erstens, die user.css wird gar nicht geladen. Das testest du schnell, indem du testweise body { border-top: 5px solid lime; } einträgst. Kommt kein grüner Streifen, wird die Datei nicht eingebunden, dann stimmt der Pfad im Child-Template nicht (sie sollte unter templates/cassiopeia_socialplus/css/user.css liegen).

Zweitens, die Spezifität reicht nicht, weil Bootstrap die Farbe spezifischer setzt. Dann brauchst du den genauen Selektor: F12 drücken, mit dem Auswahl-Pfeil oben links direkt auf die blaue Fläche klicken, und rechts ablesen, welche Klasse dort die background-color vergibt. Poste den Selektor hier, dann bauen wir dir die Regel punktgenau.

Kann ich gut nachvollziehen, und ich würde es an deiner Stelle vermutlich genauso machen. Google räumt die alten Adressen mit der Zeit selbst aus dem Index, spätestens nach ein paar Monaten hat sich das erledigt. Bei einer Seite ohne kommerziellen Druck steht der Aufwand wirklich in keinem Verhältnis.

Aggressive Bots lassen sich von einer robots.txt nicht aufhalten. Die ist eine reine Höflichkeitsvereinbarung ohne technische Durchsetzung. Seriöse Crawler halten sich daran, aggressive Scraper ignorieren sie einfach. Wirklich aussperren lässt sich das nur serverseitig, etwa über Regeln in der .htaccess anhand des User-Agents, über eine Ratenbegrenzung oder über einen vorgeschalteten Dienst wie Cloudflare. Ob und was davon bei UD-Media möglich ist, könntest du dort mal anfragen.

Zu den alten Links: Da hilft dir die Google Search Console am meisten. Unter "Seiten" beziehungsweise im 404-Bericht siehst du genau die alten Adressen, die Google noch im Index hat und die jetzt ins Leere laufen. Das sind exakt die, für die sich eine Weiterleitung lohnt, alles andere kannst du getrost ignorieren. Falls du irgendwo noch ein Backup der alten Seite oder eine alte sitemap.xml hast, wäre das eine zweite gute Quelle.

Und ein pragmatischer Zwischenweg: Du kannst das Sammeln auch einfach anlassen und die Liste gelegentlich nach der Anzahl der Aufrufe sortieren. Echte alte Adressen werden immer wieder aufgerufen, das Bot-Rauschen dagegen meist nur ein einziges Mal pro Kombination. Damit hast du die relevanten Kandidaten recht schnell oben stehen.

Dein Einwand ist berechtigt, bei dem Verhältnis ist das wirklich kein Rauschen mehr. Diese Größenordnung ist derzeit leider typisch, viele kleinere Seiten werden gerade von Scrapern und KI-Crawlern regelrecht abgegrast.

Zwei Möglichkeiten, falls es dich doch mal nervt: Du kannst im Weiterleitungs-Plugin das automatische Sammeln abschalten und die Weiterleitungen, die du wirklich brauchst, von Hand anlegen. Die Komponente funktioniert dann ganz normal weiter, sie füllt sich nur nicht mehr selbst mit Müll. Und die bekannten Crawler lassen sich zusätzlich über die robots.txt oder serverseitig aussperren, das reduziert die Flut spürbar.

Danke für die Rückmeldung, dann liegt es für "Kräuter sammeln" tatsächlich nicht an der Menüzuordnung, da hatte ich danebengelegen.

Falls es dich doch nochmal interessiert: In der Weiterleitungs-Komponente gibt es zu jedem Eintrag die verweisende Seite (Referrer). Die klärt die Frage endgültig. Ist die leer, kommen die Aufrufe direkt von Bots und Crawlern, die einfach Pfade durchprobieren, dann ist es reines Rauschen und nichts, was du abstellen kannst. Steht dort dagegen eine deiner eigenen Seiten, erzeugt die Seite die Links selbst, und dann lohnt sich die Suche nach fehlerhaften relativen Links doch.

Aber wie gesagt: Wenn dich das ohnehin nicht weiter stört, kannst du es getrost so lassen.

Meine erste Vermutung mit den relativen Links muss ich zurücknehmen, die passt nicht zu deinen Beispielen. Die Erklärung ist harmloser, als du denkst.

Joomla baut SEF-URLs nicht aus der Kategorie des Artikels zusammen, sondern aus dem Menüpunkt, über den der Artikel aufgerufen wird. Ein Artikel "Kräuter sammeln", der auf der alten Seite über den Menüpunkt "Künstler > Künstler-Blog" ausgegeben wurde, bekommt dadurch die URL /kuenstler/kuenstler-blog/kraeuter-sammeln.html, völlig unabhängig davon, in welcher Kategorie er tatsächlich lag. Dass die beiden Kategorien nie etwas miteinander zu tun hatten, ist also kein Widerspruch, sondern normales Joomla-Routing.

Das .html am Ende bestätigt das zusätzlich: Das kommt von der alten Einstellung "URL-Suffix hinzufügen", die deine neue Installation vermutlich nicht mehr verwendet.

Diese Adressen haben also sehr wohl existiert, nämlich auf deiner alten Seite. Was du im Protokoll siehst, sind Suchmaschinen, Lesezeichen und externe Verlinkungen, die diese alten URLs weiterhin aufrufen. Die Komponente macht also genau das, wofür du sie aktiviert hast. Dass sich das bei einem kompletten Neuaufbau hundertfach fortsetzt, ist völlig normal.

Hallo Manfred,

das lässt sich gut erklären, und es ist tatsächlich ein bekanntes Muster: Wenn irgendwo auf deiner Seite ein Link ohne führenden Schrägstrich steht, also relativ statt absolut, hängt der Browser diesen Pfad einfach an die aktuelle Seiten-URL an, egal von wo aus man klickt. Aus zwei völlig unabhängigen, aber jeweils real existierenden Pfadteilen entsteht so eine Kombination, die als eigenständige Adresse nie existiert hat, das passt genau zu deiner Beobachtung.

Da du die Seite gerade komplett neu aufgebaut hast, tippe ich auf Reste von relativen Links, die noch irgendwo drinstecken, zum Beispiel in kopierten Artikelinhalten, einem Custom-HTML-Modul oder einem alten Template-Bestandteil.

Kannst du mal eine oder zwei dieser unsinnigen Kombinationen aus deinem Redirect-Protokoll hier posten? Dann lässt sich meist ziemlich genau sehen, aus welchen beiden realen Seiten sich die zusammensetzen, und darüber findet man dann auch die Stelle, an der der fehlerhafte relative Link tatsächlich steht.

Hallo BBd_Muc,

gut, dass die Endebene schon passte, dann ist es noch einfacher: Es gibt im selben Modul einen weiteren, separaten Parameter namens "Untermenüeinträge anzeigen" mit den Optionen "Anzeigen" und "Verbergen". Laut offizieller Joomla-Doku bewirkt der genau das, was du suchst: "Das Menü erweitern und seine Untermenüpunkte immer anzeigen lassen", also die dauerhaft ausgeklappte Darstellung ohne Klick-Interaktion.

Schau im selben Modul, Reiter "Erweitert", nach diesem Feld und stell es auf "Anzeigen". Das sollte dir wieder das alte, immer vollständig ausgeklappte Verhalten zurückbringen, ganz ohne die neue Klapp-Funktion.

Hallo BBd_Muc,

das klingt nach einer reinen Darstellungsfrage im Menümodul, nicht nach einem strukturellen Problem, zumal die Daten selbst ja intakt sind (Backend zeigt alles korrekt, Artikel sind per direkter URL erreichbar).

Der häufigste Grund für genau dieses Symptom, nur noch 1. Ebene sichtbar nach einem Update, ist die Einstellung "Endebene" im jeweiligen Menü-Modul. Schau bitte unter Inhalte > Site-Module (oder Erweiterungen > Module) nach dem Modul, das dieses Menü ausgibt, öffne es, und geh in den Reiter "Erweitert". Dort findest du "Anfangsebene" und "Endebene". Steht die Endebene auf "1" statt auf "Alle" (bzw. einer höheren Zahl), werden tieferliegende Menüpunkte grundsätzlich nicht mehr ausgegeben, unabhängig davon, ob sie im Backend sichtbar und freigeschaltet sind.

Falls das schon auf "Alle" steht und trotzdem nur eine Ebene erscheint: Dann würde mich interessieren, ob im Seitenquelltext die zweite Ebene überhaupt vorhanden ist, nur eben unsichtbar (zum Beispiel durch CSS oder eine kaputte Dropdown-Funktion), oder ob sie im HTML komplett fehlt. Das würde die Fehlersuche weiter eingrenzen, je nachdem ob es ein reines CSS/JavaScript-Problem des Templates ist oder tatsächlich am Modul selbst liegt.

Zu deinem KI-Hinweis mit der fehlenden com_joomlaupdate: Das würde ich getrost ignorieren, die Komponente ist für Kern-Updates zuständig und hat mit der Menüdarstellung nichts zu tun.

Hallo Chris,

das ist ein bereits bekannter, offiziell bestätigter Regressionsfehler im Joomla-Kern (Issue 48058), ausgelöst durch das Update auf 5.4.7. Er sorgt dafür, dass individuelle Artikel-Einstellungen, wie bei dir die pro Beitrag abweichend aktivierte Kategorie- und Autor-Anzeige, nicht mehr berücksichtigt werden, nur noch die globale Voreinstellung greift.

Ein offizieller Hotfix ist bereits verfügbar: https://www.joomla.org/announcements/…ix-release.html. Die eigentliche Behebung kommt regulär mit 5.4.8.

Hallo joesto,

danke für die Klärung, Frontend-Login funktioniert, Backend nicht, das ist die entscheidende Erkenntnis. Damit können wir Passwort, Hash und Authentifizierungs-Plugin als Ursache ausschließen, die würden ja auch das Frontend betreffen.

Das bestätigt kitepascals Vermutung von vorhin: Vor /administrator liegt bei dir zusätzlich eine .htaccess/.htpasswd Absicherung, komplett unabhängig von der Joomla-Datenbank und dem Joomla-User-System. Diese Sperre fragt schon ab, bevor die eigentliche Joomla-Login-Seite überhaupt geladen wird, und genau das erklärt, warum Frontend und Backend sich unterschiedlich verhalten, obwohl beide auf dieselbe Nutzerdatenbank zugreifen.

Kommt bei dir vor der Backend-Login-Seite ein separates Browser-Popup-Fenster mit Benutzername und Passwort? Falls ja, liegen die Zugangsdaten dafür nicht in der Datenbank, sondern in einer .htpasswd Datei direkt auf dem Server, die du per FTP einsehen oder zurücksetzen kannst.

Elwoods Rat ist der richtige erste Schritt, dem würde ich nichts hinzufügen wollen. Nur zur Einordnung, warum es so gekracht hat: Beide Fehlermeldungen sind typische Folgen eines Joomla-3-Templates, das mit dem Framework-Umbau in Joomla 4 nicht kompatibel ist, in Joomla 4 wurden zahlreiche früher frei zugängliche Eigenschaften und Methoden umgebaut, altes Template-Code, der noch auf die alte Struktur zugreift, bricht dann mit genau solchen Fehlern.

Bevor du nach dem Zurückspielen des Backups einen zweiten Anlauf startest, würde ich dir empfehlen, vorher bei JoomShaper zu prüfen, ob es für dein konkretes Template eine für Joomla 4 oder gleich 5 freigegebene Version gibt, und diese sowie alle anderen Erweiterungen zu aktualisieren, bevor du den eigentlichen Kern-Update-Schritt nochmal versuchst. Am besten wie von Elwood vorgeschlagen erst lokal, dann erst auf der Live-Seite.

Hallo joesto,

falls du über phpMyAdmin gehst: Öffne die Tabelle #__extensions, suche dort nach der Zeile mit element = joomla und folder = authentication (am einfachsten über die Suchfunktion oder ein kurzes SELECT). In der Spalte enabled sollte eine 1 stehen. Steht dort eine 0, ist genau das dein Problem, dann einfach auf 1 ändern und speichern.

Per SQL-Abfrage ginge das auch direkt so:

SELECT * FROM `xxxxx_extensions` WHERE `element` = 'joomla' AND `folder` = 'authentication';

(dein tatsächliches Tabellenpräfix statt xxxxx_ einsetzen)

Hallo joesto,

dass selbst der frisch angelegte User mit nachweislich korrektem Bcrypt-Hash nicht reinkommt, ist ein wichtiger Hinweis: Das Problem liegt dann sehr wahrscheinlich nicht am Passwort selbst, sondern an der Authentifizierung auf Systemebene, was angesichts des vorausgegangenen Hacks natürlich aufhorchen lässt.

Schau bitte als Erstes hier nach:

1. Geh zu Erweiterungen > Plugins, filtere nach "Authentication", und prüfe, ob das Plugin "Authentication - Joomla" aktiviert ist. Ist es deaktiviert, kann sich niemand mehr anmelden, egal wie korrekt das Passwort ist, und zwar genau ohne sichtbare Fehlermeldung.
2. Schau dir in der Datenbank die Zeile deines neuen Test-Users in #__users nochmal genau an, insbesondere die Spalten block und requireReset. Die sollten beide auf 0 stehen. Falls block auf 1 steht, ist der Account gesperrt.
3. Ein Blick in administrator/logs kann auch helfen, manchmal werden fehlgeschlagene Login-Versuche dort protokolliert, auch wenn im Frontend keine Meldung erscheint.

Zu Methode 2 aus der alten Anleitung: Du hast völlig recht, das war die alte MD5-Vorgehensweise, die heute nicht mehr passt.

Da das Ganze nach einem Hack und einer Backup-Wiederherstellung auftritt, würde ich das jetzt auch nicht mehr rein als Login-Problem behandeln, sondern im Hinterkopf behalten, dass hier eventuell noch mehr im Argen liegt, als nur das Login selbst.