TGM Plugin Activation is a PHP library that allows you to easily require or recommend plugins for your WordPress themes (and plugins). It allows your users to install, update and even automatically activate plugins in singular or bulk fashion using native WordPress classes, functions and interfaces. You can reference bundled plugins, plugins from the WordPress Plugin Repository or even plugins hosted elsewhere on the internet.
I experiment conflict between a theme, third-party plugins and my own pluging i'm writing. All using TGM_Plugin_Activation (since it is a great tool, thanks folk).
I require not dismissable notice since my dependency is required.
But the theme set its own dismissable=true. And TGM remembers only the last who talked.
In addition, if I already dismiss the theme notice, mine will never appear (I spend a lot of time figure it).
So, actual solution is hook with low priority. But when all plugins ends with php_int_max, we fail back in trouble.
The best (in my mind) solution should be to have one config by given "id" (actually not very usefull key) and independent notice (install page still can be merged).
What do you think about that?
For now, what I plan to do is extend your class, overload config() function to keep, for each key, the most restrictive value instead erasing previous one.
Then, I set an instance of my extended class in $GLOBALS['tgmpa'].
This second method could be a good compromise too if implemented by default.
I got the most recent version of TGM (actually 2.6.1)
I experiment conflict between a theme, third-party plugins and my own pluging i'm writing. All using TGM_Plugin_Activation (since it is a great tool, thanks folk).
I require not dismissable notice since my dependency is required. But the theme set its own dismissable=true. And TGM remembers only the last who talked. In addition, if I already dismiss the theme notice, mine will never appear (I spend a lot of time figure it).
So, actual solution is hook with low priority. But when all plugins ends with php_int_max, we fail back in trouble.
The best (in my mind) solution should be to have one config by given "id" (actually not very usefull key) and independent notice (install page still can be merged).
What do you think about that?
For now, what I plan to do is extend your class, overload config() function to keep, for each key, the most restrictive value instead erasing previous one. Then, I set an instance of my extended class in $GLOBALS['tgmpa'].
This second method could be a good compromise too if implemented by default.
I got the most recent version of TGM (actually 2.6.1)