Cancel

Sarah Gooding

Yoast SEO’s PHP Upgrade Nag is Producing a Significant Increase in Sites Upgrading to PHP 7

Less than three weeks ago Yoast SEO version 4.5 was released with an ugly, non-dismissible notice for sites on PHP 5.2. The notice encourages the user to upgrade to PHP 7, explaining that it is faster and more secure. It includes links for getting started and example emails that users can send to their hosting companies.

In the 18 days since shipping the plugin with the upgrade nag, Yoast SEO creator Joost de Valk has seen a dramatic uptick in sites moving from old, unsupported versions to PHP 7. From December to March, PHP 5.2 usage among Yoast SEO users decreased from 1.9% to 1.7%, a modest drop over three months. After adding the nag on March 21, PHP 5.2 usage dropped from 1.7% to 1.3% for those using Yoast SEO version 4.5. PHP 5.3 usage is also steadily decreasing since de Valk began the campaign to educate his plugin’s users about the benefits of upgrading.

According to de Valk’s stats, 22.2% of Yoast SEO users are on version 4.5 of the plugin. He estimates 1,443,000 sites on 4.5 out of 6.5 million users.

“Assuming 0.5% updated their PHP versions, that’s 7K sites,” de Valk said. “And another 14-20k that updated from 5.3 to something more decent.”

Many developers are hesitant to implement a nag in their plugins, but Yoast SEO is one of the largest plugins to prove that an ugly, non-dismissible notice can be an effective tool for getting users to take action.

“One of the reasons I’m sharing is because I’d love others to join us,” de Valk said. “People don’t like nags, but we’ve had some truly great feedback from users who went from PHP 5.2 to 7 and were astonished by how fast their sites suddenly were. Negative feedback has been absolutely minimal.”

The Yoast SEO team created a project called WHIP that makes it easy for plugin and theme developers to add notices that will nudge their users to upgrade their software versions, starting with PHP. The project also includes a filter for linking to the WordPress.org recommended hosting page, as an alternative to the Yoast.com hosting overview.

De Valk said his team intends to push the notice to users on other PHP versions in the near future, starting with 5.3.

“We’ve got a release coming next week (4.6), in which we won’t do it yet,” de Valk said. “If all goes well and continues to be mellow, 5.3 will be ‘nagged’ as of 4.7, probably three weeks later.”

Category: ,
Tags: ,
81

