Not working with multiple script filenames

I’m having this same issue.

The plugin also doesn’t accept exact files, even when only trying to add one (e.g. /jquery-migrate.min.js?ver=1.2.1). One has to use ‘jquery’ thereby adding the attribute to a host of things with ‘jquery’ in the URL. Etc, etc.

I actually wonder if this plugin can work given that it is placing the data-cfasync='false' attribute after the source rather than placing it prior… As I understand it, only the data-cfasync='true' attribute functions in this manner, and if and only if Rocket Loader is in “Manual” mode.

At least it is not just me!

It works for jquery-plugin.min.js (and even jquery-plugin) for me but I’m not sure if it parses anything beyond the .js file extension. Also, are you using that / in the start of your filename?

Also keep in mind that this plugin may not work with other plugins that manually insert script tags into the site header (like YOOtheme’s widgetkit plugin) instead of using WordPress functions (wp_register_script or wp_enqueue_script).

I’ve also sent a support ticket to CloudFlare to confirm if the order of the data-cfasync attribute matters as it is not explicitly mentioned here:
https://support.cloudflare.com/hc/en-us/articles/200169436–How-can-I-have-Rocket-Loader-ignore-my-script-s-in-Automatic-Mode-

I’ll post the reply here.

Perhaps a future feature could be that the plugin also allows you to add data-cfasync='true' attributes by specifying the filenames you need to be processed by Rocket Loader in Manual mode instead of only ignoring files in Automatic mode.

Here is the reply from CloudFlare support:

Hello,

“Does the order of the data-cfasync (=’true or =’false’) attribute matter in script tags for Rocket Loader? Does it need to come before or after the src attribute?”

The data-cfasync attribute does need to be placed before the src attribute.

“And does Rocket Loader recognize script tags with double quote marks in the same way as script tags with single quote marks? Does it also work if the src attribute has one type of quote marks and the data-cfasync attribute has the other type of quote marks?”

Yes, Rocket loader recognizes both single/double quotes for the script tags. Rocket loader will also work even if the src attribute is using a different type of quotation mark from the type used for the data-cfasync attribute.

Thanks again for bringing these questions to my attention, I will also be updating our knowledge-base accordingly.

Algin
CloudFlare | Support Engineer

They have also updated the following knowledge-base article with extra notes in bold:
https://support.cloudflare.com/hc/en-us/articles/200169436–How-can-I-have-Rocket-Loader-ignore-my-script-s-in-Automatic-Mode-

It seems that you were right! The data-cfasync attribute MUST come before the src attribute. I also verified that using single/double/alternating-pair of quotes in the script tags does not hinder Rocket Loader as well.

You check on if Rocket Loader is processing your script by seeing if it appears after the file extension of the GET bag2r.php (there may be more than 1 Rocket Loader bag for your site) in any browser’s profiler/timeline.

I’ll look into cfrli.php to find a fix.

Here is my temporary fix to get multiple filenames working (tested with version 0.0.2)!

Find this line in cfrli.php:
$listoffiles = explode("\n", $options[CFRLI_DEFAULT_NAMES_NAME]);

And replace it with:
$listoffiles = explode(" ", $options[CFRLI_DEFAULT_NAMES_NAME]);

Then you’ll have to enter multiple filenames with a single space inbetween them instead of a new line. For example, to ignore script1.js and script2.js after applying my fix I would list them in the plugin like this:
script1.js script2.js

The question is still begged as to how the plugin can actually fulfill its intended purpose given that it is placing the data-cfasync='false' attribute after the source rather than placing it prior. It seems pretty clear that it cannot.

In short, even though you’ve found a work-around to get multiple filenames inserted with the attribute, the attribute is nonetheless misplaced in the order of the URL. Ergo, CloudFlare still processes the URL.

To be frank, Uzair, I wouldn’t waste any more time on this plugin until its author chimes in. Let’s hope he opts to support it. It is looking, however, as if we ought not hold our breath.

Hi ajm_1976,

I actually posted my solution to fix the order of the attributes as well in another topic here but it seems that my topic didn’t appear on the support page (probably under moderation I guess).

So here is my fix to get the attributes to display correctly! Simply replace lines 108 to 131 in cfrli.php with the follow code:

