Beiträge von Re:Later

    So Deprecated-Meldungen sind (momentan) nicht schlimm. Sie weisen dich ja darauf hin, dass es erst in irgendeiner zukünftigen PHP-Versionen dann nicht mehr funktionieren wird. Du kannst diese Meldungen verstecken, indem du "Fehler berichten" in der Joomla-Konfiguration deaktivierst.


    Wenn du dich traust, es zu reparieren, z.B. mit Editor Notepad++, nicht dem Windows-eigenen(!), gehe in die Datei (Pfad siehst ja in der Fehlermeldung) und ändere Zeile 220 von

    Code
    1. function PclZip($p_zipname)

    nach

    Code
    1. function __construct($p_zipname)

    Aber ein Wechsel ist nat. immer besser, wenn Erweiterungen nicht mehr ordentlich gepflegt werden. Den Fehler gibt es ja schon länger.

    im Backend wurden sie angezeigt jedoch sobald man öffnen wollte kam eine Fehlermeldung und wurden als eingeloggt angezeit !

    Das klingt ja schon wieder ganz anders als "Im Backend ist zwar alles da, aber nicht editierbar!". Dafür gibt es im Backend-Menü die Ecke "Globales Freigeben", Freigeben, Check-in oder ähnlich genannt. Weiß nicht, wie das unter 2.5 hieß.


    Deshalb ist es wichtig, dass man von Anfang an die Probleme etwas detaillierter beschreibt.

    Zumindest mit der Standardsuche (com_search) kannst du ein search-Plugin schreiben, da du in diesem die Treffer per Datenbank on-the-fly abfragen kannst. Da man mit Joomla-Datenbankmethoden auch Fremddatenbanken abfragen kann, wäre diese meine Wahl. Keine Ahnung, ob das mit Sourcerer aus einem Plugin heraus auch geht.


    Ganz trivial ist es dann aber nicht, die Suchhits auf die richtigen Seiten zu verlinken. Da man sich leider unüberlegt entschlossen hat mit Joomla4 com_search zu entfernen, auch wenig zukunftssicher die ganze Arbeit, die man sich da macht.


    Die Indexsuche (com_finder) hinterlegt die Suchbegriffe schon während des Speicherns von Inhalten in der Joomla-Datenbank. Das muss man natürlich entsprechend implementieren. Da bei Euch jedoch extern gespeichert wird, sehe ich wenig Chancen. Kann aber daran liegen, dass ich diese verquaste und unverlässliche Suche nicht sonderlich mag und mich damit noch nicht beschäftigt habe.


    Mein Weg wäre für die Mitarbeiter vermutlich: Daten regelmäßig, automatisiert aus der Fremddatenbank in die Kontaktkomponente einlesen. Da funktioniert dann auch die Suche (com_search). com_finder müsste man jeweils nach Synchronisation den Index aktualisieren. Dafür gibt es ein CLI-Script im Ordner /cli/.


    Die Darstellung der Daten dann eben ganz normal aus Joomla heraus.


    Andere Möglichkeit vielleicht: Regelmäßig aus den Daten automatisiert einen Joomla-Beitrag erstellen bzw. aktualisieren, also die Tabelle fix in Joomla hinterlegen.


    Fallen mir noch diverse Zwischenlösungen ein, aber unterm Strich laufen sie alle auf ähnliches hinaus.


    EDIT: Ich rede immer nur von Joomla-Hausmitteln. Keine Ahnung ansonsten.

    Ich lade auf https://realfavicongenerator.net/ ein Bild hoch. Sofort danach switcht die Seite auf eine Vorschau um. Da mache ich dann bei den Tabulatoren "Assets" Häkchen, weil ich keine Ahnung habe. "Create all ", "Declare in HTML", "Generate html_code.html"


    Ich lass mir das Paket erstellen und lade es im Tabulator "HTML5" herunter.


    Die entpackten Bilder/Dateien lade ich dann alle in das Wurzelverzeichnis (Root) Joomlas hoch, also in das oberste Verzeichnis, wo man auch die Ordner /administrator/, /components/, /images/ sieht.


    Persönliche Entscheidung. Da mir das favicon.ico meist zu verpixelt ist, behalte ich mein altes und kopiere es nicht hoch auf Server. ebenso die "html_code.html", die eine Vorlage ist, was man noch in sein Template reinkopieren soll.


    Dann kopiere ich die Zeilen aus der "html_code.html" in den <head>....</head>-Bereich meines Templates.

    Prüfe, ob in dem Bereich schon gleichlautende Anweisungen vom Template drinnen sind, die Konflikte machen könnten.

    Den Pfad zum favicon.ico setzt Joomla automatisch ein (sucht zuvor, wo es eines findet). Muss ich nix zutun.


    Dann prüfe ich, ob per Browser erreichbar sind: https://www.example.org/browserconfig.xml und https://www.example.org/site.webmanifest und https://www.example.org/safari-pinned-tab.svg, weil meine .htaccess einiges blockt ;-)

    Dann lasse ich auf obiger Seite den "Check your favicon" laufen und habe alles grün,

    auch, wenn er mich hinweist, dass mein favicon.ico nicht im Root-verzeichnis liegt. Habe ich ja oben rausgeschmissen. Könnte ich nat. aus meinem Template auch einfach rüberkopieren, wenn's mir nicht wurst wäre ;-)


    Bezüglich favicon.ico wärs natürlich besser auch ein generiertes in verschiedenen Größen hochzuladen. Wegen obigem Problem, war mir das aber für diesen Test zu blöd. Man kann ja auch ein weiteres Paket erstellen lassen, wo man dann ein besser geeignetes Bild nur für favicon.ico wählt.


    Wenns dann auf deinem Mobilgerät nicht funktioniert, kann's nat. auch daran liegen, dass das Gerät, der Browser die Grafik gecachet hat. Da sind die oft zickig. Schon das Austauschen eines favicon.ico bei einer Webseite kann eine Qual beim Testen sein.


    So, und jetzt habe ich nach diesem ""Tutorial"" Favicons auf meiner Seite, die ich nie haben wollte ;-)

    weil die ja schon seit Jahren intern diese XML-Struktur nutzen.

    Die hat doch nix mit dem Privacy-Kram zu tun. Das ist wie ein Vergleich von Webseite 1 unter Joomla mit Webseite 2 unter Worpress. Beide verwenden HTML. Trotzdem ist die Struktur komplett unterschiedlich und dient komplett anderen Inhalten. Vom XML-Teil sind die Entwickler doch auch gar nicht betroffen. Die müssen wie gesagt nur "Lauschpunkte" einbauen (Plugin-Trigger/Events) und ein Plugin schreiben.


    Und Joomla protokolliert doch auch nur "Hat id xy gespeichert" u.ä. und keine Romane. SobiPro hat auch eine bis mehrere Stelle, wo die Speicherung ausgeführt wird. Da gehört eben der "Lauscher" rein. 2, 3 Zeilen handelsüblicher Joomla-Programmcode im Normalfall.


    Und bei anderen Programmen ist das nicht anders. Wenn du vertrauliche Daten, bspw. Rechnungen, Zahlungsbelege, sammelst, hebst du die natürlich separat auf und im Normalfall werden die aus rechtlichen Gründen auch nicht gelöscht, sondern dürfen/müssen mehrere Jahre aufgehoben werden.

    Da bin ich mal gespannt, wie dieser individuelle Teil per XML weitergegeben wird.

    Exakt so wie du das im Plugin in Auftrag gibst, so wird das gespeichert. Wenn du meinst, eingegebene, geänderte Daten im Einzelnen festhalten zu müssen, obwohl du in deinem "Aktenordner" Zahlungsbelege und Formulare sowieso aufheben musst, kannst du das machen. Im Normalfall sollte aber eine Refrenz reichen, damit du und Abfrager bei Streitigkeiten die entsprechenden Daten aus deinem/seinem Aktenordner kramen kann.


    XML wird lediglich bei der AUSGABE, beim Export verwendet, nicht für die Speicherung. Alles andere ist normales PHP + Datenbank, sozusagen.

    Ich befürchte, jetzt verstehe ich Deine Ironie nicht ganz. hmm Die DSGVO fordert ja nicht, dass die abgefragten Daten NUR maschinen-lesbar sein dürfen, sondern lediglich AUCH. Im Gegenteil: Jeder Nutzer (i. d. R. ein Mensch, der nicht vom IT-Fach ist) soll auf möglichst einfache Art und Weise vollständige Auskunft über seine gespeicherten Daten abfragen können.

    XML kann sich jeder Bereitsteller rechtlich sicher sein, dass er die Daten ausarbeitbar und beliebig auswertbar und filterbar abliefert. Bei einer individuellen Formatierung ist das nicht der Fall. Auch bei einer Erweiterung der Daten, wie neue Untergruppen, ist das so weitaus einfacher zu handlen. Also macht das Joomla schon richtig und begibt sich nicht auf Glatteis. Außerdem kann sich Joomla nicht um alles kümmern. Da sind andere gefragt, entweder Freiwillige oder Leute, die mit so was ihr Geld verdienen.


    Wenn ich eine 2000 Seiten lange, starre Auswertung bekäme, wäre ich nun wieder angesäuert.


    Ich meinte das u.a. auch so. So eine menschenlesbare Auswertung zu erstellen ist programmiertechnisch nicht das große Drama. Das geht mit PHP-Standards. Wenn du und deine Gäste so was möchten, dann programmiere es dir selber oder lasse es dir programmieren und achte darauf, dass diese Daten ebenfalls im Verborgenen bleiben.


    Und selbstverständlich kann man die Daten auch direkt aus der Datenbank auslesen und den XML-Schritt umgehen.

    Wie schon oben gesagt, bietet Joomla dafür die Basis, um diese Infos in der DB zu speichern und dann mit allen anderen Daten abzurufen (ohne, dass man das Rad neu erfinden muss). Und so kompliziert ist das für Entwickler nicht, falls sich die Erweiterung an Joomla-Konventionen hält. Letztlich läuft es auf ein einzelnes nicht weiter dramatisches Plugin hinaus, das auf bestimmte Tätigkeiten der jeweiligen Erweiterung "lauscht" und dann den Auftrag zur Speicherung durch Joomla absendet.


    Zugegebenermaßen habe ich da bei SobiPro auch meine Zweifel, das ja von Joomla möglichst wenig wissen will. Wahrscheinlich brauchst dann ein Diamanten-Abo und SobiPro speichert das in einer eigenen Tabelle oder in den 2 Mio Cache-Dateien ;-) Bin ein Lästermaul... Müssen die Entwickler selber wissen.


    Und wär doch ein tolles Feature für deine Seite, die XML-Dateien menschen-lesbar zu machen ;-) Musst nur darauf achten, dass es sich um vertrauliche Daten handelt, die User dann bei dir hochladen.