Category: WordPress

Some thoughts on plugins, Jetpack, advertisements, and things

Posted on by Jeremy Felt

A series of loose thoughts I’ve been trying to work through over the last couple days in response to Jetpack adding feature suggestions to plugin search results in the WordPress dashboard.

I think injecting promotions into the current plugin search interface is not a great idea. I understand why it’s appealing, and I imagine that it will be helpful for many WordPress site owners. However, it opens an ambiguously regulated door to something that should really be part of a designed system.

I don’t think it would be horrible to have some sort of interface in the plugin search, via a WordPress core API, that allows plugins you have installed to promote their other work based on predefined keywords.

Discoverability of safe and performant plugins by WordPress site owners has always been a hard task to solve.

Which I think is why a large plugin of plugins like Jetpack exists. If it doesn’t—in the world we’ve had—the site owner goes somewhere else (Wix, Squarespace, etc…) or installs a series of plugins that do not have the same resources as the team behind Jetpack.

This series of plugins—one plugin, one feature, all safe and performant—is a vision of WordPress that I’ve always preferred. And I’d love if plugin developers I trust could highlight their other plugins when I search for something new.

Overall, this is something that has gotten much better over the years thanks to the plugin review team and tools that make it easier to apply WordPress coding standards.

But! In the past, installing this series of plugins has led to hacked sites. Hacked sites lead to a lack of trust in the WordPress core project and other plugins. A lack of trust leads to a lack of growth.

Which is where my thoughts often end up and are in some ways still muddled.

If the primary goal for WordPress.org is to increase market share, then it’s probably good to have something like Jetpack around until that ideal discoverability catches up.

If the primary goal for WordPress.org is individual ownership, then plugins of plugins should be broken apart into individual features and we should figure out how to better guarantee security across the ecosystem.

In reality, these aren’t exclusive of each other and they aren’t the only possible goals. That’s the part I’m still trying to work through. Why is it important that WordPress powers more than a third of the web? What are the consequences of slowing down growth? Are there ways to refocus our efforts to help better balance the two? Are there better models for plugins?

Still thinking!

Headed to LoopConf 2018

Posted on by Jeremy Felt

Finally, finally, finally got around to purchasing my ticket to Loopconf in February. My second event sponsored by Happy Prime rather than WSU. 😉

I got a lot out of LoopConf in 2015. My multisite talk went well, the conference's speaker experience was ridiculously good, and the conversation with everyone over those few days was excellent.

After missing last year I'm excited to go back as an attendee, soak up all the knowledge, and hang out with everyone in Salt Lake.

If you're going to be there, we should chat!

Comment on Greenpeace’s Planet 4 technical discovery findings

Posted on by Jeremy Felt

Greenpeace has been undergoing what seems to be a pretty open process in developing Planet 4, the plan for redesigning greenpeace.org. A series of posts have been published on Medium providing details on the discovery process and some of the decisions that have been made.

A few days ago, Davin Hutchins posted “Why Greenpeace and WordPress need each other“, which shares some thoughts on why WordPress is the right choice for a new CMS platform and how Greenpeace and the WordPress community share a similar set of goals in their respective domains.

A few weeks ago, Kevin Muller posted “Checking technical options, we discovered…“, which dives into the more technical details of the stack. This links to a pretty great slide deck that shows how much research went into the technical discovery process.

Both posts, and the process in general, are looking for input, so I’m going to toss out some initial thoughts I have in response after reading through all of that material. I’m going to start with the most reactionary first and then work my way through the mundane. 🙂

And to Greenpeace – Hi! I’m happy you’re moving forward with WordPress!

Customizing WordPress

The word “fork” comes up at some point in the technical discovery post and “customized version of” appears in Davin’s post. Those start raising a yellow flag for me. Not because I think forking is bad, as that’s the heart of free and open source software, but because I think it would be the wrong technical decision.

The WordPress core project has hundreds of contributors and ships 3 major releases a year. As soon as a fork happens, a maintenance burden begins. This maintenance burden grows as things are built into the forked version that do not make their way into the upstream project.

That said, having your own production version of WordPress managed in git makes complete sense. This is a common practice, and something we do with our multi-network multisite WordPress platform at Washington State University.

This provides the ability to test patches in production or release hotfixes while you’re waiting for contributions to be merged upstream. It also makes management of local, staging, and production environments easier across the team.

Multisite vs Single Site

This list of pros and cons in the slide deck is a good one. I have quite a bit to say about multisite, as I think it’s a good enough decision for something like this. I’ll break it down to a couple points:

  • If you foresee using the same set of plugins on every site, or making the same set of plugins available for every site, multisite is a good answer.
  • If it makes sense for a global set of users to have access to multiple sites, multisite is a good answer.

There’s always more detail, but those are pretty good initial gut checks.

I’d be less concerned about the performance issues. Today’s modern LEMP stack is pretty dang good at serving requests and from a maintenance perspective I’d rather manage one installation than many.

For reference, WSU’s installation of WordPress has 57 networks, 1500 sites, and serves about 2.5 million page views a month on one server. WordPress.com is a single installation of WordPress with many millions of sites, spread out across many thousands of servers.

Performance

The slide deck mentions a couple things. Here are a couple more (very much my opinion):

  • Use something for object cache, and get a good object cache plugin. See plugins for PECL memcached and PECL memcache.
  • Use Batcache for page caching before moving on to something more complex like Varnish. This uses your object cache to cache pages and is super straight forward.
  • HyperDB is worth paying attention to when using multisite. This will help you scale.

Plugins

Don’t install too many plugins and be focused with the ones you do install.

WordPress is extremely extensible and has a great plugin ecosystem, but when approaching a project this large you’ll want to be sure that any plugin you install goes through a code review focused on security and performance. This also helps with developer familiarity when things go wrong.

Here are the basic criteria we use at WSU when vetting plugin requests.

REST API

The slide deck briefly mentions a REST API, but it’s not entirely obvious that it means the forthcoming WordPress REST API, which will be shipping next month in WordPress 4.7.

This should be a very useful tool in building custom applications that use data throughout the Greenpeace network. Use the built in routes and create your own custom routes rather than developing a new API on top of WordPress.

Community

And (of course) the last important note is community.

At the very least, pay attention to the notes that are frequently published on Make/Core, the official blog for WordPress core development. As things move forward, raise bugs and enhancements, submit patches, etc…

The easiest way to reduce maintenance burden when extending WordPress is to be familiar with WordPress.

Everyone contributing to WordPress is also interested in the ways that people use and extend WordPress, so please keep sharing your work as you build Planet 4 out. And as Petya mentioned on Twitter, it’d be great to hear your experience at next year’s WordCamp Europe or any other.

Please feel free to ask for more detail if you’d like! 💚☮