In a conversation at WP Tavern (a Matt Mullenweg official property) about the problems with maintaining recent WordPress versions (say anything post 3.7), a very lively debate took place about whether major new features in WordPress should come enabled by default with no option to disable them.
The feature in questions was oEmbed this time but it could just as easily have been emojis or XML-RPC (which recently took thousands of WordPress websites down in a major hack exploit).
The large group in favour of offering a preference to turn off oEmbed was shouted down by paid WordPress establishment figures parachuted late into the discussion. In their own words, there is a way to turn off features: finding, installing and maintaining plugins:
If you want to disable XML-RPC (and I’m cool with that) then it’s just one line of code in a plugin or your theme’s functions.php file. I had to look at a plugin to find it myself. I also knew it was one line in a plugin; I looked at it before....I’m going to skip the privacy conversation and just point out that Emoji is a little more lines to disable but that’s simple too. Look at the source for this plugin.
Otto wrote a plugin that will not only disabled them but replaced them with original the classic smileys.
The point I am trying to make is that each time WordPress adds a new feature or enhancement, there is always a way to disable it in code, if you feel the need to do so.
So that's three more plugins (a lean WordPress site should be running fifteen or fewer plugins) just to get to zero. That's an afternoon (or two if you don't have much experiences) of research to be able to get to zero on a single website. The final recommendation is for publishers/users to code their own plugins to be able to disable unwanted features:
You might want to write your own short custom plugin. Something small with just a description and the PHP code to do those things you want....You’d take that small custom plugin, drop it into your installations, activate it and POOF! you’re done. It’s even easier with WordPress multisite, just drop the file into the mu-plugins directory. In your case (and others) a little code to maintain isn’t a bad solution.
So if you want to be able to turn off unwanted features, you need to become a developer yourself. Unloading maintenance on your users and publishers is not very friendly when a simple advanced options page would do the job.
Jose wrote this approvingly in a symbolic last comment left standing:
Cool feature! Like many features in WP, if one wants to disable, you just have to do the proper research on how to do it.
More maintenance is easy to say: especially when your WordPress website is not online. I've noticed a lot of cheerleaders for more features and less ability to turn them off don't have many real sites (supporting viable economic activity or at least updated regularly) to care for.
The solution was to install a plugin to disable the feature! What is wrong with just having a checkbox to disable features?
The discussion about offering on/off checkboxes was shut down by the moderators by threatening, banning and silencing those who spoke up against implementing oEmbed with no simple checkbox to disable it. Anyone who spoke up against turning everything on by default was called a troll or banned.
The “many” are just the tavern trolls, that like to troll but never to actually participate in anyway in the development, and in open source if you do not participate in the development then you just don’t count.
WordPress core developers and their apologists have completely lost the thread. No wonder they are now afraid of open discussion. In that same discussion, I wrote the lunatics had taken over the asylum. It's that and worse.
Why should I or any small publisher have to do three days of research in order to be able install WordPress in a minimalist configuration with no external services (hello Jetpack and Gravatar and Akismet), no unnecessary plugins (Hello Dolly and the rest), no advertising clutter (Automattic's feeds into the dashboard) and no extra features (like oEmbed). What happened to "fewer features as a feature"?
There should be a simple preferences page which enables and disables all the crap in one place.
Why isn't there such a page?
- Arrogant self-centred core developers know that most of their "exciting new features" would be disabled.
- Matt Mullenweg wouldn't get free advertising and free registrations (hey Matt, remember us we built the software and we build the audience: they don't belong to you. If you wanted to be a second rate Mark Zuckenberg with forced registration everywhere and spam following your users 24/7, you should have told us about that up front).
Matt Mullenweg in San Francisco in 2013. Despite the trendy beard and long hair, Matt appears to be aging pretty quickly. The sparkle has gone out of his eyes. Dishonest dealings like treating people as suckers has a tendency to suck the lifeblood out of you. In fairness, good hard work can do it too. Which is it in this case? We the small publishers using WordPress will have to decide.
What's going on behind the scenes? How could WordPress let this happen? For the current crop of core developers is that the prestige is in forcing your features down the users throats. You have a feature in core. When you get that status you are made man and can double your billing rates and gun for big agency lead positions.
What any of this has to do with helping users and building better software is a mystery. Well actually it's not. Adding features which can't be turned off has nothing to do with building better software or helping users.
WordPress is a project gone completely off the rails into spyware (Jetpack, Gravatar and Akismet all sell your data to third parties via Automattic) and featuritis. Just maintaining a simple WordPress site involves dozens of hours of updates and conflict resolution now. Keeping WordPress running well has turned into the nightare of maintaining a video edit station on a Windows NT box.
Sadly the developers want it that way because that way we can milk you poor sucker small publishers and users for thousands of dollars a year to maintain your sites which haven't changed in six months. If we (they) didn't keep changing WordPress, there would be no reason to keep expensive WordPress consultants on retainer and even less reason to spend thousands every month on VIP.wordpress.com (minimum monthly spend $2500).
WordPress security has become a billion dollar business! Instead of adding features, WordPress should be concerned about how to make WordPress (much more) secure out of the box. Including a standard Limit Logins routine would solve a huge number of problems (the one good Limit Logins plugin with 143 five star reviews and over a million active installs has not been updated in two years and so is invisible to users, while the one you can find is crippleware with settings you can't change to force you to upgrade to pro).
The Limit Logins plugin on the top left has +4000 users and lots of negative reviews, while the good one with a million plus users has been made invisible: progress. Another drop in the steady monetisation of WordPress. Safe limit login functionality should have been in core WordPress long before emojis or oEmbed.
Other simple small tweaks easily made in core like forcing publishers to choose a custom name for the admin account and turning off XML-RPC by default would go a long way to fixing WordPress security. Why are we not making it easy for small publishers to be safe?
Frankly all of this treating publishers as suckers and marks makes me sick to my stomach. I'm tired of facing our clients and forcing them to pay many hundreds if not thousands of dollars (depends on the complexity of the website) every year just to keep the damn thing running the same way it did last year. I'm ashamed to be a WordPress developer. I'm ashamed to have helped sell people on this scam.
Somebody has to change this and perhaps somebody will. Please sign up for our newsletter at businesspress.eu to help show support for a stable and secure WordPress and to get early access to just such a WordPress when it's ready.