[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.

This topic contains 55 replies, has 28 voices.

Last updated by thomasS-11 4 years ago.

Assigned support staff: Luo Yang.

Author
Posts
#319493

Luo Yang
Supporter

Languages: English (English ) Chinese (Simplified) (简体中文 )

Timezone: Asia/Hong_Kong (GMT+08:00)

It is already in our to-do list, our developers are working on it, I think it will be able to fixed in next version of Views.

#319510

Same Same ... using the older shortcodes.php workes for me for now.

I´m sure your developers are doing everything they can at the moment to find a solution for this.
That´s really something! I´am just about to set up 3 new WP-sites with toolkit in August and I´m so hoping that it won´t be a problem then any more – otherwise I´ll have a problem (like many others too I guess :-))

Following!

#319515

This statement by Chris
"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)" - makes me wonder if there are any other erros in TYPES/VIEWS which will take affect when any of the next WordPress versions is released.

Is there any competent statement of how secure or unsecure using an old shotcode.php (while keeping the rest of the updated 4.2.3 files) is?

Best
P.

#319518

Extremely insecure because the vulnerability is now partially publically disclosed. If I'm a bad guy I would troll forums looking for people who didn't update. That's the most qualified statement you're almost certainly going to get on this forum likely as I helped write 4.2.3. I'm the 5th person on the list: https://wordpress.org/news/2015/07/wordpress-4-2-3/

#319521

Hi Chris,

thanks for your reply. Could you please be a bit more specific concering this issue.
I've 10+ critcal sites running on VIEWS/TYPEs and I need to know in which scenario the old shortcode.php is a security risk.

Thanks!
P.

#319522

I unfortunately cannot at this time. The policy of the WordPress security team is not to discuss specifics about a vulnerability until the team is confident that as many sites as possible are updated in order to keep as many users as safe as possible.

#319525

Lee

Just posting so I can stay on top of the updates.

Keep up the good work, guys.

#319533

Juan
Supporter

Timezone: Europe/Madrid (GMT+02:00)

Hi Chris

Thanks for stepping in. This is Juan, lead develper of the Toolset family.

While I do apreciate that security fixes are addressed, solved and taken out of the table as soon as posible, I truly think this does not entitle anyone to make claims on the shortcodes API like "Over 40k plugins used it correctly. A handful, including Types, did not".

Shortcodes are, almost by definition, placeolders with variables that are then expanded to the actual content they aim to provide. The API documentation clearly states that "Any string returned (not echoed) by the shortcode handler will be inserted into the post body in place of the shortcode itself. ", and code up until now did just that, without any kind of restriction of usage positioning but the known ones about nesting. I also know codex documentation is not written in stone and might not be accurate, but looking at the code, the source of authority if you agree with me, also stated just that. Until now.

The idea that shortcodes can not or should not be used as HTML attribute values just landed with this change. As simply as that.

I do thank that now the specs are clearer and we know what we can and can not do, I would also thank if we could stop calling things incorrect just because they became so like yesterday.

Regards.

#319756

I've found a curlpit in views-1.9.1-b1 -> wpv-shortcodes-patch-for-wp-4.2.3.php that breaks shortcodes that open and close on different lines ie:

          [temp-content name="bx-pager"]
              <a data-slide-index="[counter-increment output='true']" href="#"></a>
          [/temp-content]

I am not a regex expert but on line 32:

$inner_expressions[] = "/\\[" . $custom_inner_shortcode . ".*?\\].*?\\[\\/" . $custom_inner_shortcode . "\\]/i";

works if you change the regex modifier to "is"

$inner_expressions[] = "/\\[" . $custom_inner_shortcode . ".*?\\].*?\\[\\/" . $custom_inner_shortcode . "\\]/is";

Also html attributes containing shortcodes are passed through wp_kses_attr_check() function that has an $allowed_html that does not contain data-* attributes hence data-attributes that contain shortcodes are broken ie:

 <a data-slide-index="[counter-increment output='true']" href="#"></a>

Thank you in advance for your effort.

#320045

Luo Yang
Supporter

Languages: English (English ) Chinese (Simplified) (简体中文 )

Timezone: Asia/Hong_Kong (GMT+08:00)

Our developers are already into this problem, I will update this thread if there is any news. thanks for the patience.

#326570

Try updating to latest Types and WordPress update, all above issues seems to have been fixed.

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