Comments (12)
Author: @freakerz
Could we do a "clean plugin options" for all current options/plugins on top of that checkbox?
Not sure how it could work, but we can surely find a way.
from habari.
Author: @arickmann
I proposed a system for another platform which allowed the plugin author to register the assets the plugin was going to use, i.e. files, options, new database tables, etc, when it was first installed.
The idea being that the plugin could be uninstalled by the system instead of relying on the plugin to trigger it.
If assets have been registered then an uninstall link can be added beneath deactivate that would uninstall and deactivate.
I think this is a little more seamless than a checkbox.
from habari.
Author: @freakerz
arickmann, that is what was discussed further on in IRC... can you elaborate on how you achieved this?
from habari.
Author: @arickmann
Replying to [comment:5 freakerz]:
arickmann, that is what was discussed further on in IRC... can you elaborate on how you achieved this?
What I did was really pretty basic. I created a function, register_plugin_assets, that accepted the plugin file name, an array of tables, an array of options, and a callback.
A subsequent function added the option to uninstall the plugin to the action list if the plugin was deactivated and called a script that would either remove all the assets, or call reactivate the plugin, call the callback function, and deactivate it again.
from habari.
Author: @michaeltwofish
Replying to [comment:6 arickmann]:
What I did was really pretty basic. I created a function, register_plugin_assets, that accepted the plugin file name, an array of tables, an array of options, and a callback.
A subsequent function added the option to uninstall the plugin to the action list if the plugin was deactivated and called a script that would either remove all the assets, or call reactivate the plugin, call the callback function, and deactivate it again.
I like this idea. If an active plugin's directory is deleted, the plugin page could have an option to clean its assets, instead of just leaving it in the active list forever, waiting for it to return.
from habari.
Author: @lildude
If and when this gets implemented, it needs to be implemented for themes too as they too can store options and themes will definitely lead to DB bloat.
With the change implemented in r5022, theme previews now save options to the DB too.
from habari.
Ticket imported from Trac:
http://trac.habariproject.org/habari/ticket/346
from habari.
Another method we could implement for this would be to encourage, and possible enforce, that plugins and themes always store their options be preceding the defined option name with the class name used by the plugin.
A lot of plugins already store all options using something like
$ui->append( 'checkbox', 'myoption', __CLASS__ . '__myoption', _t( 'This is my option' ) );
So I don't think much more work would be needed other than changing peoples behaviour and a few plugins. We could then implement code which could check the existence of __CLASS__
options against the currently installed plugins and themes and then offer the admin the various purge options etc.
from habari.
Some thoughts. Possibly should write to the database instead of using the cache.
Well-behaved addons implement the following, where assets could be files, database tables, options, etc:
private $assets = array(__CLASS__ => array(
'files' => array('list', 'of', 'files'),
'db_tables' => array('table')
));
public function filter_addon_assets($assets) {
return array_merge($assets, $this->assets);
}
On plugin init we do the following (psuedocode-ish):
$assets = Plugins::filter('addon_assets', array());
$cached = Cache::get('addon_assets');
$deleted = array();
foreach ($cached as $addon => $cache) {
// Check if the addon is no longer announcing assets (may have been deleted)
if (!array_key_exists($addon, $assets))
$deleted[$addon] = $cache;
// Find released assets (assets previously but no longer referred to)
$released[$addon] = $cache - $assets[$addon];
}
// store $released, a daily Cron job will remove the assets
// store $deleted, users with permission will be asked if they want to clean the assets
// Refresh the cache
Cache::set('addon_assets', $assets);
On the plugins and themes pages, we add 'clean' to the dropdown (not delete or uninstall unless we're actually going to remove the files). In Pluggable we add (psuedocode-ish):
public static clean($addon) {
// Check the type somehow. Maybe pass in a flag?.
// Deactivate the addon if it's active
// Remove its registered assets
$cached = Cache::get('addon_assets');
$cache = $cached[$addon];
// Delete files
// Drop tables
// Remove options
// Do whatever else you have to do
}
from habari.
@ringmaster expressed some concern that the garbage collection was done with Cron rather than a specific action. I didn't get to ask him what specific action he meant though.
from habari.
There's a branch for this, but I ran out of ergs. https://github.com/habari/system/tree/%2310
from habari.
@chrismeller initially was concerned what to do with posts a plugin created. That made me think of another thing that comes up every now and then: When a plugin that provides a custom content type is deactivated, what should happen to the posts of that type? I would definitely not want to have them deleted automatically.
from habari.
Related Issues (20)
- Provide predefined search criteria where we use faceted search HOT 1
- Logging modules are inconsequent
- Log "type" column should be removed
- Plugin wishlist: encrypted mail HOT 1
- Force changing auto-generated passwords on password reset
- Allow passwords to expire
- Dashboard welcome message does not disappear because isset($user->info->bla) does not work
- Aggregate Control does not work on dynamically added elements HOT 1
- FormControlRadio Missing HOT 1
- Menu hotkeys broken - submenu hotkeys always use first submenu
- Do not allow to create invalid faceted searches
- FormControl File missing HOT 1
- Faceted search has internationalization issues HOT 1
- Utils::mail() ignores filter
- "Use the importer" displays even if no importer is present
- Password reset form logs in when hitting enter
- missing PDO driver names not populated in installer dropdown.
- Date format hint on publish page is unnecessary
- SSL HOT 3
- habari and PHP 7.2 HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from habari.