Support

Account

Home Forums Front-end Issues Meta data for edited post applied to page (5.3.9)

Solved

Meta data for edited post applied to page (5.3.9)

  • I did submit a support ticket on this a couple of weeks ago but I’ve heard nothing back so I’m trying here since I can also find no way to retrieve an existing support ticket, only submit another one.

    Recently, a front-end ACF form submission appears to have overwritten the title and meta-data for the page that the form is on, rather than the post id which was being edited. The form has always worked previous to that incident, and I have been unable to recreate the error. The timing of the incident seems to be around the release of ACF Pro v5.3.9, but the site has since been updated to v5.3.9.1. I just want to know if the x.x.x.1 release might have been a fix for just such an error being possible, but any release notes I can find don’t seem clear on this.

    Is it likely this was a bug introduced in 5.3.9 and subsequently fixed in 5.3.9.1?

  • I don’t see anything in the recent changes that specifically addresses this:

    = 5.3.9.2 =
    * Time Picker field: Added compatibility with previous 3rd party field settings
    * Core: Fixed JS error setting l10n for Select2 with 3rd party libraries

    = 5.3.9.1 =
    * Time Picker field: Fixed bug causing value to appear as current time
    * API: Fixed bug causing have_rows() to fail when using an object as $post_id parameter

    Unless it had something to do with the last one, maybe.

  • Hmm, my slight understanding of this makes me think it might have been that last one. If the post_id was effectively being cast to null perhaps the WP way would have had it apply the data to the page post instead.
    Think I’m gonna have to grasp at that particular straw.

  • There was an update to have rows in 5.3.9 that added a new function the_row_index(). Before this update you could call have_rows('field_name, $post_object), in other words you could use$postin a loop instead of using$post->ID. After the updatehave_rows()` would always return false when using a post object. This was to do trying to convert the post object to a string before getting the valid post id, and this caused a PHP error.

    If you were using a repeater, and a post object was used when executing have_rows(), the PHP error during could have cause any number of things to go wrong.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.