Reporting bugs here is fine. Afraid we don’t allow people to log them in the bug-tracker or we would spend half our time dealing with all the garbage! If a bug is reported here and after confirming it is a bug then we always add it as we do sensible and possible enhancements and features.

So – the first thing we have to say is that this is a unique report. That doesn’t rule it out from being a bug but is much more suggestive of a local conflict of some kind in your setup.

We certainly did nothing in the last update to cause a rash of ‘several other instances where scripts half-way down a page are error’ing because jQuery is not available yet’. So can we start by determining what else was updated at the same time?

In my own experience, the main jQuery library is usually force loaded in the header in any case.

And finally, use of the proper, standard, WP supplied jQuery library does not require a wp_register_script() call as it is already registered. It simply requires to be enqueued with wp_enqueue_script(). If your site is registering that sounds suspiciously like it is loading it from a third party source and that will almost certainly cause errors as it is unsupported.

jQuery is being registered to a CDN, and then enqueued as ‘jquery’, so dependencies remain unaffected (usually).

Other javascript errors (new to plugin, so probably just first time noticed and not caused by last update).  

sp_BreadCrumbs()

jQuery(“#spBreadCrumbs a:last-child”).addClass(“spCurrentBreadcrumb”);

and

sp_forum_footer()

jspf(“#spQuickLinksForumSelect, #spQuickLinksTopicSelect”).msDropDown();

Then it is probably the jQuery from the CDN. This is the usual suspect.

The WordPress version of jQuery is specially compiled to include the ‘no conflict’ clause which is needed for anyone who may also be using the older prototype on their website. This is the standard WordPress supplied version of the library and – as our system requirements page states – the one we support. Actually it is the one that all kosher plugins should support.

By using this standard we also ensure that the jQuery version being used is always the correct one to match the WordPress version. We have encountered many sites in the past loading jQuery from a CDN where the version being loaded os getting more and more out of date.

I would also posit that using a CDN doesn’t really help much with anything and hinders more.

Try disabling the CDN load. Refresh your browser cache – and see if these errors persist…

Understand your position.  Thanks again for the quick replies, appreciate it.  We’ll work around it where possible, as we’re getting a nice speed bump using a CDN.

Unrelated, do you want notified of these?

Notice: Undefined index: editor in /simple-press/forum/content/forms/sp-form-components.php on line 22

Notice: Undefined index: editor in /simple-press/forum/content/forms/sp-form-post.php on line 16

Mainly notices can be ignored and are really more a nuisance than anything. I assume these are showing up in your error log as opposed to on the display.

In this case it might be worth eradicating them as it looks to me like a couple of default values have not been stored as they should.

I would visit Forum Admin > Options > Global Settings and ensure that a default editor is selected. And update. Then Forum Admin > Options > Global Display Settings and update the panel. Unless you want to change the option to use the integrated editor toolbar.

These actions should, I believe eradicate the notices. But I will look at outting sme checks in place as well in case ity ever pops up again with someone. Thanks.