[WIP] Full addons support

BoboTiG commented 8 years ago

(I copied the PR discussion here to keep a trace.)

Work list:

[x] [addon] add specific CSS and JS files (commit 5e684e4875f5cee94b61b44606181ba2dce5ccac)
[x] [addon] add optional URL for support (commit 95a08d31ae13543a6b1f6252ccffc20c2cf6c4da)
[x] [addon] name and description translations (commit 95a08d31ae13543a6b1f6252ccffc20c2cf6c4da)
[x] [admin] disable/enable addons (commit 5e684e4875f5cee94b61b44606181ba2dce5ccac)
[x] [admin] rework addons presentation (commit 3e69e111ffc296f092beefb2d3d86bee142e6dff)
[x] [admin] move the menu entry to the floating menu in the right corner (commit 3e69e111ffc296f092beefb2d3d86bee142e6dff)
[x] [admin] find an icon for the menu entry (commit 3e69e111ffc296f092beefb2d3d86bee142e6dff)

Ideas:

[addon] add icon?
[admin] remove addons?

Missing something?

See addons/calendar/calendar.php for good explanations. There are few simple rules to follow when you write your own addon.

Important changes:

[themes] use {includes.css} between head blocks (like any CSS file) to include both current theme and addons styles
[themes] Use {includes.js} to include all JS files needed by addons (in the bottom page, do not load scripts in the head block)
[addons] for styles, do not add @charset, it is defined by default before any import
[addons] each addon has its own directory into addons based on this scheme: addons/addon_tag/addon_tag.php.

Breaking changes:

[addons] renamed "calendrier" to "calendar"
[addons] to include an addon, use this scheme: {addon_NAME} where NAME is the addon tag

remrem commented 8 years ago

Hello,

serai-t'il possible d'ajouter une modification au support des addons afin d'avoir la possibilité que le tag d'un addon ajouté dans chaque articles, ou qui reviens plusieurs fois dans le template, soit traités indépendamment ?

En modifiant dans /inc/them.php dans la fonction conversion_theme_addons()

if ($addons_status[$addon['tag']] && function_exists($callback)) {
    $texte = str_replace($look_for, call_user_func($callback), $texte);
} else {
    $texte = str_replace($look_for, '', $texte);
}

par

if ($addons_status[$addon['tag']] && function_exists($callback)) {
               // à valider/corriger, fait de tête..
        $pos = strpos($texte, $look_for);
                $strlen = strlen($look_for);
        while ( $pos !== false ) {
            $texte = substr_replace($texte, call_user_func( $callback ), $pos , $strlen );
            $pos = strpos($texte, $look_for);
        }
} else {
    $texte = str_replace($look_for, '', $texte);
}

Ou en plus élégant, l'essentiel serait qu'un plugin puisse pouvoir traiter différemment chaque tag intégré. On peut même pousser un peu plus loin en ajoutant un "paramètre" dans la "déclaration" du plugin et adapter le code proposé en fonction de se paramètre :

$GLOBALS['addons'][] = array(
                           'tag' => '{calendrier}',
                           'callback_function' => 'addon_calendrier',
                           'multiple_independant_tag' => true // bool
             );

Ainsi je pourrais utiliser les addons que j'ai développé sans avoir à modifier le coeur de blogotext à chaque mise à jour et les rendre publique ;) (image dans chapo entre autres addons)

BoboTiG commented 8 years ago

Salut remrem,

Si j'ai bien compris, tu souhaiterais qu'il y ait un autre tag, en plus de celui du module, pour faire des traitements ailleurs que juste à l'endroit d'inclusion du module ?

remrem commented 8 years ago

Salut BoboTiG,

pas forcément un autre tag, plutôt quelque chose dans le genre 1 insertion du tag = 1 appel de la fonction de traitement. Si le développeur d'un addon ne souhaite pas cette politique, à lui de mettre en place un "cache" du résultat de son traitement dans une variable globale, ou voir ma dernière proposition dans mon post précédent.

Je peux poster un commit dans la journée et à charge de la communauté & timo de valider .. ?

timovn commented 8 years ago

Si je comprends bien, tu veux que les add-ons puissent avoir accès au contenu des articles/commentaires de façon indépendants. Par exemple, pour un add-on qui fait un lien "partagez-moi sur facebook", on a besoin du titre de chaque article et d’un lien spécifique.

C’est bien ça ?

Actuellement c’est vrai que les tags des addons ne fonctionnent que pour les éléments du blog, pas pour les éléments relatifs à un article ou un commentaires (ceux dans une {BOUCLE_*}).

Il est prévu que ça soit possible, les add-ons seront alors traités différemment selon qu’ils ciblent du contenu propre à un élément (article…) ou du contenu indépendant (comme le calendrier).

Il faudrait effectivement un "parse_addon" quelque part dans les conversions_theme_article et consors.

remrem commented 8 years ago

Yep, dans le commit que j'ai poussé #72 , ça permet de le faire en jouant avec$GLOBALS['billets'][$compteur_apel_fonction] qui me permet d'avoir accès au contenu de chaque article. Voir le plugin en question https://github.com/remrem/bogotext-chapo-img/blob/master/addon_chapo_img.php

Autre piste : ajouter un système de hook à différents points clés des processus de blogotext, mais je pense qu'il faudrait en discuter ailleurs afin d'éviter de trop pourrir ce topic ;)

timovn commented 8 years ago

Un système de hook serait à la fois trop lourd et trop de travail. Actuellement le code HTML produit se fait à un seul endroit, au niveau des fonctions conversion_themes*, et je pense que c’est là qu’on doit placer la conversion avec les addons.

remrem commented 8 years ago

Je finalise un POC en ce moment même, je le pousse sur mon fork dans la journée, si ça te dis de jeter un coup d'oeil...

remrem commented 8 years ago

(updated 2016/08/28) POC disponible : https://github.com/remrem/blogotext/tree/poc-hook plugin de test (url rewrite) POC : https://github.com/remrem/blogotext_light_seo

Pour le système de hook, j'ai utilisé et adapté : https://github.com/DirtyScript/hook

Il y a encore un peu de travail (sécurité), cleaning, ajouté des hooks et mettre en place une doc, je ne pousse pas plus loin pour l'instant sauf si vous validez.

remrem commented 8 years ago

J'ai ajouté un système d'options/paramètres pour les plugins + une modif sur la base de données pour sauvegarder les nouveaux paramètres. Il y a un petit coup de polish à donner sur le formulaire/css pour que ça soit plus cohérent et plus secure (token ?). Il faut aussi que j'étende le type de paramètres pris en charge (actuellement INT, BOOL et STRING). Voir le pull request #77

BoboTiG commented 7 years ago

Je ferme, @remrem peux-tu réouvrir d'autres PR/issues avec le code à jour ? Plutôt que de toucher à la BDD, il serait plus intéressant d'utiliser des fichiers de configuration ini dans chaque dossier des addons. Qu'en penses-tu ?

remrem commented 7 years ago

Ok, j'essaie de faire ça cette semaine.

BoboTiG commented 7 years ago

Ah oui, aussi, le dépôt des addons est migré ici : https://github.com/BoboTiG/blogotext-addons

remrem commented 7 years ago

Vu ;) testing est mort ? Direct sur dev ?

BoboTiG commented 7 years ago

Yep !

BoboTiG commented 7 years ago

J'y pense, tu pourras en profiter pour ajouter tes infos dans le fichier CONTRIBUTORS :)

BlogoText / blogotext

[WIP] Full addons support #70