Conversation

Notices

1. Embed this notice
   Matthias Pfefferle (pfefferle@mastodon.social)'s status on Tuesday, 05-Mar-2024 18:26:02 JST Matthias Pfefferle

   is there a best practice to set plugin default settings or do (db) migrations on plugin install and update?

   #wordpress #plugin #followerpower

   • Embed this notice
     Thomas Kräftner (kraftner@mastodon.social)'s status on Tuesday, 05-Mar-2024 18:34:54 JST Thomas Kräftner

     in reply to

     @pfefferle Whatever you do: Do not (only) rely on hooks that only trigger when using the standard, internal updating mechanism like https://developer.wordpress.org/reference/hooks/upgrader_process_complete/
     There are way too many sites out there that update differently (manual, FTP, composer etc.)
     Generally I'd say have an autoloaded option that stores the current version you compare with the current version. On mismatch start migration.
     Also be careful to handle downgrades or other broken states and not solely rely on version info in the option

   • Embed this notice
     Matthias Pfefferle (pfefferle@mastodon.social)'s status on Tuesday, 05-Mar-2024 18:41:11 JST Matthias Pfefferle

     in reply to

     • Thomas Kräftner

     @kraftner the `upgrader_process_complete` is tricky anyway, because it is triggering the old code!

     I hoped to avoid a regular check to save resources, but there seem to be no alternative :(

     Thanks for your reply!

   • Embed this notice
     Thomas Kräftner (kraftner@mastodon.social)'s status on Tuesday, 05-Mar-2024 18:46:15 JST Thomas Kräftner

     in reply to

     @pfefferle Well it basically is a single "if" comparing a string with an autoloaded option. I'd say the performance impact will be almost impossible to see even in a benchmark. If you've reached that level of performance optimization I really envy your codebase! 😉

   • Embed this notice
     Matthias Pfefferle (pfefferle@mastodon.social)'s status on Wednesday, 06-Mar-2024 01:15:44 JST Matthias Pfefferle

     in reply to

     • Matze
     • Thomas Kräftner

     @matze @kraftner that is very similar to what I am using atm., thanks!

   • Embed this notice
     Matze (matze@dewp.space)'s status on Wednesday, 06-Mar-2024 01:15:59 JST Matze

     in reply to

     • Thomas Kräftner

     @kraftner @pfefferle A while ago, I searched for something similar. All that I found can be viewed in code here:

     https://github.com/epiphyt/embed-privacy/blob/main/inc/class-migration.php

     I hope that helps. 🙂

   • Embed this notice
     Matthias Pfefferle (pfefferle@mastodon.social)'s status on Wednesday, 06-Mar-2024 01:21:17 JST Matthias Pfefferle

     in reply to

     • Giuseppe Mazzapica
     • Thomas Kräftner

     @kraftner @gmazzap I am already using something like you explained: https://github.com/Automattic/wordpress-activitypub/blob/master/includes/class-migration.php

     But I check for the latest version number from the PHP/readme file, so it always has a file-read: https://github.com/Automattic/wordpress-activitypub/blob/master/activitypub.php#L220

     Why you ask? ;)

     Because hate to update the same version number in multiple files, to to avoid inconsistencies.

     Any suggestions for a GitHub Action, that does this properly based on a tag?!?

   • Embed this notice
     Thomas Kräftner (kraftner@mastodon.social)'s status on Wednesday, 06-Mar-2024 01:21:18 JST Thomas Kräftner

     in reply to

     • Giuseppe Mazzapica

     @gmazzap @pfefferle But if the flag is stored in a DB option then never rely on the flag alone because people do "crazy" stuff like downgrade plugin versions . So use it to trigger the migration but then re-check the pre-conditions again. Also make sure that if you run multiple upgrades at once when people do huge version jumps you do them in the right order. I've seen plugins wrecking themselves badly by not paying attention to this. And I've probably missed some more potential issues 🙃

   • Embed this notice
     Giuseppe Mazzapica (gmazzap@phpc.social)'s status on Wednesday, 06-Mar-2024 01:21:19 JST Giuseppe Mazzapica

     in reply to

     • Thomas Kräftner

     @kraftner @pfefferle Also mind multisite. When plugins are installed network-wide, the upgrade/installation process might be seen on only one site (the first hit), but options are site-specific.
     So, really, the best option is to check if what you expect is there with a simple flag, and if not, do it, then set the flag.

   • Embed this notice
     Matthias Pfefferle (pfefferle@mastodon.social)'s status on Wednesday, 06-Mar-2024 04:35:23 JST Matthias Pfefferle

     in reply to

     • Giuseppe Mazzapica
     • Thomas Kräftner

     @gmazzap @kraftner oh nice, thanks!

   • Embed this notice
     Giuseppe Mazzapica (gmazzap@phpc.social)'s status on Wednesday, 06-Mar-2024 04:35:24 JST Giuseppe Mazzapica

     in reply to

     • Thomas Kräftner

     @pfefferle

     1. Have a thing like `%%VERSION%%` in: plugin headers, README.txt|md, package.json, and in the main plugin file have a constant `define('MYPLUGIN_VERSION', '%%VERSION%%')`

     2. Have a GitHub action triggered on tag push that replaces the version before deployment, see https://gist.github.com/gmazzap/ed7a305d55adc7e0238fffa6d66b829d

     - Have code like this to simplify development using the non-built version: see https://3v4l.org/YaGJg

     Disclaimer: none of the code shared above is tested :)

     @kraftner