Recherche avancée

Sur d’autres sites (8498)

• To all Matomo plugin developers : Matomo 5 is coming, make your plugin compatible now

  5 mai 2023, par Matomo Core Team — Development

  We’re planning to release the first beta of Matomo 5 in a few weeks. For making it easy for Matomo users to be able to upgrade to this beta, it would be great to have as many plugins on the Marketplace as possible already updated and compatible with Matomo 5. Then many users would be able to upgrade to the first beta without any issues.

  Presumably, as you put your plugin on our Marketplace, you want people to use it. Making your plugin compatible with Matomo 5 helps ensure that people will be able to find and keep using your plugin. If your plugin is not compatible with Matomo 5, your plugin will be automatically deactivated in Matomo 5 instances. We’ll be happy to help you achieve compatibility should there be any issue.

  How do I upgrade my Matomo instance to Matomo 5 ?

  If you have installed your Matomo development environment through git, you can simply checkout the Matomo 5 branch “5.x-dev” and install its dependencies by executing these commands :

  • git checkout 5.x-dev
  • composer install

  Alternatively, you can also download the latest version directly from GitHub as a zip file and run composer install afterwards.

  How do I upgrade my plugin to Matomo 5 ?

  • We recommend you create a new branch for your plugin that supports Matomo 5. For example a branch named “5.x-dev“. This way you will be able to make changes to your plugin for Matomo 4 and Matomo 5 and release separate versions.
  • Check out our migration guide from Matomo 4 to Matomo 5 and make sure to review the list of all breaking changes.
  • Release a new version of your plugin in GitHub as usual.

  While there are some breaking changes in Matomo 5, most of our Platform APIs remain unchanged, and almost all changes are for rarely used APIs. Quite often, making your plugin compatible with Matomo 5 will just be a matter of adjusting the “plugin.json” file (as mentioned in the migration guide).

  You can find all developer documentation on our developer zone which has already been updated for Matomo 5.

  How do I know my plugin changes were released successfully ?

  If you have configured an email address within your “plugin.json” file, then you will receive a confirmation or an error email within a few minutes. Alternatively, you can also check out your plugin page on the Marketplace directly. If the plugin release was successful, you will see additional links below the download button showing which versions your plugin is compatible with.

  

  How can switch between Matomo 4 and Matomo 5 or downgrade to Matomo 4 ?

  To downgrade from Matomo 5 to Matomo 4 in your Matomo development environment :

  • check out the “4.x-dev” branch 
  • run “composer install” as usual

  When will the final Matomo 5 release be available ?

  We estimate the final stable Matomo 5.0.0 release will be released in approx. 2-3 months.

  What is new in Matomo 5 ?

  We don’t have a summary of the changes available just yet but you can see all closed issues within this release here.

  Any questions or need help ?

  If you have any questions, or experience any problems during the migration, don’t hesitate to get in touch with us. We’ll be happy to help get your plugin compatible and the update published. If you find any undocumented breaking change or find any step during the migration process not clear, please let us know as well.

  Thank you for contributing a plugin to the Marketplace and making Matomo better. We really appreciate your work !

• Evolution #4223 (Nouveau) : étendre le pipeline notifications_envoyer_mails

  14 novembre 2018, par Maïeul Rouquette

  inc/notifications.php sous spip 3.2 l.143

     foreach ($emails as $email) {
       // passer dans un pipeline qui permet un ajout eventuel
       // (url de suivi des notifications par exemple)
       $envoi = pipeline('notifications_envoyer_mails', array('email' => $email, 'sujet' => $sujet, 'texte' => $texte));
       $email = $envoi['email'];

       job_queue_add('envoyer_mail', ">$email : " . $envoi['sujet'],
           array($email, $envoi['sujet'], $envoi['texte'], $from, $headers), 'inc/');
   }

  a remplacer par

     foreach ($emails as $email) {
       // passer dans un pipeline qui permet un ajout eventuel
       // (url de suivi des notifications par exemple)
       $envoi = pipeline('notifications_envoyer_mails', array('email' => $email, 'sujet' => $sujet, 'texte' => $texte,'from'=>$from,'headers'=>$headers));
       $email = $envoi['email'];

       job_queue_add('envoyer_mail', ">$email : " . $envoi['sujet'],
           array($email, $envoi['sujet'], $envoi['texte'], $envoi['from'], $envoi['headers']), 'inc/');
   }

  
  (non testé, codé à la volée)
  but : pouvoir modifier le champ from via un pipeline afin, par ex, d’avoir un from qui utilise la personne qui crée un compte plutôt que l’email generique.

• Evolution #4281 : Extension du critère secteur (à l’id_groupe en plus de l’id_rubrique)

  13 février 2019, par Naema *

  Merci tcharlss pour cette réponse,
  qui plus est, est beaucoup moins désagréable que la précédente. Mon message
  est une suggestion, et je vais de mon côté me renseigner sur cette API et
  ce plugin "déclarer parents". Merci.

  Cordialement

  Le mer. 13 févr. 2019 à 15:50, <redmine@spip.org> a écrit :

  La demande #4281 <https://core.spip.net/issues/4281#change-14733> a été
  mise à jour par tcharlss (*´_ゝ｀).

  Avec l’API de déclaration des parents qui est en test dans le plugin « 
  déclarer parents », il est envisageable d’avoir un critère générique qui
  marche sur tous les types d’objets.
  Un critère racine par exemple.
  ------------------------------
  Evolution #4281 : Extension du critère secteur (à l’id_groupe en plus de
  l’id_rubrique) <https://core.spip.net/issues/4281#change-14733>

  - Auteur : Naema *
  - Statut : En cours
  - Priorité : Normal
  - Assigné à :
  - Catégorie : filtres et balises
  - Version cible : 4.0
  - Resolution :

  Bonjour,
  une simple suggestion (et mes excuses si c’est déjà effectué ou sur les
  rails) : le secteur est actuellement la rubrique racine de l’objet, ce qui
  permet de shunter toute l’arborescence hiérarchique et de définir finement
  les critères d’affichage d’une boucle sans se préoccuper de la hiérarchie
  intermédiaire. C’est un excellent système et je me demande s’il est
  possible de l’étendre à la notion de id_groupe, pour les objets éditoriaux
  qui ne sont pas reliés à des rubriques (comme par ex. les auteurs, ou à un
  autre objet éditorial créé de novo). On peut bien sûr utiliser
  l’id_parent pour affiner aussi, mais dans le cas où l’id_parent est
  attribué au groupe et non à l’objet lui-même, il manque juste une petite
  solution. Merci !
  ------------------------------

  Vous recevez ce mail car vous êtes impliqués sur ce projet.
  Pour changer les préférences d’envoi de mail, allez sur
  http://core.spip.net/my/account