Hi @benbornschein,
In the first place, data-wpmeteor-nooptimize is an internal thing, that excludes wp meteor native code from optimization. Unfortunately, I can not rely on the attributes like data-no-optimize or data-no-minify to do internal work, required by the plugin.
Does it cause any issues for you?
Best,
Alex
Thread Starter
Ben
(@benbornschein)
Hi Alex,
you can keep the data attribute for your JS files, but any other script tag that has a no-optimize or no-minify data attribute should be ignored by your plugin, just like any other caching/optimization plugin does.
Otherwise, your plugin will cause conflicts. The same goes for script tags of type="module". These script tags must be ignored; otherwise you will break code.
Best regards,
Ben – Developer of Borlabs Cookie
-
This reply was modified 2 years, 2 months ago by
Ben.
-
This reply was modified 2 years, 2 months ago by Ben.
While I will certainly review your suggestion about using no-optimize and no-minify, I believe that delaying type="module" should work perfectly, provided the order of loading is preserved. If you have scripts that are excluded from optimization and depend on a type="module" script, then the module should also be excluded from optimization. Otherwise, If you have any examples where this approach fails, please share them with me; I’d like to address that issue.
Thread Starter
Ben
(@benbornschein)
I have checked your code. You simply block JavaScript without changing the location of the file, that shouldn’t be a problem for modules. But I see possible problems in combination with our plugin if you change JavaScript that has been changed by us and is not allowed to be changed.
In addition, the first customers are already reporting problems: https://ww.wp.xz.cn/support/topic/exclude-borlabs-cookie-plugin-scripts-issue/
