XF2.x [DevPandi] Two Click Embedded Media 1.0.0 Beta 1

[DevPandi]

DevPandi erstellte eine neue Ressource:

[DevPandi] Two Click Embedded Media - Verhindert das sofortige Laden von einbetteten Medien und erfordert einen "Klick".

Ein relativ simples Add-on, dass die sofortige Einbindung von eingebetteten Medien verhindert.Anhang anzeigen 12540
Nutzer müssen den Inhalt über einen zusätzlichen Klick erst aktiv laden, was zumindest im Bereich Datenschutz durchaus eine Erleichterung sein kann.

Nach dem Klick wird der Inhalt entsprechend sofort eingebunden.
Anhang anzeigen 12541

Nutzer können in ihrem Profil die sofortige Einbindung der Inhalte erlauben.
Anhang anzeigen 12539

Die...

Erfahre mehr über diese Ressource...

 

[Kirby]

Funktioniert leider nicht mit X (Twitter), es wird nach dem Klick gar nichts angezeigt - ist vmtl. bei jedem OEmbed-Provider so.
Und z.B. bei Facebook werden schon vor dem Klick Daten von Facebook geladen.

Weitere Anmerkungen

1. Der Namespace für Class Extensions sollte die Quelle vorangestellt haben, d.h. DevPandi\MediaBbCodeTwoClick\XF\...
   Kein Muss, aber Best Practice
2. Listener ist üblicherweise Listener.php im Hauptverzeichnis
   Auch hier kein muss, aber ebenfalls Best Practice
3. JavaScript Files immer kleingeschrieben
4. Im JS nach am besten const anstatt let verwenden wenn nichts verändert wird
   Auch das ist Best Practice
5. Eigenen Namespace nicht unterhalb XF erstellen
6. Einen Ordner js innerhalb des Add-on Odners braucht es nicht, .idea ebensowenig (per build.json ausschließen)
7. Eine description wäre hilfreich in addon.json wäre hilfreich, ebenso ein icon und ggf. support_url (üblicherweise der Thread zum Add-on bei xenforuo.com oder hier)
8. XenForo Code Standard ist Tab für Indent, nicht 4 Spaces
9. Ebenso öffnende geschweifte Klammer in einer neuen Zeile
10. XenForo hat bereits einen Mechanismus um HTML für Embeds nicht aktiv bei der Seitenerzeugung einzufügen, evtl. magst Du dir das mal anschauen

Das alles bitte nicht als Kritik auffassen, nur als Anregungen

 

[DevPandi]

Das alles bitte nicht als Kritik auffassen, nur als Anregungen

Warum sollte ich da böse sein?

Der Namespace für Class Extensions sollte die Quelle vorangestellt haben, d.h. XF\DevPandi\...
Kein Muss, aber Best Practice

Meinst du: class MediaBbCode extends XFCP_MediaBbCode zu XF\DevPandi\MediaBbCode? Wozu dann allgemein der Spaß mit Namespaces ohnehin vorweg? Kann man sich ja gleich schenken. Ansonsten noch mal bitte ein besseres "Beispiel" geben, damit ich das vestehe.

Listener ist üblicherweise Listener.php im Hauptverzeichnis

Genau das habe ich allgemein mal gesucht, wo hin das Zeug soll. Wobei ich das etwas "mäh" finde, aber wird mich nicht umbringen.

JavaScript Files immer kleingeschrieben

Mich macht das ehrlich gesagt irre, dass man dort "so" und an der anderen Stelle "anders" arbeitet. Ich versuche es zu beachten. Mal sehen wie lange mein Autismus damit klarkommt, bis es mich triggert.

Im JS nach am besten const anstatt let verwenden wenn nichts verändert wird
Auch das ist Best Practice

Japp, weiß ich. Danke. Passe ich auch an. - Also auf ToDo.

Eigenen Namespace nicht unterhalb XF erstellen

Jetzt auf JavaScript bezogen? Wenn ja: Danke für den Hinweis. Dann wird das noch mal angepasst.

Einen Ordner js innerhalb des Add-on Odners braucht es nicht, .idea ebensowenig (per build.json ausschließen)

Genau für solche Ratschläge bin ich dann dankbar. build.json soll eh noch angepasst werden. Wobei ich mir endlich wünschen würde, dass XF ihre Dokumentation etwas verbessert. ich such immer noch zu viel.

XenForo Code Standard ist Tab für Indent, nicht 4 Spaces

Ebenso öffnende geschweifte Klammer in einer neuen Zeile

