Make WordPress Core

Opened 11 years ago

Closed 4 years ago

Last modified 4 years ago

#25137 closed feature request (duplicate)

Enable safe mode to run WordPress without loading plugins

Reported by: knutsp's profile knutsp Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.6
Component: Bootstrap/Load Keywords: dev-feedback
Focuses: Cc:

Description

One of the most used phrases in support is something like "Please deactivate all plugins and activate the default theme to see if the problem is still there".

Could it be possible to use a specially crafted URL to let an administrator log in, loading WordPress with no plugins and the default theme, in a safe way that, would enable such administrator to permanently disable all plugins and activating the default theme, for finding the offensive plugin or theme?

I know the plugin Safe Mode http://wordpress.org/plugins/safe-mode/ has made an attempt to prove the concept, but I think a better, more reliable and safer way could be included in core.

Change History (32)

#1 @nofearinc
11 years ago

  • Cc mario@… added

#2 @c3mdigital
11 years ago

  • Keywords dev-feedback added

I like this idea in theory but there are concerns like undefined function fatal errors and what would be the best process for doing this. I did a quick test of this concept by adding the following to a mu-plugin:

add_filter( 'option_active_plugins', '__return_empty_array' );

All plugins were temporarily disabled. The next question would be how would this be enabled? If we set an option and something breaks it might be hard to recover. A $_GET parameter would work but there are security concerns.

#3 @toscho
11 years ago

  • Cc info@… added

#4 follow-up: @knutsp
11 years ago

The main concern for me has been plugins that restricts login or enhances login security. These should ideally (?) be MU plugins, but I see no way to force them to be.

May we maintain a list of plugins that has a special header, or has registered themselves for such list, indicating it can't or shouldn't be deactivated in "safe mode"? Or more generally, user could also be warned when deactivating such plugins manually.

And when "safe mode" is active for a session, only users with the "activate_plugins" capability should be allowed to log in.

#5 @DrewAPicture
11 years ago

  • Cc xoodrew@… added

#6 in reply to: ↑ 4 ; follow-up: @toscho
11 years ago

Replying to knutsp:

May we maintain a list of plugins that has a special header, or has registered themselves for such list, indicating it can't or shouldn't be deactivated in "safe mode"? Or more generally, user could also be warned when deactivating such plugins manually.

Safe mode should run a default WordPress. Especially security plugins do strange things sometimes, they might be the reason for a broken site.

And when "safe mode" is active for a session, only users with the "activate_plugins" capability should be allowed to log in.

Plugins can change capabilities. Looks like a chicken-egg problem. :)

How it could work: the user sets a secret URL parameter in the back-end to enable safe mode. Maybe add a column to the plugin list to mark plugins that should be enabled in safe mode.

I think this is plugin territory.

#7 follow-up: @SergeyBiryukov
11 years ago

Enabling and disabling safe mode should be as transparent as possible. I'm aware of the "Decisions, not Options" philosophy, but this sounds like a good case for a UI option in the admin to me.

Last edited 11 years ago by SergeyBiryukov (previous) (diff)

#8 in reply to: ↑ 6 ; follow-up: @knutsp
11 years ago

Replying to toscho:

Safe mode should run a default WordPress. Especially security plugins do strange things sometimes, they might be the reason for a broken site.

They certainly do. As some sites rely on some security enhancements, like admin lock down for a period, we must not allow this to bypassed without some strong, secret key.

How it could work: the user sets a secret URL parameter in the back-end to enable safe mode.

A long, secret parameter value seems best. No plugins loaded while this is in place and verified, except mu-plugins. Admin users are advised to bookmark this "safe mode" URL, after install or upgrade. When a user is logged in with this parameter key/value present, and has the right capability, all plugins are immediately deactivated, with a message and a visit plugins page link.

This could even be enhanced through a two-step procedure. Step one is a request for the secret URL to be emailed back to the admin user, in case he has forgotten to bookmark it. This would have to happen outside of the admin, but with username/password, through a wp-get-safe-mode-url.php, and with no other indication of success but the email silently being sent.

New features as plugin first.

Last edited 11 years ago by knutsp (previous) (diff)

#9 in reply to: ↑ 8 ; follow-up: @rmccue
11 years ago

Replying to knutsp:

A long, secret parameter value seems best. No plugins loaded while this is in place and verified, except mu-plugins. Admin users are advised to bookmark this "safe mode" URL, after install or upgrade. When a user is logged in with this parameter key/value present, and has the right capability, all plugins are immediately deactivated, with a message and a visit plugins page link.

Disagree with this approach. If we were to implemented, I think it should be simple:

define('WP_DISABLE_PLUGINS', true);

Anything else is IMO too complicated for something that's only really used during debugging.

