One common mistake in many public facing MOSS/WSS sites (including this blog) is the Name ActiveX Control warning, it seems its the presence control activeX, that can be very useful in an intranet environment, but its no good at all in public facing sites:
MS gives us a solution http://support.microsoft.com/kb/931509, but it is a really crappy one, you can add the site to the trusted sites or you can copy the init.js and reference the copy in your design… then you’ll might have to take it into account when a service pack is applied and things so..
I’ll tell you how I made it in my current project: A public facing site that uses webpartzones, and must be AA compatible.
Removing the default scripts when not needed
First of all, the only moment when I need MOSS’s default scripts and css is when an editor is working on the page, not when the visitors are in the site, so we will only show all the MOSS scripts and css when the user in an editor, we will archieve that by inserting the references inside an AuthoringContainer that is showed only when the user is an author:
After that you’ll see that when an anonymous user visits the page, MOSS does not render the script and css references, the page is lighter, loads faster and the ActiveX warning is gone, but if you use webparts, the script generated by the SPWebPartManager causes a javascript error at the end of the page in this script:
If you think about it, for anonymous users there is no need for this script since they are not editing the page, moving or exporting webparts, so… let’s fix it.
We have two options:
- Introducing a fake script to do nothing:
- Removing completely the script and thus reducing the page size.
Fake Script
It’s a simple but IMHO a bit incomplete solution, it consists of setting up a fake script that makes nothing so the browser does not raise a javascript error, you can get the script here:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/46ecb6c0-ad30-4e8f-8e46-e3b95bde9b6a
You can put this script on a container that only shows for anonymous users, and the browser will not cry. ;)
Remove the script
The fake script solution worked for me, but I do not want all those unused, heavy scripts on my page, so I need a way to eliminate them, so after a bit of “Reflectoring” I saw that the sealed SPWebpartManager used the RegisterClientScript functions to emit that script into the page.
Both the ClientScriptManager and the SPWebPartManager were sealed classes (why in the hell does MS seal all interesting classes?), so I couldn’t inherit them to control when to emit the offending javascript and hidden fields, so I had to use reflection to simply “clean” the script before rendering the page:
I named the class “ScriptManagerFixer” and made some functions to eliminate the generated scripts. You can download the class here.
So I need a point from where to call the functions, so I chose my MasterPage’s Render method:
You can see that I eliminate all the scripts generated by the SPWebPartManager class and its base class, WebPartManager, I also eliminate all the hidden fields, so I can save some kbs in the html size.
With this solution you’ll get the full package, you’ll eliminate the script error and also will make your pages lighter.
Hope it helps!!