// main function start
    function cfrli_add_cfasync_start() {
        ob_start();
    }

    // main function middle
	function cfrli_add_cfasync($url) {
		$options = cfrli_getpluginoptions();
		$enabled = $options[CFRLI_DEFAULT_ENABLED_NAME];

		if ($enabled) {
			$listoffiles = explode(" ", $options[CFRLI_DEFAULT_NAMES_NAME]);
			if (!empty($listoffiles)) { // proceed only if there are filenames to be processed
				if (strpos($url, '.js') !== false) { // its a javascript file being src'd
					$listoffiles = array_map('sanitize_text_field', $listoffiles); // Chapter 6 Pro WordPress Plugin Development, run each filename through sanitize function
					foreach ($listoffiles as $fname) {
						if ($fname) {
							$thisfilename = basename($url);
							if (strpos($thisfilename, $fname) !== false) {
								return "{rocket-ignore}$url";
							}
						}
					}
				}
			}
		}
		return $url;
	}

    // main function end
    function cfrli_add_cfasync_end() {
        $script_out = ob_get_clean();
        $script_out = str_replace(
            "type='text/javascript' src='{rocket-ignore}",
            "data-cfasync='false'"." src='",
            $script_out);
        print $script_out;
    }

    // filters to include main function in header and footer of WordPress
    add_filter('clean_url', 'cfrli_add_cfasync', 11, 1);
    add_action( 'wp_print_scripts', 'cfrli_add_cfasync_start');
    add_action( 'print_head_scripts', 'cfrli_add_cfasync_end');
    add_action('wp_print_footer_scripts', 'cfrli_add_cfasync_end');

Or you can download my working cfrli.php here:
https://www.dropbox.com/s/qfi6qlbrbhf5bt6/cfrli.php

This code includes my multiple filenames fix above (you should use a single space between multiple filenames that is). Tested and working with version 0.0.2 of this plugin!

Here is an example of what ignoring script1.js with my fix does to the script tag:
<script data-cfasync='false' src='https://www.example.com/wp-content/plugins/example/js/script1.js?ver=3.9.1'></script>

That fixes the major problems of this plugin! So it now displays correctly and is in accordance with the reply from CloudFlare support.

Credits to Ernest Marcinko for the original solution, which I integrated for this plugin:
https://wp-dreams.com/articles/2014/03/cloudflare-rocket-loader-for-wordpress/

Ah, okay gothca. Very nice.

I should note that what I wrote about the “true” attribute above turns out to be incorrect. Both the “true” as well as the “false” attributes are to be placed before the ‘src’.

I am including the correction as there is another CF/RL plugin that deals with RL from the other direction; in “Manual” as opposed to “Automatic” mode – which also places the attribute incorrectly (i.e. after the ‘src’).

As per CloudFlare:

In order for Rocket Loader to recognize the script, the data-cfasync=”true” attribute will need to be place BEFORE ‘src’.

Thanks for the solution, Uzair. I will implement this and report back.

Unfortunately, the above fix (somehow) broke some WP Admin functionality.

Also, the plugin still is not accepting exact file names or combined file names.

E.g:
default.include-body.8d4ce0.js
default.include-footer.64e61e.js

I am rating this plugin 1 star. I will change the rating should the author make a working plugin.

The fix doesn’t affect any wordpress functionality. It only looks for the name of the script specific script and adds the attribute in the correct order.

Unless of course you are trying to add the data-cfasync attribute on a manually inserted header script tag for some plugin or a dynamically cached script file. This plugin (or any similar one) can NOT add the data-cfasync attribute on script tags if they do not go through the wp_register_script or wp_enqueue_script wordpress functions. This may happen if the script file is cached or if it is manually inserted into the header or footer.

I can help you solve your issue if you want. What WP version are you using? If there any specific plugin/theme that isn’t working with Rocket Loader for you?

Judging from the filenames that you wrote above, I guess you’re trying to add the attribute to cached important wordpress script files. Are you using a caching plugin like W3 Total Cache? (It could also be the cache feature of a different theme or plugin as well) If you are, then try disabling all caching (or deactivate the caching plugin) and then ignoring:

default.include-body.js default.include-footer.js

Does that work? If it does, then it means that you’re caching plugin is getting in the way and you need to exclude these files from the cache or you can modify the plugin itself to add the attribute manually. It would help if you could give me some details of exactly what you’re trying to do.

If you’re trying to disable Rocket Loader on the WP Admin area then you can set up a Page Rule on the CloudFlare website and customize where to enable and disable individual features of CloudFlare.

As I said previously:

Also keep in mind that this plugin may not work with other plugins that manually insert script tags into the site header (like YOOtheme’s widgetkit plugin) instead of using WordPress functions (wp_register_script or wp_enqueue_script).

Hi Uzair,

When the cfrli.php edits are made and the plugin activated, some functions in WP Admin are immediately broken in our setup prior to configuring the plugin in any way. Or, and if you like, some or another conflict is immediately created upon post-fix plugin activation such that some WP Admin functions are broken. Said either way, the net result is the same: Broken WP Admin functions. This likely has something to do with our caching schema – APC database cache in particular. Regarding that, I’m not going to undergo some time consuming investigation and/or re-work all (or any) of that finely-tuned schema to suit a plugin, the only function of which is to add an attribute to a script tag. I mentioned the broken WP Admin functionality not as a jab at you or your committed efforts, but because if the fix (or the resultant conflict of having edited the plugin) breaks our set up it will break others. The bottom line is what it is: the author of the plugin needs to go back to the drawing board, both to fix the plugin’s fundamental flaws, and, to insure that it ultimately ends up working in a reasonable range of environments, up to and including the complex or necessarily complicated ones in which it should technically work.

The combined file name examples I provided are indeed combined (and cached) files created by W3TC, and what you write about wp_register_script or wp_enqueue_script wordpress functions are certainly correct. That said, the plugin in its original state, or with the edited cfrli.php file, is still not recognizing certain other combined file names that it should; or – and more importantly and particularly – exact file names, which is what I meant to provide examples of, but in my rush, did not:
backstretch-2.0.3.min.js
jplayer-2.3.0.min.js
jquery-ui-1.8.22.min.js
So on and so forth, etc.

I am glad you have found a work-around such that you can use this plugin, even though you have – in essence – created an entirely new one. You should not, however, have had to go through the trouble, which would be the first, best, and most salient point I’m trying to express.

Best,
AJ

No problem AJ! I didn’t take your issue with the fix as anything personal. I’m just trying to help you out! =)

In your case, I would not bother with this plugin because you have too script files being combined with W3TC and you’d have to edit W3TC if you really wanted to get it to add the attributes to the cached files or exclude those scripts files from W3TC which defeats the point of caching and combining!

Actually, I just got an idea. What if you disable W3TC minification and combination and use the CloudFlare auto minify for all files? (You’ll also have to clear all W3TC caches and CloudFlare cache to see immediate changes) I do that for my own website and it reduces my server load as CloudFlare then does all the processing instead! It works very well for me and I get a PageSpeed and YSlow score of above 95% on GTMetrix.com

That way you can use this plugin for non-combined and non-cached files on your server and then CloudFlare can do all the rest.

It was a real pain figuring out how to set up the attributes properly because there simply isn’t any WordPress API that can do this.

But considering the amount of research I’ve done, I’m going to make my own plugin that works for cached script files and for manually inserted script tags as well! I have a good idea of how I can make it work now so it definitely not impossible.

It’ll take a few days but I have some free time this summer. I’ll post the link to my plugin right here as well once it is completed and fully tested!

Sorry for the trouble. I am looking into this and should have a fix shortly.

I believe I have fixed this issue. An update will be available tonight.

For the record, I believe Cloudflare only updated their KB in response to a query from a user who submitted a ticket to them after contacting me about this issue.

The documentation on their site, while updated, is still poor. For example, it still doesn’t mention (based on comments I found on other sites) that the ‘type’ attribute is not allowed. Even so, ‘type’ is only optional in HTML5. Why the ‘type’ attribute must be removed, is beyond me.

I don’t understand why the order of attributes in the script tag matters, and why the ‘type’ attribute is not allowed. Everywhere I checked, the order of attributes does not matter, and it should not.

Requiring a specific attribute order makes it more difficult to implement. Since this is a proprietary attribute for their service, they should make a better effort to make it work with existing code instead of forcing everyone to conform to their method. The hardcoding of attribute order runs counter to the way I think tag attributes should work.

I hope someone from CloudFlare reads this and considers a better parsing method that allows existing workflows to remain intact. I challenge them to explain why this kludgy inclusion method is required.

Also, as a rule I do not look at suggestions that are posted in reviews. I don’t think it’s appropriate to put suggestions there — post them in the forum and let’s try to find a solution. Yes I did test this plugin but I didn’t and couldn’t anticipate every possible issue. At the time the plugin was written, CloudFlare’s documentation ddn’t specify that the attributes had to be in a specific order, only that their data-cfasync attribute had to be added to the script tag.

Nice to hear from you Jimmy! I guess you’ve been very busy lately. Looking forward to the update!

I was also very surprised that the order of the attribute mattered. I have actually sent them a feature request to recognize the attribute in any position, regardless of the presence of the type attribute. This seems like a big oversight so I think they will probably fix it in due time.

I only posted my suggestion in the review so that users who stumble on this plugin know that the order matters as well. I’ll update my review as soon as I get your update for the plugin! I posted my main concerns in the support forum as that is where they belong.

Now that you’re back, do you think you could get this plugin to work with W3TC (for minified and combined files like script.8d4ce0.js) or for plugins that manually insert script tags into the WordPress header/footer/content block?

Also, a cool feature would be if the plugin could do a manual mode where you can specify whether to ignore the listed scripts and add true to all other scripts or add ‘true’ to the listed scripts and ignore all other scripts.

I think it’s not working for me, image lazy load job it’s still delayed.

From the FAQ:

I entered some filenames but don’t see any changes on the page.
Are you caching your pages?

I am using Quick Cache pro, configured to concatenate and compress some java scripts. Does it really matter ?