[MOSS 2007 public facing site] access to MS Office documents in Document Library

I am less and less certain if this is a right product…
This is THE most incredible and discouraging experience that I ever had with this product, which I have been working on to maintain our public internet site.

First of all, MANY MANY MANY thanks to the author of this blog post.
http://www.theblackknightsings.com/RemoveLoginBoxWhenAnonymousUsersDownloadOfficeDocumentFromSharePointSite.aspx
# BTW, the design is very funny. I thought it was a genuine error screen at the beginning.

The explanation is very clear, and so is the code. So I went straight plugging it in to our production site.
# I have at least compiled the DLL myself, and did a bit of test though.

We know that this product i.e. SharePoint is now widely used, especially with intranets, sites for collaboration and so on, where you know the users, they are all authenticated. However, for public facing internet sites such as ours where majority of users are anonymous, there are points overlooked, including ones as obvious as this one. And we users by ourselves need to apply workarounds… Hope with the coming 2010, it comes as a WCM product fully ready for public sites.

A day with video files

Nothing to do with work. Some video stuff.

Many probably knows about .fll (FLV Flash Video) file. I have got some movie files where there are some annoying discrepancy between image and sound.

I was bored today so tried to do something with it.

There is this famous Avidemux freeware with which you could fix this discrepancy. The latest is 5.2. It appears not yet nicely support the H264 video format.

When it finds that your file is in the format, it popups:

H.264 detected. If the file is using B-frames as reference it can lead to a crash or stuttering. Avidemux can use another mode which is safe but YOU WILL LOSE FRAME ACCURACY. Do you want to use that mode?

I am not at all an expert in this area, do not know what this means exactly, so went on accepting use of the "safe" mode. That appears fine. However, if you do not do what you want at this first time you open the file and close it. The popup would never come again and as the consequence, you can not open the file, unless you go to its conf file (in XML) and manually clear the history. This was the first difficulty that I encountered.

The second thing is the sound. To adjust the sound so it goes nicely, side-by-side with the video, of course you want to see the video together with the sound in its preview mode. I use a mac at home by the way. And the latest mac version of the freeware does not seem to allow me to listen to the sound.

I went back to a previous version, 4.4. Its handling of the sound device seems ok. Good! But then it does not yet support the audio format of my files!!!

So finally what I did was the following. I open each of those files with the latest, 5.2, change the audio data format to mp3, then turn to the 4.4 and shift the starting point of the sound.

A nice holiday activity.

media="print" and proxy

Really strange thing happened.

One of our developer tried to do a print-friendly rendering of a page. That is, when you print the page, logo is removed, hyperlinks is followed by their URLs written etc. A usual stuff.

He did so using media="print" trick with CSS.

He made it work nicely with FireFox but not on IE. Still needs some improvement, to support various browsers. That's OK. Not my business.

The weird thing is that it behaves differently when you get the page, css everything via a proxy.

The simplest example. If I start Fiddler to see if all come from where they are supposed to, you see it already different in the print preview...

You would normally suspect that some element of the page such as a css file fails to come, due to some authentication/authorization issue for instance, when you go thru the proxy. But Fiddler reports none. The key, linked as media="print", css seems downloaded OK. If the elements are the same, whether or not via proxy, it should behave in the same way...

After almost one day of fruitless investigation, given up... Asked him to revise it, so it works OK with IE as well, and with or without a proxy.

Mmmm...

ASP.NET Menu for Arabic i.e. right-to-left pages

Just to share, or for myself to remember this small piece of info.

http://www.microsoft.com/middleeast/msdn/Asp2_menu.aspx

It is becoming more and more that the key to be a good programmer is the ability to come up with a good set of keywords for the problem in hand, to type into a search engine...

In this case... what did I type?
At first, I typed something like "ASP.NET Menu right to left", whcih did not give me any useful pages.
Then tried (already started thinking of moving to CSS adapter. No, do not want to do that. Would be quite a work...) "ASP.NET Menu Arabic". Then, Voila! I found the above.

For those who speak Arabic, it must be a well-known trick. But for us...

"The site with the id {GUID} could not be found" and BLOBCache

My own memo. Nothing I myself found.
Anyway it was really hard to figure out. But I was lucky that it happened in our testing environment. So I did not have to start crying yet.

The problem was the following.
I was getting “The site with the id {GUID} could not be found” error to get some css files from Style Library. But only on the extended web application, and futhermore, only when a user logs in to the site. # Our site accepts anonymous visitors too.

I re- extended the web app, re-restored the data from our production site. Nothing helped. # I did not have the problem on the production site.

As always, I went to the net for some help, a hint at least. But this time I did not think I would find anything helpful. I was believing that the content database might have been corrupted somehow, or something…

However, there are people who had the exact same problem, and have overcome it.
http://blogs.msdn.com/joshuag/archive/2008/05/22/filenotfoundexception-the-site-with-the-id-guid-could-not-be-found.aspx

This was a big help. I did not even think about the cache.
Unfortunately, however, the solution did not work for me.

But I know now all I need to know is how to clear the cache. And found this http://blogs.pointbridge.com/Blogs/monnette_jeff/Pages/Post.aspx?_ID=15.

More (seemingly) in depth explanation can be found at http://sharepointinterface.com/2009/06/18/we-drift-deeper-into-the-sound-as-the-flush-comes/.
I did not have anough patience to read it throughly though…

In short, the UI does not work for a farm like ours, and the stsadm solution (http://msdn.microsoft.com/en-us/library/aa622758.aspx) stinks.
We have only two front-ends. So I went for the manual flush.

Accessibility : Accessibility Kit for Sharepoint

There is this tool (? add-on?) exists. But after all it did not help much.

You find a couple of things in the package but we were only interested in what they call HCCE (HiSoftware Compliant Code Engine) and WebZonePart controladapter.

The HCCE is nothing more than a custom base class for Page Layout, and what it does is simple string replacements.
For instance, MOSS Publishing feature generates <SCRIPT> in its output HTML, which violates XHTML. It has to be <script type=”text/javascript”>.
It does this, the replacement in the output. But only if you specify it, exactly as above, one by one, in its config file.
So it is not like, it does the work if you say you want to “comply” to XHTML, or HTML. “Compliant Code Engine”… Funny..

And the other cr*p, WebZonePart controladapter, it is a controladapter. So as you know, it replaces with table with div.
By default, MOSS generates lines like below for each webpart on the page. Of course it all violates standard.
<td id="MSOZoneCell_WebPartWPQ3" orientation="Vertical" name="MSOZoneCell" relatedWebPart="WebPartWPQ3"…

The adapter replaces those with divs. Sounds nice. But my problem was that it does not produces title and border of the part even if you configure you want them.
Luckly, the package contains the source (not for HCCE. HCCE comes only as binary (of debug build…)). So I managed to have them back.


What still remains not OK are those XHTML not compatible codes generated mainly by Rich HTML editor.
The HCCE’s static string replacement does not do anything for this. Here you want to replace, for instance border=0 with border=”0”. And there could be border=1, or 2, or 3, you never know…

For this, I did not find any turnkey solution. However, I found a guy who solved the similar problem in a different CMS by plugging-in a httpmodule of his own.
http://www.codeplex.com/compfilter4umbraco
He uses this library http://www.codeproject.com/KB/dotnet/apmilhtml.aspx , for basic clean-up of markup.

I was not sure if I can plug-in a httpmodule to MOSS, but since I did not have any other more promising alternative, I gave it a try. And voila, it works!!
For the module, I created it from scratch. I did not need any of logics placed specifically for the CMS. Quicker to build one from scratch than to remove those.
But the library, thanks to the author, I did use it, although I changed it a bit.

The challenge I had was that, at the beginning I had all page go thru this filter. It screwed up things.
So, in the end, I made it so that it cleans up only contents, not part coming from masterpage. That works. This is where the rich editor generating codes appear.

Accessibility : XHTML or HTML

The first step for an accessible site is conformance to a standard. A colleague of mine who closely follows this subject told me. It can be XHTML or HTML. Does not matter much as far as we conform to one, he added.

Please contest me if I say something stupid, but in a word, a site created using MOSS 2007 Publishing Feature does not conform to none of the two. You can not configure it to. You have to customize it.

It is based on ASP.NET 2.0 which I believe supports XHTML more than HTML.One of the places that you clearly see it is that it inserts lines like below, which violates HTML scheme.

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />

And you can not configure it to stop doing so.

OK. Let us go for XHTML then. But, thank you MS! It violates it too...
You can see it quite easily, just by inserting an image using its Rich HTML Editor. It generates a line like this.

<img border=0 ... >

Actually, I have the impression that MOSS Publishing feature is designed(?) to create HTML sites. Its OOTB masterpage files have got HTML doctype declaration.I really do not understand why it comes out like this...

Anyway, after having tried both, I saw going for XHTML should be a realistic solution, and started customizing it.

In a couple of posts after this, I would like to talk about the series of tricks that I employed.