10 Comments

  1. Amir

    Themes and plugins (like our) use $wpdb->prepare(). It would be great to get an early heads-up, so we know about upcoming API changes and we can release our updates ahead of time.

    As it is, WordPress 4.8.3 fixes a security problem and breaks a good number of sites. Of course, we’re releasing an update ASAP for that change.

    For end-users, it doesn’t help knowing who’s right and who’s wrong and what all the underlying good reasons are. Their sites broke and they’re frustrated.

    It’s our common responsibility to make sure that sites are secure AND don’t break. If we could get advanced warnings about upcoming changes, we will stay up all night to adapt our plugins ahead of these changes, to prevent sites from breaking.

    Report

    • David Anderson

      @Amir can you give any examples of code that has broken? The information in the release notes is a bit sparse, and itself gives no examples.

      Report

      • David Anderson

        Hi Jeff, why do my comments go into moderation?? Did I do something wrong?

        Report

      • Jeff Chandler

        All comments are moderated.

        Report

      • Andrea

        @david here’s the explanation of the issue.

        In `sitepress-multilingual-cms/classes/query-filtering/class-wpml-get-page-by-path.php` (`\WPML_Get_Page_By_Path::get_page_by_path_filter`), we had the following where clause:

        “`
        $this->wpdb->prepare( “ID IN ( SELECT element_id FROM {$this->wpdb->prefix}icl_translations WHERE language_code = %s AND element_type LIKE ‘post_%%’ ) AND “, $this->language )
        “`

        In case this is not clear, here we want to add a WHERE clause which filters by language and looks for all element types starting with “post_”. To escape the “%”, we must prefix it with another “%”.

        With WP 4.8.3, this string is converted into something like that:

        “`
        “ID IN ( SELECT element_id FROM wptests_icl_translations WHERE language_code = ‘en’ AND element_type LIKE ‘post_{e72a1103990676cd16df62a59657d29057b9f79ef08138075ceae85fee130fb6}’ )”
        “`

        `post_%%` was turned into `post_{e72a1103990676cd16df62a59657d29057b9f79ef08138075ceae85fee130fb6}`.

        We hook this method which adds the WHERE clause to the `query` filter.

        We’ve fixed the issue by using a higher priority (-1).

        This way the placeholder gets fixed by WP after we adjust the where clause.

        In our case, it was only one affected place (at least, after looking at all similar issue and running our tests which, thankfully, spotted the problem before our fix).

        As Amir wrote, like we had this problem, many other plugins and themes could have been affected.

        Report

    • Tim Nolte

      I think the challenge with security issues is trying to balance end user security-related safety versus breaking their site. It’s almost a catch 22 issue since from a security perspective a secure broken site is better than a functioning site with security issues. Unfortunately it’s hard, as a plugin, to have that sort of conversation with a user, and as you stated, user’s don’t actually care why their site broke even if it is a good thing. Security is hard and I don’t see there being an all encompassing answer.

      Also, how can WordPress release the pending changes to developers only, without risking nefarious people getting that information also and using it to attack sites before the security fixes are publicly available?

      Report

  2. Danny Brown

    I’m sure all the work being done on Gutenberg took precedence over an important security issue… /endsarcasm

    Report

  3. Denis

    So WPML and newest WP obviously don’t play nice together, because the site I’m maintaining is broken after the update…

    Report

    • Amir

      Yes Denis. That’s exactly what I was referring to. WPML already got an update which fixed the newly-introduced compatibility problem. It was a very simple fix and we released it quickly after we saw WordPress 4.8.3.
      Had we been able to see this version of WordPress before it was released, we would have updated our code ahead of time. It’s impossible to come up with updates for WP versions that come without betas, over night, during a major holiday.

      Report

Comments are closed.

%d bloggers like this: