Not working with multiple script filenames

Hi all,

@uzair,

Not sure I follow. CloudFlare/RL still processes .js files combined via W3TC. Generally speaking, as is the case with our particular set up, a single (or a couple) combined and Rocket Loader ‘bagged’ .js files constitutes a significantly faster load-time scenario than does implementing non-combined, CL auto minify and bagging from there. Also, we (as is the case with the majority of sites) have some .js that cannot be minified without site breakage, but can be combined. In the end, we’re not combining the .js for the caching benefits as those headers are stripped-away once the files are bagged via RL anyway, but for the benefits of combining those files into one. At any rate, there should be no technically insurmountable challenge to getting an attribute applied to any script that is RL enabled, bagged, and served asynchronously, be that a file combined via W3TC or no. Thanks again for all your efforts.

@jp2112,

Let me start by saying that CloudFlare support is notoriously bad. Perhaps even worse than their poor documentation. And it is poor. I too hope that they meet the more-than-fair challenge you’ve set. I will go ahead and add another: that CloudFlare works to improve their support in any and all ways online support can be improved, up to and including improved education of support staff as to how CloudFlare’s products and features work.

Your choice to look at reviews and make changes accordingly is obviously your own. That said, and as already elaborated upon, there is nothing currently – or essentially – functional about the plugin. Not just that it misplaces the load order of the attribute, which is, of course, a big deal in itself. It is broken out of the box and required someone with the patience of Uzair to doctor it up such that it worked at least in his environment. Were there a single jenky thing about it or perhaps a couple relatively insignificant bugs that were not integral to the plugin’s reason-for-being, it would indeed be a matter of first requesting support.

The comment in my review about whether or not the plugin was tested prior to release is also fair for all of the reasons both express and implied in this support thread, and the review itself. The crux of course being how you were able to test and verify that the plugin was fulfilling its function of excluding Rocket Loader from processing certain scripts, all while the plugin was misplacing the “false” attribute.

In short, there was not proverbial ‘jumping the gun’ as it was not I who needed support, but the plugin itself. Ergo: straight to review. This is my reasoning and I feel you deserve to hear it as I think your plugin will ultimately prove to save a lot of headaches that CloudFlare shows no interest in saving themselves.

Best,
AJ

From my perspective, there was no misplacement of attribute — the plugin throws no PHP errors and included the rocket loader attribute as stated in the CF documentation. So it “works” from a certain point of view. I hope you can understand why I see it that way.

The only other issue with the plugin was the way it was handling filenames being input into the textbox on the plugin settings page. That issue was quickly resolved and hopefully the version that is available now will resolve all the current outstanding issues. If that is not the case then I will fix it again.

It’s a testament to how useful this plugin is that even version 0.0.2 causes such an uproar that it inspires people to leave negative reviews. Next on my plate are the suggestions made in this thread and others. I will continue to work to make this plugin better.

Hi jp2112,

How CloudFlare ought to be doing things (while a reasonable discussion to have in itself) is ultimately irrelevant to whether or not this plugin fulfilled or now fulfills its function – and again misses the point.

If the plugin was tested to see if it actually excluded files from being processed by RL, and if you were able to somehow verify that it was excluding files, we are then left with only two logical possibilities given that the plugin could not have been excluding any files due to the misplaced attribute:
1.) the plugin was not tested at all; or,
2.) whatever verification methodology was employed with the test was also fundamentally flawed and didn’t actually verify anything.

If, however, one defines “works” as a plugin intended to exclude certain files from being processed by RL, that adds an attribute without actually excluding the file to which the attribute was added, then yes: The plugin “works”. Mission accomplished. This is, of course, setting aside all of the other issues with the plugin, some of which are arguably core.

The only other issue with the plugin was the way it was handling filenames being input into the textbox on the plugin settings page.

Not so. The plugin also was not (still is not? Dunno.) accepting exact or combined file names (see discussion above).

Further, I just attempted the update and, similar to Uzair’s fix, it either broke or initiated a conflict such that some WP Admin functionality immediately broke. This is the only plugin amongst 23 on this site and set up that breaks or conflicts with this site and set up. I understand that there may or may not be anything that can be done about that, but it is relevant to the discussion that has evolved.

I agree, this plugin does have the potential to be very useful. Generally, negative reviews are given to plugins that either do not, or as is the case with this one, cannot do what they are supposed to do, and have further problems radiating from that critical starting point. I am glad you’re willing to make the plugin better and look forward to watching its refinement.

Cordially,
AJ

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 implemented #2 (switching the plugin sentiment so only non-matching files get the data-cfasync attribute) and also added a fix to pick up footer scripts as well.

