Tag: custom actions

Posted on

SharePoint Printing Services, UrlAction, STSNavigate2 – Fixing "Invalid page URL:" in SharePoint 2010

After the eBay upgrade, I have decided that it is really easy to do SharePoint upgrades and thusly I'm doing another upgrade here in San Diego.  As part of the upgrade, you have to go through and analyze the 3rd party components that are installed and make sure they are going to work in 2010.  As I have learned, most are not SP2010 ready (OutlookPowerTools, older CorasWorks versions to name a few).  Some of them work with some tweaking.  That's what this blog post is about. 

This particular customer has the PrintingServices.wsp that allows a one click approach to printing pages and items.  What this product does is adds custom actions with a javascript url as the target of the click.  This works great in SharePoint 2007, but unfortunately, does not in SP2010.  The reason it does not work in SP2010 is that they do not simply pass the URL to the page anymore.  It is now wrapped by another javascript method called "STSNavigate2":

function STSNavigate2(evt, url)
{ULSxSy:;
    STSNavigate(url);
}

As you can see, it in turn calls function STSNavigate:

function STSNavigate(Url)
{ULSxSy:;
    if (window.location.search.indexOf("IsDlg=1") !=-1)
    {
        if (Url.indexOf("?") !=-1)
        {
            if (Url.match("&$") !="&")
            {
                Url=Url+"&IsDlg=1";
            }
            else
            {
                Url=Url+"IsDlg=1";
            }
        }
        else
        {
            Url=Url+"?IsDlg=1";
        }
    }
    if (isPortalTemplatePage(Url))
        window.top.location=STSPageUrlValidation(Url);
    else
        window.location=STSPageUrlValidation(Url);
}

STSNavigate in turn calls STSPageUrlvalidation:

function STSPageUrlValidation(url)
{ULSxSy:;
    return PageUrlValidation(url);
}

It then calls PageUrlValidation – THIS IS THE KEY PART:

function PageUrlValidation(url)
{ULSxSy:;
    if ((url.substr(0, 4)=="http") ||
        (url.substr(0, 1)=="/")     ||
        (url.indexOf(":")==-1))
    {
        return url;
    }
    else
    {
        var L_InvalidPageUrl_Text="Invalid page URL: ";
        alert(L_InvalidPageUrl_Text);
        return "";
    }
}

Notice that the only valid URLS start with http and contain a colon!!!!  Not sure the reasoning behind this "validation", but it breaks any custom actions that had a simple "javascript" call in them. 

You can fix this by changing the C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATELAYOUTS1033Init.js file.  Note that this file has been minified (variable names reduced and spaces removed) and does not match the init.debug.js file.  Find the following text in the init.js file:

function PageUrlValidation(a){ULSA13:;if(a.substr(0,4)=="http"||a.substr(0,1)=="/"||a.indexOf(":")==-1)return a;else{var L_InvalidPageUrl_Text="Invalid page URL: ";alert(L_InvalidPageUrl_Text);return ""}}

Change it too:

function
PageUrlValidation(a){ULSA13:;if(a.toLowerCase().indexOf("javascript")>-1) return a; if(a.substr(0,4)=="http"||a.substr(0,1)=="/"||a.indexOf(":")==-1)return
a;else{var L_InvalidPageUrl_Text="Invalid page URL:
";alert(L_InvalidPageUrl_Text);return ""}}

This will then allow the older javascript links to work.  be sure to document the change as it would get overwrite with any service packs later.

Enjoy!
Chris

Posted on

Removing "Open With Windows Explorer" custom action

There is this great blog by Jérémie Clabaut about hiding the "Open In Explorer" custom action…it however misses the a few points of what is trying to be accomplished by doing it.

 http://jclabaut.free.fr/serendipity/index.php?/archives/52-Hide-Open-with-windows-explorer-menu-in-list-actions.html

Once you have deleted the section, end users can STILL access the explorer view via two methods:

1) The "Explorer View" via the dropdown on the right
2) "My Network Places" via windows explorer

In order to remove the the "Explorer View" on the library, you would need to delete it from the library settings page (at the bottom).  BUT you would have to do this for every library that exists and every list that gets created!  This means you would need to remove the view from the Site Definition for the document library so it doesn't get created every time.

For the second, there is nothing you can do but to remove the "Use Remote Interfaces  –  Use SOAP, Web DAV, or SharePoint Designer interfaces to access the Web site." permission from any Permission Level that the users are in!  However, even though this SHOULD remove there ability to use Network Places, it does not (at least in pre-SP1 environment).

The last resort to prevent uploading of documents without entering metadata is to write an event handler that enforced those columns be there or you cancel their item add.

Chris