Theme/Plugin Editors: disable by default

Following this discussion that asks for complete removal, it seems that most people would actually not want to see them removed at all, but instead they would like to see the editors disabled by default.


Read-only archive: https://petitions.classicpress.net/posts/93/theme-plugin-editors-disable-by-default

Author: Pieter Bos

Vote count: 52

Status: Planned (v2.0.0)

Tags:

  • difficulty-moderate
  • request-modify-feature

Comments

This petition had a lot of support, and I do agree disabling them by default would be a good idea.

There are 2 ways to set this up:

  1. Easiest option would be to set this constant when CP is installated. Similar to how debugging is set to false by default.
  2. Change the code to disable it by default and user would have to set constant to enable it. It can be the original constant set to false define( 'DISALLOW_FILE_EDIT', false ); or a new constant define( 'ENABLE_FILE_EDIT', true );

Setting the (already-available) constant to false by default seems the right approach to me. Of course, if the user changes it to true, then that should be respected on a CP update.

1 Like

Setting the constant to false would likely be required anyway once this would, if ever, be in a core plugin, because when activating said core plugin it would then set that constant to enabled, so it should by default be disabled.

One thing I am not sure is where to set said constant. WP Config is not the right place because only fresh installs would get that change, not existing (since wp config does not update, afaik, but is created once during install, based on the sample config)

So this constant would have to be set elsewhere. The only thing Core does with this constant is check like so:

case 'edit_files':
case 'edit_plugins':
case 'edit_themes':
		// Disallow the file editors.
		if ( defined( 'DISALLOW_FILE_EDIT' ) && DISALLOW_FILE_EDIT )
			$caps[] = 'do_not_allow';
		elseif ( ! wp_is_file_mod_allowed( 'capability_edit_themes' ) )
			$caps[] = 'do_not_allow';
		elseif ( is_multisite() && ! is_super_admin( $user_id ) )
			$caps[] = 'do_not_allow';
		else
			$caps[] = $cap;
		break;

So we need to set the constant before that, somewhere. What would be the right place in code to do so?
The PR itself then is a tiny amendment that could even be pushed to 1.4 upcoming release.

And both due to vote number and also because if ever a core plugin is made for it, it is just preparation and not redundant.

A change in default should only affect fresh installs.

1 Like

Hmmm. If I add a feature it’s also changing the default

I think all these users who voted for this are active users, they’d want this as an update.

Duh, I honestly have no strong opinion on this own and neither could tell what’s the right thing. On one side I agree default is default… on the other hand if we change it only in wp config it’s kinda weird
You’ve got to start differentiate installs in minor versions and that is not really good.(?)

This does need to be done as a change for new installs first. When we are ready to ship core plugins then we can move this code out into a core plugin and allow existing sites to more easily disable it.

Generally, disabling a feature for everyone would be something to do in a new major version. Arguing that disabling the file editors is a breaking change is stretching things a bit, but it’s a good idea to apply that logic consistently.

DIfferentiating in minor versions should be done by adding new features.

1 Like

In order to get this into the code without it being a breaking change couldn’t we just add:
define( 'DISALLOW_FILE_EDIT', true );
to the wp-config-sample.php file for new installs?

Then anyone currently using ClassicPress can simply add that line to their own install to change current behaviour on their site.

2 Likes

Rethinking this…

  1. It can already be done by anyone very easily and we have dismissed other Petitions justifying you can do it with code that require way more complex code. Point in favour of DO NOT
  2. The only right place to do it is wp-config and it is thus something we could only push to new installs making the implementation basically pointless (we have maybe 1 new install compared to 50 existing who want this feature/change). Another point in favour for DO NOT, imo.
  3. It complicates our support. We have to start asking what minor version you use because it might be that major features will not work the same way in either of the versions. Definitely a point in favour of DO NOT

The only thing that I would still consider is making this change (for all installs, inclusive existing) if we package it as a security update because that is what it really is. If this is about “I do not like it” we will find exactly as many users who say “I do like it” and we should try to not fit preferences for everyone but give options (which are available with the existing constant)
Security wise, server hardening and site security may include disabling this editor and that would thus be the only really justifiable reason to push it to all installs but then we cannot use wp-config.

The other reason is bloat, and then this constant is useless because removing bloat means removing the code that adds the feature and that is not done by setting a constant true or false.

So, rethinking it, the DO NOT outweighs the DO. Removed my vote for it and correct my opinion that this should be shipped - specially if we are going to ship it only to new installs, and as a “because user wanted”, or have to do a major release because of a non-breaking constant definition - I am not in favour of it.
If we ship it as a security improvement and to all installs (and that can be done even in a minor bug release), then I would be in favour of.

1 Like

I am in favor of changing defaults for new installs because this will over the long term help to drive the evolution of ClassicPress in the direction we have wanted for a while (turn things off by default and make core leaner), all without breaking existing installs.

In the short term, we can pretty much all agree that the on-site code editors are a terrible idea, but I can guarantee you that people are using it, because it exists and has existed for many years. So disabling this for existing installs should still be seen as a breaking change requiring a new major version.

4 Likes

If any IMPROVEMENTS or changes were to be dedicated to the Files Editor, it SHOULD be better to have editor permissions and capabilities honored to a user—not by user_level.

Even if you did implement an enable/disable(by default); specified users would be most likely the most altruistic way to CHOOSE [who] edit capabilities/permissions. There would be a higher chance of editor success with PHP code. (although, codemirror will stop most poor editing discord. But not ALL)

This is coming in v2.0 for new installations. The petition will be closed now.

2 Likes