New WordPress.org Homepage, Cloudways Acquired, WebP on Hold 🗞️ September 2022 WordPress News w/ CodeinWP

DesktopServer, a local WordPress development tool, is shutting down for good

In a sad bit of news, ServerPress announced that it would be shutting down the DesktopServer local WordPress development tool after 12 years in business (along with the ServerPress business in general).

To my knowledge, DesktopServer was one of the first WordPress-specific local development tools and it offered a number of convenient features for WordPress users.

The DesktopServer team had been working on a new version (5.0), but stopped working on it after coming to the conclusion that it didn’t have much chance of achieving a high market share.

To be honest, this doesn’t really surprise me. Competition in this space has really heated up, most notably from managed WordPress hosts releasing free local development tools as a value-add/attraction for their hosting customers.

For example, Flywheel (and subsequently WP Engine) started this trend with Local WP. Then, Kinsta also got into the mix with DevKinsta.

Given that both of those tools have functional and unlimited free versions, it’s hard to justify the cost for DesktopServer, even if it is/was a solid tool.

Not to mention, there are also lots of new local development options that aren’t specific to WordPress, but still work well for WordPress sites.

I think the ServerPress team is handling this in a really fair way, though. ServerPress will continue supporting people with a license until their subscription expires, including assisting them with migrating to another tool.

There is a chance that ServerPress either sells or open-sources the DesktopServer code, but there’s no official news on that yet.

To see some other options, you can read our full collection of the best WordPress local development tools.

WP-Optimize alleged to artificially boost its optimization scores

If you’ve ever dug into WordPress performance optimization, you’ve probably noticed a really annoying trend:

A lot of users, especially on the more casual end of things, care more about their sites’ “optimization scores” than they do about their sites’ actual performance.

Sure, their site might load in under one second for all visitors, but they only got a 79 in their speed test tool, so clearly something is wrong.

Perhaps it’s no surprise, then, that some WordPress performance plugins would go out of their way to boost performance scores in any way possible.

This leads me to this tweet from Gijo Varghese, who makes the popular FlyingPress optimization plugin, as well as a number of free optimization tools.

In the tweet, Gijo alleges that the popular WP-Optimize plugin is detecting popular speed testing tools and not serving JavaScript to those tools, thereby artificially boosting performance when tested (even though the JavaScript would still be served to human visitors).

WP-Optimize is a comprehensive WordPress performance plugin that was acquired by the same team behind UpdraftPlus.

If true, this would harken back to the Volkswagen emissions scandal, where Volkswagen was artificially lowering emissions but only when being tested. In the real world, emissions were up to 40X higher.

In a response to inquiries from WP Tavern, David Anderson of UpdraftPlus said that the code was added as part of including code from a fork of the Fast Velocity Minify plugin and that the code hadn’t been touched since initially merging it into the WP-Optimize plugin.

David said that he’s tasked the team’s lead JavaScript developer with investigating the code and, if it is indeed only there to game speed test tools, it will be removed.

Overall, I’ve been a happy user of UpdraftPlus for a long time, so I’m inclined to give them the benefit of the doubt that there wasn’t anything intentionally sinister going on. Still, it shouldn’t have happened.

Either way, this is a good reminder that, when it comes to WordPress performance, you should always focus on the actual experiences of your human visitors, rather than nebulous optimization “scores.”

Newsletter Glue ditches WordPress.org to go all premium

A lot of plugin developers like the WordPress.org plugin directory because it gives them access to a large audience.

However, there are also some downsides, most notably some…entitled users, so to speak, who want high-quality support from a free extension.

Still, most developers either bypass the directory from the beginning (e.g., Gravity Forms) or put up with the demands of supporting those free users in return for the exposure that it brings them.

That’s why I thought it was interesting that Newsletter Glue made the decision to officially shut down its existing free WordPress.org plugin to shift to an all-premium approach (after a few months of forewarning – they didn’t do it out of the blue).

The WordPress.org page is officially disabled as of August 15.

In an interview with WP Tavern, Leslie Sim of Newsletter Glue said that they just hadn’t set up the free-to-premium experience in an optimal way.

For example, users had to delete the free version of the plugin and install a separate premium plugin, which meant that Newsletter Glue’s “active installs” count at WordPress.org would stay unrealistically low (as the “active install” count would actually go down if someone upgraded to premium).

If you’re planning to release your own plugin or theme, this is a good reminder that you’ll want to think about these types of implementations before you go live.

WebP by default is on hold (again)

Will they or won’t they? That’s been the question about default WebP usage in the WordPress core.

By “default,” I mean automatically generating WebP versions of newly uploaded JPEG images (which would essentially double the number of image files on the server).

Even though much of the main work had already been merged into the upcoming WordPress 6.1 release, it appears that it is now “on hold” after objections from a number of WordPress lead developers.

Common complaints about the implementation are as follows:

• It will double the number of image files on the server.
• It dramatically increases the processing required for uploading images, as the server would now need to additionally convert them to WebP. This could also cause image uploads to fail more often.

Overall, I tend to agree that this just doesn’t make sense as a core feature, at least in its current implementation.

If users actually want to use WebP images, they have tons of options, including both converting the images themselves or using a plugin like Optimole that dynamically optimizes images in real time.

It also seems like Google-sponsored developers are the ones driving the change, which could be a bit of a conflict of interest given that Google also developed the WebP format.

Overall, the push for WebP by default is definitely not dead, but it still remains to be seen when and how the implementation will arrive.