Nein, einfach simple. Ich arbeite da an mehr Projekten und hab mich endlich an PSR-2/PSR-12 gewöhnt und dabei bleibe ich jetzt auch. In den anderen Projekten ist PSR-2/12 Standard und ich will mich da auch nicht mehr umgewöhnen.

Da können die XF-Entwickler hier sogar persönlich mit Knarren auftauchen, dann hole ich allerdings meine Freunde und wir sind viel mehr, dann mischen wir XF auf. *Das war ein Witz! Ich kann verstehen, dass XF sich da ihren Standard gegeben haben, ich will mich jedoch nicht zwischen zig Projekten jedes mal umgewöhnen.

Ansonsten Danke, und natürlich ist das, was du da angebracht hast Kritik, allerdings konstruktiv und ich versuche die auch mitzunehmen. Das mit den listener.php auf der Hauptaddon-Ebene kannte ich so nicht - finde ich auch etwas - bäh, aber ich versuchs mal, ob ichs hinbekomme.

 

[Kirby]

Meinst du: class MediaBbCode extends XFCP_MediaBbCode zu XF\DevPandi\MediaBbCode?

Nein, ich meinte namespace DevPandi\MediaBbCodeTwoClick\XF\BbCode; anstatt namespace DevPandi\MediaBbCodeTwoClick\BbCode;

Warum? So ist das einheitlich, man sieht schon am Namespace der Klasse ob es eine eigene Klasse des jeweiligen Add-on ist oder eine Class Extension.

Fügt z.B. ein Add-on eine neue canXXX Methode auf der User Entity hinzu, man sieht diese in einem Template und will wissen was sie genau macht, dann ist sofort klar der Code ist in <AddOnNamespace>/XF/Entity/User.php

Wenn die Class Extensions irgendwo liegen ist das nicht so klar, da muss man ggf. erst einmal schauen wo denn die Klasse ist.

Genau das habe ich allgemein mal gesucht, wo hin das Zeug soll. Wobei ich das etwas "mäh" finde, aber wird mich nicht umbringen.

Was gefällt dir daran nicht?

Finde ich eigentlich easy zu merken:
Setup Code in Setup.php
Listener in Listener.php

Ist wie gesagt kein muss (und auch von den Add-on Standards her nicht vorgeschrieben) aber halt Best Practice.
Machen XFMG, XFI, XFRM, XFES und vmtl. die meisten 3rd Party Add-ons so - wenn man z.B. die Developer Tools nutzt wird das auch automatisch so vorgeschlagen, man erspart sich somit Klassen- und Methodennamen manuell einzugeben.

Nein, einfach simple. Ich arbeite da an mehr Projekten und hab mich endlich an PSR-2/PSR-12 gewöhnt und dabei bleibe ich jetzt auch. In den anderen Projekten ist PSR-2/12 Standard und ich will mich da auch nicht mehr umgewöhnen.

Durchaus nachvollziehbar, wobei der Trend eigentlich eher wieder von PSR-12 weggeht.
Ich versuche immer Code entsprechend den Standards des jeweiligen Projekts zu veröffentlichen, das macht die Arbeit für alle anderen einfacher wenn der öffentliche Code immer einheitlich ist.
Was spricht dagegen das so zu handhaben, d.h. via build.json php-cs-fixer drüber laufen lassen und fertig?

GitHub - xenforo-ltd/xf-cs-fixer: A PHP Coding Standards Fixer configuration for XenForo

A PHP Coding Standards Fixer configuration for XenForo - xenforo-ltd/xf-cs-fixer

github.com

 

[DevPandi]

Warum? So ist das einheitlich, man sieht schon am Namespace der Klasse ob es eine eigene Klasse des jeweiligen Add-on ist oder eine Class Extension.

Danke, das ist verständlicher und ja, das ist durchaus eine gute Idee.

Was gefällt dir daran nicht?

Weil sowas mit der Zeit zu großen Dateien neigt, wenn man viele "Handler" hat und dann die Dateien wieder schlechter lesbar/wartbar werden. Kann man andersrum aber auch bei vielen Dateien so sehen.

Ich versuche immer Code entsprechend den Standards des jeweiligen Projekts zu veröffentlichen, das macht die Arbeit für alle anderen einfacher wenn der öffentliche Code immer einheitlich ist.

Durchaus verständlich, ist in dem Fall nur, dass man sich ständig selbst umgewöhnen muss. Ich bin froh, wenn ich einen Standard weitgehend durchziehen kann. Solange ich primär alleine daran arbeite, sehe ich aktuell dafür auch keinen Grund.