One of our SW6 plugins comes with fairly basic javascript code. Before shipping it to the SW plugin store, I use the bin/build-frontend.sh script to compile the js assets just as described in the documentation:
https://developer.shopware.com/docs/guides/plugins/plugins/storefront/add-custom-javascript
This has always worked without problems for me. But somewhere in the 6.4.x series, more and more customers reported incompatiblities with their Shopware version. I often have trouble reproducing the error. Most customers report this JS error:
Uncaught TypeError: Cannot read properties of undefined (reading 'call')
My workaround so far has been to install a demo shop with the Shopware version they are using, install my plugin, compile the JS and ship this version to them - with does not seem right at all. Is there any compatibility table or maps which lets me know if a new Shopware Version breaks bw compatiblity when I compile my JS? Or am I missing something?
Any help is very much appreciated.
Maybe this issue is the same like this one: https://github.com/shopware/platform/issues/2420
There was a problem with compiled admin plugins with shopware versions smaller than 6.4.5.0. The compiled code was not compatible with newer shopware versions, but worked with the old ones. When you compile it with a version greater or equal than 6.4.5.0 it will work with all shopware versions.
Maybe this bug also exists for compiled frontend plugins?
Solution for this was to compile it with a Shopware version greater or equal 6.4.5.0 to be compatible with all versions.
No way of knowing without having the actual code.
Generally speaking there shouldn't be breaking changes between minor releases, as long as you're using the provided APIs as intended, e.g. as per the documentation. Most certainly breaking changes are never intended outside of new major releases. The more you move outside of the bounds of the intended implementations however, there will be less of a guarantee for that.
If you can reproduce the error, you can to find which line causes the error by debugging storefront javascript errors. Then you can provide a sample of the corresponding code.
Related
I have developed the library bertinjs which allows to make svg interative maps. In Observable, require("bertin") works. In Quarto, require("bertin") does not work. The following error is returned: OJS Error. RequireError$1: invalid module. See the issue on Github (see). It's weird. Any help is welcome.
(Quarto dev here) I recently fixed a bug that would cause that behavior you're seeing. Can you try a release later than 0.9.430? Thanks!
Edit: I see now that bertinjs uses modern JS syntax, which the stable versions of the RStudio IDE don't yet support. Your example works on the latest Electron daily builds, the right-most column on the linked page.
I have my site running with Angular Bootstrap v1.3.2 and everything works great. I am however being forced to add an in-house typeahead module which was built around Angular Bootstrap v0.13. I've tried running the module with the latest version of AB but it just doesn't function. It sadly doesn't throw any errors, which makes it hard to troubleshoot.
Reverting the whole site back to AB v0.13 results in multiple errors on my code.
I've seen that bower can host multiple package versions and tried running both the new and old together, but get modal provider errors. Is there a way to specify a specific AB version for a specific bit of code? Or at least allow the 2 versions to cooperate?
I work on an ASP.NET MVC 4 application.
I updated jQuery, jQuery UI and all other nuget packages in my project. Built it and ran it to see that no problems occured. Everything worked so I continiued development for several days.
After a while I published the project to a test-server I have to see how it looked on Ipad, Iphone etc. And then I realized that the jQuery-UI accordion stopped working.
It renders, but does not respond on click. This goes for all browsers. I found this strange since the only difference is that the MVC bundeling i applied in release mode and as far as I understand it either minifies the jQuery file or chooses the minified version (the latter probably beeing what is does here since it is added when updating using nuget).
The jQuery version is: 2.0.3
The jQuery-ui version is: 1.10.3
In Chrome console the error reads:
Uncaught TypeError: Cannot read property 'safari' of undefined
OK, so i realize this might be the result of one of my jQuery assemblies references $.browser that apparently was removed in jQuery 1.9.
However the fact that it works in debug mode (using the non-minified versions) leads me to think that it might not be that. I could almost think that it is a problem with the minified versions, but that should not be possible either.
Anyone knows why this happens and know how to fix it?
Update
As requested I attach most of the code. The strange thing is that this works in debug mode, but not in release. I cannot see why there would be any significant changes that should cause this problem:
_Layout.cshtml
Bundleconfig.cs
The view (which calls a partial view)
The partial view
The jquery code
The javascript error in Chrome
Bigger view of the error in chrome
Just to add. After posting this I removed the duplicate loading of modernizr (the telerik custom one was added without me noticing). The problem still persists.
Update 2
I turned off the optimizations in bundleconfig.
BundleTable.EnableOptimizations = false;
This allowed me to see what was throwing an error in jquery-ui, and it seems indeed to be the $.browser that was removed. It seems that it actually loads two old versions of jquery (current + 1.6.4 and 1.7.1) together with the new one and two versions of jquery-ui (current + 1.8.16) the last one throwing an error. None of these files are loaded in my solution or in the file folder.
This seems to be a publish problem, but disguised by the bundling and minification... I'll try to fix this and see if it works.
OK, so this was not at all a problem with the code itself, and I learned something new that might be of help to others.
Setting
BundleTable.EnableOptimizations = false;
Was what helped me solve this.
Obviously the Asp.Net MVC 4 bundling bundles every script that is found in the folder where it is released, not what is in the solution folder in Visual Studio. I did not think of this at all... But in retrospect it kind of makes sense.
Combined with the fact that VS default publishing settings does not remove files that does not equal the files that you publish means that when removing i.e. an old version of Jquery and adding a new one, the old one still remains on the server.
Add the default bundling using {version} for jquery selection and you have one unreadable jquery file throwing error. Not until you disable bundling and minification it becomes obvious that I in this circumstance loaded 3 versions of Jquery:
Before
After
The solution? Easy, just have to expand a setting called "File publish options" in the publish wizard and check "Remove additional files...":
Thanks for the suggestions. It helped me look the right places, but I was not able to imagine this beeing the problem.
I think you have forgot to add '"~/Content/themes/base/jquery-ui.all.css"'
Note: although you have called all modules separately sometimes calling single file makes difference. As we might miss some dependent file in choosing separate modules.
In BundleConfig.cs you need to add/modify like..
bundles.Add(new StyleBundle("~/Content/themes/base/css").Include(
"~/Content/themes/base/jquery-ui.css",
"~/Content/themes/base/jquery-ui.all.css"
));
if in your locals the file of jQueryUI exist that will do the trick for the same(that might be possible problem that makes it working on Local Testing).
Your _layout.cs will be like..
#Scripts.Render("~/bundles/jquery")
#Scripts.Render("~/bundles/jqueryui")
#Styles.Render("~/Content/themes/base/css")
#RenderSection("scripts", required: false)
as you are not rendering jqueryUI that we need to call and render saperately after jQuery.
And your Section script should be called like this,
#section Scripts{
#*#Scripts.Render("~/bundles/jqueryUI")*#
<script type="text/javascript">
$(document).ready(function () {
$("#accordian").accordian();
});
}
This is what I will suggest and should work, with MVC things are really small to identify exact problem, So I have provided all these lines, thank you,
Do post back if problem persist.
I'm trying to use Microsoft's Web Optimization bundling toolkit, which works well for everything else.
When I try to ask it to minify AngularJS, though, I get this error message in the resultant Javascript output:
"Ambiguous reference to named function expression"
I'm not even sure where to start with this one . . .
The answer to this question (which should not have been downvoted, in my opinion, because it represents a real issue) is to upgrade from the older Microsoft.Web.Optimization package that uses the "Microsoft.Web.Optimization" namespace and making sure you're using their latest, signified by the "System.Web.Optimization" namespace instead.
In the older Microsoft package, Angular would bomb out when handed to JsMinify. Not so anymore in the latest version.
I hadn't realized at first that I was on an older version of that package because the package name changed - hence my spinning my wheels on it for a while.
The best workaround in my opinion is to preminify the Angular applications using ngmin before minifying with another tool in order to keep dependency injection working.
https://github.com/btford/ngmin
HTH
Jquery.com provide 2 version of jquery library. I always use Minified version because i never edit anything in jquery base file. but what is the use and purpose of another Uncompressed Code version? Does people edit main library file to get something?
If yes then if we edit anything in main file then we can't use google ajax library link.
Production (19KB, Minified and Gzipped)
Development (120KB, Uncompressed Code)
If you're using the minified version during development, browsers will tell you there's an error on line X, but line X might consist of hundreds or even thousands of lines of uncompressed code. This makes it very, very difficult to figure out what exactly caused the problem.
Developing against uncompressed code thus allows you to see what's causing problems and fix. Minified jQuery should always be used in production, and the core functionality of jQuery shouldn't be tweaked - that's what plugins are for.
edit 5/2014: Source maps have been implemented in many browsers to allow debugging of minified code. https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps
It just makes it much easier to read the source code of jQuery, especially during debugging to see what is happening with a problem in your application.
It's for Debugging (although I would argue that if you're using jQuery, you should be looking through the source to understand it).
In ASP.NET at least, when using the ScriptManager control, you can assign one script to use in Debug mode and another to use in Release mode, so using the uncompressed version in debug allows you to step through the source and figure out if an issue you're having is coming from there, but when you finally build the release, you'll use the minified and gzipped version.