I will not be implementing #1 because I am not going to install W3TC just to test it. If you can explain the mechanism by which W3TC combines and injects/enqueues its scripts, or point me to a technical resource, I will look into it. You can also write the code and send it to me, or create your own plugin if you prefer (that isn’t intended to be harsh just to list the available options here).

Thx

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

I looked at the lite version which is available for download on this site. I need to understand the mechanism by which it concatenates and output scripts. Is there any documentation available?

Not so. The plugin also was not (still is not? Dunno.) accepting exact or combined file names (see discussion above).

Further, I just attempted the update and, similar to Uzair’s fix, it either broke or initiated a conflict such that some WP Admin functionality immediately broke. This is the only plugin amongst 23 on this site and set up that breaks or conflicts with this site and set up. I understand that there may or may not be anything that can be done about that, but it is relevant to the discussion that has evolved.

Version 0.0.3 should have fixed the issue with multiple file names. Please confirm that is the version you are using.

As far as “accepting” I’m not clear on what you mean. Do you mean it isn’t adding the data-cfasync attribute, or that it isn’t allowing you to enter the filename into the textbox on the plugin settings page?

This is what I currently have in the textbox on my site:

jquery.js
jquery-mig
M9TPKc3NzEssSdVNyy
jquery-migrate.min.js
jquery-plugin.min.js
default.include-body.8d4ce0.js
default.include-footer.64e61e.js
backstretch-2.0.3.min.js
jplayer-2.3.0.min.js
jquery-ui-1.8.22.min.js

You mentioned that the plugin broke some WP Admin functionality. Please explain exactly what functionality is breaking. If my plugin is causing it then I can look into it and attempt a fix.

I need to understand the mechanism by which it concatenates and output scripts. Is there any documentation available?

@jp2112
I have a comment here with a few more links.

https://forum.weavertheme.com/discussion/comment/44226#Comment_44226

Issue with breaking admin functionality has been addressed. New version will be committed for update tonight.

Outstanding feature requests:

— Add attribute to combined .js script tags

Once I get a grip on how other plugins are doing this I can work out how to add the data-cfasync attribute to those as well.

I have a comment here with a few more links.

https://forum.weavertheme.com/discussion/comment/44226#Comment_44226

Let me look at the plugin again.

Uzair, I need your feedback on two of the items you requested.

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?

Currently my plugin uses the filename to determine whether to include/exclude the attribute from script tags. How is my plugin to decide when to include the data-cfasync attribute for these two types of files?

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

OK I looked at Quick Cache again. The Lite version does not include the compression feature, so I cannot test it.

But I have some preliminary code that adds the data-cfasync attribute to javascript that is combined and output by W3TC, so I think it will work for any plugin that does a similar action.

The problem is, how do you decide whether to add the attribute or not? For example, W3TC generates a random-looking filename for combined scripts. The choice is whether to add data-cfasync to all of these scripts, or none.

QC options allow excluding that particular .js file. That’s what I did for image-lazy-load/js/unveil-ui.min.js, and here it is the error I found in error.log

[14-Aug-2014 12:41:11 UTC] PHP Warning: strpos() [<a href='function.strpos'>function.strpos</a>]: Empty needle in /home/myblog/public_html/wp-content/plugins/cloudflare-rocket-loader-ignore/cfrli.php on line 183

The result is the same: image lazy load can’t do its job, so pictures not loading at all.
I don’t have knowledge about php, java and all the rest. Thank you for attention !

Thank you. I will fix that error in the next version. Also I figured out a way to implement the code that adds the data-cfasync attribute for combined scripts, I will add that as well.

Wow, thanks guys for zero feedback regarding the changes I made. It’s really hard to stay motivated when people just complain, leave low ratings, then disappear.

As all bugs reported in this thread have been resolved, I am marking it as Resolved. If that is not the case, please open a new thread.

hi !
I just tested version 0.0.6. Works realy fine now, many thanks for your work. I even added jquery.js to be ignored, Rocket Loader made it load later some arrows for category menu. But Quick Cache must be disabled.

If this two plugins are enabled simultaneously, the page is not cached anymore. That would not be a problem, but it’s the file concatenation that I want to use from QC.
Here is the message I copied from Page Source:

<!– Quick Cache is NOT caching this page, because Quick Cache detected an early output buffer termination. This may happen when a theme/plugin ends, cleans, or flushes all output buffers before reaching the PHP shutdown phase. It’s not always a bad thing. Sometimes it is necessary for a theme/plugin to do this. However, in this scenario it is NOT possible to cache the output; since Quick Cache is effectively disabled at runtime when this occurs. –>

Maybe this could help you ? This is from a QC GitHub thread:

due to WordPress loading the advanced-cache.php file VERY early-on; before any themes/plugins; and before the do_action() function is available.