Location rules bugs after migration to version 4.1.6, WP v. 3.5.2

• ashkas

• July 8, 2013 at 3:01 pm

This is a repost of a topic I put up last week that appears to have been lost in the migration to the new support forum.

Original should have been here – http://support.advancedcustomfields.com/discussion/comment/20322#Comment_20322

Elliot this was your reply to me (had it in email)

Before I jump into this topic, can you please first edit your field groups and re-save them (without changing any fields or settings). This will potentially re-save some data and fix the issue.

Next is to head to the edit page and perform a hard refresh. Can you confirm that the correct acf javascript file is being loaded in the head? You can check the version parameter of the script file with the version of the plugin

Tried re-saving the field groups, did not make any difference. I should also add that after we upgraded we also added quite a few new field groups that have had no data saved to them, so there was nothing to migrate (we are beginning to develop new sections of the site, hence the upgrade). These new fields experience the same problems.

Next I tried a hard refresh and still no dice.

On the third, however, checking the version parameter of the script file, I did notice something.

On a different site that I have upgraded to 4.1.6 (actually now 4.1.7 with both installs), I have the version paramter after the script. For instance, it appears like this

plugins/advanced-custom-fields/js/input/ajax.js?ver=4.1.7

But with the problem instal, there’s no version parameter after the script.

plugins/advanced-custom-fields/js/input/ajax.js

I did do a code difference check between the two scripts and they are both the same file. But as the version should be showed after, I wonder if something is interfering with the way you enqueue the scripts in the plugin in the new version? Now I’m not so sure the javascript is actually completely executing…

• Elliot

• July 8, 2013 at 3:35 pm

That’s very interesting!

Great debugging my friend.

My bet is that on the ‘problem’ install, there is a server setting or .htaccess setting that is preventing the input.php file to be used as a .js file

If you head back to the old support site, there is a featured post on input.php 404

You may find some useful info there!

• ashkas

• July 8, 2013 at 6:41 pm

Thanks for the response Elliot, unfortunately in our situation that did not solve the issue.

Did some further testing (switching plugins themes) and eventually narrowed it down to an action hook for admin_enqueue_scripts. We load css on the backend for some of the content editor forms, and with the issue happening with ACFs enqueue’s we were able to finally find the issue.

At the moment we’ve just commented out our own enqueue hook as we’re on the development server. Will provide the code of how we’re doing this, but we’ve never had an issue with this before (either with ACF nor other plugins).

function load_theme_admin_scripts($hook) {
	// Admin CSS
	wp_enqueue_style('theme_admin_css', get_template_directory_uri() . '/library/css/admin_css.css', false, '1.0', 'all');

}
add_action( 'admin_enqueue_scripts', 'load_theme_admin_scripts' );

• Elliot

• July 9, 2013 at 9:39 am

Hi @ashkas

Thanks for the reply. I’m not sure why this would be causing any issues with ACF. It doesn’t seem to change any core functionality at all…

Is it possible that there is a Syntax error which is breaking the admin_enqueue_scripts action?