Beiträge von Re:Later

    Z.B. in der default.php des com_contact/contact/-Overrides: Nach der Zeile

    Code
    1. defined('_JEXEC') or die;

    so:

    Code
    1. defined('_JEXEC') or die;
    2. if ($this->contact->image)
    3. {
    4. $doc = JFactory::getDocument();
    5. $doc->setMetaData('og:image', JUri::root() . $this->contact->image, 'property');
    6. $doc->setMetaData('og:image:secure_url', JUri::root() . $this->contact->image, 'property');
    7. $doc->setMetaData('og:image:alt', $this->contact->name, 'property');
    8. }

    Bei "og:image:alt" habe ich den Kontaktnamen genommen.


    Ich habe keine keine Ahnung was "og:image:secure_url" ist. Hab ich also plump aus deiner Override-Vorlage übernommen ;-)

    Bei Programmierversuchen in der Joomla-Konfiguration am besten immer "Fehler berichten" auf "Maximum" setzen. Schätze mal, dass du dann einen Hinweis bekommen hättest.

    Code
    1. $this->form->setFieldAttribute('contact_subject', 'default', 'Anmeldung zum Kurs ' . $this->contact->name);

    Ob das schon zum Ziel führt, weiß ich nicht, aber jedenfalls mal richtiger als zuvor ;-)

    Warum sieht mein Post #4 jetzt so komisch aus "@@@WCF_LITERAL_AMP@@@" soll natürlich das amp entity sein.

    Das Erscheinungsbild der Webseite auf dem iPad ändert sich über die angeforderte Desktop-Site übrigens überhaupt nicht. Das verstehe wer will, ich nicht!

    Es ändert sich die Info, die an Youtube geht, was, wie gesagt, das Video optimiert für das fragende Gerät auszuliefern versucht. Vielleicht hat auch das iPad und/oder Browser dann noch Krimskrams, das für die finale Videogröße und -qualität verantwortlich ist.

    Wie kann man denn die Qualität der YouTube Videos unter Verwendung von JavaScript im Browser erzwingen? Gibt es dazu Code-Beispiele?

    Wirst im Internet kramen müssen. Vermutlich wird man das irgendwie über die sog. Youtube-API machen müssen. Hauptproblem dabei ist, dass es dazu zu viel Kram im Internet gibt, was längst veraltet ist.

    Leider macht der blöde TinyMCE Editor aus dem & ein & und so funktioniert der zweite Parameter &vq=hd1080 natürlich nicht.

    Es ist in URLs vollkommen richtig @@@WCF_LITERAL_AMP@@@ zum Trennen der Query-Parameter zu verwenden. Oder umgekehrt: Es ist falsch, nur ein & in URLs dafür zu verwenden. Und Youtube versteht das natürlich auch, wenn es @@@WCF_LITERAL_AMP@@@ ist.


    Da der vq-Parameter in keiner aktuellen Anleitung mehr genannt wird und auch in der Vergangenheit nicht immer verlässlich funktionierte, tät ich mal tapfer schätzen, dass das gar nicht mehr so funktioniert und man die Qualität nur unter Verwendung von JavaScript erzwingen kann (Youtube API).


    Youtube liefert das Video passend zur Videoplayer-Größe (und anderen Faktoren) aus. Stallt sich weiters die Frage, warum du bei einem Player 640x320 eine so hohe Auflösung willst. Besser wird da die Qualität dessen, was der Besucher sieht vermutlich nicht.

    Es gab da in meinem Joomlaleben schon mehrere komische Tricks, die dann je nach Browser funktionieren oder plötzlich nicht mehr.

    Also musterfrau, mustermann gibt's schon. Jetzt will ich muster neu eingeben und im Ausklappmenü wird mir die musterfrau blau markiert.


    z.B. konnte man auf die eingefetteten Zwischenüberschriften mit gehaltener STRG-Taste klicken, um die musterfrau zu entmarkieren. Geht wohl im aktuellen Firefox nicht mehr.


    Was geht, ist mit der Maus über die blaue Frau fahren, ohne Klick oder irgendwas halten, und den Mauszeiger dann nach links rausziehen aus der Markierung oder einfach über die Dropdownliste "wedeln". Dann verschwindet die Markierung. Maus loslassen, während die Liste ohne Markierung offenbleibt. Und man kann das "muster" per Enter eintragen. Ein Hoch auf Mäuse.

    Wenn, dann irgendwo im Frontend. Vielleicht, wenn du einen fehlerhaften Link aufrufst. An welcher Stelle genau, kann man nicht sagen. Seite dann mal durchscrollen, ob irgendwo mittendrin.


    Die Meldungen lauten dann irgendwie so ähnlich:

    Zitat

    Notice: Undefined index: IRGENDWAS in /irgendwo.php on line 10

    Gibt es für deine Versionierung andere Vorteile, als dass man das Datum der Version auf den ersten Blick sieht?

    Nein. Abgesehen von dem Vorteil für mich, dass ich nicht lang rumsuchen muss in meinem Chaos, welche Version denn heute dran ist. Außerdem hift es mir bei der Zusammenführung/Abgrenzung von "temporären Parallelversionen", die hier und da zum Einsatz kommen und von denen dann vielleicht das eine oder andere Feature in die "Hauptlinie" übernommen wird. Ändere ich in irgendeiner Online-Seite was, trage ich im jeweiligen Manifest-XML einfach plump die neue Datums-Version ein plus kleinem Vermerk in eigenem Tag, auch in dieser XML und kann das dann beim Zusammenführen (oder nicht) mit einem kleinen XML-Reader-Script schon mal grob sondieren, was da so los war.


    Kurz: Reiner Erfahrungswert bzgl. meiner Arbeit.

    Na ja, du wirst doch wenigstens wissen, ob die Seiten beim selben Provider unter dem selben Provider-Account laufen.


    Und das "Fehler berichten" kann jeder einstellen, der im Backend Zugriff auf die Joomla-Konfiguration hat. Vielleicht hast ja Glück und es erscheint eine Meldung der Art "Notice: Undefined index ...." usw.

    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