JQuery.Migrate saves the day with Telerik UI for ASP.NET MVC

The relentless pace with which libraries, and dependent javascript resources now change,  is quite difficult to keep up with – particularly when you’re attempting to be frugal and use open source projects like Telerik UI for ASP.NET MVC – which basically got dropped in 2013, and replaced by Kendo UI.

The basic problem is that when you’re using libraries like these, that depend quite a bit on things like JQuery, and get subsequently dropped – you can be left in a bit of an upgrade quandary.

It’s tempting to go to NuGet, and just ‘update all’ libraries you’re using, but all sorts of bad things can happen if you get a little trigger happy on that function.  The Telerik components for instance expect JQuery 1.7.1 (which is a 2012 version).  I now want to use Bootstrap to create a responsive theme, and that’s wanting JQuery 2.x.  I’d tried to update to a later JQuery version previously and basically the whole deal broke – almost all components were using deprecated JQuery features.  I was considering going through the code and patching where required, but I don’t have that kind of time.

Whilst looking for deprecated features on the JQuery API doco, I saw mention of JQuery.Migrate plugin – which basically fills in those gaps for you.  I then picked up the package in NuGet, added to my Bundle config (right under JQuery)

 bundles.Add(new ScriptBundle("~/bundles/jquery").Include(

Stopped the site in IIS Express, restarted, and everything just magically started working again!

Now – I just have to get the responsive stuff singing and dancing with BootStrap 🙂

Using JQuery with DotNetNuke 4.x

I’m currently doing a project using DotNetNuke, and we’re using JQuery plugins to achieve certain content rotation and scroller functionality.  All was ‘amost’ good as I’d found a way to inject the JQuery script to the page header on a per-skin basis, but in ‘edit’ mode the actions button wasn’t showing up at the top of containers in FireFox and was causing JavaScript errors in IE.

I’d already gone through the hoops of declaring jQuery.noConflict(), but it still appeared to be conflicting with the dnn:actions (solpartactions) control.  I’d read somewhere else about Solpart code being incompatible with JQuery.

I tried one last thing, adding the noConflict() call in the JQuery library script file itself – rather than running as a fragment on page load.  This fixed everything, as something else was obviously getting in and hijacking in the meantime.  Apparently with V5 this will all be fixed as JQuery’s more integrated with the framework.  Anyway, for those interested here’s what I had to do to get JQuery (and associated plugins) talking nicely whilst still allowing the actions menu to pop up on my containers…

  1. Amend the JQuery library (jquery.1.x.x.min.js) by adding the following line at the bottom…


  2. Amend the skin you want to load the jquery library (and plugins) in (we’ve got it only in specific skins to avoid the overhead where it’s not required).  You could also do this in the module by checking ‘if loaded’, but here’s the code for a skin (in ascx file)…

    <script runat=”server”>
        Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init
            ‘add a script reference for Javascript to the head section
        End Sub
        Private Sub AddScript(ByVal fileName As String)
            Dim oLink As New HtmlGenericControl(“script”)
            oLink.Attributes(“language”) = “javascript”
            oLink.Attributes(“type”) = “text/javascript”
            oLink.Attributes(“src”) = fileName
            Dim oCSS As Control = Me.Page.FindControl(“CSS”)
            If Not oCSS Is Nothing Then
                oCSS.Controls.AddAt(0, oLink)
            End If
        End Sub

    The order is important, as we’re adding the scripts to the ‘top’ of the scripts each time.  JQuery needs to be the first referenced.

  3. Make sure that anywhere you use jQuery you use the jQuery(xx) syntax, and not $(xx).

That’s it.

Make JQuery and Prototpye coexist and play together with a GreaseMonkey User Script

I’ve been playing with Greasemonkey scripts recently – for Redbubble.com, and wanted to use JQuery with GreaseMonkey.  This is pretty well documented, but I discovered an incompatibility with my script and the host site, as it uses the Prototype Javascript library (must admit I didn’t know much about it).

Prototype (like JQuery) uses the $ notation, and so by default any GreaseMonkey User Script loaded will hijack the $ object, meaning that stuff on the original site may stop working.

I thought I was sunk but it turns out JQuery just gets better, and it can gracefully give back control of the $ to whichever library originally loaded it.  Just call..


You then have to use jQuery instead of $ (e.g. jQuery(“#myID”) instead of $(“#myID”) ), but hey – that’s a small price to pay when the alternative is rewriting the whole thing long-hand.