#10 in reply to: ↑ 9 ; follow-up: @knutsp
11 years ago

Replying to rmccue:

Disagree with this approach. If we were to implemented, I think it should be simple:

define('WP_DISABLE_PLUGINS', true);

Anything else is IMO too complicated for something that's only really used during debugging.

Even "simpler" to rename the plugins folder. The target users for this enhancement should be those who don't know how to edit wp-config.php or to rename a folder. There is no need to use FTP to run WordPress today, except when an unexpected fatal error occurs, perhaps after an update. Clicking on a "safety" bookmark or a URL in an email, is something they can do.

I still think this can be implemented without being too complicated, still safe. A plugin may demonstrate. Case could rest until it's made. I can try.

#11 in reply to: ↑ 10 ; follow-up: @c3mdigital
11 years ago

Replying to knutsp:

Replying to rmccue:
Even "simpler" to rename the plugins folder. The target users for this enhancement should be those who don't know how to edit wp-config.php or to rename a folder. There is no need to use FTP to run WordPress today, except when an unexpected fatal error occurs, perhaps after an update. Clicking on a "safety" bookmark or a URL in an email, is something they can do.

I still think this can be implemented without being too complicated, still safe. A plugin may demonstrate. Case could rest until it's made. I can try.

I don't think we should deactivate the plugins only prevent them from loading so you can switch back and forth easily.

I created a proof of concept mu-plugin using rmccue's suggestion of defining a constant.
https://github.com/x-team/plugin-safe-mode

#12 in reply to: ↑ 7 @SergeyBiryukov
11 years ago

Replying to SergeyBiryukov:

this sounds like a good case for a UI option in the admin to me.

Just realized that an option is not helpful if the admin is inaccessible due to a fatal error. I guess I'd prefer the suggestion in comment:8 then. In most cases where safe mode would be used, the user would still have to deactivate and re-activate plugins one by one to find the culprit, so automatic deactivation makes sense to me.

Last edited 11 years ago by SergeyBiryukov (previous) (diff)

#13 in reply to: ↑ 11 @knutsp
11 years ago

Replying to c3mdigital:

I don't think we should deactivate the plugins only prevent them from loading so you can switch back and forth easily.

The reason for deactivating all is to be able immediately leave the "safe mode" and start activating plugins one by one. They will be listed under "recently active", as usual, or we create a new filter "Deactivated by safe mode".

#14 @Bueltge
11 years ago

  • Cc frank@… added

I like the idea. The save mode is a fast option to help users, custumors. Currently I have a custom solution inside the plugin Debug Objects.
https://github.com/bueltge/Debug-Objects/blob/master/inc/class-default_mode.php

But the topic is more complex for me. It is possible to deactivate plugins and switch the theme to a default theme. But Is not so easy to change the roles and capabilities to the defaults, but is also often a topic on debugging.

#15 follow-up: @nacin
11 years ago

  • Keywords close added

Moving the plugins directory immediately prevents plugins from loading, but doesn't deactivate them. Going to plugins.php will deactivate them. But, the plugins page remembers "Recently Activated" (but deactivated) plugins.

I'm not sure there is anything for us to do here. It's probably just as easy, if not easier, for a user to disable plugins via a directory move, than it would to edit wp-config.php. One requires just a simple web-based server file browser (or FTP client), the other requires a more complicated file edit. Safe mode also doesn't help the issue that once you've disabled all plugins, you need to test (ideally one by one) to see which plugin is causing the problem. Safe mode only allows for all-on or all-off, unless you let them deactivate a plugin while in safe mode, then they can remove safe mode again. But then there is the issue of the default theme, and whether you switch that back to, and whether a "safe mode" could actually cause data problems.

There are some cool ideas here but it's pretty clear none of them are good for core.

#16 in reply to: ↑ 15 @knutsp
11 years ago

Replying to nacin:

Safe mode also doesn't help the issue that once you've disabled all plugins, you need to test (ideally one by one) to see which plugin is causing the problem. Safe mode only allows for all-on or all-off, unless you let them deactivate a plugin while in safe mode, then they can remove safe mode again.

The idea I'm working in through a demo plugin deactivates all plugins and places them in recently active. Then the safe mode is gone and the user asked to activate one by one from recently active.

But then there is the issue of the default theme, and whether you switch that back to, and whether a "safe mode" could actually cause data problems.

There are a lot of issues, but I'm sure they can be solved. Default theme should also be taken care of.

There are some cool ideas here but it's pretty clear none of them are good for core.

I guess it's best to just come up with a plugin to demonstrate and test this.

#17 @alex-ye
11 years ago

  • Cc nashwan.doaqan@… added

