WordPress.org

Make WordPress Core

Tagged: shortcodes Toggle Comment Threads | Keyboard Shortcuts

  • Robert Chapin 8:05 pm on July 23, 2015 Permalink |
    Tags: , , shortcodes   

    Changes to the Shortcode API 

    Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API. Due to the nature of the fix – as is often the case with security fixes – we were unable to alert plugin authors ahead of time, however we did make efforts to scan the plugin directory for plugins that may have been affected.

    With this change, every effort has been made to preserve all of the core features of the Shortcode API. That said, there are some new limitations that affect some rare uses of shortcodes.

    Reminder: Never, under any circumstances, should you hack core files. This includes downgrading specific files. Doing so could have unintended consequences on your WordPress installation, including major security implications.

    Basic Shortcode Usage

    A brief explanation on the original purpose of shortcodes will help to explain the change. In a basic post, like this example, shortcodes are used to insert dynamic code:

    Here are my images. [gallery]

    Here you can see that the shortcode stands on its own as a dynamic element within the blog post content. This is the central premise of the Shortcode API: make it easy to insert blocks of dynamic code.

    Shortcodes with Filtered Styles

    In today’s release of WordPress 4.2.3, however, we’ve added some new limitations that affect some existing plugins. Take, for example, the following shortcode, which is no longer recognized:

    <div style="background-image: url('[shortcode]');">

    The shortcode in the example above appears in a context that is no longer supported. Further, this use of a shortcode stretches the imagination for how the Shortcode API was intended to be used. Fortunately, there are some workarounds still available, so that site administrators are not overly restricted in their use of HTML.

    Workaround

    The following example still functions as expected and is considered more acceptable:

    <div [shortcode]>

    Going forward, plugins implementing shortcodes for inline styles should output the entire style attribute rather than a bare value. Keep in mind that this workaround – just as the original example above – is only available to administrators and editors (i.e. only roles with unfiltered_html). Less-privileged users are still prevented from using shortcodes to output whole attributes in this manner. If a plugin is intended to work with author and contributor roles, we recommend that the plugin output an entire <div>.

    Shortcodes with Bad Quotes

    The following example is also no longer allowed:

    <a href="/[shortcode query="?ref="]">

    In the above situation, the shortcode is now properly recognized as HTML and it is rejected by the API. Apart from the example being confusing, WordPress cannot parse that shortcode.

    Workaround

    Instead, either of the following examples would be appropriate:

    Example 1: <a href="/[shortcode query='?ref=']">
    Example 2: <a href='/[shortcode query="?ref="]'>

    Administrators as well as lesser-privileged authors can continue to use shortcodes in this way, as long is it conforms to the usual HTML filtering rules. However, as explained in the first example, administrators are now somewhat limited in this situation in one case: if the content in this href attribute is generated by a shortcode that does not conform to the HTML filters, then the shortcode is rejected for all users.

    We do not make this change lightly and understand that it may affect some usecases. The above examples and explanations should help plugin authors make the modifications needed to support the Shortcode API.

     
    • Mickey Kay 9:30 pm on July 23, 2015 Permalink | Log in to Reply

      And. . . half our client sites just broke :)

    • Dave Navarro, Jr. 9:55 pm on July 23, 2015 Permalink | Log in to Reply

      may affect “some” usecases…

      LOL! How about, you broke half the internet without so much as a “howdy do”.

      And if it worked before, why exactly can’t it work now? I am still not understanding why it had to change. WordPress itself was not intended for many of its uses today, are you going to start forcing people back into blogging? Designers/developers made better use of it than you intended and you don’t like that?

    • arippberger 9:56 pm on July 23, 2015 Permalink | Log in to Reply

      Can we get a list of the affected plugins?

    • Dave Navarro, Jr. 10:07 pm on July 23, 2015 Permalink | Log in to Reply

      Every single plugin that adds shortcodes that could be used inside of an HTML element. Not because it’s a security issue, but because someone doesn’t like how we play with our toys in their sandbox.

    • kitchin 10:12 pm on July 23, 2015 Permalink | Log in to Reply

      The shortcode API has never been well-defined, as far as I know. What html is allowed in a shortcode, and how shortcodes are allowed in html tags has changed over time. Scanning for the use case above would be difficult since it would involve the help files and sample tags shown to users, which may be formatted with sprintf, etc.

      The API should be defined. The test cases are the de-facto definition, but they are ad-hoc and clearly not complete. It’s very complex, with nesting issues and all the rest.

      I don’t know the security bug, but I wonder if malicious uses could have been filtered out more directly as a short-term fix, until the API was rewritten.

      • kitchin 10:20 pm on July 23, 2015 Permalink | Log in to Reply

        As a further example of complexity, many people are not aware that < and > are legal characters in html attributes, and some authors use them, for instance in sample code in the jQuery plugin Cycle2.

        The shortcode API was never intended to contain a complete html parser, and never claimed to. But it also did not strictly limit html or quoting, as it should have. Really it should have allowed either tags in html or html in tags but not both. Too late now.

    • Braad 10:19 pm on July 23, 2015 Permalink | Log in to Reply

      We’re experiencing some major frustration as a result of this change, and now plugins like Toolset’s Types and Views are basically non-functional. There are a lot of confused and unhappy people filling up their support forum right now: https://wp-types.com/forums/topic/types-shortcode-breaks-after-wordpress-4-2-3-autoupgrade/

      Even if this was a necessary change, it’s one that has far reaching implications, and it would have been nice to get a heads up that this was coming so we could have prepared. A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

      We’re already seeing people on support forums tell each other to just replace the shortcodes.php file with the version from 4.2.2, which as Mark Jaquith has pointed out is not a good idea, but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

      • chriscct7 10:49 pm on July 23, 2015 Permalink | Log in to Reply

        A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

        As stated above, this was not possible.

        but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

        The majority of WordPress users who are not developers will not know how to replace a file on a remote web server.

        • Braad 12:31 am on July 24, 2015 Permalink | Log in to Reply

          Saying something like “Here is a use case for Shortcodes that will no longer be supported” is different from saying “Here is a security vulnerability and how you exploit it”. I have a hard time believing that some form of notice couldn’t have been given, even if it was only given a day before the update.

          But that said, the core devs who deal with this stuff are in a tough position and deserve a big thanks for their hard work. Hopefully they can find a way to keep supporting the affected shortcode use cases while still keeping things secure.

    • Angelika Reisiger 10:20 pm on July 23, 2015 Permalink | Log in to Reply

      Sorry, please delete my previous two posts. I could not post the complete code snippet.

      So here again:

      I tried to follow your recommendation in the article. But whatever I try, it does not fix the issue ticket #33097
      Below is the code:

      http://pastebin.com/8xvN2eb1

    • mvandemar 10:41 pm on July 23, 2015 Permalink | Log in to Reply

      This change is listed as “Improve the reliablity of shortcodes inside HTML tags.” It says absolutely nothing about this being a security issue. Do you have a link to the actual security issue this change fixed?

    • James Huff 10:44 pm on July 23, 2015 Permalink | Log in to Reply

      Thanks for doing this, both the security fix and the write-up!

      I appreciate that the concern was on security over functionality. Existing functionality can always be fixed, and sometimes a better way of doing things is found, but recovering from a security vulnerability is a *nightmare*.

      Thanks again for keeping us safe!

      • Dave Navarro, Jr. 10:56 pm on July 23, 2015 Permalink | Log in to Reply

        Nothing in this write-up says that this is a security issue. Nothing in the release notes say this is a security issue. This is about how they don’t like how shortcodes are being used, so they put a stop to it. And I guess if they don’t like it, they can change it. But if it’s not a security issue, why change it in a security release without any notification so that it breaks hundreds of thousands of web sites? Why not announce “in 4.3 your shortcodes aren’t going to work anymore” and release it then? Well, because someone messed up and merged the update into core prematurely. So rather than fix the mistake, just roll with it…

        • James Huff 11:00 pm on July 23, 2015 Permalink | Log in to Reply

          Nothing in this write-up says that this is a security issue.

          It’s in the very first sentence, “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You’re welcome to form whatever theory you’d like to, I’m just reflecting the published facts.

          As far as I see it, the developers had to make a choice, security or functionality. They chose security over functionality, and I’m thankful they did. It’s the right choice.

        • mvandemar 11:01 pm on July 23, 2015 Permalink | Log in to Reply

          @Dave – the very first sentence in here says that it is a security issue:

          “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You are correct though that nothing in the release notes, or the bug track that I can see, indicates that this is the case.

    • Curtiss Grymala 11:07 pm on July 23, 2015 Permalink | Log in to Reply

      First of all, I want to say that I do truly appreciate the quick security fix, and I fully appreciate how much work is going into keeping this codebase up-to-date.

      Granted, the original example I originally posted in my trac ticket (<a href="/[shortcode query='?ref=']">) was a bit confusing, but I don’t necessarily agree with the idea that this can’t be fixed just because it’s “invalid inout”. A perfectly reasonable example could have been something more like <img src="[post-thumbnail size="thumbnail" id=55]" alt="I want an alt attribute"/> (maybe an example where you want the user to be able to dynamically reference the featured image of another post) or something like that. I don’t see that example being confusing at all, but the results, for most users, will be terribly confusing.

      As someone else already mentioned, this had a major effect on the functionality of the Toolset (Views) plugin, but it also has major implications on a number of other plugins, and, due to the fact that these changes only occur inside of HTML tags (so things may not be visibly broken), it may be a long time before people fully realize how much of their sites are broken.

      Normal users will not understand why things don’t work; they’ll just know that they don’t work (as we have seen from all of the reports blaming the authors of Types & Views for these new issues).

      As plugin authors, we are now responsible for telling users that, if they want to use double quotes in their HTML tags, they have to wrap their shortcode attributes in single quotes. However, if, for some reason, they want to use single quotes in their HTML tags, then they have to wrap their shortcode attributes in double quotes. As if that’s not confusing enough; if we try to help our users out by building an MCE plugin that auto-inserts our shortcodes, we either have to build it to be smart enough to recognize whether there are single quotes or double quotes around the selection, or we’ll have to tell our users to change the tag because it won’t work this way.

      I, better than most, understand just how difficult fixing this issue can be without rolling back the fixes/changes that were released today, but I am not excited about the prospect of breaking so many existing implementations just because it’s tough to come up with a fix. I hope that some minds greater than mine will continue to look into possible solutions for this issue (not necessarily the background-image example, but at least the quotes-within-quotes issue), rather than just writing it off as a won’t-fix.

      • Ipstenu (Mika Epstein) 11:19 pm on July 23, 2015 Permalink | Log in to Reply

        For those playing at home, the trac ticket is https://core.trac.wordpress.org/ticket/33102

        • Curtiss Grymala 11:44 pm on July 23, 2015 Permalink | Log in to Reply

          Thanks, Mika. I probably should have included that link in my reply.

          Also, again, I want to make it clear that I’m not complaining about the security fix (I hope I’m not coming across that way). I agree 100% with @macmanx above, in that I’d much rather have to go through and fix code issues for clients (even if I have to do so for free) than have to deal with security intrusions.

      • Dave Navarro, Jr. 12:11 am on July 24, 2015 Permalink | Log in to Reply

        Custom Content Shortcode, Advanced Custom Fields, and hundreds of other plugins. This isn’t “just a few plugins” or “just a few sites”.

        And if it’s a legit security issue (I still don’t see it that way), then fine.. but handle it better. “We just couldn’t do it is a BS excuse.” And even if you couldn’t, you still should have posted a HUGE MONSTER post about the issue immediately so that there weren’t lost hours of trying to figure out the problem.

        Again, this was VERY VERY poorly handled and all I’m seeing are excuses.

    • mvandemar 11:19 pm on July 23, 2015 Permalink | Log in to Reply

      Actually, I see it now. The fixer of the XSS vulnerability is the same one who owns the bug ticket, namely miqrogroove. Someone just let me know that was where the actual issue was.

    • Mickey Kay 12:20 am on July 24, 2015 Permalink | Log in to Reply

      Third times a charm. . .

      Just to provide another example, in case it’s helpful, of the issue as experienced when using the Types & Views plugins (which seem to be a pretty huge use case based on feedback re: this issue).

      One example of how we might commonly use shortcodes within a Views template to output custom fields:

      <a href="[wpv-post-url]" title="[wpv-post-titlle]" rel="nofollow">[wpv-post-titlle]</a>

      If I had to guess, I would venture that we have upwards of 100+ sites we’ve built that use some form of the above example – all of which are now in theory broken.

      Just for clarification, can you illuminate how this is any more of a security risk than using PHP to spit out the custom field directly? Is it an issue of validation/sanitization? If that’s the case, then why is the decision being made to force a certain format, when validation and sanitization are the developer’s burden in all other cases (custom fields, theme options, customizer controls, etc)? Am I missing something?

      Thanks, and appreciate the open ears to all the feedback (however rough it might be getting at times :)

    • Mickey Kay 12:23 am on July 24, 2015 Permalink | Log in to Reply

      Goodness, this is ridiculous – tried 3 methods to include my code. How the heck do you include code in here? Not normal markdown?

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        It’s not markdown at all. Use code tags.

        <code>

      • Curtiss Grymala 12:49 am on July 24, 2015 Permalink | Log in to Reply

        You have to encode the angle brackets yourself (type the ampersand symbol, followed by either “lt;” or “gt;” – so, &lt; gets turned into <)

      • Samuel Wood (Otto) 8:52 pm on July 24, 2015 Permalink | Log in to Reply

        Perhaps unsurprisingly, we use shortcodes for that. The word “code” in square brackets will do the job for you on the make blogs.. Use “/code” to close the block.

        Example of code
        

        You can also use “php” for PHP code and “css” for CSS. Then it will have syntax highlighting as well.

        <div> html works too, it will encode the brackets for you </div>
        

        I fixed your most recent comment to have the correct syntax.

    • Dave Navarro, Jr. 12:23 am on July 24, 2015 Permalink | Log in to Reply

      So Gary Pendergast and others have convinced me that there really was a security issue, so my apologies for claiming it wasn’t. However, it still comes down to someone not taking the time to fix the security issue WITHOUT breaking so many live `web sites`.

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        Sadly that’s not always a tenable option.

        Once a security issue is known, it’s a mad race against time to get it patched before news gets out and people get hacked.

        • Dave Navarro, Jr. 12:56 am on July 24, 2015 Permalink | Log in to Reply

          Okay, well, I still think they could have make THIS post at the time the update was released and saved a lot of wasted time trying to figure out why sites didn’t work anymore…

          I’m gonna go see if I can find a snickers and if it will make me less cranky. I’ve bitched about this enough that someone on Facebook challenged me to do a better patch… Sadly regular expressions are a major weakness in my dev skills, but I’m gonna try anyway. There’s got to be a way to fix the security problem AND keep the prior functionality.

        • Timothy Jacobs 8:54 am on July 24, 2015 Permalink | Log in to Reply

          That is true in many cases, but not this one. The bug was disclosed in November of last year. Both were responsibly disclosed. And if you look at the trojan emoji security release, the core team has the ability to work on a patch for a long time. There simply wasn’t enough testing done before releasing this patch.

          • chriscct7 9:03 am on July 24, 2015 Permalink | Log in to Reply

            There was a heck of alot of testing done. However regardless of the amount of testing the way less than 1% of 1% of 1% of people use shortcodes makes it impossible not to break sites. For example: nested shortcodes inside of a single html attribute with mixed quotes.

            • Timothy Jacobs 9:23 am on July 24, 2015 Permalink

              I know not all bugs can be caught, but Views & Types seems to have quite a large user base… It just seems that the amount of testing done for this is much less than the trojan emoji bug.

    • mountainguy2 3:25 am on July 24, 2015 Permalink | Log in to Reply

      Downdate 4.2.3 broke my main site, took me 6 hours this morning to fix as I’m a total amature. These automatic updates are the height of lameness. It needs a one-click revert function, as well as a one-click revert that can be done somehow if admin access is broken, as happened to me.

      What is more, near as I could tell from reading, I was at risk for none of the vulnerabilities, I thus had my site broken for no good reason. Again the height of lame.

      MTN

    • codepage 4:42 am on July 24, 2015 Permalink | Log in to Reply

      this fix has broken easy 2 douzen websites of mine plus more of partners of mine. many plugins are broken. i’m working a lot with shortcodes and attributes in my designs. i have no idea on how to hack stuff where only the path is saved and i have for example an id as attribute. please fix this!

      • codepage 4:45 am on July 24, 2015 Permalink | Log in to Reply

        i use plugin OptionTree to make designs configurable. eg:
        <img src="[getoption">

        broke. how am i supposed to fix this? having the customer fill in the html code in a text field? that sucks.

    • lkraav 5:05 am on July 24, 2015 Permalink | Log in to Reply

      Following

    • Shailesh 5:51 am on July 24, 2015 Permalink | Log in to Reply

      Is this change also affect this case?

      <a href="[homeurl]/contact" rel="nofollow">Contact Us</a>

      In most themes I am using [homeurl] and [themeurl] to make dynamic url in links. So I don’t need to worry when I move site from local to live or sub directory to main.

    • Sam Rohn 6:04 am on July 24, 2015 Permalink | Log in to Reply

      here is an easy fix, this resolved WP 4.2.3 breaking some s2member shortcodes on one of my sites

      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"]"

    • twinsmagic 6:39 am on July 24, 2015 Permalink | Log in to Reply

      I’m trying to get this to work:

      I also tried

      @Sam Rohn, your suggestion didn’t work for me unfortunately.

    • AmirHelzer 9:00 am on July 24, 2015 Permalink | Log in to Reply

      We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.

      This is a straight forward change, which takes us one day to complete.

      Would have been great to receive a heads-up about an upcoming change in WordPress, so we could do this change on time.

      We received a huge amount of support requests due to this, but this isn’t the issue. We can deal with a wave a support issues. This time it wasn’t “our fault”, but sometimes it is.

      What worries us, as mentioned above, is seeing our clients (folks who build WordPress sites for a living), losing their faith in the system. They feel like the system sees them as little ants and not as humans. People don’t like seeing their problems being dismissed.

      Many of them run hundreds of sites. They cannot afford to stop everything and fix content on so many sites. Especially not if they are currently away for their family vacation.

      What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.

      We are your partners.

      Without WordPress (secure, stable and reliable), we would not exist.

      Without great themes and plugins, WordPress would not power 24% of the Web.

      WordPress core members already volunteer a lot of their time. I’m not asking for anyone to volunteer more time. Need help? Ask us. There is a huge community of developers who rely on WordPress. We would be happy to get involved and set up whatever is needed.

      Does this make any sense?

      • gfazioli 9:14 am on July 24, 2015 Permalink | Log in to Reply

        I agree!!

      • Mario Peshev 10:46 am on July 24, 2015 Permalink | Log in to Reply

        +1 – it’s not a one-time thing, it’s a process problem. And we had a late night urgent maintenance iteration due to a bunch of broken things for the same reason.

        It’s demoralizing for us and some of our clients don’t trust WordPress to be a stable and reliable platform that will run their business and let them sleep at night, without being afraid that things will break with zero changes on their end.

      • Rasheed Bydousi 2:10 pm on July 24, 2015 Permalink | Log in to Reply

        +1 You’re right. It shouldn’t be conducted in such a way. It is so annoying. Such changes shouldn’t be made arbitrarily. This isn’t a typical behavior pattern when it reaches to WordPress.

      • schutzsmith 2:50 pm on July 24, 2015 Permalink | Log in to Reply

        +1 Absolutely sums up how I’m feeling as well Amir! For instance, our digital agency runs on WordPress, we’ve built over 100 websites for clients on it, but as I tweeted this morning, this was the final nail in the coffin, we have to move away from WP because it’s literally killing our relationships with our own clients.

        I’m truly saddened by it because we’ve loved the community up until the last few months. It’s now at a point where we can no longer keep relying on WordPress to run a smooth and fruitful business.

      • Eliot Akira 3:03 pm on July 24, 2015 Permalink | Log in to Reply

        +1 – Thank you for articulating a sensible and constructive suggestion from the developers’ perspective. As someone who is one of the “folks who build WordPress sites for a living”, this issue has affected me greatly – spent most of the night trying to fix clients’ sites as well as doing the best to help plugin users. But more than the unexpected time and effort for support, as Amir states, the biggest worry for me is the loss of trust and reputation, both for myself as a developer but also for the clients regarding the reliability of the WordPress system.

        Last night, in a desperate attempt to find even a temporary solution, I made a plugin update which provided an option to patch one of the core files so that sites will be functional again. In hindsight, it was a poor judgement and bad mistake – but how the issue was handled was very disappointing. Apparently it was against the rules, and the plugin has been blocked from the official repository – without any warning or message to me. If someone had contacted me, I would have gladly removed the offending code. After all, I was only trying to help the situation. But now, I have no way to provide a reasonable update, and the users cannot access the support forum to get any information about why their sites are broken or what to do about it. Since there doesn’t seem to be any motivation to address the issue from the core side, we are all left hanging.

        “We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.”

        This seems to be the direction I need to take as a workaround solution, to resolve/render plugin shortcodes before passing to WP to process content. Just to note, in the original announcement are listed two cases (Shortcodes with Filtered Styles and Shortcodes with Bad Quotes) – but neither apply to the issue that I’m seeing across numerous sites.

        “What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.”

        I agree with this. At the same time, I can also see why the update was rolled out so quickly without prior notice, due to its sensitive nature. Perhaps the reasoning for not informing plugin developers is that some of them might try to exploit it. Another reason could be that there was no clear way to determine which plugins would be affected – and informing thousands of developers about a security vulnerability would have defeated the purpose of the update.

        I’m glad to see someone suggesting a positive way to look at the whole situation – what can we as developers and users learn from this on-going situation, and how can we contribute to improve the reliability and stability of WordPress sites.

        P.S. If someone of authority can contact me regarding the blocked plugin, I would really appreciate knowing how to remedy it. Almost immediately after the problematic update,I have pushed another update which removed the change. Both myself and the plugin users are waiting for any information that could help us.

      • safesoundaudio 4:03 pm on July 24, 2015 Permalink | Log in to Reply

        Well said Amir! You speak for many hundreds of us in this wonderful WordPress community.

      • dmccan 4:32 pm on July 25, 2015 Permalink | Log in to Reply

        I appreciate that the core team addresses these security issues. At this point, the WordPress ecosystem is so large that it is difficult to ascertain the impact of core changes, so I agree with Amir that we need a better process.

    • Herre 9:14 am on July 24, 2015 Permalink | Log in to Reply

      I fully understand this is an issue… but isn’t this a weird way of updating… almost al our clients are calling / e-mailing us at the moment as their sites seem to be broken…

      Normally it would be better to announce such huge impact changed to the plugin and theme developers…

      This means I need to fully reschedule my agenda… which already is full during holiday season…

    • JesseHeap 1:26 pm on July 24, 2015 Permalink | Log in to Reply

      Wondering if someone could provide some advice for us as I’m having a little trouble understanding what needs to change with shortcodes to fix our particular issue.

      The simpliest example I can give is below:

      Use Case: We use a short code to pass the HTTP_REFERER as a hidden value in our form:

      SHORTCODE in PAGE:

      Code in Theme Functions:
      //pcbReferrer
      function pcbReferrer_func() {
      return(getenv('HTTP_REFERER'));
      }
      add_shortcode( 'pcbReferrer', 'pcbReferrer_func' );

      Based on my understanding of the above, I’m not clear what I would change since we aren’t using attributes for this short code. I have other short codes that do use attributes which I’m trying to fix as well, but that’s a different story.

      • JesseHeap 4:09 pm on July 24, 2015 Permalink | Log in to Reply

        Here’s the solve in case this helps anyone:

        –ORIGINAL SHORTCODE THAT WAS NOT WORKING–

        Page Shortcode Reference:

        Themes Function Code:
        //pcbReferrer
        function pcbReferrer_func() {
        return(getenv(‘HTTP_REFERER’));
        }
        add_shortcode( ‘pcbReferrer’, ‘pcbReferrer_func’ );

        –NEW SHORTCODE THAT IS NOW WORKING–

        To solve this I moved the HTML into Themes Function PHP file. So I changed my form page shortcode to just:


        [pcbReferrer]

        And modified the function to include the HTML that was originally in the page:

        //pcbReferrer
        function pcbreferrer_func() {
        $output = '';
        return ($output);
        }

        Less then ideal as it intermingles more of the HTML with the shortcode and I always try to maintain as much separation as possible.

        But I certainly do not understand the security concerns of the prior approach so I’ll just assume this is the new constraint that we’ll need to follow for the sake of security…

        • JesseHeap 5:57 pm on July 24, 2015 Permalink | Log in to Reply

          Sorry I thought the <code> tags would leave the HTML alone but they are still stripping it away… This commenting system is a little frustrating…

    • safesoundaudio 4:02 pm on July 24, 2015 Permalink | Log in to Reply

      The change to allowed shortcode usage has NOT just affected a few RARE cases of shortcode uses. It has affected the functionality of hundreds (maybe even thousands) of websites including my own commercial site. Aside from the disaster it has caused to hundreds of web designers who use the excellent Toolset plugins, it has destroyed the functionality of a large number of other plug-ins. The forum is just full of examples today.

      As far as I can tell there was no advance notice. SOMEONE should have stopped and thought, ‘best we tell the community what we are planning’ The folks at Toolset seem to have been given no notice and they are probably the biggest plugin designers of the now disallowed shortcode usage.

      We can debate for ever what should be allowed and not allowed with shortcodes but that misses the point. Most of us are in the communication industry and this update has been very sadly lacking in foresight and communication.

      PLEASE role back this disaster of an update. I am 100% sure it was well intended but PLEASE look at the reality of what has happened.

    • crazycanuck27 6:00 pm on July 24, 2015 Permalink | Log in to Reply

      So I’m trying to pass a User Shortcode [currentuser_iserid] as a variable in an iframe and what worked for v4.2.2 suddenly broke and working to recover.


      … used to work but now it passes the shortcode as text. The shortcode works on its own. So is this an issue with the iframe and trying to pass a shortcode .. or quotes, or something else?

    • Claudio Esperanca 11:03 pm on July 25, 2015 Permalink | Log in to Reply

      is removed by TinyMCE when switching between HTML and WYSIWYG views as it is considered an invalid attribute for the tag, so it isn’t a perfect workaround.
    • minderdl 8:55 pm on July 26, 2015 Permalink | Log in to Reply

      While I can agree that wrong quotations do not need to work (i.e. one should only use single quotes inside double quotes and vice versa) the change also killed wrapping shortcodes:

      [blockcode]
      <a href="[myurl]">[mytitle]</a>
      [/blockcode]

      The href attribute will be empty, only mytitle will be replaced.

      Is this also considered “wrong” use of shortcodes??? Wrapping shortcodes are used for conditions, loops, etc. by several plugins. And this could not be changed in the same easy way like just changing quotation :-(

      With version 4.2.3 the part inside a wrapping shortcode is first processed by do_shortcodes_in_html_tags(). There all the replacement of the inner shortcode is done. Only afterwards, the result is passed to the wrapping shortcode callback. This has several problems: For wrapping shortcodes implementing a condition substitions will take place that might be completely unnecessary (ok, only a performance problem). But for wrapping shortcodes implementing a loop, the content will always be the same – i.e. the whole thing is completely broken.

      Did anyone thought about this?

    • FolioVision 9:53 pm on August 1, 2015 Permalink | Log in to Reply

      Surely 95% of the security issues could have been clamped with a minimal fix to be followed in next major version with a comprehensive fix – with proper warnings to all involved in shortcodes to clean up their act. Breaking people’s websites is always a bad idea.

  • Daniel Bachhuber 8:01 pm on July 20, 2015 Permalink |
    Tags: , , shortcodes   

    Shortcake (Shortcode UI) chat summary – July 20th, 2015 

    Present: @danielbachhuber, @matth_eu

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1437419017000004

    Next chat: same time and place

    Next release: v0.5.0 – Tuesday, August 4th

     
  • Daniel Bachhuber 7:46 pm on June 29, 2015 Permalink |
    Tags: , , shortcodes   

    Shortcake (Shortcode UI) chat summary – June 29th, 2015 

    Present: @danielbachhuber, @samuelsidler, @matth_eu

    • Sam shared with us the possibility of getting Shortcake committed to WordPress core. While he can’t make any guarantees, this is the direction he suggested:

      • Better first-run experience with the plugin so people can evaluate it better. He recommends adding a few “example” shortcodes, and mention that they’re examples / not to be included in core. Pull quote and PDF could be a good start.
      • Decide on the appropriate UX for inserting new shortcodes. The experience is currently tucked away under “Add Media”. We’ve been exploring a “Add Post Element” button alongside “Add Media”, or dedicated buttons in the editor for some post elements.
      • Inline editing would be really nice. We should see if we can make it the default experience for most shortcodes, and all existing core shortcodes. We should also experiment with content blocks, and see what other editors are doing.
    • Matt lost his internet, so we didn’t talk about any code things.

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1435604506000006

    Next chat: same time and place

    Next release: v0.5.0 – Tuesday, August 4th

     
    • webdevmattcrom 5:56 pm on July 3, 2015 Permalink | Log in to Reply

      Love the idea of adding a “Add Post Element” button. While I’m not a fan of adding more clutter to the editor in general, the current Shortcake experience is anything but intuitive for the average end-user. We build plugins that utilize shortcodes and that is the only thing that has kept us from using Shortcake to date.

  • Daniel Bachhuber 8:27 pm on June 22, 2015 Permalink |
    Tags: , , shortcodes   

    Shortcake (Shortcode UI) chat summary – June 22nd, 2015 

    Present: @danielbachhuber, @goldenapples, @davisshaver

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1434999676000006

    Next chat: same time and place

     
  • Daniel Bachhuber 7:57 pm on June 8, 2015 Permalink |
    Tags: , , shortcodes   

    Shortcake (Shortcode UI) chat summary – June 8th, 2015 

    Present: @danielbachhuber, @matth_eu, @goldenapples

    • Shortcode UI v0.4.0 will be shipping tomorrow (June 9th) or Wednesday (June 10th). Here are all of the issues.
    • We spent some time discussing the bugs in the backlog.

    Next chat: same time and place

     
  • Daniel Bachhuber 11:35 pm on June 1, 2015 Permalink |
    Tags: , , shortcodes   

    Shortcake (Shortcode UI) chat summary – June 1st, 2015 

    Present: @danielbachhuber, @matth_eu

    If you’d like to get involved, our documentation could really use some editing / additions. Feel free to open a GH issue with suggestions, or stop by #feature-shortcode in Slack.

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1433185206000006

    Next chat: same time and place

     
  • Daniel Bachhuber 11:41 pm on May 11, 2015 Permalink |
    Tags: , , shortcodes   

    Shortcake (Shortcode UI) chat summary – May 11th, 2015 

    Present: @danielbachhuber, @matth_eu, @goldenapples

    • Fusion pushed Image Shortcake to production today. It’s a plugin that uses Shortcake to replace with [img]. The biggest outstanding implementation issue is aligning an image left or write with text wrap. @goldenapples will continue to explore in Shortcake.
    • We’d like users to be able to edit shortcode attributes with a rich-text editor. However, core doesn’t easily support this use-case. For now, it looks like we’ll transparently encode and decode attributes with HTML values. @matth_eu will create a core ticket see how we can make this less of a hack.
    • We’re still looking to ship v0.4.0 on or around June 9th. Enhancements will be landing in the next couple of weeks so we can have a week or two of soaking before publishing to WordPress.org.

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1431371317000011

    Next chat: same time and place

     
    • Pat Hawks 11:57 pm on May 11, 2015 Permalink | Log in to Reply

      Replace *what* with `[img]`?

    • goldenapples 12:34 am on May 12, 2015 Permalink | Log in to Reply

      Replace `` tags or `` shortcodes inserted through the WP Editor using the *Add Media* function.

    • Jon Brown 1:49 am on May 12, 2015 Permalink | Log in to Reply

      As much as I’ve _long_ advocated for some sort of intelligent image object/element that themes & plugins could affect the markup on, shortcodes for this just feels wrong…. I’ll certainly be testing it, and am excited at the possibility, just skeptical that anything shortcode based is a reliable future theme change proof option.

  • Daniel Bachhuber 8:15 pm on April 27, 2015 Permalink |
    Tags: , , shortcodes   

    Shortcake (Shortcode UI) chat summary – April 27th, 2015 

    Present: @danielbachhuber, @matth_eu

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1430161317000487

    Next chat: same time and place

     
  • Daniel Bachhuber 7:55 pm on April 20, 2015 Permalink |
    Tags: , , shortcodes   

    Shortcake (Shortcode UI) chat summary – April 20th, 2015 

    Present: @danielbachhuber, @matth_eu

    • Meeting focused on clearing up some of the remaining issues in the v0.3 milestone.
    • In v0.4, we’re looking into de-coupling Shortcake from the Media Library experience. If you have opinions on this regard, you should follow along on this issue
    • Matt has done some exploration of repeatable fields. The crux of the problem is our field templates include the field, and label and description. Fieldmanager and CMB use prototype HTML for repeatable fields. However, before we go about reinventing Fieldmanager, we should reach out to Metadata API working group to see how they’re approaching.
    • Supporting rich text editor for a shortcode attribute is a nice idea but has a couple fundamental flaws: 1) HTML can’t easily be stored in shortcode attributes, 2) TinyMCE views gets funky when there’s HTML in the inner_content. The idea needs more technical baking before we can commit it to a milestone.
    • Goal is to have remaining v0.3 issues into Fusion production by tomorrow morning PT, and then ship Wednesday or Thursday.

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1429556549000347

    Next chat: same time and place

     
  • Daniel Bachhuber 10:59 pm on April 13, 2015 Permalink |
    Tags: , , shortcodes   

    Shortcake (Shortcode UI) chat summary – April 13th, 2015 

    Present: @danielbachhuber, @matth_eu

    • Not much development done in the past week.
    • Discussed HTML in our `description` attribute. User goal is to be able to use arbitrary formatting HTML in a field’s description. However, Underscores permits either no HTML or any HTML. It would be nice if we could use `$allowedposttags` or similar. Matt will be doing some research for any prior art.
    • Discussed whether we should use `switchEditors._wp_Nop` or roll our own. Matt will reach out to core to see why it’s private in the first place.
    • All of the issues in v0.3 have been assigned. By next Monday, we’ll be making the release decision. Code will be shipped to Fusion production throughout the week.

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1428951753000191

    Next chat: same time and place.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar