Beiträge von Re:Later

    Gibt es eine Möglichkeit, die Ausführungsreihenfolge von Plugins zur Laufzeit zu beeinflussen oder wenigstens zu ermitteln?


    Es ist mir bekannt, dass man im Backend die Reihenfolge durch Umsortiene ändern kann. Und durch Datenbankbefehle ein Sortieren "an erste Stelle", "an letzte Stelle" etc. ausführen kann.


    Scenario:
    Ich habe z.B. ein System-Plugin, das immer als erstes oder letztes ausgeführt werden soll bzw. "weitestgehend immer" ;-) .
    Andere Plugins z.B. JCH-Optimize haben den selben Anspruch. Kommt es halt ggf. nach einiger Zeit zu "unsicheren" Reihenfolgen, weil man was zuinstalliert usw.


    Mein System-Plugin setzt deshalb bei jedem Seitenaufruf Datenbankabfragen ab, die die Reihenfolge in DB prüfen und ggf. korrigieren. Ist klar, dass das dann nur beim nächsten Seitenaufruf Wirkung zeigt.
    Das würde ich gerne etwas optimieren.
    Bspw. per PHP aus schon vorliegenden Joomla-Systemdaten, Application, erfahren, wie denn die aktuelle Reihenfolge ist und ob DB-technisch was zu tun ist oder sogar Möglichkeit Reihenfolge zur Laufzeit umzustellen, wenn ich früh genug dran bin, mit dem Versuch.


    Füe jede Erleuchtung, jeden Ansatz dankbar.

    wäre ja schön wenn joomla das auch vom sytem her alleine hinbekommt


    Ausprobiert. Klappt wie gewünscht. Kein Bug.


    2-Sprachiges Joomla 3.5.1 (DE und EN).


    Artikel DE angelegt. "artikel-de". Sprache auf DE.
    Menüpunkt DE angelöegt. Alias "artikel". Menütyp: Einzelner Beitrag: Zeigt auf "artikel-de". Sprache auf DE.


    Artikel EN angelegt. "article-en". Sprache auf EN. Verknüpfung mit "artikel-de" nach erstmaligem speichern.
    Menüpunkt EN angelöegt. Alias "article". Menütyp: Einzelner Beitrag: Zeigt auf "article-en". Sprache auf EN. Verknüpfung mit Menü "artikel nach erstmaligem speichern..


    Im aktivierten Plugin alles auf JA außer "Sprachkürzel entfernen".


    Seitenquelltext ohne URL-Rewrite nutzen aktiviert.:

    Code
    1. <link href="http://localhost/multilang/index.php/de/artikel" rel="alternate" hreflang="de-DE" /><link href="http://localhost/multilang/index.php/en/article" rel="alternate" hreflang="en-GB" />---- SOWIE weiter unten------<link href="http://localhost/multilang/index.php/de/artikel"" rel="alternate" hreflang="x-default" />


    Seitenquelltext mit URL-Rewrite nutzen aktiviert.:

    Code
    1. <link href="http://localhost/multilang/de/artikel" rel="alternate" hreflang="de-DE" />
    2. <link href="http://localhost/multilang/en/article" rel="alternate" hreflang="en-GB" />
    3. ---- SOWIE weiter unten------
    4. <link href="http://localhost/multilang/de/artikel" rel="alternate" hreflang="x-default" />


    Dabei war es wurst, ob ich nur die Menüs verknüpfe und/oder nur die Beiträge, so lang die Spracheinstellungen in Menü und Beiträgen korrekt sind.
    Wenn die Beiträge verknüpft sind, sollte man auch keine Probleme bei Artikeln haben, die keinen eigenen Menüeintrag.

    Dann hilft Update per XAMPP machen. Da kannst execution_time etc. beliebig hochschrauben.


    Oder überlegen, ob die DB so groß sein muss.
    _finder_ -Tabellen kann man ja nach Update neu befüllen durch Neuindexierung des Suchindexes.


    _overrider kann man bedenkenlos platt/leer machen. Ist nur eine Cache-Tabelle.


    _redirect_links, falls das Plugin aktiviert ist und Haufen deaktivierte drin sind, zumindest die deaktivierten löschen (Siehe ghsvs.de/programmierer-schnipsel/joomla/129-komponente-umleitung-loeschen-von-eintraegen-per-datenbank)


    _ucm_history ist zu überlegen, ob man die gesammelten Versionierungen überhaupt braucht oder, ob nicht eh neu begonnen werden kann.


    _session kann man auch bedenkenlos leeren vor Update. Muss sich halt selbst neu anmelden.


    Desweiteren im Backend aufräumen. Alles Unnötige auch aus Papierkorb raus usw. usf.


    Käme ich bspw. derzeit auf >10MB Einsparung, verwende aber Indexsuche gar nicht und auch nicht Umleitungskomponente (zumindest sammelt die nicht).

    Die Anzahl der Worte kann man zwar beliebig erhöhen, auch so, dass allles angezeigt wird, aber
    trotzdem mit den Joomla-Suchkomponenten nicht per Overrides zweckmäßig möglich, da die Suchergebnisse mehrere "Filter" im Core durchlaufen, bei denen bspw. alle HTML-Tags entfernt werden. Hast also ziemlich hässliche, schwer lesbare und teils unvollständige Ausgabe.


    Wirst wohl auf ein CCK oder ähnlich, vielleicht mit trickigeren Schlagworten als Joomla das kann, und entsprechenden Filtererweiterungen ausweichen müssen oder selbst programmieren (lassen). Oder mal im JED kramen.


    Kennen sich andere hier besser aus mit CCK und so...

    Bei mir werden die Container und Inhalte wie gewünscht angezeigt und auch im Quelltext werden sie angezeigt. Einen Inline-Style haben sie nicht. Weder Firebug noch Web-Developer > Erzeugter Quelltext. JavaScriptFehler liegen keine vor. Nachdem Seite kein Mootools lädt, fällt auch der Verdacht aus.


    Vielleicht ein Ads-Blocker oder so was in Euren Browsern aktiv? Dafür spricht evtl. auch, dass ihr im Seitenquelltext die Container nicht seht, was, egal, ob die nun auf display:none stehen oder nicht, NICHT normal ist, egal welcher Browser. Nur den per JS eingefügten Style sieht man dort nat. im Normalfall nicht

    Für den Joomla-CMS-Erweiterungs-Entwickler von Feld-Wald-und-Wie­sen-Komponenten sehe ich kaum Vorteile, eher Nachteile. Weil, deshalb verwende ich ja das Joomla-CMS, damit ich mir solcherlei "tippfehlerfreundlichen" Datei-, Klassen-, Task-Orgien etc. nicht antun muss ;-)


    Für komplexere Quasi-Standalones innerhalb des CMS oder Standalones ohne CMS, aber + Joomla-Framework, wirds wohl schon richtig sein.


    Anders: Für Joomla-CMS selbst/allein immer noch nicht spruchreif, das neue MVC, wenigstens kein Anlass bestehende Komponenten umzustellen, bis klar ist, was das CMS an Erleichterungen (wiederverwendbare Core-Klassen z.B.) dazu mal bieten wird.


    Weils im magazine-Artikel als Beispiel von M.Babker genannt wird: Schade halt für Feld-Wald-und-Wie­sen-Entwickler, dass man sich zunehmend mehr Applikationen auf GitHub erst mal selber "builden" muss, was in > 50% der Fälle auf einem Feld-Wald-und-Wie­sen-Entwickler-Computer auch nach mehrtägigem Fluchen nicht hinhaut. So bleiben mir auch die Vorteile am Bsp. eines komplexeren JIssues verborgen ;-) , das aber auch gar keine Joomla-CMS-Erweiterung ist, sondern ein Standalone + Joomla-Framework, wenn ich das richtig sehe.

    A)

    Code
    1. $lang_code = JLanguageHelper::detectLanguage();


    Was macht detectLanguage()?
    - 1) Ermittlung der im Browser eingestellten Sprachen. Unter Firefox die Einstellungen unter "Bevorzugte Sprachen für dir Darstellung von Websites".
    Also der Inhalt von $_SERVER['HTTP_ACCEPT_LANGUAGE'].
    Bsp.: ar-SA,en-US;q=0.8,de-DE;q=0.7,de;q=0.5,en-GB;q=0.3,en;q=0.2


    - 2) Ermittlung der Inhaltssprachen Joomlas.


    - 3) Abgleich "welche der Browsersprachen einer Inhaltssprache am nächsten kommt". Und das ist dann obiger $lang_code.


    B)

    Code
    1. JFactory::getLanguage()->getTag()


    - Sollte aktuelle InhaltsSprache der Seite sein(?)


    C)
    - Ggf. Empfehlung für Wechsel ausgeben (nach Prüfung von D), Sessioneintrag, was ganz zu Anfang des Gesamtcodes passieren sollte).

    Code
    1. JFactory::getApplication()->enqueueMessage('Change your language');


    D)
    - In Joomla-Session schreiben, dass Meldung bereits ausgegeben wurde, damit nur einmalig passiert.


    Ermittlung, ob Seite in betr. Sprache esxistiert? Keine Ahnung. JLanguageAssociations::getAssociations ? Hängt ja auch von Komponente der aktuellen verknüpften Seite ab (Menü, Kategorie, Beitrag...).


    Grobe Theorie. Nix geprüft. Nur so aus Code zusammengesucht und Gedächtnis.

    Du hast mehrere Denkfehler.


    Der gravierendste:
    Zuerst wird mod_test2.php ausgeführt, dann erst default.php. Eine Variablenermittlung $uebergabe in default.php wird deshalb nie in mod_test2.php ankommen.
    Den Teil musst also nach mod_test2.php verschieben (wenn du bei deinem eingeschalgenen Weg bleiben willst) und anschließend kann default.php das dann ausgeben.
    (Ich würde die POST-Abfrage wahrscheinlich gleich in die helper.php verschieben, weil dann kannst die modTest2::getDatei() sowohl in der mod_test2.php als auch default.php direjt und ohne Übergabeparameter aufrufen. Dabei auch gleich prüfen, ob der POST-Wert überhaupt existiert und ggf. abbrechen.


    Und wegen Hinweis zu $params oben. $params enthält NICHT Formulardaten, die im Frontend eingegeben wurden, sondern Konfigurationsdaten des Moduls.
    Klar könnte man in $params temporär auch den im Frontend eingeg. Pfad ablegen. (Muss man aber bei diesem Code-Schnipsel nicht, da getDatei() sowieso keine weiteren Konfigurationsparameter verwendet.

    Code
    1. $params->set('uebergabe', $_POST['pfad']);$ausgabevariable = modTest2::getDatei($params);


    und kannst dann wie Robox schreibt in getDatei() auslesen.


    Das hier wird nebenbei ziemlich sehr vermutlich auch nicht funktionieren, da du die deafult.php des Moduls gar nicht direkt aufrufen kannst, selbst wenn der Pfad stimmen würde, was er nicht tut

    Code
    1. <form action="default.php" method="post">


    Du musst unter der action den Pfad der aktuellen Seite hinterlegen, wo das Modul angezeigt wird. Gar nichts geht glaub ich auch.


    Und noch als Tipp, da arbeiten mit $_POST in Joomla "unschön" ist: So macht man korrekt und hat den Vorteil, dass man $_POST['xaz'] gar nicht mehr prüfen muss, sondern einfach einen leeren Wert als Defaultwert eintragen kann und Joomla prüft für dich.
    https://docs.joomla.org/Retrieving_request_data_using_JInput

    Nur so nachgetragen:


    Zumindest für die, die für andere Joomlas aufsetzen, gibt es ja noch die Option im Admin Menu-Modul ein Eigenes Supportforum oder sonstwie benannt (MOD_MENU_HELP_SUPPORT_CUSTOM_FORUM) einzutragen (oder sonstige URL zu Übersichtsseite zu diversen Foren o.ä.).


    Und das "offizielle deutsche" per Sprach-Override (MOD_MENU_HELP_SUPPORT_OFFICIAL_LANGUAGE_FORUM) umzubenennen oder ebenfalls durch anderen Sprachoverride gänzlich zu entfernen (MOD_MENU_HELP_SUPPORT_OFFICIAL_LANGUAGE_FORUM_VALUE="").

    So einfach ist das technisch nicht. Joomla setzt hartkodiert in das Menü ein

    Code
    1. $forum_url = 'http://forum.joomla.org/viewforum.php?f=' . (int) JText::_('MOD_MENU_HELP_SUPPORT_OFFICIAL_LANGUAGE_FORUM_VALUE');


    Meint, Deutsch ist nur eine id = 14. Und die wird per Sprachplatzhalter

    Code
    1. MOD_MENU_HELP_SUPPORT_OFFICIAL_LANGUAGE_FORUM_VALUE="14"


    gesetzt.


    http://forum.joomla.org/viewforum.php?f=14


    Mehr geht derzeit nicht, ohne sicherlich hart diskutierten PR und neuem, alternativen Sprachplatzhalter.

    Sieh es als individuellen Marker für eine einzelne Joomla-Installation an.


    - Änderst ein Secret, werden bspw. alle laufenden Sessions/Cookies ungültig, weil dort das Secret zur """Verschlüsselung""" des CookieNamens verwendet wird.
    Man kann sich aber trotzdem neu anmelden im "normalen Joomla". Erhöht also nicht die Sicherheit. Hast halt mehfache Cookies und Sessioneinträge pro Browser.
    - "Komische Dateinamen", z.B. gelegentlich Cache-Dateien von Erweiterungen. Selbes Spiel. Sind nicht mehr gültig. Cache muss neu erstellt werden.
    - Formular-Tokens (glaub ich zumindest).
    - Ich hab das mal mitverwendet, um eine Erweiterungsinstallation, die sich selber in externer Datenbank registrierte, eindeutig identifizieren zu können (so ne Art Salting), um Lizenzcodes zu generieren. In diesem Fall hätte eine Änderung bspw. zu einer Neuregistrierung der Erweiterung geführt und User hätte neu generierten Lizenzcode in Joomla eingeben müssen, damit wieder läuft.


    Also: Diverse Stellen und Möglichkeiten, ggf. auch lästiges Verhalten bei Änderungen. Mag sein, dass an andern Stellen auch kompletter Kollaps möglich ist(?)