ACF PRO 5.7.11 bugs (and it's solution) just caused a massive loss of confidence

• curtisb

• February 14, 2019 at 11:09 am

I just want to be honest with you and let you know that my confidence in ACF just took a massive hit today.

There were multiple serious bugs in 5.7.11. This makes me question how much QA is going on to where slashes are tacked onto quotations without anyone noticing. Slashes added to quotations. Entire functions accidentally deleted. acf/format_value behavior changed. Plus whatever else has been reported so far. Don’t mean to sound harsh – I get it, shit happens.

But the solution was more alarming to me. You have overwritten 5.7.11 in the downloads with undocumented fixes, and are instructing your users to “manually edit acf.php to 5.7.10 to trigger the update”. So how many users have 5.7.11 and aren’t getting an automatic update because of this very bizarre decision?

Without a changelog how do I know what damage to check for? Slashes will be saved to people’s databases – I only know about it because I noticed it first hand.

Should I be downloading 5.7.11 often and checking the diffs to see if you fixed more stuff? This is an absurd workflow… does this happen frequently?

• Elliot

• February 14, 2019 at 4:04 pm

Hi @curtisb

Thanks for the honest feedback. I’m first to admit this was a buggy release.

I would like to clarify that in no way am I trying to “hide” these bugs by asking users to re-download the plugin, this is simply a way to get those bugs fixed, and allow users to test out the fix. I am planning to release a new 5.7.12 version tomorrow which will include all the fixed bugs. I would rather release a single version to fix all bugs, than multiple versions each day.

The Options page slashes value caught us by surprise, but luckily was one that we could fix quickly and confidently.

I’m not sure that I am familiar with the “acf/format_value” filter issue. I’ll search around for reports on this.

I’ll definitely reflect on this for sure.

Thanks again.
Elliot

• curtisb

• February 15, 2019 at 12:35 am

@elliot I appreciate your response. I had a feeling it was a way of deploying hotfixes quickly, vs trying to hide the bugs – but thank you for clarifying. I was a little more frustrated in the moment yesterday, so apologies for the bluntness.

I would definitely recommend against having unmarked versions of versions though. Being able to trust that 1 version number = 1 copy of code is super important for many reasons 🙂

If I may offer a suggestion? I know it sucks to have a bunch of new versions in one day (like if you need to release each fix out ASAP). You could try a 4th version number for “hotfixes” — ACF 5.7.11.1, 5.7.11.2, etc. Once you’ve got them all, you can consider the latest hotfix as the only relevant version within the “5.7.11.X” series — so if you finish with 4 hotfixes, then in your download archive you’d have:

Download 5.7.10
Download 5.7.11.4
Download 5.7.12

In this way, you’d also be able to save 5.7.12 for an actual new release, rather then “5.7.12 – just bug fixes for 5.7.11” 🙂

A more involved idea:

I see you have free version of ACF on Github — I assume you have ACF PRO on Github as well, just set as private? It would be very interesting if you considered giving PRO members read access to the PRO repo. FontAwesome Pro works in this way which is where I got this idea. You could even market that as a new benefit of buying PRO. The reason I bring this up though, is that you could direct users to a specific branch for testing if you don’t want to release it publicly yet.

Hope this is helpful in some way!

Curtis

• curtisb

• February 15, 2019 at 12:53 am

@elliot For the acf/format_value issue, if you haven’t received any reports for it, it’s possible I was doing something very unusual.

qtranslate saves all translates in the same fields, separated by a syntax, something like this [:en] english here [:es] spanish here. By default it gives you English, but I wanted to get unfiltered full value with all languages.

// * Removing filter so that we get the raw untranslated value (acf-qtranslate uses acf/format_value)
remove_all_filters('acf/format_value');
$fields = get_fields($post_id);

This did the trick for me. But after 5.7.11, this also caused all of the field key names in the response to turn into IDs (“text_field_name” turned into “field_5bfd7724ed94”).

I already refactored it to work without remove_all_filters so I’m not stuck on it. If nobody else has reported it perhaps there’s not an issue especially since I was using a heavy handed technique in the first place (remove_all_filters)