Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot disable "default" plugins #1427

Closed
pstadt opened this issue May 5, 2016 · 13 comments

Comments

@pstadt
Copy link

commented May 5, 2016

With release 0.9.2 I tried to disable the plugin "Public Comments" aka "Comments".
The Admin GUI always reported "The plugin was uninstalled." but every time it was marked "enabled" again in the list (and the plugin was active).

For a test I removed in Idno/Core/Config.php from config -> plugins Comments and Media.
Now I was able to disable those two plugins via Admin GUI and they were no longer active.
I cannot disable all other listed "default plugins", so it looks like this list of initial? default plugins is merged in at a time into the list of active plugins.

@rikmendes

This comment has been minimized.

Copy link

commented May 5, 2016

There is a simple switch to turn plug-ins completely off on the config.ini
at the root of your known installation.

I'm outdoor right now can't check it up but it's on the documentation.
Le 5 mai 2016 12:59, "Oliver Paukstadt" notifications@github.com a écrit :

With release 0.9.2 I tried to disable the plugin "Public Comments" aka
"Comments".
The Admin GUI always reported "The plugin was uninstalled." but every time
it was marked "enabled" again in the list (and the plugin was active).

For a test I removed in Idno/Core/Config.php from config -> plugins
Comments and Media.
Now I was able to disable those two plugins via Admin GUI and they were no
longer active.
I cannot disable all other listed "default plugins", so it looks like this
list of initial? default plugins is merged in at a time into the list of
active plugins.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1427

@pstadt

This comment has been minimized.

Copy link
Author

commented May 5, 2016

No, I don't want to disable all plugins. I only want to disable specific plugins, but I cannot disable those plugins which are listed in Idno/Core/Config.php as default. They are automatically reenabled all the time.

@kylewm

This comment has been minimized.

Copy link
Collaborator

commented May 5, 2016

@pstadt I think this is a bug, but you can work around it with the config setting Rick was alluding to. You'd want to set:

antiplugins[] = 'Comments'

in config.ini

@kylewm

This comment has been minimized.

Copy link
Collaborator

commented May 5, 2016

This change seems to be the culprit: 3db80d2 specifically the change from array_merge to array_replace_recursive.

If I have a list of default plugins:

'plugins' => array(
 [0] => "Status",
 [1] => "Text",
 [2] => "Comments",
)

and try to "replace" that with the saved set of plugins from the DB (where Comments has been disabled -- notice that index 2 is missing):

'plugins' => array(
 [0] => "Status",
 [1] => "Text",
 [3] => "Twitter",
 [4] => "Facebook"
)

then I get a new array with Comments restored:

'plugins' => array(
 [0] => "Status",
 [1] => "Text",
 [2] => "Comments",
 [3] => "Twitter",
 [4] => "Facebook"
)
@rikmendes

This comment has been minimized.

Copy link

commented May 6, 2016

You dont need to disable all plugins. that's the point of config.ini : to disable or enable specific items without having to mess in the code.

@pstadt

This comment has been minimized.

Copy link
Author

commented May 6, 2016

@rikmendes I don't want to mess with the code. See it as a kind of debugging support to understand the problem.

@cannod

This comment has been minimized.

Copy link

commented Jun 19, 2016

Have just installed a fresh install of 0.9.2 and can confirm that I also see this bug. Disabling a Plugin from Plugins page does not work as @pstadt described.

@ghost

This comment has been minimized.

Copy link

commented Aug 24, 2016

Same here.

@kreativmind

This comment has been minimized.

Copy link

commented Oct 3, 2016

Just delete the folder of the plugin you don't want to use from your idno/plugins folder and all is well. It will go away from the site and your homepage too will reflect that as well. For example, delete the media plugin folder and you will see that audio is no longer in the enable/disable plug-ins list and also, the homepage will not show the icon to create a new audio post anymore.

@benwerd

This comment has been minimized.

Copy link
Member

commented Oct 4, 2016

This will be fixed in the next release.

@mapkyca

This comment has been minimized.

Copy link
Member

commented Jan 1, 2017

Is this still an issue on the current version in git?

@kreativmind

This comment has been minimized.

Copy link

commented Jan 1, 2017

Probably so. I haven't seen any updates yet about it being resolved. Nor has a new release come out that I know of.

@mapkyca

This comment has been minimized.

Copy link
Member

commented Jan 10, 2017

I've been looking into this a little bit as part of addressing some other issues and I think we have a conceptual conflict going on somewhere... basically we're setting a "initial_plugins" default, which is merged with the database loaded version and replaces any missing values (since it's not possible to tombstone or anything).

Interestingly, if there is a host specific config.ini present the ini loaded version of "initial_plugins" is unset, which explains why we're seeing this on hosted and some self hosted services, but I'm not seeing it on my own site (which uses host specific configs).

I think the least worst option would be to unset the ini loaded version of "initial_plugins" if a database defined version is present. This will allow plugins to be toggled and a site created with an initial list of activated plugins... however it will prevent us from using initial_plugins to activate new plugins on old sites by modifying the config file.

Given that initial_plugins is unset before loading host specific ini files, I'm guessing this was the intent...

mapkyca added a commit to mapkyca/idno that referenced this issue Jan 10, 2017

@mapkyca mapkyca closed this in 2cba7b2 Jan 11, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.