Beiträge von Re:Later

    Keiner weiß, wozu diese Versionsangabe da ist ;-) Wenn ich was neu anfange, schreibe ich da oft die aktuelle Joomla-Version rein. Nur als Merker quasi... Hab jedenfalls noch nie gemerkt, dass dadurch irgendwas geblockt wird, wenn was Falsches drin steht.

    Zeilen 49 bis 85:

    https://github.com/GHSVS-de/up…sghsvs-update.xml#L49-L85


    Version der Erweiterung ist in beiden Fällen

    2019.06.11


    Zeilen 49 bis 66 richtet sich an Joomla 4.0.

    Zeilen 68 bis 85 an Joomla 3.9 und 3.10.


    Alles andere ist identisch, da ein und die selbe ZIP auf 3.9, 3.10 und 4.0 verwendbar ist.


    ---------------------------------------------------------------


    Selbe Datei Zeilen 4-17

    https://github.com/GHSVS-de/up…asghsvs-update.xml#L4-L17

    Eine ältere Version 2016.08.01, die NUR auf Joomla 3.6 angeboten wird.


    In Zeilen 34 bis 47

    https://github.com/GHSVS-de/up…sghsvs-update.xml#L34-L47

    befindet sich aber eine neuere Version 2017.09.05, die AUCH für Joomla 3.6 geeignet ist. Also zeigt Joomla die zum Update an und nicht die obige ältere Version 2016.08.01.


    Keine der älteren Versionen ist für Joomla 4 geeignet, also auch kein Block für Joomla 4.

    Zwischen den Master-Tags <updates> kannst du beliebig viele <update>-Blöcke anlegen. Auch für unterschiedliche Erweiterungsversionen, z.B., wenn eine 2.0 nur <php_minimum> PHP 5.6.0 braucht, die 2.1 aber <php_minimum>7.2.0</php_minimum>.


    Oder zusätzlich ein Block für eine Developper-Version, den du dann mit dem <tags>-Tag kennzeichnest, damit sie nur auf Joomlas angeboten wird, die die Optionen unter Erweiterungen entsprechend eingestellt haben.


    Joomla ermittelt sich dann aus all den Blöcken den zum jeweiligen Joomla passenden und den mit der aktuellsten Version.


    version ist die Version der Erweiterung. Wenn eine auf 3 und 4 funktioniert, ist sie in beiden Blöcken gleich.


    Gibt auch Leute, die alle älteren Versionen in der Update-XML drinnen behalten und die neuen Blöcke einfach hinzufügen. Geht also alles.

    Das einfachste ist, 1 <update>-Block für Joomla 3, ein weiterer für Joomla 4. Soweit ich mich erinnere, geht das gar nicht, verschiedene Haupversionsnummern in einen Block.


    EDIT (auch, wenn man der Doku nicht immer ganz trauen kann):

    Zitat

    Note: If your extension is Joomla! 2.5 and/or 3.1 compatible, you will be required to have separate <update> definitions for each version due to the manner in which the updater checks the version if you specify a number.

    https://docs.joomla.org/Deploying_an_Update_Server

    Laufen beide Seiten auf dem selben Server, also mit identischer Grundkonfiguration? Ich frag nur, weil beim Überfliegen des Plugin-Codes mir auffiel, dass viele "Entscheidungen" aufgrund von PHP-$_SERVER-Daten gefällt werden. Habe aber nicht geprüft, ob da auch "kritische" dabei sind, die evtl. einen Fallback auf andere Indices benötigen, wenn nicht gefunden.

    Hast du schon "Fehler berichten" in der Joomla-Konfiguration auf "Maximum", wobei das vielleicht nichts bringt, weil die obigen Warnings/Notices vielleicht durch Umleiten auf die Fehlerseite verschluckt werden.

    Hilft dann nur Blick in PHP-error_log-Datei, falls du Zugriff hast.

    Weniger Logik als einfach Muss-man-wissen-und-beachten. Dass der moderne Router in solchen und ähnlichen Fällen auf schräge, teils unaufgelöste URLs zurückfällt, wenn er nichts findet, ist bekannt. Gibt es mehrere andere Fälle, wo das noch offensichtlich(er) wird.


    Der moderne Router erwartet eine astreine Menüstruktur, wo MINDESTENS die übergeordneten, also die allerobersten Kategorien von Beiträgen einen Menüeintrag haben.


    (Deshalb baue ich mir auch bei allen Seiten erst eine solche astreine Menüstruktur in einem zentralen Schattenmenü auf und baue alle anderen Menüs mit Menüeintrags-Aliasen, die auf dieses Hauptmenü zeigen. Anfangs mehr Arbeit, später aber leichter zu pflegen und oder zu fixen.)

    Die Frage ist nun warum werden keinerlei Fehlermeldungen aufgelistet?

    Vielleicht erzeugen die alten URLs ja gar keine 404-Seiten, sondern kommen irgendwo anders raus?


    Vielleicht hast das zugehörige Plugin nicht aktiviert?


    Ist zwar nicht immer ein Kriterium, aber die Erweiterung ist ja schon etwas älter. Aktiviere mal das joomlaeigene Umleitungs-Plugin mit Einstellung "URLs sammeln" aktiv, ob das ebenfalls nichts sammelt für die joomlaeigene Umleitungs-Komponente.

    Hikashop 4.2.1

    Wenn ich in dem Paket (das Starter von Herstellerseite) nach

    /components/com_hikashop/views/product/view.html.php

    Zeile 131 schaue, dann gibt es da nichts, was die Fehlermeldung

    Call to a member function get() on null

    werfen könnte.


    Und auch die

    ProductViewProduct->listing()
    JROOT/components/com_hikashop/views/product/view.html.php:28

    stimmt nicht überein.


    Wenn du eine PRO-Version verwendest, wirst wohl die Hersteller fragen müssen.

    Es handelt sich um einen Fehler in der Datei templates/rt_plethora/error.php deines Templates, das offensichtlich nicht mehr das frischeste ist. Bennene diese error.php um, damit sie deaktiviert ist und die von Joomla genommen wird. Dann solltest du die eigentliche Fehlermeldung sehen.


    Mit dem Modul hat das höchstwahrscheinlich gar nichts zu tun.

    1.) Solltest du dein Joomla auf aktuellste Version bringen.


    2.) Archivierte Beiträge sind nach wie vor erreichbar, auh für Nicht-Super-User. Wenn suchmaschinen den Link vor der Archivierung schon erfasst haben und in Suchtreffern anzeigen, werden sie auch nach Archivierung weiter angezeigt und sind unter altem Link erreichbar erreichbar.


    3.) wirst du dein Ziel nur mit Template-Overrides erreichen können, wenn dein Template den Super-Usern nicht für alle Stati eine entsprechende Info anzeigt. Ich habe leider keine Ahnung, ob Joomla das im Normalfall korrekt macht. Kannst ja mal testweise auf's Protostar-Template umstellen, um das zu prüfen.

    Sie gar nicht mehr anzuzeigen, sollte ebenfalls über einen Override möglich sein.


    In Unkenntnis deiner Seite und Umgebung etc. aber schwer zu sagen.


    Weitere Variante könnte sein, die Artikel in eine eigene, "versteckte" Kategorie zu verschieben, die extra dafür gedacht ist und im Frontend nicht zum Einsatz kommt. Eine übergeordnete Hauptkategorie und darunter Kondkategorien, die man so benennt wie die originalen Kategorien, wenn man diese Ordnung weiter bewahren möchte.

    Die Profile werden von oben nach unten durchprobiert. Man kann die Profile-Reihenfolge ja sortieren durch Drag & Drop (erste Spalte der Übersicht).


    Hast du also als ERSTEN eines, das NUR für die Publisher eingerichtet ist, werden weitere Profile ignoriert.


    Wenn du als ERSTEN einen hast, der AUCH auf Publisher zutrifft, z.B. der ausgelieferte Standard (glaub ich zumindest), wird der genommen.

    Ich kenne sogar noch mehr ;-) Aus einer Email:

    Und da mich die lobpreisenden Antworten des Machers, der isoliert in seiner philosophisch-theoretischen WebAsset-Welt lebt und final mit einem alberen Override-Vorschlag kommt und da mbabker absolut nichts zu entscheiden hat und das Thema ansonsten wegignoriwert wird, ist meine Entscheidung jetzt eben so gefallen wie sie gefallen ist. Da arbeite ich mich lieber in andere CMS und weiteres ein als Zeit-Lotterie zu spielen...


    Gab auch noch einen weiteren, TANGENTIALEN Thread, wo ich aber nach konstruktiver, zielführender Erklärung durch mbabker erkennen musste, dass der Fehler bei mir liegt, was aber trotzdem viele andere treffen wird: https://github.com/joomla/joomla-cms/pull/25669

    Eine externe und kostenpflichtige Seite ist mir bei meiner heutigen Recherche aufgefallen: http://www.cookiebot.com

    Da habe ich mal einen kostenlosen Scan laufen lassen. Das Standard-Joomla-Cookie (das einzige, das meine Seite schreibt) wird mir von denen als Marketing-Cookie ( = Tracking-Cookie) ausgewertet. Kompletter Blödsinn.


    Dann folgt ein allgemeiner Sermon zu Dingen, die auf meiner Seite 0 relevant sind und/oder bereits korrekt in der Datenschutzerklärung behandelt werden.


    Kurz: Die finden auf jeder Seite irgendwas (auch inkorrektes), um Betreiber zu Abos zu überreden. Mag für Firmen u.ä. ein sinnvoller Service sein. Kann ich nicht beurteilen.

    Am core wird sich nicht mehr allzu viel ändern und Erweiterungen, die unter 3.9 sauber programmiert wurden, sollten auch auf V4 ablauffähig sein.

    Bspw. der WebAssetManager vernichtet auch sauber programmierte Erweiterungen und stellt die Rückwärtskompatibilität Joomlas in Frage. Wäre das nicht der Fall, wäre ich nicht so sauer. Das Ding ist ein unkontrollierbares, starres, nicht auszuhebelndes Parallel-System zu bisherigen HTMLHelper-Methoden, addScript-, addStylesheet-Methoden u.ä. In meinem Fall ist jahrelange saubere Programmierung für den Ars.. und es ist nicht so, dass ich nicht weitere Wochen drangehängt hätte, um Lösungen für Joomla 4 zu finden. So kann ich bspw. alle meine Templates in die Tonne klopfen, die auf einem für Nutzer einfach und flexibel zu konfigurierendem Plugin basieren, dass sich im Unterschied zu anderen "Frameworks" niemals einschaltet und bspw. Müll lädt, wenn das verwendete Template es nicht benötigt.


    Dass die Auswirkungen von dem Asset-Klumpertz noch nicht so auffällig sind, hängt einfach damit zusammen, dass die Leute bisher nur mit Core und irgendwelchem Kleinkram rumprobieren. Und, wenn der die Alpha-Phase überlebt, haben wir ihn auf Immer. Und noch mal: Als verquastes, querschießendes Parallelsystem, nicht als alleinstehender Ersatz von gewohnten Methode, worauf man sich hätte einstellen können.


    Es kommt auf die Komplexität und Zielsetzung sauber programmierter Erweiterungen an, ob sie den Wechsel auf Joomla 4 ohne schlampige Krücken überleben und, ob Programmierer noch Bock haben, weiter zu machen.


    Egal. Ich habe meine Kunden und Nutzer informiert, dass der Support für alle meine Erweiterungen mit Joomla 3 endet

    Desweiteren wurden nerdige und unfertige "Verbesserungen" reingebombt, die in Teilen mit absoluter Inkompatibiltät gleichzusetzen sind, wenn sie sich durchsetzen und nicht wieder entfernt werden.

    Und wieder ist das Resultat eines Posts, dass Legenden und Gerüchte verbreitet werden und Leute sich ihre Seiten mit unnötigem Kram zuballern.


    Es hat sich überhaupt nichts geändert.

    - Seiten die Tracking-Cookies schreiben lassen, dürfen keine schreiben lassen bevor der Besucher nicht eingewilligt hat.

    - Ein pauschales "OK" oder "Ich akzeptiere", obwohl die Seite schon längst Cookies geschrieben hat, ist nicht ausreichend.

    - Der Zugang zur Seite darf nicht verwehrt werden, wenn ein Besucher nicht akzeptiert, da dies sonst keine freiwillige Entscheidung mehr ist.


    Deshalb waren solche Cookiewarner schon vom ersten Tag an BEKANNTERMAßEN Schotter.


    Wer also Maps, Likes, Filme und anderen Kram, was cookiesetzenden Code ausführt erst per explizitem OptIn + Hinweis zur Verfügung stellt, muss seine Seite nicht mit nervtötenden, kostenpflichtigen Blockade-Tools zuballern und Besucher abschrecken.


    Die Wald-und-Wiesen-Seite sollte einfach darauf verzichten so Kram überhaupt direkt in die Seite einzubinden, wenn man unsicher ist. Und Konzerne wie IBM können es sich halt leisten für so ein Tool ausreichend Euronen hinzublättern.


    Das o.g. Urteil ist einer der typischen Fälle, wo geltendes Privatsphäre-Recht einfach rücksichtslos missachtet wurde.

    Und ich kann dir aus leidlicher Erfahrung sagen, dass es absolut gar keinen Sinn macht, jetzt schon so weit zu gehen, seine Seite nach Joomla 4 zu portieren, um dann später evtl. Arbeit zu sparen. Was heute noch funktioniert oder von dir angepasst wurde, klappt morgen schon nicht mehr. Desweiteren wurden nerdige und unfertige "Verbesserungen" reingebombt, die in Teilen mit absoluter Inkompatibiltät gleichzusetzen sind, wenn sie sich durchsetzen und nicht wieder entfernt werden.

    Wenn du was vorbereiten willst: teste schon mal, ob auch deine Erweiterungen auf Version 4 ablauffähig sind.

    Selbst das ist mit oben Gesagtem derzeit komplett sinnfrei. Beschäftigungstherapie....

    Nur nebenbei: Ein Like-Button ist was anderes als Teilen. Das Ufuk-Plugin ist zum Teilen.


    Die Entscheidung bringt absolut nichts Neues. Dem User muss vor Verbindung zu Facebook (und anderen) klar sein, dass er mit Facebook verbunden wird und muss das vorab entscheiden dürfen. Damit er für sich richtig entscheiden kann, muss er auch informiert sein. Damit er informiert wird, reicht ein Satz "Mit Klick werden Sie mit einem amerikanischen Milliardenkonzern verbunden, der in den letzten Jahren vor allem durch erhebliche Sicherheitslücken aufgefallen ist und sich weiters einen Dreck um Privatsphäre-Einstellungen oder geltendes Datenschutzrecht kümmert und stattdessen immer wieder lieber Millionen/Milliarden für Prozesskosten u.ä. ausgibt. Weiteres in der Datenschutzerklärung". Und jetzt gilt halt im Detail noch zu klären, ob der Satz auch kürzer sein darf ;-)

    Zitat

    Der Konzern ist für eine Beaufsichtigung zu groß, und diese Körnchen-im-Sand-Strafe bestätigt das. Die FTC sollte Facebook schlicht und einfach zerschlagen. Genug ist genug.