Beiträge von SniperSister

Zitat von Wichtelmann

die kopierte Seite läuft ja sowohl mit PHO 8.2 als auch 8.3. Dann sollte es die Kopie ja auch.

Die PHP Version mag gleich sein, aber die Konfiguration nicht. Die Meldungen die du da bekommst, verweisen auf Deprecations, also Stellen an denen Joomla Code hat, der in aktuellen PHP-Versionen als veraltet betrachtet wird. Der Quellserver hat vermutlich das error_reporting, also die Fehlerausgabe, so konfiguriert dass dort keine Deprecations ausgegeben werden. Der Zielserver hingegen gibt Deprecations aus.

Ok, dann ist es komplett. Dann fehlt jetzt noch dein erfolgreicher Test in dem Pull Request:

Joomla! Patches testen – Joomla! Documentation

> Ich ändere die Zeile jetzt manuell.
Du hast aber jetzt nicht nur die Zeile 148 verändert, sondern auch die andere Änderung aus dem patch gemacht, oder? Also den implode?

> Muss das jetzt bei jedem manuell eingetragen werden oder wird es im nachsten Update integriert?
Der Prozess ist: Jemand entwickelt einen Patch und mindestens zwei unabhängige Tester prüfen den Patch und geben im issue Tracker Feedback ob es funktioniert. Erst dann kann der Patch im nächsten Update aufgenommen werden.

Aber dann fehlt doch der Patch?!

Das müsste doch so aussehen wie auf der rechten Seite des Screenshots:

Zitat von WM-Loose

Hab jetzt den Debugmodus eingeschaltet und folgendes Ergebnis:

Was steht in der Zeile 148 der libraries/namespacemap.php?

Zitat von raumteiler

Entsteht durch die leeren Einträge ein neues Problem/Nachteil?

Nein, ganz im Gegenteil: für 99,99% der Seiten sollten diese Einträge leer sein. Sie dienen dazu, in Situationen wo die Domain die Joomla "intern" sieht (weil z.B. ein Proxy-Server davorgeschaltet ist) von der Domain abweicht, die der Browser des Benutzers verwendet. Joomla würde ein Cookie nämlich sonst ggf. für die interne Domain erzeugen und damit kann der Browser nichts anfangen. Da diese Proxy-Setups aber sehr, sehr selten sind, braucht kaum jemand diese Config-Einträge.

raumteiler schau mal in deiner configuration.php nach den Einträgen "cookie_domain" und "cookie_path" und setz sie auf einen leeren Wert falls dort konkrete Angaben drin stehen

Dumme Frage: die Änderung aus meinem Patch ist aber schon eingespielt, richtig?

> Offline-Seiten (also Testseiten die sich im Offline-Modus befinden und da Backend zusätzlich noch über Passwort abgesichert ist) dürften davon aber weniger bis gar nicht betroffen sein?

Habe ich nicht ausprobiert, da kann ich keine zuverlässige Aussage zu machen.

WM-Loose auf die Gefahr hin dass ich mich wiederhole: du musst für das Testing des Patches nicht auf das nächste Update warten. Der Fehler tritt unter PHP 8.4 nicht nur bei Updates auf, sondern auch bei Neuinstallationen und leeren des Caches, quasi immer wenn die autoload_psr4.php gelöscht wird -das ist das Grundproblem und lässt sich daher auch problemlos nachstellen.

Zitat von WM-Loose

Gerade gemacht und wieder auf php8.4 umgestellt. Beim nächsten Update wird sich rausstellen, ob dies schon die Ursache war. Ich lass den Thread dann doch noch offen.

Du musst da nicht auf ein Update warten, nur das machen was im Patch als Test-Instruktionen hinterlegt ist.

WM-Loose teste den patch gerne, dann sind wir schonmal einen Schritt näher am merge. Ist dann "nur" im 5.x Branch, aber mit Blick auf weitere Inkompatibilitäten von 4.x mit PHP 8.4 macht eine Integration des Patches in 5.x ohnehin mehr Sinn.

Siehe

[5.2] Fix namespace map creation on PHP 8.4 by SniperSister · Pull Request #44789 · joomla/joomla-cms

Summary of Changes The creation of the namespace map file fails on PHP 8.4 as the content is implicitly provided to File::write as reference, causing this…

github.com

Zur Fragestellung: Joomla bietet von Haus aus keine verschleierung von Handynummern; die Bandbreite in der Darstellung ist da auch wesentlich größer, deswegen ist eine automatische Erkennung schwieriger

Heart1010 ich habe einen Post in einen eigenen Thread verschoben, dein Anliegen hat mit dem Originalthread nichts zutun.

haegar Check mal die Version des deutschen Sprachpakets. Du hast da vermutlich noch die alte Version aus der 3.x Zeit installiert, da machte die Meldung in der Form Sinn. In der 4.x Version ist die Nachricht dann anders.

Zitat von WM-Loose

Selbst eine Update-Installation des Sourcerer bringt den Fehler:

Und wie sieht die Meldung aus, wenn der debug Modus an ist? Das sollte die entscheidende Info zur Lösung sein.

Für den Sourcerer gibt es ein kritisches Sicherheitsupdate für eine Lücke, die aktiv ausgenutzt wird. Schnellstens Updaten und prüfen ob die Seiten, bei denen das Plugin bereits installiert war, nicht befallen sind:

Zitat von Stef

Der Moderator oder die Moderatorin hätte es lieber direkt unter "Framework" verschoben als unter Erweiterung.

Done. Warum der Ursprungsthread dann unter "Erweiterungen" steht hinterfrag ich mal nicht.

Zum Thema "verschieben in eigenen Thread": Das war bewusst. Der Ursprungsthread ist mit inzwischen über 120 Posts ein endloser Bandwurm geworden und somit für Dritte, die vielleicht nach Lösung für ein ähnliches Problem suchen, nicht mehr zu durchschauen. Ein eigener Thread mit sprechendem Namen ist da die bessere Variante.

Hast du über die kornkete Meldung hinaus noch weitere Infos? Insbesondere einen Callstack, also die Infos zum kontext die bei aktiviertem Debugmodus angegeben werden?