Die Entwickler haben ein update zur Verfügung gestellt. Problem gelöst - vielen Dank an alle Beteiligten!
Beiträge von deevau
-
-
Dann wirst wohl die Entwickler fragen müssen, weil eine Pro-Erweiterung.
ist gemacht, werde das Ergebnis hier melden...
-
-
-
da sehe ich dann folgenden in Call stack:
Code
Alles anzeigen121: * 122: * @return string The translated humanly readable URL. 123: * 124: * @throws \RuntimeException 125: * 126: * @since 3.9.0 127: */ 128: public static function link($client, $url, $xhtml = true, $tls = self::TLS_IGNORE, $absolute = false) 129: { 130: // If we cannot process this $url exit early. 131: if (!\is_array($url) && (strpos($url, '&') !== 0) && (strpos($url, 'index.php') !== 0)) { 132: return $url; 133: } 134: 135: // Get the router instance, only attempt when a client name is given.Programmcodes sind für mich aber im Großen und Ganzen böhmische Dörfer... diese Website ist in einem Unterverzeichnis einer anderen Website da ich damals dort die Migration von 3 auf 4 getestet habe, aber ich denke nicht, dass das ursächlich ist...
-
d.h., die Fehlermeldung wird innerhalb der Seite, die komplett, mit allen Inhalten und Modulen geladen wird, angezeigt.
Alles anzeigenDeprecated-/Notice-/Warning-Meldungen werden vom Joomla-Debug-Modus nicht weiter aufgearbeitet. ALso auch kein CallStack.
Das ginge mit dem n3t-Debug-Plugin, das dann einen Backtrace anzeigt, wenn entsprechend konfiguriert. Da sähe man dann auch, ob ggf. eine zuinstallierte Erweiterung oder ein Override oder ... den Joomla-Core-Router "falsch beliefert".
Aaaber, schalte zuvor den Joomla-Debug-Modus aus, weil der auch Fehlerchen hat, aber weiß nicht mehr, ob das nur JavaScript betrifft.
Oder schaltest halt "Fehler berichten" aus im Joomla.
Ich habe das plugin jetzt mal installiert und wie hier konfiguriert
es werden 3792 Fehler angezeigt. Suche ich nach "131" finde ich
2x
PHP Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in .../joo3-joo4/libraries/src/Router/Route.php:131
Wenn dieses plugin aktiv ist verschwindet die Fehlermeldung welche sonst unter dem head angezeigt wurde...
Aber wie kann ich den Fehler nun beseitigen? Da die Seite prinzipiell funktioniert kann ich natürlich "Fehler berichten" auf "Standard" setzen... So ganz wohl fühle ich mich dabei aber nicht...
-
es wird kein CallStack angezeigt, die Seite lädt ja auch, allerdings mit besagter Fehlermeldung
Deprecated
: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in
/pfad/joo3-joo4/libraries/src/Router/Route.php
on line
131
-
habe ich gemacht aber in welchem der Tabs soll der Fehler zu finden sein? In Request?
-
was genau soll da den gemacht werden?
Presume you are on the latest version 4.3.4 Enable Debug and get the Stack Trace. The error is with the extension that passes data to this Library.
-
habe hier noch was gefunden, hilft mir aber nicht weiter... welche Erweiterung ist da genau gemeint?
-
Hallo allerseits,
in der Kopie einer website habe ich nun mal php 8.1 aktiviert und bei Fehlermeldung Maximum erscheint im frontend 2 Mal untereinander folgendes:
Deprecated
: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in
/pfad/joo3-joo4/libraries/src/Router/Route.php
on line
131
Hat jemand da Infos wie ich das Problem lösen kann?
Viele Grüße
-
Der support bei crosstec ist laut Info andere Nutzer wohl seit Monaten offline. Dann sehe ich mich nach einer anderen Komponente um... schade eigentlich.
-
Ich erhalte nur eine 404er:
Ja, wie beschrieben. Bei der genannten Installation und anderen joomla 4 mit dem captcha von breeziong forms ist das so. Anders als bei joomla 3. Dort geht es. Aber was mag der Grund dafür sein?
-
Hallo allerseits!
Mir fiel kürzlich auf, dass bei den joomla 4 Seiten das captcha nicht mehr angezeigt wird. Die einzige Änderung in letzter Zeit war das update von joomla 4.3.2 auf 4.3.3 und auf 4.3.4. Ob es wohl daran liegen könnte?
Laut crosstec können Akeeba Admin Tools (habe ich nicht im Einsatz) die Ursache sein. Der häufigste Fehler ist aber das Fehlen von "True Type Font" (TTF) unterstützung mit Ihrer PHP Installation. TTF ist aber aktiv.
Wenn ich bei einer funktionierenden joomla 3 Installation den Pfads aufrufe wird das Captcha angezeigt, bei der Testinstallation bekomme ich ein 404 siehe https://www.treffpunkt-nachhal…ptcha/securimage_show.php
Das Formular liegt hier: https://www.treffpunkt-nachhaltigkeit.de/testformular
Mir fiel auch auf, dass sich die Ordnergrößen bei joomla 3 und 4 unterscheiden.
joomla 3
joomla 4
Hat jemand eine Idee?
Viele Grüße
-
Mir fiel gerade auf, dass der Manager selbst angelegte Kontakte (Komponente: Administrationszugriff erlaubt) ändern kann, fremde Kontakte 404-Fehler...
-
Hallo allerseits,
eine Manager hat alle Berechtigung für die Kontaktkomponente erhalten, bekommt aber beim speichern einen 404-Fehler im Backend. Beim superadmin kommt das Problem nicht,
Wenn die Standardrechte für den Manager aktiv sind ist im Backend kein Link zu den Kontakten.
Was mache ich wohl falsch???
Viele Grüße
-
Das ist in der Tat so. Lässt sich in CloudPit auch nicht deaktivieren, soweit ich mich erinnere ohne nachzuschauen.
Das hast du ja aber bereits in deinem ersten Post geschrieben.
Möglicherweise gibt es noch eine Deaktivierungsmöglichkeit über .htaccess?!? Habe ich nie überprüft, da nicht nötig. Wie gesagt, im Fall des Falles unten den Block als Kommentar setzen.
Oder halt mal einen Link angeben zum Analysieren!
Es ist tatsächlich so, dass die Seiten auf dem Server bei alfahosting grundsätzlich komprimiert werden. Das gleichzeitige Aktivieren von gzip in der joomla-Konfiguration ist dann also eher sinnlos und kann im manchen Fällen sogar zu Problemen (SobiPro, Easy Services Booking) führen. Mir wäre es lieber ich könnte selbst entscheiden bzw. steuern ob meine Website komprimiert wird oder nicht.
Danke an alle für die Unterstützung!
-
Beachte folgendes:
Wenn du GZIP in der Joomla-Konfiguration auf "ja" stellst, wird die generierte HTML-Seite komprimiert. JavaScript, CSS, Bilder etc. hingegen werden nicht komprimiert.
Guten Morgen!
Uund wenn ich GZIP auf "nein" stelle wird nichts komprimiert aber der Test sagt ja etwas anderes. Ich vermute, dass der Provider alle Seiten auf dem Server grundsätzlich komprimiert aber es so nicht kommuniziert hat. Ich frage da jetzt nochmal nach und bitte um eine Erklärung.
-
Werde ich morgen mal ausprobieren... hier hatte jemand ein ähnliches Problem, die Lösung wurde aber verschwiegen.
-
Es wäre hilfreich zu wissen, um welche Buchungskomponente es geht.
Dann kann man auch weitere Schlüsse ziehen.
Die Buchungskomponente Easy Services Booking funktioniert ja wenn ich gzip in der joomla Konfiguration abschalte. Das seltsame ist jedoch, dass auch bei abgeschaltetem gzip die Seite komprimiert wird (also bei aktivem gzip in Konfiguration quasi doppelt komprimiert) und dadurch wohl das Problem bei der Buchungskomponente entsteht... Die Kernfrage ist also: Wieso wird die Seite komprimiert obwohl gzip in der Konfiguration deaktiviert ist?
Es gibt wohl ein “double gzip” problem after J! 4.2.9 was hier ausführlicher beschrieben wird: https://kuneze.com/blog/110-joomla-double-gzip-problems ist für mich so jetzt nicht allerdings nicht mehr nachvollziehbar Zitat:In any case, the admission by the J! project team of a problem that took over a year-and-a-half to address notwithstanding, the J! 4 “double gzip” problem will be around for a while longer.
