Ghosted and Unghosted

Or, as I once called them, inherited and modified.

Anyone wanting to understand what going on behind the screens when you're editing pages with FrontPage 2003 needs to read Ghosted and unghosted pages - part 1 of 2.

Maurice Prather's blog is an excellent resource for serious developers...

10 page limit in Meeting workspace

Not any more.

This one held me up for an afternoon...

Anyone else who has tried to get around the 10 page limit in meeting workspaces will probably have spent a bit of time going through the XML config files, and I had pretty much given up after 2 hours...

Then, the first real sign of desperation set in. I considered using FrontPage.

No, really.

Obviously I continued searching the 60 directory, even binary searching the dlls to see if I could even find where the limit was set. But eventually I fired up FP2003 and very quickly found I could copy and paste existing .aspx files in the /pages directory until there were 13 files.

Then reloaded my site, and 14 tabs appeared. And they worked. And I could use all the existing page management tools in the web interface. Fantastic.

So why does the limit exist? Possibly a performance factor, perhaps a UI consideration. SharePoint seems perfectly happy for now...

To be fair to the FrontPage 2003 team, FP2003 is a great product, but old memories die hard. ;-) Check out their blog at http://blogs.msdn.com/frontpoint

New member

I've been a bit slack over the last couple of weeks and neglected to post my recent discoveries with SharePoint, intend to make up for that over the next 24 hours..

Plus I've invited a friend to also post his own notes... Oisin works at a much lower level than myself in .Net so I'm sure he'll be adding posts about optimising threads and debugging the CLR... right Ois?

First tip while it's in my head, when you're running SPS on Win2003, don't then convert it to a DC and install DNS and Active Directory. Not if you want to be able to use SPS again in a hurry...

I'm guessing most people out there will know this already. Especially if they've any common sense at all...

Visible security options

Daniel McPherson has a great blog that's well worth reading. He was also kind enough to give a very detailed reply to a question I posted to him.

It's a question that is often asked, Why can read only users see all the administration options, and how can I stop it?

Read Daniel's answer

For the record, I firstly edited the themes to make all the classes used by security sensitive links hidden. Then I wrote a client-side javascript function that hid the remaining elements by searching for them through the DOM. Then, for administrators to be able to make changes, I wrote a script that undid all the 'visible:hidden' changes. I made the function available in the 'Modify Page' drop-down by editing the XML fragment embedded in the page that determines the contents of the menu (also with client-side script). To finalise, when administrators clicked the option in the menu, a cookie wound be written to remember their setting.

Believe me, that didn't all happen at once! :-D

Probably about 2 weeks of messing about to get to the final stage... but it's still a messy way of doing things. A cleaner solution is needed. Anybody know what it is?

Using alternate header in ONET.XML

Serge has written a lot of detail on using the AlternateHeader parameter in ONET.XML. This is the best way to customise those hundreds of admin pages in the _layouts directory.

http://weblogs.asp.net/soever/archive/2004/06/01/145831.aspx

Unfortunetly AlternateHeader doesn't customise the web part pages or the list pages, which are of course the pages that make up 99% of the site for the average user. Unless I've missed a trick of course, let me know!

To assist in editing the ONET.XML file, and those templates, here are a few pointers.

When editing the NAVBARS elements, an iisreset will be required to see the change.

When editing the top PROJECT element, no amount of restarting will pick up the changes, the AlternateHeader, CustomJSUrl, and AlternateCSS parameters are grabbed at the point the site is created, so you can't change a site that already exists...

When editing files that the parameters point to, or editing the .aspx templates for the web part pages and list pages, no restarting required at all, the changes are immediatly live!

remember changes in these areas will be the first to get over written by service packs and the like, so think about your changes carefully..

Sharepoint 2003 blog

Hi all,

Another new Sharepoint Blog, looking forward to Sharing points on Sharepoint.

It's a mighty powerful thing, but it's not an obviously powerful thing is it?