Forum Replies Created

  • +1 for this functionality.

    I found this forum post that started all the way back in 2014 and ended in March 2018 when a link was posted to this post by Elliot:

    That post would imply that Elliot add this functionality in 5.7.0 but it does not appear to be working in 5.8 beta3, so not sure if Gutenberg broke this or something else is going on. Someone created a plugin to address this issue before Elliot posted that 5.7.0 supports it. But I just installed this plugin and it does not appear to be working in WP 5.0 and ACF Pro 5.8 beta3.

    I guess the only way for me to get around this is to create a Type field that is a select/checkbox list and manually add my values in and then base my conditional logic off of that. Hoping that this functionality will be added back in a future release.

  • John, you’ve provided a lot of help in the past on many acf issues, so glad this info was useful. Thanks as well for the wp-update-prevent-db-changes file. That will be useful.

  • Anu,

    The solution that we settled upon to speed up our post edit admin loading was to alter the postmeta meta_key index to 191. There are some potential downsides, but in our case it appears to be working for us. If you upgrade WP, check to make sure that the upgrade did not set meta_key back to 255. Here’s the mysql statement:

    ALTER TABLE wp_postmeta MODIFY meta_key varchar(191);

    Here’s an original thread that discusses the issue:

    Here’s a post that suggests some alternatives:

    We also periodically run a query to delete empty rows both the hidden _ ACF field reference, for example: _some_field_name and the some_field_name field as well. ACF does not appear to mind if those are deleted and if you end up add a value to one of these fields, ACF will re-create the row/s. Here are the queries that I run to do the clean up. These queries work for us because all of the acf fields we want to delete start with the word “article”.

    — delete “_article” postmeta rows that have corresponding empty “article” rows
    DELETE wsp.*
    FROM wp_postmeta AS wsp
    WHERE meta_id IN (
    SELECT mid
    FROM (
    SELECT t1.meta_id AS mid FROM wp_cdp_postmeta as t1
    JOIN wp_cdp_postmeta as t2 ON t1.post_id = t2.post_id
    WHERE t1.meta_key = CONCAT(‘_’,t2.meta_key)
    AND t1.meta_key LIKE ‘_article_%’
    AND (t2.meta_value = ” OR t2.meta_value = ‘0’)
    AND t1.post_id BETWEEN 0 AND 400000
    ) x

    — remove “AND t1.post_id BETWEEN 0 AND 400000” if you don’t want to limit the query

    — delete empty “article” postmeta rows
    DELETE FROM wp_postmeta WHERE meta_key LIKE ‘article%’ AND (meta_value = ” OR meta_value = ‘0’) AND post_id BETWEEN 0 AND 400000;

    — remove “AND t1.post_id BETWEEN 0 AND 400000” if you don’t want to limit the query

    — change DELETE to SELECT if you want to get a count before you run these statements. Always back up your database before your run a DELETE statement

  • John, thanks for such a quick and detailed reply. I’ll share this info with our team and let you know if we have any follow up questions.


  • Thanks so much for your quick reply James. Your answer was what I suspected. Don’t think I want to modify core, so we’ll probably look into getting rid of Tags which we were using for related posts. Or we might just keep using Tags and rely on the auto complete that’s built into the Filter by Taxonomy select field, rather than try to scroll through all of the taxonomy values.

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