#18 @nacin
10 years ago

  • Component changed from Plugins to Bootstrap/Load
  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

I think this is safe to "maybelater". If a promising idea or implementation comes along in the future, I'm happy to reconsider.

#19 @aubreypwd
9 years ago

I have a duplicate over at #29772 with a possible solution too.

#20 follow-up: @knutsp
9 years ago

  • Keywords close removed
  • Resolution maybelater deleted
  • Status changed from closed to reopened

What we need is to be able to load a minimum part WordPress, without plugins and with the default theme, bringing up a special emergency administrative screen where an admin user can permanently deactivate one, some or all active plugins, and even permanently switch to the default theme, in order to start all over with theme and plugin activations through the normal wp-admin interface. This is the simple part.

To achieve this we also need to login without plugins loaded. This is the main problem I have identified, because it would create a simple way to bypass security enhancements like "Limit Login Attempt" and others. One could argue that such plugins ideally should be among Must Use plugins, but I don't think that is a way to go for several reasons, though discussable.

Another approach to the login problem could be to allow plugins to blacklist themselves for such "safe mode" deactivation on wp-login.php.

A third approach I have been thinking about since my first suggestion is to set a special short-term, administrators only, login cookie only valid on the new plugin/theme emergency deactivation page. This must then be combined with an extra site wide emergency password or secret word.

Since discussion about something like this is back on #29772 I reopen this ticket, so both can be open until we decide what ticket is best suited to continue the discussion on.

#21 @SergeyBiryukov
9 years ago

  • Milestone set to Awaiting Review

#22 @aubreypwd
9 years ago

I'd like to write something using the same method as what I've done in #29772 (a cookie written to temporarily disable plugins) but use a different approach were there might be a [X] Safe Mode option when logging in or CTRL-clicking on the login button does "safe mode" which disables the including of plugin files and the active themes' function.php for a session. way to disable plugins for a login session by passing ?_wp_safe_mode at wp-login.php

Removed: Broke plugins would not let wp-login.php load.*'

Last edited 9 years ago by aubreypwd (previous) (diff)

This ticket was mentioned in Slack in #core by travisnorthcutt. View the logs.


9 years ago

#24 in reply to: ↑ 20 @netweblogic
9 years ago

Replying to knutsp:

What we need is to be able to load a minimum part WordPress, without plugins and with the default theme, bringing up a special emergency administrative screen where an admin user can permanently deactivate one, some or all active plugins, and even permanently switch to the default theme, in order to start all over with theme and plugin activations through the normal wp-admin interface. This is the simple part....

I agree with most of it. This would help so many people giving support in all areas of WP to provide a better experience to the less technical people when dealing with this common situation.

I think it's quite feasible. There should be a simple dedicated admin interface where only super admins can log in and get an interface for disabling plugins and switching or disabling the theme. That's it. We don't need to get fancy with this.

Regarding security concerns, I think a maximum of 3 tries for a password per admin account should suffice, it's only an emergency use scenario. Security plugins shouldn't be enabled here either because they may be the culprit.

Also, a super-bare-bones theme should be bundled in the event users have one theme or no default WP theme.

#25 @Mte90
8 years ago

Maybe add also a constant for enable that only for logged user or admin can improve the security.
I know, for a developer is easy with manage_options but I think that is can be helpful in the various support forums where the mainly users are not developers.

#26 @Mte90
8 years ago

Maybe a way can be define('WP_DISABLE_PLUGINS', 'manage_options'); with that value with false as default internally on wordpress.
In this way the user can choose the capabilities but I think that add the support for the user name will be better.
So with a three state: true to disable globally, capabilities and username we can cover all the cases where that safe mode will be useful.

#27 @jorbin
8 years ago

I don't think that this is something that can be done based purely on query string. Imagine the case where you have a plugin to limit login attempts. Should you be able to get around that purely based on a QS? Or a caching plugin?

That means in my eyes, it needs to be done in code which makes me wonder why nacin's suggestion to just rename the plugins folder doesn't solve this.

#28 @Mte90
8 years ago

Well in the case of a limit login attemps this is not important because the meaning of this feature it's to disable the plugin for a certain user without disable for all the users in a temporary way.
So if someone need to test with only few plugins he can clone the website and do all the test that he need.

This ticket was mentioned in Slack in #core-php by mte90. View the logs.


6 years ago

#30 @TimothyBlynJacobs
4 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

I think this has been solved by Recovery Mode in 5.2? See also #47192 about making it easier and more reliable to trigger.

#31 @netweb
4 years ago

  • Milestone Awaiting Review deleted

#32 @SergeyBiryukov
4 years ago

  • Resolution changed from fixed to duplicate

Duplicate of #44458.

Note: See TracTickets for help on using tickets.