Updated and no change for me, still adding a bunch of these at the bottom of my script, if you want to speed this up I can give you access to have a look to make troubleshooting faster:
<script type='text/javascript' src='http://mydomain.com?ver=1.8.9'></script>
<script type='text/javascript' src='http://mydomain.com?ver=1.8.9'></script>
<script type='text/javascript' src='http://mydomain.com?ver=1.8.9'></script>
<script type='text/javascript' src='http://mydomain.com?ver=1.8.9'></script>
<script type='text/javascript' src='http://mydomain.com?ver=1.8.9'></script>
<script type='text/javascript' src='http://mydomain.com?ver=1.8.9'></script>
<script type='text/javascript' src='http://mydomain.com?ver=1.8.9'></script>
Well, I got it working.
I removed these completely from my functions.php:
wp_enqueue_script('jquery', '', '', '', true);
wp_enqueue_script('jquery-ui-core', '', '', '', true);
wp_enqueue_script('jquery-ui-tabs', '', '', '', true);
wp_enqueue_script('jquery-ui-resizable', '', '', '', true);
wp_enqueue_script('jquery-ui-draggable', '', '', '', true);
wp_enqueue_script('jquery-ui-selectable', '', '', '', true);
wp_enqueue_script('jquery-ui-dialog');
does that mean something is trying to enqueue this more than once? I always had 7 of these:
<script type='text/javascript' src='http://mydomain.com?ver=1.8.9'></script>
which matches how many scripts I was trying to enqueue there.
Thank you very kindly for your help Jason, it is much appreciated. Any chance you know why this was happening for my understanding?
Essentially you were mis-using wp_enqueue_script in such a way that you broke things. There are two ways to use wp_enqueue_script. The main way is just:
wp_enqueue_script('handle');
The other way is to pass all the arguments you would normally pass to wp_register_script. This is for single use scripts that don’t need to be registered separately. It is not for enqueueing already registered scripts.
So to explain:
wp_enqueue_script('jquery', '', '', '', true);
That says: register a new script with the handle 'jquery', with no source url, no dependencies, no version, in the footer, then enqueue it, which judging from the URLs you ended up with, it mostly worked, but I don’t think it’s what you wanted.
I’m guessing you are trying to force scripts that WordPress registers as header loading to instead load in the footer. Don’t do that. Even if it did what you wanted, core WordPress doesn’t work if you do that.
Hope that helps!
Thread Starter
Mugsy
(@mugsy)
Hi Jason,
Unfortunately, the updated UGL didn’t solve my issue (I’m using WP3.2.1) and I haven’t added any scripting of my own the way “defunctlife” has, so I’m not sure what is happening on my end.
Re: My browser cache… I disabled it when I moved to a SSD to reduce writes to my SSD, but even before I added my SSD two weeks ago, I was still having the problem, so I know that’s not it. The issue is definitely on the Server-side of things.
I configured my host (“1and1”) last year to use PHP5 and SQL5, if that makes any difference?
I don’t know enough about how the “Quick Edit” link works normally to figure out what UGL is doing different, and at this point, I haven’t noticed any other commands not working, so it is all very odd.
Mugsy,
Other than changing where scripts are enqueued from, UGL does it’s very best to do nothing else. Unfortunately other plugins often do things like unregister core scripts and replace them, or register scripts with the wrong dependencies. With the exception of the issue I fixed in 1.2, there have been no issues found in UGL like the one you are reporting where some other plugin or theme wasn’t doing something incorrectly. If you’ve found one, I want to know so I can fix it, but I don’t have anything to go on.
If you can run a browser with a javascript console (life Firefox with FireBug enabled) and tell me if you see any errors on page load and/or any new ones when you hit Quick Edit that would be a big help. Also check and make sure the scripts are actually loading or being blocked for some reason (the FireBug ‘Net’ tab can tell you this). If a javascript file doesn’t actually load you won’t know about it (other than possibly things not working on the site).
If you want to give me access to your site to take a look you can use the contact form here: http://jasonpenney.net/contact/
Jay
Hey Jay,
Spot on here, I was trying to force them to the footer.
Thanks again for spending the time.
Mugsy,
Taking a look at the source of the plugins on your site, I see the following potential issues:
flv-embed: This plugin does not use the script loader, but prints directly to the header (even worse it’s printing to the header a script that WordPress’s script loader already supports).
lightbox-2: This plugin calls wp_enqueue_script outside of an action, which is not supported according to WordPress docs, and it’s known to break UGL.
pretty-comments: this plugin in registering scripts and enqueueing them during ‘wp_print_scripts’, which is too late according to the WordPress docs.
Both litebox-2 and pretty-comments are doing things that WordPress codex calls out will break things:
This function will not work if it is called from a wp_head or wp_print_scripts actions, as the files need to be enqueued before those actions are run. See the Usage section for the correct hooks to use.
That’s my guess as to what’s going on, although looking at the net console n FireBug I also see it trying to load a script from a URL that doesn’t exist. I’m not sure what’s doing that, but it’s probably not helping.
