In this video, the Bridget Willard tests the Hide AI plugin by Andrew Hoyer, sharing her experience with the installation process and its impact on the WordPress dashboard. They discuss the absence of AI buttons from Rank Math due to not paying for the premium version and demonstrate how to upload and activate the Hide AI plugin. The presenter expresses satisfaction with the plugin’s functionality, noting that it successfully removes unwanted AI features from the dashboard, allowing for a smoother user experience.
Hide AI by Andrew Hoyer does, in fact, hide the Spectra AI button when I go to “New Post.”
Five Stars!
Also, stop with all of the crazy buttons everywhere. Our brains get trained on your UI; use that to your advantage.
With any software development, you have to take into consideration your technical dependencies. This is no different in WordPress plugin development. The caveat may be that in an ecosystem with 40-50% adoption and over 50,000 plugins in the directory, how can this process be more of a team effort?
“Here are a few things that might make this communication more difficult. If you can think of other communication challenges (or solutions to the ones below), please share them in the comments. We don’t have established communication channels with theme and plugin authors.”
In her article, on Make WordPress Core, Josepha Hayden explores options on how to make the best use of volunteer contributors. Managing a volunteer team is quite a lot of moving parts, without factoring in burnout, attrition, and the pace of the release schedule. Those are real issues. Maintaining volunteerism in the Open Source Movement is hard; it’s hard in church. Volunteers are unsung heroes.
Can We Make WordPress Releases Easier for Whom?
So the question I immediately thought of when I saw the title was, “for whom?”
For the volunteers? I don’t worry about that too much. Josepha is amazing at working with people and creating an environment for collaborators.
For the users? She makes a good point in her article.
“In my observation, our users see no difference between our nuanced guidelines around minors vs majors, and currently experience each type of release (~9ish on average) as “yet another thing I have to update.”
For Plugin Developers? Hmm. I’m not certain this has been considered to scale that the plugin ecosystem has become. (Not to mention themes.)
Now, I know from leading the Make WordPress Marketing Team for two and some odd years, that “users” is a persona with a complicated Venn diagram. I tend to think of users as people like me. Small businesses that have a website running on WordPress. I’m a user of WordPress. I also have plugins on my website. Additionally, I am now a plugin developer thanks to Media Ron, LLC. See where the waters of “who is a user” is easily muddied?
As a marketer who has been working with plugin shops since 2015, I can’t help but bring up the very small window of 14 calendar days between Release Candidate and launch of the major update. With four updates planned for 2021, that felt burdensome for plugin developers — regardless of how large their shops are.
Yeah, in my mind I hear Dr. Laura’s pithy, “you chose him so what do you expect” response to a wife calling about her toxic, cheating, abusive husband. (That always used to bother me.) Yeah, she chose him as the person she was twelve years ago. Now, that she’s evolved and the problem is scaled, what are her options?
Let me be clear: I’m not comparing WordPress Core to domestic violence. With that said, there is a power imbalance. That’s expected. Yes, plugin developers chose to become technically dependent upon WordPress. That’s true. So, should developers follow best practices and revolve their entire product development around WordPress’ schedule? Um. Yes and no.
What people should do and what they actually do is the middle ground that should be solved. WordPress should have a smaller schedule. Developers should subscribe to the core updates.
“Shoulds” — implied or otherwise — are the blameshifting language that divorcing couples use. It is a warning sign of an unhealthy relationship. So, I figured I would do my part and do a bit of outreach.
When Do Plugin Developers Test?
So the question is when do plugin developers test. Do they start testing at alpha? Beta 1? Beta 2? Or wait for the Release Candidate. Like most things in tech, the annoying “it depends” response is the answer.
The best case is nightly builds. But what if you have dozens and dozens of extensions that integrate with say, other dependencies a lot bigger than WordPress like PayPal and HubSpot?
“We test with the RC. And yes, 14 days isn’t very much time. We have some devs working with the nightly, but officially we test at RC.” Kevin Stover of Ninja Forms
“We run a full suite of automated tests against trunk and Gutenberg trunk every night and ramp up manual testing as soon as beta starts. We also run the Gutenberg plugin on our sites to test and work with it.” Joost de Valk of Yoast
“We have integrated automated unit testing with bleeding-edge WP for the most critical functionality.” Adrian Tobey of Groundhogg
“The beta periods last fairly long and ideally plugin devs should be testing against the betas. But there are so many “passion” projects on .org, so it’s a bit of a chore to test your free plugins.” Ronald Huereca of Media Ron LLC
“14 days feels reasonable? Can’t say I really test my free plugins and my premium ones depend more on Woo vs integrating directly with WP.” Kathy Darling
“We keep the bleeding edge versions on our dev environments and try to test related upcoming changes before the RC. Then when the RC comes out, that kind of marks the end of testing for us since things won’t change much.” Jason Coleman of Paid Memberships Pro
Plugin Developers v WordPress Core
Here’s my analysis. In the case of Plugin Developers (“devs) v WordPress Core (“Core), devs feel they have no voice on the schedule. This essentially goes against the philosophy of the Open Source Movement in their minds. Regardless of the dependencies that we choose while building the web, a healthy working relationship is important.
Core is dependent upon PHP, mySQL, Apache, jQuery, and a lot more I’m not even mentioning I’m sure. My knowledge of code only goes so deep; my specialty is strategic awareness and how that affects our ecosystem.
So, in this case of devs v core, who takes custody of the children (“users)? How do web hosts factor in? When a website is broken, the user doesn’t know what broke. Case in point, when 5.6 dropped, my Caldera Forms didn’t work. I went to my web host first (Pressable at the time), who installed the jQuery manager plugin. Support for WordPress websites will increase after a major release regardless of whose product broke or why.
Back in the days of the Growth Council, there were quite a few people chiming in on the project itself from a long-term strategic view. I think that was an important discussion to have.
Yes, WordPress Core writes about all that they do and they take feedback quite well, I’d like to add.
Here’s where I see the problem.
Even medium-to-large plugin shops don’t have a full-time developer who monitors, runs, and tests the nightly build. As far as I understand, the nightly build is the time when all of the code is done for the day and is tested against the source. This is like reconciling a cash register after someone’s shift. What broke? Where did it break? Etc.
“For Wordfence, we do some testing with alpha and beta versions, to try to catch any compatibility issues as soon as we can. I generally keep at least one of my test sites running the nightly builds, to watch for any new issues. This does get a bit more cumbersome when there are both a minor release and a major release in active development. Once the release candidates are available, we do more rigorous testing since they can contain significant changes or additional trac tickets that were not included in the earlier betas.A 14-day window does feel a bit short, especially if one or more team members is working on another project or has some time off during that period. Other factors like the PHP 8.0 release that was so close to a major WordPress release can add to the time crunch as well.” – Matt R
For my devs who are my clients, I highly recommend that they themselves get involved and subscribe to the Core Blog. This is why I’m always tweeting out when software changes. It may seem odd when a marketer is tweeting these things out except, breakage affects us all.
Ronald Huereca of Media Ron, LLC, for example, appreciates the emails that come out. They’re well thought out and helpful. He forwarded me the email he got for 5.6 and it explained all of the issues with jQuery, what plugins he has listed on the repo, etc.
For WordPress 5.6 the email was sent 23 November and 5.6 dropped 8 Dec. This is the 14 calendar day period of testing. Also, this happened during the holiday season in the States.
“IF we keep this short RC length, then we MUST be able to contact developers sooner with the Field Notes and details of changes. Anything less means plugins (and themes) absolutely will not be updated in time and we’ll have conflicts, which will lead to larger support queues for the volunteers here, as well as any webhost who automates updates.It also suggests maybe we need something better than the emails from the plugins team and instead have something automated when a Beta drops, which contains an overview of the changes, that goes to everyone with a commit bit to anything (plugin, theme, core). “ Mika Epstein
So, How About Shortening the Release Candidate (RC) Window?
The problem I see with shortening the RC window is that the window is already too short. There is also the presumption that plugin developers have fully vetted their products by the time the RC is out. Meaning, plugin developers are closely mirroring their own plugin development schedule around Core.
In an ideal world, sure. That sounds awesome.
Does it actually happen? Not really.
Many developers I reached out to don’t bother testing until the RC is out because they don’t want to duplicate work. Larger companies test against nightly builds but, as Matt from WordFence pointed out, that comes at awkward times when point releases are also being tested.
I love that you’re opening up this conversation, Josepha.
I’ve always believed it is burdensome on plugin shops to release Core Versions after 15 October. Most of the world celebrates holidays at the end of the year.
For example, PHP 8 dropped on American Thanksgiving and 5.6 dropped 8 Dec.
I’m also wondering if there could be more than 14 calendar days between the release candidate and launch.
Could this be changed to business days and/or extended by 5 days?
I’ve pinged some of my peers who develop plugins and I’m sure theme authors may have excellent feedback as well.
“I think with Francesca’s suggested realignment of the phases in each release cycle, the idea is that by the time we get to RC there are essentially no new changes left to manage. The experiment to shorten the RC window is pretty new and I’m committing to it all the way, but it’ll be interesting for us to look back on it at the end of the year!”
How Long Should the RC Window Be?
I would like to see Core do a better job reaching out to plugin companies to get a feel for how testing against Core is done in practice, rather than in a perfect testing scenario. Will this be realistic on every release? No, but from a social science and research standpoint, it is important. What are the trends? What actually happens? Outreach as research is important to get the data that matters.
To study the mountain gorillas, Diann Fossey didn’t watch them on Slack or expect them to come to her. She went to where they are. She observed them. Listened to them. Drew their faces. Now, that may be super odd for the Core team to start sketching a plugin developer in the wild, but you get my point.
How long should the release candidate window be?
What is too short?
What is too long?
What is the labor burden for these releases?
At what point will it adversely affect development shops and their users?
Who Loses When Windows Are Too Short?
My suspicion of how core releases affect dev shops is this. Keeping up with Core, especially if there really are four updates in 2021, comes at a cost to their own product development and updates. If their products aren’t at the cutting edge, then how does that ripple resonate in the WordPress ecosystem?
So, who really loses?
Without a healthy working relationship, like most dysfunctional parents, it’s the kids that suffer. The users lose. Something breaks. They don’t care what it was or whose fault it is. It comes down to a retention and branding issue. If their site is WordPress, then WordPress broke. It wasn’t Ninja Forms or Yoast. It’s not the slider plugin they insisted on installing. It’s not advanced custom fields. It’s WordPress. Regardless of the pieces of software that are assembled, it’s “WordPress.”
“WordPress breaks. We’re moving to Squarespace.” This is a direct quote from one of my large-business, non-WordPress clients. Even running their company’s website, which only changes as we publish content, has become expensive. WordPress isn’t expensive. The time managing an outside vendor is expensive. The invoices for management is expensive.
With our goal for WordPress to be the dominant CMS, we have to look at how we can set realistic goals that move Core forward at a reasonable pace that allows growth while also factoring in real-world scenarios from plugin shops.
If we don’t, at 40% of the market share, we will have a hard time getting to 51% of the market. As an ecosystem scales, its faults scale.
If we don’t achieve our 51% market share, who loses, then?
It will be plugin shops first, because they’ll lose end-users to Squarespace, Webflow, and Wix. (This is the time to think about a SaaS move.) Without users, there is no revenue. Without revenue, marketing folks and developers will lose employment. I personally know WordPress developers working for Shopify.
WordPress the Project will lose because plugin developers won’t have the time or money to sponsor full-time volunteers to work on the project. The web hosts will have to continue to do the heavy lifting as far as that goes, much as they are doing now. Last I heard, Bluehost has 8 full-time employees who work on Core. I imagine that number is larger in the 16 months since I’ve talked to them at a WordCamp. That doesn’t account for the employees that are full-time sponsors from Yoast and anyone else I can’t think off.
WordPress.com will lose, not to the same degree, but Automattic will have to pick up the slack from the attrition of companies who sponsor full-time employees to work on the project. Sure, dot com and Automattic, in general, have what seems like a bigger part of the pie, but they also have a bigger part of the overhead. Automattic is not only accountable to their product teams and employees, but their vendors and clients. Let’s not forget their fiduciary duty to their investors as well.
When “WordPress” the brand doesn’t work, it affects us all. Maybe not to the same degree, but it will affect our reputation.
“Oh you’re going to use WordPress? Doesn’t that break?”
We have to do better.
Shortening the Release Candidate window is not a good move for Core. The domino effect is too grave.
“Here are a few things that might make this communication more difficult. If you can think of other communication challenges (or solutions to the ones below), please share them in the comments. We don’t have established communication channels with theme and plugin authors.”
Just when you were getting used to WordPress 5.6 and all of the jQuery issues, you’ve got more work to do, plugin devs. Don’t stop testing your themes and plugins. The next WordPress Core Update (5.7) is coming on March 9, 2021.
In fact, there will be four three WordPress Core updates in 2021 according to the roadmap. This is a healthy, yet robust schedule for plugin and theme developers. I suspect mostly for plugin developers.
The best marketing for a WordPress plugin is smooth updates for your users.
For plugin developers, you’ll want to get ready for the beta which will be available on February 2, 2021.
The release candidate for testing will be available two weeks later (Feb 23) and the WordPress Core update launches March 9.
Yes, the release candidate will be out in or 39 business days.
It is hard to keep track of all of these updates, I know. You can subscribe to WordPress Core updates on Make.WordPress.org.
What About WordPress 5.6?
First the good news. WordPress 5.6 “Simone” dropped on December 8, 2020 and I’m happy to have been listed as one of the contributors. (Yes, this marketer has brackets.) I reviewed copy on a few Trac tickets as well as editing and rewriting the baked-in copy on a few default themes.
What went wrong for me?
For people who were hosted by companies like Pressable (I’m now on SiteDistrict), it was an irreversible auto update for major core. Meaning, 5.5.x automatically updated to 5.6 without the ability to roll back. Normally, I’d be fine with that until I started building a landing page.
But the website didn’t break, you may say. Or did it? So, to me something “not working as expected” is a break. I was creating my landing page for my new book, “How To Market Your Plugin,” and needed to clone a form. Something that should have taken 20 minutes copying my template and cloning my Caldera Form took two hours.
To a visitor, my website was fine. I was frustrated. I tried clicking “clone” and nothing happened. So I clicked “create new form” and nothing happened.
So, I spent about two hours the week WordPress 5.6 came out Googling and submitting support tickets to both Caldera and Pressable. I had no idea what was wrong. Pressable ended up installing the jQuery Migrate Helper plugin which solved the problem. Two days ago, Caldera rolled out an update that fixes that issue, so I deactivated and deleted the jQuery plugin (as per best practices).
Then I decided, I needed the option of, well, opting out of auto updates for WordPress Core. So, I moved my hosting to SiteDistrict, too. I’m fairly certain I lost four hours of billable time for that update and migration. It’s all part of supporting Open Source, right?
Hey, I’m all about software updates. I’m the first to update my iOS apps and Google Chrome and even WordPress. I have Updraft backing up my site and it’s all good. You know? I’m for it.
You’ll have four, 14-day periods of testing to do in 2021. I suggest blocking out time in your production schedule and company calendar. You’ll be busy with support tickets if you don’t and your social media manager will be pinging you in Slack with all of the complaint tweets.
Is your plugin ready for PHP 8? Maybe I should ask if you’re ready for WordPress 5.6? Either way, there will be changes. Breaking ones. Read them all on PHP 8’s GitHub page.
PHP 8 comes out on Thanksgiving and WordPress 5.6 comes out 12 calendar days later. So, yay! Not so much? Also, why are there any software releases after October 15? If you believe in holidays, then believe in holidays. Sheesh.
I’ve reached out to my clients who build plugins and themes and none of them are surprised by either WordPress 5.6 coming or PHP 8. They’re a bit bummed that it means another holiday testing their code, but yeah. Welcome to plugin development in WordPress, right? Nothing new to see here, folks.
When is PHP 8 Coming Out?
General availability or GA of PHP 8 will be on 26 November, according to their calendar. PHP has 4 release candidates and the fourth will be on 12 November.
And, yes, WordPress 5.6 will have support for PHP 8. So you may as well make your plugin ready. Right?
“Even though WordPress 5.6 will add support for PHP 8.0, no changes will be made to the minimum required version of PHP at this time.” Andrei Draganescu (10/6/2020)
How Does PHP Affect My WordPress Website?
If you’re reading this and you’re a website owner but not a product or plugin developer, that’s okay. The bottom line is this: it’s best practices to have your software as up-to-date as possible. If you’re not sure, check with your web host.
WordPress is a content management system that uses PHP to talk between the servers, your website, and the browser. Generally, your website host determines how high you can upgrade your site’s PHP. My site is and I was on PHP 7.2, for example. I just upgraded to PHP 7.4. That was as high as I could go.
Should I Refactor for PHP 8?
Maybe. My suggestion from a strategic standpoint and manpower is to be ready for the future. In marketing and public relations, we like to be ahead of the story. It seems to me you save yourself a lot of work later if you plan for the future now.
“Refactoring WordPress plugins is no joke. But if you start with small functions like this and gradually work your way around the codebase, it gets easier.” Tom McFarlin
Maybe start another dev branch that is PHP 8 ready but wrapped to support down to 7.2 or something. 7.4 might be a better route, but it’s up to you.
We like to honor backward compatibility in WordPress but Gutenberg is already a major breaking change (though I seem to be the only one saying it). But that’s another blog post.
“PHP 8 is actually already at RC2 and will be released nov 26th. Re: WP vs PHP8 – as things stand, expect breakage in unexpected places. Most of WP is untested on PHP 8 and with WPs reliance on type juggling, things *will* break.” Juliette on Twitter
How Should PHP 8 Affect My WordPress Plugin?
PHP 8 and WordPress plugins may be a bit of a challenge. Like I noted earlier, WordPress 5.6 (as of right now) will support PHP 8. Some of my friends, however, worry about some issues that will cause breakage.
Marketing Your Plugin’s Compatibility with PHP 8 and WordPress 5.6
Yes, you should let people know that your plugin is compatible with WordPress 5.6 and/or PHP 8. Start your GitHub repos, begin your documentation, write blog posts, include notes on update schedules on product pages. Tweet. Yeah. You should tell people.
Note that Josepha wrote: “WordPress 5.6 includes seven Gutenberg plugin releases.” SEVEN. So, maybe check those out.
But, thankfully, after writing a comment on The WP Tavern, Andrey set me straight.
“PHP language is still absolutely supported and works on Windows.Microsoft discontinued donation of time and infrastructure to the process of producing Windows binaries of PHP. Just that.” Andrey “Rarst” Savchenko
He’s nice like that. One of my favorite people on the planet!
Many of us who have been blogging for years are completely used to being able to post a link to a Facebook or Instagram post and it magically appearing.
That is from the oEmbed support from Facebook’s API. The old oEmbed endpoints end October 24, 2020. They have new Facebook oEmbed endpoints. The developer requirements, should you want to create your own app, are in that post.
Keep in mind that when we say “Facebook’s API” this also includes Instagram.
Search Engine Journal noted that the changes are retroactive.
“To be specific, an upcoming API update will remove support for unauthenticated Facebook and Instagram embeds. …The change is retroactive, so all Facebook and Instagram embeds on the sites of unauthenticated publishers will soon become broken. This has the potential to affect millions of sites.” Matt Southern
I will admit it was nice to see something about WordPress Core in SEJ!
Facebook and WordPress
As a result, WordPress Core (the base software not plugins and themes) is ending support for Facebook and Instagram oEmbeds as of WordPress 5.5.2.
As a writer and social media manager, who loves and depends upon oEmbeds (rather than screenshots), I completely understand the logic behind removal.
I completely agree this should become plugin-dependent.
Facebook is famous for changing the rules on their playground. And, honestly, APIs be like that sometimes. Right?
So, as far as communicating this to the general public, we should fill in the holes of people’s education.
WordPress 5.5.2 has an important update that affects oEmbeds of Facebook properties. This includes Instagram and Facebook links.
How Does This Affect You?
Previously, any WordPress blogger could simply insert a URL of a Facebook or Instagram post and the image and post would render. Like magic, but definitely technical.
Unfortunately, Facebook has made access to their API a bit more complicated which, cheers to them, helps protect the privacy of its user base.
If you’re worried about this update, check your posts for links that don’t unfurl/render. They will appear as regular links. It isn’t broken, it just doesn’t render. Instead, use the link like you would any link — in a sentence — with accessibility in mind.
You can always include a screenshot with alt tags and a caption as well
Jetpack to the Rescue
Well, it’s no surprise that Jetpack by Automattic finds a reason to be relevant again. They will be supporting oEmbeds from Facebook and Instagram as long as your site is connected to Jetpack.
“Facebook and Instagram are ending support for their oEmbed API on October 24. After this change, you must register a Facebook developer account, create an app, and provide a token when calling the new API. …Simply connect your site to Jetpack and start sharing. We’ll handle everything behind the scenes so you don’t have to worry about it.” Jetpack
But I Want My oEmbeds
If you don’t want to use Jetpack, and I get it, there are other plugins you can use. In the same WordPress Trac thread, Syed Balkhi suggests two of his company’s solutions:
“Just wanted to comment here, since our Smash Balloon Instagram and FB feed plugins are already used by over 1.2 million users, we have added the oEmbed functionality to it.
This was easy for us to do because to create custom feeds, users would have to use the API key anyways. Over the years, our plugin has simplified that process to make it very user-friendly.
I think it’d be helpful to recommend these because we DO NOT require users to go through a complicated FB app setup process or anything.
How Else Can I Link to Facebook and Instagram Posts?
The good news is that links are links. As long as the post is public, you can still create a link within the context of a paragraph. People can click the link and go to the post. It’s not that big of a deal. If you really want the visual, then take a screenshot. If you do that, make sure to include alt text and a link to the actual post. It’s a little bit of work, but worth it.