81 responses to “Yoast SEO’s PHP Upgrade Nag is Producing a Significant Increase in Sites Upgrading to PHP 7”

  1. I commend Yoast’s efforts to not just nag site owners, but to educate them on how they benefit from upgrading to PHP7. WordPress, in the larger sense, has an obesity problem.
    The average size of a web page is running well above 2MB (in 2011 the average mobile web page was 370KB or less). Add easy access to kitchen sink themes, plugins that add significant amounts of code, and low expectations on bringing coding standards in line with today’s progressive web application requirements with continued support for unsupported versions of PHP, ancient browsers, and supporting libraries, and you get a sense of the problem.
    The solutions begins with educating users on what they are missing out on. Then and only then will they make smarter choices about who they host with and what they use to build a WordPress site with.
    Overcoming objections, excuses, and sometimes downright laziness helps no interested party, not WordPress as a product, not hosting companies who deliver the sites, and certainly not the users who constantly wondering why their homepage takes 20 seconds to load. Yoast is taking a step to combat one part of the issue head on.
    I don’t like nag messages either, and they can be abused. But it’s worth it if we’re moving the best practices bar higher. Some will dismiss these efforts as “butting in,” but we should all do our part to make the user experience better and safer when we can.

  2. I thought non dismissable messages weren’t allowed in plugins in the repo? Why does this get a pass? Seems unfair to those who actually follow the rules…

      • What a joke. I guess by that logic I can start adding non dismissable messages to my plugins that only go away when you switch to a different browser. It’s dismissable after all!

        • You could try. Email the plugins team and see what they say. The question is: what would the purpose be?
          I don’t think anyone would object to you throwing an error when people use a very old browser version.
          Do keep in mind that PHP 5.2 and IE7 are equally old. WordPress no longer supports IE7 and only partially supports IE8, which is just as old as PHP 5.3.

    • All plugin developers are equal, but some are more equal than others.

      • No, everyone can do this. We’re not any different from others. In fact, because of our size, we’re probably under more scrutiny than others.

  3. Congrats to Yoast! He has done what WordPress core developers should have done long time ago but didn’t have the courage.

      • Why would a php7 site be noticeably faster if you do the most basic optimization of using an object cache?

        Even without object cache, PHP core speed improvement are not the bottle neck in any DB driven app like wordpress, and anyway the major PHP speed improvements came with PHP 5.6 so people being nagged to upgrade from that release will see zero improvement.

        • anyway the major PHP speed improvements came with PHP 5.6 so people being nagged to upgrade from that release will see zero improvement.

          Excuse me what? I think you have no clue what are talking about. First thing that came up.

        • PHP 5.6 (or was it 5.5?) integrated opcode caching into php core which eliminated the need of parsing php files for every request and reduced the amount of memory required for php application in a web server enviroment.

          PHP 7.0 have improved the parsing speed but if the generated opcode is cached the parsing is not done at all and therefor in the real life you will not notice any improvement in a webserver enviroment.

          People that use PHP in a command line enviroment will experience a great speedup because in that enviroment files are being parsed on every request.

          Anyway, the major bottleneck in wordpress sites is DB access. DB access speed (or slowdown) eclipses any thing you do on the PHP side. You might have the fastest PHP code but with slow DB access your site will be slow.

          The answer most people have to that is page caching. With page caching which is done right, (via nginx or apache 2.6+ caching directives) you are not going to even run any PHP code. If you use some inferior solution like W3TC, there is some wordpress booting involve but again if you use opcode caching it is just super fast whatever php version you use.

          The other answer to the DB slowdown is object caching. Here there is some actually improvement that might be gained from faster PHP, but you usually can not do object caching in a shared hosting enviroment, and where available most people employ it as an addition to page caching which was discussed above.

          So Here is a challenge, you are welcome to prove me wrong and show actual speed improvement numbers that are relevant to wordpress, with a core theme. Check it with with three scenarios – no caching, page caching, object caching based on APCu and object caching based on mecache (memcache is slower than APCu therefor it will be interesting to see the difference).

          Sorry for not bothering to do the tests myself, but you made the claims, you need to show they are actually true.

        • @mark k. there are tons of resources out there showing the improvements of php7 over the previous versions. its not just the improved opcache, many calls were rewritten, structures were improved ( see array code for example ). If you don’t wont be bothered to do your own tests, don’t hag the rest of the people with your suppositions.

          I, for one, I applaud the efforts yoast team is doing in improving the safety and awareness of their users. walk the walk, they say.

  5. Another example of why I don’t use Yoast….I’m on 7.1 but I wouldn’t want this kind of abuse of the Plugin repo rules allowed on my site.

    • The repo admins have approved this and are following closely to see if it works. We need to move WordPress forward, not stand still.

        • Yes, seven times out of five!
          You should commend Yoast for taking that risk.

          @Joost, keep up the great work.

        • @otto, this is one of your worst comments ever. If everything goes, and I just need to convince you it is for “the general good” can you please outline how I go about getting a permission to break the rules, so people will not have the impression they have right now that only for specific people there is such a flexibility.

        • @TheMojoWill – There is no absolute answer to your question. In some cases, the harm to the few it is too great for the “greater good.” In other cases, the harm to the few is reasonable considering the outcome.

          In this case, I don’t see the harm to be very great, especially when compared to the benefits, even for those who were “harmed.”

          In general rules are there for maintaining order, but rules are made to be broken, when they get in the way of forward progress. That is the way rules often evolve in every area of governance; people push the edges until those in charge finally realize the rules need to change.

          And now for my personal opinion on the subject: being too focused on the rules and not on the outcomes is too much pedantry for my tastes. But of course YMMV.

        • Mark k. Well, it starts by asking us what we think the right way to do something is, and then having a conversation about that. It starts by working with the plugins team instead of treating them as the enemy. It starts by emailing us before doing something that you think might not be okay, so that we can help you get it right the first time.
          Not complicated, when you think about it.

        • So @otto, what is the chance that this will be made obvious to more than the 10 people involved in this discussion right now? IIRC neither the email address nor the slack channel are easy to find, at least neither of them are specified here https://wordpress.org/plugins/ and I can’t think of any other places where people should look for it.
          It is hard to have any meaningful discussion with the plugin repository team when you can’t find a way to contact them.

        • Mark K, “If you have suggestions to improve the documentation, or questions about it, please email us at plugins (at) wordpress (dot) org and let us know.”

          That’s from the third paragraph at https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

          It’s probably not possible to get the email address in every corner that every person might look first, that’s all subjective, but it is there for anyone who would like clarification on the guidelines.

        • Well, @James, being a software developer I am kind of a literal person and I assume I am not the only one, so not only this address is buried at a page that developers read only once, but it also states that the email should be used for things regarding the documentation, not about bending the rules or getting detailed version stats.

          Since I am not only a literal person, but also one that like to respect the wishes of others (even if they are just guidelines and not rules), I for sure will not send just a random request to that address.

  6. I think a more important question is how is Yoast getting these PHP stats.

    Is Yoast SEO plugin calling home with the server info. Is that mentioned in a privacy policy beforehand? What other data is being collected?

    • I too really wanna know how they know this and which other info is collected?

        • Sorry Jeff, but how exactly will that help? Yoast asked for information **all** plugin and theme authors want to know, and ask for it, but only he got it.

          The method which I assume was by email is obviously not scalable and if every author in the repositories asked for such an info just once a year, there will have to be a dedicated person just to answer them.

          So this whole issue is not about yoast having fun with annoying his users. They are grown man and can switch to other plugins, The only issue is about transparency from the wordpress.org team. If they feel like bending the rules to promote PHP upgrades, that is cool, just let everybody that wish know they can participate. If they want to release the PHP version usage for plugin authors, let all the other plugin authors know they can apply to get it.

    • Okay. The data from the WordPress Users must be minimal like that:
      – phpinfo about the version
      and
      – which pluigns does a wp install running (active or deactivated?)
      This will give you an overview about the wp users with the plugins and the php-version. This is incredible.
      I really heard this the first time of my wp life.

      In Germany it is illegal to send data to another non-german driven host if the complete IP is included. We must mask the IP, if we do that. For example: 123.123.xxx.

      So. Where can i get an concrete information about the hole data, which is sending to wp.org. @jeff chandler: Your article is not clear enough.

      p.s. to yoast: Your automatically activated onpage.org “feature” is sending data to onpage.org, too?
      Which concrete data? Isn’t this illegal in german, too?

  8. Keeping Yoast out of the conversation php 7 is way better for wordpress in overall performance and security hands down. You can php 5.6 all you want but not upgrading to conform to what wordpress calls better standards for the software is just cheating yourself and clients if you have them.

  9. Yoast and his team made what WP should have done years ago. Period. What do you think why it was allowed? Because even WP plugin team is aware of that they just did not dare the same thing with the lamest excuses.

    So stop weaning and complaining here! Do not forget the fact: you can uninstall this plugin anytime free of any costs and go back to the stone age using PHP 5.2 or even further if you want. Just enjoy all the security issues and even babies hacking your sites.

    • It’s not a question of whether 7 is better, or more secure, or faster. It’s a question of whether they are breaking the rules of the repo. And they are.

      • Hi Josh,

        Don’t think we ever met. Which is weird, because I thought I knew everyone who was involved with the plugin repository, and suddenly someone who apparently can tell me the rules appears.

        Would love to meet you and discuss this :-)

      • Hi Josh!
        Please read the title of the article. Twice. There is no question of any plugin rules. Somehow you just do not seem to care of the effect: many poeple and hosting services adopting more secure (and maybe even somewhat faster) PHP versions.

        Who the hell could it hurt in anyway? I mean besides of hackers.

        • The answer is so easy: naturally achieving positive outcomes is far more superior&important than insisting to any rules. By the way i’ve just read the official plugin guidelines and guess what… i just simply did not find any rules that could have been violated.

        • Peter, see #11. Notices *must* be dismissable. Counting upgrading php as dismissable is absurd.

        • Josh, this is technically an error, not a notice. It has very clear info on how to resolve the situation. End of discussion :-)

        • Josh, the message in question is not a site wide notice nor an embedded dashboard. So it does not need to be dismissible. Actually it is an alert and includes all the needed information how to resolve the situation and the alert is removed in that case. It is in full concordance with rule #11.

      • It’s not breaking the rules or better yet, the guidelines. If it were, the plugin repo admins would not approve it. Why is that so hard to understand?

  10. I have been suggesting for years that WP core do this, especially here on WPTavern. Yet many in the WP community have acted like I was suggesting that they euthanize their grandma. Good to see some validation from Yoast.

    • You can’t really have a conversation about whether it’s an effective campaign or not, when the Tavern professional naysayers use these forums as a means to vent about how unfair the world is, or for exposing their underlying deepseeded resentment against successful plugin authors. It’s that whole hate/hate relationship they have with WordPress thing ?

  11. I can’t comment on Yoast’s “breaking the rules,” but getting more hosts to upgrade to PHP 7 is definitely good news.

    Our servers all run PHP 7. :)

  12. It’s called nudging. While I don’t mind being informed, I do mind being nudged. I don’t care who it is. Good or bad, I’m big on my choice, my decision. Don’t nag.

  13. This nag was the final straw and the main reason I dropped Yoast and am trying other SEO plugins.

  14. In the for what it’s worth department, I upgraded my sites from PHP 5.6 to PHP 7 because of the conversation generated by Yoast’s plugin nag. It came to my attention via the previous Tavern article.

    I host with WP Engine and my highest traffic site is also running WP Rocket and Autoptimize. So I considered the site reasonably fast, though I admittedly didn’t put too much effort in fine tuning things.

    That said, upgrading to PHP 7 cut my page load times in half. Needless to say, I was surprised to see that much improvement. That much speed increase will likely directly affect the bottom line of our nonprofit which sees the overwhelming majority of its income come though the site. So I appreciate the controversy that brought the issue to my attention.

    The rule of law is important for any community like the WordPress community. Therefore rules should not be discarded lightly or the community will fall apart.

    At the same time, wisdom dictates that rules should be bent, or even outright broken, in those rare instances when a rule makes no sense or prevents an overwhelmingly desirable outcome for many people. If not then the rule keepers become soulless bureaucratic tyrants like the worst imaginable government agency because, “the rules!”

    In this case we’re talking about something in the grey area at worst. The only cost is the feelings of some developers who observe that it doesn’t seem fair. Yet because of this decision we will see literally millions of sites benefit before it’s over. That’s a huge boost to the WordPress community overall.

    So even if it we stipulate that yep, this is a flat out rule violation. It’s still the right decision. It’s not about favored developers, though there are precious few plugins with the reach and ability to make the impact that Yoast’s has in this area. Instead this “exception” is about a (nearly) no cost way to benefit millions in the WordPress community. It’s a no-brainer. And thank you!

    • All good points, but based on an assumption that WP Engine, WP Rocket, and Autoptimize were all already making your site significantly faster. If I were running your site, I’d certainly want to revisit that assumption.

      As mark k. states above, the biggest impediment to a fast site is not the version of PHP being run, but the database. So, if you noticed that much of an increase in speed just by bumping up your version of PHP, something on your site has likely not been doing its job. If that has been true so far, it probably remains true now.

    • There is no right vs wrong decision. Calculate future-proofing reqs at the strat phase–well before getting stuck. Then scale per needed. Never rely on 3rd party software telling you what you need. You should already know–and prep/trigger when the time is good. If a piece of software alerts you of incompatibilities, then that software should be removed until you’re realigned. Start with Host, not Yoast.

    • We don’t have “rules”, we have “guidelines”. When I first wrote them almost 7 years ago, I named them such for a very specific reason. Everything is acceptable depending on circumstances. If you work with us, then things can get done. That’s how it works. Community, working together to accomplish shared goals.

      Given that the notice is limited and specific for a purpose, we allowed it. They asked and we answered, and indeed, provided feedback. That’s how things work when you ask and have goals in mind and are willing to try new things. Nothing is ever fixed.

    • Most of those PHP 7 gains would be in the WP-admin on the back-end, if your already using page caching on the site. Since PHP and WP is never being hit, but the static caching is being served to viewers of the site.

  15. Omg . It’s not about favored developers, though there are precious few plugins with the reach and ability to make the impact that Yoast’s has in this area.

  16. I did this in a light version in my plugin. I discovered this by accident using some php code what did not work with on php 5.2 and discovered I had multiple users who were running php 5.2.

    And I also discovered that oh proud wp.org endorsed host Bluehost was actually showing customers in their settings that they were running 5.6 when they actually ran on 5.2!

    My message is dismiss-able however but it reappears after a hour if they do not upgrade and my plugin did not fully load. I could use different code to make it work but I figured I am doing people a favor by telling them that everything below 5.6 is End Of Life anyway. And I can use anonymous functions in my code now that came in 5.3. I thought about requiring 5.6 but then went with 5.3.

    I could do another message encourage people below 5.6 to upgrade without actually require them to.

  17. Another reason I dropped the Yoast plugin for The SEO Framework. Too many invasive messages and alerts – gave me a headache every time I logged in.

  18. I don’t see why people are complaining about this. It’s good that people are upgrading to PHP 7, the WordPress team should’ve done this years ago.

    • I agree, 5.2 is insecure. Who wouldn’t want to know?

      This would be convenient in core for every EOL version of PHP. Regular users aren’t likely to know that their host has dropped the ball.

  20. I think that PHP 7 is a game changer and applaud the bold effort to get users to update.

    Sarah, where do the PHP usage stats come from? I don’t see any on WordPress.org for my plugin and that would be pretty interesting.

    • You can request them from the WordPress.org plugin team. It would be very helpful if they would give plugin devs access to these stats without having to request them every time.

  21. This is one of the best news in a long time! Something WordPress should’ve done many years ago. Yoast has earned my complete respect. Let’s hope more projects join him.

  22. I just upgraded to 7.0. I didn’t know I could do it until I had a look at my cpanel and it gave me the option!

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: