WordPress 4.2.3 broke my code

reverting to 4.2.2 is not a good idea, a hacked site is bigger headache than a few broken shortcodes…

here is an easy fix, this resolved WP 4.2.3 breaking some s2member shortcodes on one of my sites, the same principal should work for similar shortcode usage with other plugins

use single quotes ‘ for html attributes surrounding the shortcode, and double quotes ” for the shortcode’s own attributes

like this

a href='[shortcode value="foo"]'

NOT like this

a href="[shortcode value="foo"]"

sam

Hi, after update a slider on my homepage disappears. The section in pagecode is empty. Only for a slider type, other types still running. It is not a shortcode. I’ve asked to the theme supplier, I’m waiting an aswer…but this is not professional. I’ve bought the theme 3 weeks ago, it’s impossibile they still have a new release.

I think I’m going to rewrite the affected sections in pure php in page templates. This is the most future proof solution for now.
I really hope developers will find a solution for this problem, custom content was really a great plugin.

Hi Sam,

I tried your suggestion (a href='[shortcode value="foo"]'), but it didn’t work, unfortunately, but many thanks for your constructive suggestions!!!

Cheers,
Marc

I’m still a bit confused on the “we couldn’t tell plugin authors” point. I’m genuinely curious how this is any different from the 4.1.2 security release, when a number of plugin authors were informed ahead of time and it was high-fives all around on the large coordinated effort to keep everyone’e sites secure and functional?

It’s a known fact at this point that dropping an API update overnight, with zero notice to affected developers, broke the content on many people’s websites. Sure, sometimes that happens anyway; but this was an intentional move.

If the long-term goal is to promote trust in the auto-update system as it continues to be pushed and evolved, the 4.2.2 release didn’t do that goal any favors. And “Too bad, deal with it” is not a sentiment that leaves a good taste in most developers’ mouths, whether they were directly affected by the API update or not.

i suppose the option would have been to announce that there was a major vulnerability in WP, but it would not be patched until all plugin devs have a chance to review and update ?

a few or even a lot of broken shortcodes is preferable to being hacked imo, wp dev team privately notifying all plugin devs in advance is the same as making a public announcement of an un patched vulnerability (word will get out to the wrong ears somehow), and leaving it that way while waiting could be risky…

i guess concerned plugin devs should subscribe to wp security trac or whatever, and wp devs should have at least sent an email notification after 4.2.3 release to all plugin devs to review their code…

Fortunately I subscribed to this support feed. If I hadn’t, I would have gone to Custom Content and seen the clever Whoops! message and wonder what is going on. This is a real issue. I understand if they want to stop distribution of the plugin but to cut off access to support, especially when WP knows there is an issue that they deeply involved in is wrong. Elliot has provided over the top support for this plugin. He is a huge value to the community. And now he can’t communicate to his user base.

Elliot’s plugin was yanked. It’s not the end of the world. He can still post in forums. Don’t make a mountain out of that molehill. I do this to about 10 people a day on average, and most get their code access back within 5 days. It happens, we learn from it. The severity of the situation is what mandates how we handle this.

I’m still a bit confused on the “we couldn’t tell plugin authors” point. I’m genuinely curious how this is any different from the 4.1.2 security release, when a number of plugin authors were informed ahead of time and it was high-fives all around on the large coordinated effort to keep everyone’e sites secure and functional?

A few things were at play here.

1) It was a plugin author who brought the issue to the masses

2) It was a security issue both within core AND the plugins, so a coordinated fix had to be pushed. If we’d only patched the plugins and not core, there would still be issues. Had we only patched core and not the plugins, again, still issues.

3) The number of plugins and their users were much higher than the number of users being impacted today. Yes, it’s a numbers game.

4) The more people who know about a security hole, the more likely it is to be leaked.

If you want a better example, take into consideration the Genericon’s readme hack. Plugin authors were NOT told about it. The code was ripped from themes and plugins without notice. THEN they were told.

But this was a vulnerability that was only in core, that could only be secured in core, and that affected a much smaller number of people than you think. Yes, the people it impacts are hit hard, but it really is a very small amount. That doesn’t make it more or less horrible, it just sets the expectations differently.

We have to weigh the options. Break plugins or leave people open for a hack. Break 1% (max) of people using WordPress or leave 24% of the entire internet vulnerable. The needs of the many win out on this one.

Thanks for the reply Mika. I feel the the Genericons incident is quite different from this, though: when that happened, there was no actual EFFECT of the removal there, other than a security enhancement. Nothing broke.

Even a shell game would have been preferable to what was done, in my opinion. Recently the community was given emoji under the guise of “well we needed to give you new character sets anyway” due to a known security vulnerability. Then after the fact, we found out that “well actually we were patching a massive database security issue”. Was it ever discussed that perhaps the same game could have been played again? The API could have been updated, with forewarning to plugin authors, without disclosing the security-minded reasons behind why the API was changing soon? The notice could have been given with “you have until 4.3”, and then developers could have had fair opportunity to get out in front of this.

While the needs of the many is obviously an admirable goal, I’ll refer again to the trust issue. For those who were affected, and even for us developers/admins who were NOT directly affected by THIS change, it erodes that all-too-important trust. And once trust is lost, it can be quite difficult to earn back. I *want* the community to trust the core team. And that’s why we’re having this conversation, because we all want the same thing and care about what we’re talking about here.

My beef is that unless you are subscribed to the support threads, you can’t get to the support thread at all. I’m not trying to make a big deal about this and If I’m wrong,please let me know.

That’s because the plugin this support thread is for has been temporarily disabled.

The support forums being inaccessble is a ‘quirk’ of the plugin forum system and not something I personally have access to fix, but it IS on the to-do list :/

Dave … Yes. But there’s a sad truth here. We cannot trust all plugin developers equally. If we couldn’t, we’d never have to worry about hacks.

What erodes trust more? The developers who are blindsided by a security change or the mass of end users whom we just knowingly made vulnerable to a security issue?

We would rather piss people off who have the understanding of security importance (the devs) than the masses of people who just know their site was hacked. A smaller group of people loses trust, but also they learn how to do things better and more safely.

Does WP really believe that only because WP did not told the plugin developers about the upcoming changes means that hackers didn’t knew already about these security holes anyway?

I don’t think that hackers get their knowledge about vulnerability of WP by official WP announcements…

This is surely not the right way to manage security issues by hiding their existence and keeping everyone in the dark and letting WP customers down by making unexpected code changes that are not backwards compatible.

I have to say that I am fairly new to the WP community, but I am surely not impressed about the attitude WP takes towards their own community.

Hi Everyone,

Thank you for your patience during this situation. I have removed the problematic update (2.4.9) that got the plugin blocked from the directory, and it’s back in action. Please understand the decisions of the core team and plugin moderator – it was all done to keep WordPress sites secure.

As it’s said, “Every incident is a push for self-improvement.” From now, I will never make a plugin update that will “patch” core – it was a very wrong move that made the situation worse. I will also be keeping closer watch on core development to be more informed of upcoming changes.

The newest plugin update, version 2.5.1, addresses the issue with shortcodes inside HTML attributes, to be compatible with Shortcode API changes in WP 4.2.3. The strategy is to handle specific plugin shortcodes before the content is passed to default filters. There is another thread in the support forum for recommended next steps, so please post there for feedback regarding the new update.

Finally, thank you Mika, Pippin (I admire your work!), Chris, Dave, Marc, Julie, jjgleim, and all others who pitched in to help during this time.

My Gallery is broken in 4.5 https://goo.gl/p6WbKi “Regranex” using the shortcode [gallery ids="19045,19046,19044"] The thumbnails display but the shortcode links to 404 image urls. The gallery ids do exist.