wildmice

Hi David, and thanks for such a quick response.

After some head scratching and digging in your code, i realized that you solve time limit problems by using resume, and i found the very same instructions that you posted above. It works now.

Thanks for the help.

… I should also mention that i would be nice if you could check whether a font is already in use on the site, before downloading it again from Google. In this case i already have Indie Flower on the site and don’t want to load it again.

– shanna

just change line 566 from :

if($custom_tooltip_active == 1) {

to :

if (isset($custom_tooltip_active) && $custom_tooltip_active == 1) {

Hi Arnan,

I’m thinking maybe you missed the point here. The Autoptimize plugin gets the order of scripts from WordPress. Whatever order they are queued in (explicitly or by default) is what the plugin will use.

So in the case of AdRotate, they are not being queued in the right order. Your plugin only works by accident/good luck because fortunately your script does not execute before jQuery is loaded, even though jQuery is loaded *after* yours.

I did of course add the dependency and it solved the problem for me because then Autoptimize got the correct order from core. But i cannot use a modified version of your plugin because then i’d be excluded from future updates or updates would erase my mod. So i have little choice but to either hope you resolve this, or else i’ll just not be able to use AdRotate.

I’d like to re-iterate that Autoptimize does not overrule your loading order. It is using it. That’s the problem. As soon as you put all scripts into one file, in the order that WordPress queues them, the order becomes critical and it will no longer work by coincidence as it does now with separate files.

Maybe that’s how it *should* be, but the code actually generated by your plugin shows it’s not the case. Here is what we are getting :

<script type=’text/javascript’>
/* <![CDATA[ */
var click_object = {“ajax_url”:”http:\/\/ancronmedical.com\/wp-admin\/admin-ajax.php”};
/* ]]> */
</script>
<script type=’text/javascript’ src=’https://ancronmedical.com/wp-content/plugins/adrotate/library/jquery.adrotate.clicktracker.js’></script&gt;
<script type=’text/javascript’ src=’https://ancronmedical.com/wp-includes/js/jquery/jquery.js’></script&gt;
<script type=’text/javascript’ src=’https://ancronmedical.com/wp-includes/js/jquery/jquery-migrate.min.js’></script&gt;
<script type=’text/javascript’ src=’https://ancronmedical.com/wp-content/plugins/google-maps-widget/js/jquery.colorbox.min.js’></script&gt;
<script type=’text/javascript’ src=’https://ancronmedical.com/wp-content/plugins/google-maps-widget/js/gmw.js’></script&gt;
<script type=’text/javascript’ src=’https://ancronmedical.com/wp-content/themes/nelson-base/js/wildmice.min.js’></script&gt;
<script type=’text/javascript’ src=’https://ancronmedical.com/wp-content/themes/nelson-base/js/picturefill.min.js’></script&gt;

This is with scripts being loaded at the end of the page. As you can see, your script gets loaded before jquery because its dependency on jquery is not declared in the enqueue. The code snippet i posted earlier resolves this problem for us.

The AdRotate script only works because jquery happens to get loaded before your script executes. The reason why it matters is because this interferes with a plugin (Autoptimize) that uses the enqueued order.

Note that this is the regular WordPress version of jQuery, loaded at the end, and jQuery does indeed get loaded *after* your script.

Sorry, i should have mentioned that i had already checked “load javascript in footer”. But jquery.adrotate.clicktracker.js still loads before jQuery.

It seems also that it is being loaded even when there are no active ads.

Yes, resolved. I’m with you on that. Consistent is good ?? and it seems to be that.

You can mark this one as resolved. The script in AdRotator is being enqueued without the necessary jquery dependency. I have notified the plugin author.

It was only working because jquery was fortunately getting loaded before the script executed, but because AO puts everything in one file the script executed before jquery, breaking the script and everything after it.

So it seems the problem is that you don’t specify jquery as a dependency when you enqueue the script, and in this case your script is getting enqueued before jquery, so it doesn’t work.

In version 3.11.7 of AdRotate, in file adrotate-output.php, line 472 is :

wp_enqueue_script(‘clicktrack-adrotate’, plugins_url(‘/library/jquery.adrotate.clicktracker.js’, __FILE__), false, null, $in_footer);

and it should be :

wp_enqueue_script(‘clicktrack-adrotate’, plugins_url(‘/library/jquery.adrotate.clicktracker.js’, __FILE__), array(‘jquery’), null, $in_footer);

Thanks for your patience on this. Perhaps those hidden JS exclusions should be more prominent. That is why the Google Analytics code is being excluded.

As for the CDATA, if the rules you listed above are also being applied when the XHTML filter is enabled, then yes, i would say it’s working – just not what i expected. However, i can’t see any problem with removing extraneous CDATAs if your rules are consistent with the XML standard (which i presume they are).

shanna

I sent you some screenshots. None of the options seem to be working on that last block of JS (the Google Analyics tracking code), and there are no matches with the exclude list.

Ok, yes the filter is working. But there is another problem here.

The block of JS that i pasted above (standard Google Analytics tracking code) is not getting filtered by your new filter, and it is not getting compressed and combined with other JS, even though there are no matches on the exclude list.

For other blocks of JS the filter and the compression/combining are working fine.

Frank, i downloaded the zip from Github and that version appears to still be stripping out the CDATA.

~shanna

I will try to test that Github version tomorrow.

Ok, thanks. This is the standard Google Analytics JS, and apparently something in it matches something in your default exclusions. But i’m not especially worried about inline JS that’s at the bottom of the file. There’s not much of a performance problem there i don’t think.

As for how to detect XHTML, that may be a can of worms if you don’t use the doctype. Do you really want to go there…? Even if a theme developer uses xhtml, there would be little control over html produced by plugins, so WordPress is basically html soup with assorted standards. I don’t see any way to have a pure xhtml WP site. So does this really matter? I think the only important thing is that valid xhtml should not be changed.

Well that’s my opinion, but i’m ok with using nooptimize tags to preserve CDATAs.

Anyway, thanks for looking into this. The more i think about it the less i think that html standards matter any more in html5, as long as it’s html of some sort.