Realistic means of giving the user options

Hallo @timkaye ,

Nice to meet you.

My apologies for creating a new thread for this, but I didn’t know that my number of replies were restricted for the first day. It is nearly midnight and I want to get some sleep, so I don’t really want to wait 13 hours before posting this :speak_no_evil:
Also, this contains some new info that wasn’t addressed in the OP’s post, so a new thread might be appropriate anyway.

Disabling the worst of the nightmare-inducing features for new sites would already be a massive improvement that I would be very thankful for.
Yet I do think you should give some consideration that many people who will be migrating away from WP, will be doing so for security-related reasons. And they may very well be okay with things “breaking” temporarily or “breaking” in a sort of “preview” / “compatibility” mode, given clear instructions on how to trouble-shoot and fix the issues.
I think sometimes it is possible to see something as an insurmountable hurdle when it really doesn’t need to be. While I agree that proper, careful consideration should always be given to the implications of any choice, being business-centric means asking “how can we make this possible, given system constraints?”

In fact, for users of Softaculous, this should not even be an issue at all. Softaculous already allows you the option to install WP 4.9. There are also other custom installation options for WP that are very easy to use. It should be minimal effort to make CP ready for Softaculous. And it is possible to include an option under the versions that asks whether you should turn off all blogging features by default, or if you want to run the install in compatibility mode (i.e. “offensive” features enabled).
Many great hosts have Softaculous by default under cPanel.
As a sidenote, Softaculous is also a great way to create brand awareness among DYI / startup phase business users.
Combine this with a solution like all-in-one WP migration (didn’t they already indicate that they are willing to support CP? I’m sure I read that somewhere on the forum) and it really doesn’t need to be painful.

So, what I was thinking… in terms of what can be realistically achieved relatively quickly:

Is there a reason why is it not possible to create a tab in the CP v2 admin panel / settings with a heading like “Additional settings”?
Then register an add_option function in the options table for whether each of these “offensive” settings should be on/off?
The default setting could be off. I’d like that. But I could definitely live with being able to manage them all easily in one place if I cannot have my way. :rofl:
If the default is off, the installation instructions can say clearly that, if you are having compatibility issues, please review these specific settings on this one specific page as a first point of call (with a short explanation / alert as to why it is strongly recommended that business users turn off these features unless they are essential to the site’s function).

1 Like

Just a quick response about Softaculous. They have been approached and are aware of CP. The current response is “we’ll wait and see”. I think they want to see more versions released and be assured that it is not some flash-in-the-pan project. Installatron have also been told about CP.


Because this hasn’t gone through the process we use to make all major changes to ClassicPress, and the direction for v2 was set months ago :wink:


But anyway…

What are “offensive” settings? This is not explained in this thread and I’m not sure what the previous thread was.

Hallo @james

We pretty much all agree on what the offensive settings are across the threads.
The four that are already included in the roadmap being some of the major ones.
XML-RPC, gravatars, REST API and emojis.
As you already know, post via e-mail is also a big one for me. (I have already added a short petition for that as per your request.)
There are others, that I’ll add as a petition after making a coherent list.

A large number of plugins rely on REST API.
I suggest a mechanism (setting) to choose whether REST API should be enabled, disabled for anonymous users or disabled for all. So three options, not just on / off.

The discussion wasn’t really so much about the features that should be included as it was about whether CP should allow an option to disable it, or whether it should be disabled with an option to enable.

Personally, I really like the approach of core extensions.

The debate was on what the default ought to be.
@timkaye suggested that the default should be off for all new sites and on for all existing sites.
I was making the case on why I believe the default should be off for everyone, even for existing sites.

Hope it helps to make it more clear for everyone following the topic :bouquet: