[Closed] Types shortcode breaks after WordPress 4.2.3 autoupgrade

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Our next available supporter will start replying to tickets in about 6.28 hours from now. Thank you for your understanding.

This topic contains 55 replies, has 28 voices.

Last updated by thomasS-11 4 years, 6 months ago.

Assigned support staff: Luo Yang.

Author
Posts
#319260

Nevermind

#319270

derekB, shannon: There was a change in the WordPress core that was made 33 hours before release that broken shortcodes across a wide range of Plugins/Themes: https://core.trac.wordpress.org/ticket/15694 . I am bewildered as you are, such a major change should of been made in time for the WordPress community to test, instead the WordPress team suddenly released it and it has broken quite a few plugins/themes that use Shortcodes.

Small sample of other products broken:
https://wordpress.org/support/topic/wordpress-423-broke-my-code
https://wordpress.org/support/topic/no-buttons-to-see-after-update-wp-423

We are hard at work to resolve the issue on our end - our lead developers are aware and engaged. For the time being, some customers are reporting that rolling back to an old version of the shortcodes.php file in WordPress seems to fix the issue for now: https://toolset.com/forums/topic/types-shortcode-breaks-after-wordpress-4-2-3-autoupgrade/page/2/#post-319201

As previously stated, now would be a good time to review your staging/production environments and come up with a good strategy to test/rollback in case of issues such as these. This advice is universal regardless of platform, plugin or theme used and can save a ton of headache for any project.

As for WordPress themselves, their core development team is aware of the breakage. I would advise using the workaround for now or reverting back to a backup from before the update occurred. Keep posted on coming WordPress updates as I feel as if a hotfix from the WordPress team could be coming soon.

#319300

Same here ! Please fix soon !!!

#319301

Same here !!

#319329

We have released an official blog post regarding this issue and are awaiting a fix from the WordPress team:
https://toolset.com/2015/07/wordpress-4-2-3-fixes-a-security-problem-but-breaks-sites-with-shortcodes/

#319349

I was very frustrated with this issue as well - but please, do not attack the Types team. This error is affecting MANY sites NOT using Types.. It isn't Types / Toolset's that causes the problem - its the recent WordPress update.

Maybe they havn't reacted to your post for 2 hours, but today they have MANY posts regarding the same issue, so you should understand that they dont necessarily reply withint 2 hours.

#319351

I'm seeing this same behavior with shortcodes in HTML attributes. It would be helpful to understand if the developers believe this can be patched soon, or if we should be investigating rollbacks.

#319354

From this post: hidden link

:

"WordPress versions 4.2.2 and earlier are affected by a cross-site scripting vulnerability, which could allow users with the Contributor or Author role to compromise a site. This was reported by Jon Cave and fixed by Robert Chapin, both of the WordPress security team.

We also fixed an issue where it was possible for a user with Subscriber permissions to create a draft through Quick Draft."

For sites that are not running additional roles, this gives some peace of mind to rolling back the shortcodes.php version as a temp fix.

#319361

@ianc9730 : As of now, we are waiting on the WordPress team for a fix and as we don't have control over their development process - it is unclear at this time when a fix will be rolled out.

@thomass-11 : I appreciate your kind words! We have been on fire since the update released. I'm personally handling 8 tickets and keeping everyone up to date on the current status. We aim to respond to all tickets within an hour and keep supporters on payroll from all over the world to ensure the queue is watched carefully. I'm one of the few from the USA, hello from Eastern Timezone!

@vincea : I can admire the WordPress team for wanting to keep WordPress secure but it is very strange that 500 lines went into the do_shortcode method, especially hours before release. I do appreciate your thoughts on the security of rolling back the shortcodes.php file 🙂

@all : I appreciate your continued patience! We are but of a few of potentially tens to hundreds of thousands of sites that is experiencing this issue and I can only imagine the activity in the core WordPress team right now.

#319375

Sam

Just jumping in so that i can stay updated.

#319388

How do I get the old shortcode.php?????

#319394

Thanks antonv-2,

1. Downloaded the shortcodes.php file you supplied:
hidden link

2. Uploaded it to my wordpress 4.2.3
/wp-includes/shortcodes.php

3. Everything fixed!

#319432

> @ianc9730 : As of now, we are waiting on the WordPress team for a fix and as we don't have control over their development process - it is unclear at this time when a fix will be rolled out.

> Keep posted on coming WordPress updates as I feel as if a hotfix from the WordPress team could be coming soon.

There will not be a fix from WordPress for "this issue". This is a security release that fixes several major issues.

The reason Types is broken is because it encouraged the use of shortcodes in a way that was not designed or intended to be used in the Shortcodes API.

> I can admire the WordPress team for wanting to keep WordPress secure but it is very strange that 500 lines went into the do_shortcode method, especially hours before release.

They are probably some of the most reviewed lines of code in WordPress core. They didn't just get generated out of thin air.

> I appreciate your continued patience! We are but of a few of potentially tens to hundreds of thousands of sites that is experiencing this issue and I can only imagine the activity in the core WordPress team right now.

Types is one of only a handful out of over 40k+ distributed plugins having issues with this update. Almost exclusively, all the tickets on the .org forums about the 4.2.3 release deal with people using shortcodes inside of HTML attributes, something the shortcodes API was never designed nor intended to support.

> For sites that are not running additional roles, this gives some peace of mind to rolling back the shortcodes.php version as a temp fix.

No, it doesn't. It makes your site immediately vulnerable to what is now a partially disclosed security issue with shortcodes.

Reverting the shortcodes file, downgrading your WordPress version, and turning off auto updates, all make your site immediately vulnerable.

The changes to the Shortcodes API are permanent. The Types plugin developers will need to update their code to make it compliant with the API changes outlined on make.wordpress.org.

#319442

>There will not be a fix from WordPress for "this issue". This is a security release that fixes several major issues. The reason Types is broken is because it encouraged the use of shortcodes in a way that was not designed or intended to be used in the Shortcodes API.

There is much discussion going on across the WordPress community that the API wasn't clearly documented from the get go.

>They are probably some of the most reviewed lines of code in WordPress core. They didn't just get generated out of thin air.

While that may be true, the changes were still added within 12-24 hours before the actual release which gave no one the chance to test compatibility. Ideally and the usual release cycle is to publish previews well in advance so that plugin/theme authors can fix their code ahead of time - there was no such luck with this release.

>Types is one of only a handful out of over 40k+ distributed plugins having issues with this update. Almost exclusively, all the tickets on the .org forums about the 4.2.3 release deal with people using shortcodes inside of HTML attributes, something the shortcodes API was never designed nor intended to support.

Again, official documentation on this front is lacking and it wasn't until hours after the release was the API properly documented at https://make.wordpress.org/core/2015/07/23/changes-to-the-shortcode-api/ . I don't believe that our developers, nor 40k+ plugin authors deliberately and intentionally misused the shortcodes API.

>No, it doesn't. It makes your site immediately vulnerable to what is now a partially disclosed security issue with shortcodes. Reverting the shortcodes file, downgrading your WordPress version, and turning off auto updates, all make your site immediately vulnerable.

The XSS Vulnerability that the update fixed only affects sites with users of Contributor or Author role (meaning if your site doesn't have users with this role, there is no concern). Personally, I feel that modifying core files is always a red flag but in this case, some users may choose to keep their site online until this is sorted out. The inconvenience of a potential security risk in limited scenarios vs losing brand reputation and revenue needs to be carefully judged to as if you choose to use a workaround.

In closing, it's a sticky situation for many of the WordPress community today however we are hard at work to come to a resolution as quickly as possible. We know how important your site is to you and our CEO has started an update thread on the situation: https://toolset.com/forums/topic/wordpress-4-2-3-update-breaks-shortcodes/

#319450

> While that may be true, the changes were still added within 12-24 hours before the actual release which gave no one the chance to test compatibility. Ideally and the usual release cycle is to publish previews well in advance so that plugin/theme authors can fix their code ahead of time - there was no such luck with this release.

Core didn't that option, as documented on the make article. Doing so would have put sites at risk.

> I don't believe that our developers, nor 40k+ plugin authors deliberately and intentionally misused the shortcodes API.

40k didn't. Well over 40k plugins used it correctly. A handful, including Types, did not. Maybe its easier to understand as a percent: over 99.99% of plugins used it correctly, under 0.01% used it incorrectly (including Types)

> The XSS Vulnerability that the update fixed only affects sites with users of Contributor or Author role (meaning if your site doesn't have users with this role, there is no concern).

This is false. There are many security fixes in 4.2.3. One of them affects only contributor or author role users (the one you are referencing). Not all of them do. Some more, some less. 4.2.3 had more than 1 security fix affecting shortcodes.

The topic ‘[Closed] Types shortcode breaks after WordPress 4.2.3 autoupgrade’ is closed to new replies.