Scripts broken in latest update - Bugs & Issues - Bugs & Issues - Progress Community
 Bugs & Issues

Scripts broken in latest update

  • Scripts broken in latest update
  • 45634e1e-37c1-6deb-a958-ff0000446526_sf-requirejs.png
    In the last 6.3 release, Sitefinity is automatically loading RequireJS on every page by default. The problem is that now when you load ANY AMD-complaint library, such as Kendo, MomentJS, Lo-Dash, etc, your page will not know it’s there unless you use RequireJS to extract it. In other words, many people right now are loading libraries into their Sitefinity site and are completely baffled as to why they can’t find or use the script in code as if they never loaded it.

    See the attached screenshot. I added MomentJS on the bottom of the page, but can’t use it because MomentJS said, "Oh you have RequireJS on the page, I’m going to load as define(..) and call me when you need me via require." But say I have no idea what RequireJS is, I’ll be wondering why I can’t use "moment" if it is clearly loaded in the HTML. A very frustrating bug to them they will never figure out unless they know about RequireJS, even if you know RequireJS still frustrating because no one knew Sitefinity snuck RequireJS in the latest build which is buried in the embedded scripts.



  • Hey Basem,

    You mean in the latest 6.3.5020 internal build? Even with the inline-editing turned off?

    Jochem
  • This has to be with inline turned on...I'm not seeing this (and I always disable it)

    ...but RequireJS was always included with lnline, since it changed...
  • Yes, you both are right it is with inline editing and gets around it by disabling it. Content editors will have to choose between a broken site and inline editing.

    It's still a problem in the internal build. IMHO, to salvage this RequireJS should be added below ALL scripts, even below the scripts specified to "add below closing body tag", then the inline-editing scripts added below RequireJS. Furthermore, if SF wants to extend the power of RequireJS to devs then a new option should be added to the script widget: (1) In the head tag, (2) Where the widget is dropped, (3) Before the closing body tag, and (4) AMD-compliant. The last choice would add it below the RequireJS script, which again has to be added below all scripts and all AMD scripts added below this. This is the nature of inconsistency and having a cocktail of technologies in the same system.
  • I'd rather see them take a full dependency on RequireJS (including their own scripts) and have a configurable path/map/shim section in the toolbox.

    Then on dropping a JS widget on the page and selecting an external JS file, you get the option to add a 'dependency' and a 'export', which adds it to toolbox section and takes care of the  require([.... automatically for the user.

    This way developers who know what they're doing are able to extend and tweak it and novice users simply take benefit of the optimized loading.

    And in the next release they can even extend it further by 'combining' all the header scripts into one require statement and all the footer placed scripts in another and include support for css files as well... 

  • This still seems to be an issue in Sitefinity 7.x

    We have had to disable inline editing to allow our other script references to work.

  • Has anyone had any luck moving RequireJS loading to the end of the body? It is quite frustrating that Sitefinity loads RequireJS and that throws off the loading of other scripts unless they too are loaded with RequireJS. Also, turning off off inline editing is not a viable solution.  This is still an issue in version 9.

    We receive the RequireJS error: Mismatched anonymous define() module

    Thanks!