Beiträge von bembelimen

Und wenn möglich, sollte man die "public folder" Funktion von Joomla! verwenden:

[5.0] Allow Joomla be served from a public* folder by dgrammatiko · Pull Request #40509 · joomla/joomla-cms

Pull Request for Issue # . public folder == subfolder of the root installation (but not restricted to only this config) that has only the allowed entry points…

github.com

[5.0] Introduce a CLI UI for creating a public folder by dgrammatiko · Pull Request #41446 · joomla/joomla-cms

Pull Request for Issue # . Summary of Changes Added 1 new command on the main joomla.php CLI: site site:create-public-folder Create a public folder…

github.com

(Oder den Zugriff auf allgemeine PHP Dateien auch im Frontend unterbinden)

Zitat von svenyeng

Doch von Joomla. Derzeit gefühlt bald alle 2 Wochen.

Das sind aber eher Gefühlte Wahrheiten: https://downloads.joomla.org/cms/joomla5

5.1.3 => 5.1.4 war ein kurzer Zeitraum, aber sonst?

Zitat von WM-Loose

Mach bitte das Update auf Joomla 5.2.1

Berichte dann ob das Problem immer noch besteht.

Im ernst....?

Zitat von Sieger66

Übrigens wurde der Fehler wohl damit:

github.com/joomla/joomla-cms/pull/43829

in Joomla 5.2.0 eingebaut.

Nö, den Bug gabs schon vorher, es gab nur kein Szenario was ihn sichtbar gemacht hat.

Bei Entwicklungsversionen muss der Ordner nicht gelöscht werden, Joomla! funktioniert auch mit Ordner.

Es gibt da mehrere Möglichkeiten:

• Du könntest eine PHP Datei als CSS einbinden, die dann onthefly sich als CSS generiert und die Variable ausgibt (com_ajax + template helper)
• Du könntest ein Plugin schreiben was beim Speichern der template Parameter die Datei schreibt
• Du könntest in der Index.php checken ob die Datei existiert und aktuell ist und wenn nicht schreiben

Finde keine der Ideen wirklich schick (außer eventuell das Plugin) da die Lösung die du eh schon hast wahrscheinlich die einfachste ist.

Was ist denn für dich ein "hoher Preis"?

Zitat von christine2

also ab Zeile 2, Deinen Code einfügen? Also ob screenshot dem TE hilft?

Ja, nur das Feld vorher komplett leeren. Und wenn die Tabelle nicht gefunden wurde ist entweder die falsche oder keine Datenbank gewählt.

Das sind nicht die Daten der Tabelle sondern irgendwelche statistischen Auswertungen der Ladezeit.

Wenn du mittels phpMyAdmin auf die Datenbank gehst und nach der Tabelle suchst + drauf klickst, hast du oben in der Leiste einen Knopf "Anzeigen" um zu sehen ob Einträge vorhanden sind.

Du kannst auch dann auf "SQL" klicken um dann den Code aus dem "Spoiler" von oben einzufügen (auch hier den #__ Prefix ersetzen). Vielleicht reicht das schon.

Was steht denn in deiner Tabelle drin?

SniperSister hat dazu einen guten Vortrag auf dem Joomladay gehalten. Lohnt sich definitiv ein Videoticket für zu holen.

Dein Problem ist, dass in der #__tuf_metadata wahrscheinlich keine Daten drin sind. Lösung: führe diesen Query aus (Prefix ersetzen)

Falls die Tabelle nicht leer ist, musst du sie zuerst leeren.... und wie immer Backup nicht vergessen.

Die Frage die sich immer stellt: warum nicht einfach irgendwas fertiges aus dem Internet nehmen? Da gibts so viele Scripte und Tutorials...

Würde sich wahrscheinlich anbieten, wenn man auf SemVer umsteigen würde. Das macht es bedeutend einfacher sowas zu vermeiden.

Zitat von Duderino

Scheint mir eine gute Alternative zu sein und umsonst.

Ich kann ja nur empfehlen, obwohl es kostenlos ist, immer wenn es angeboten wird auch eine Subscription abzuschließen. Das hält den Hersteller einigermaßen am Leben (wenn es genügend tun) und man steht in 1-2 Jahren nicht vor dem selben Problem, weil der nächste Programmierer sich das ganze nicht mehr leisten kann.

Hier ist ein temporärer Fix.

Bist du dir sicher? Zeile 54 ist nicht das Query.

Kannst du mal die "helper.php" hier anhängen?

Zitat von Kallle

Ich glaube, das Gesetz zur Barrierefreiheit ist auch wieder so ein übereilter politischer Schnellschuss, wie so vieles andere seit Beginn des neuen Jahrtausends. Vorschriften und Gesetze erlassen macht Spaß und geht schnell. Aber zur Zeit fehlt noch die einwandfreie Technik, die das alles auch sauber und verständlich umsetzt! Bisher führt das BF-Streben m. E. oft zu noch mehr Barrieren ...

Für dich als Dienstleister ist das Gesetz doch pures Gold. Barrierefreiheit zu implementieren ist reines SEO, angefangen, dass Maschinen (Screenreader) deine Seite lesen/verstehen sollten...schätze mal was Google-Bots sind...genau Maschinen, die deine Seite lesen und verstehen wollen. Saubere Auszeichnung von Bildern, Google wird es lieben. Einfache und verständliche Sprache, Google liebt es. Gute Kontraste, Menschen bleiben eher auf der Webseite, wenn das Lesen nicht anstrengt, das gibt Google das Signal, dass die Seite relevant ist. Texte in der korrekten Sprache ausgezeichnet: mag Google auch. Und so weiter, und so fort....Jede Optimierung um die Seite barrierefreier macht führt im Regelfall sofort zu einer Optimierung für Google & Co. Im Gegenteil, wenn du dich dem verweigerst, schadest du ja aktiv deinem Kunden und dessen Erfolg.

Als Dienstleister solltest du wirklich dankbar für dieses Gesetz sein, selbst wenn es dich nicht interessiert, weil plötzlich hast du eine Anleitung zur Hand, wie die Seiten optimiert werden können und gleichzeitig zwei Fliegen mit einer Klappe zu schlagen...

Hier gibts ganz unten eine Erklärung wie du in deiner Komponente weitere Parameter für die Pagination freigibst: https://docs.joomla.org/J5.x:Paginatio…uery_parameters

Zitat von CurlY BracketS

Allerdings lese ich aber, dass dieser Update die Pagination von Smartsearch kapput macht. Hmm, vielleicht doch besser abwarten?

Es gibt bei Security Updates sehr wenig Gründe ein Update rauszuschieben, dieser ist KEINER davon. Also Updaten und bei Bedarf den Fix einspielen.