Wednesday 26 November 2008

Page Settings: More Bad Paths - MOSS Restore Issues continued

It happens when you restore WCM (publishing) sites to another location. The Page Layout source URL is not updated to reflect the new location.

There are several painful options I tried before finally coming across this solution:

http://stsadm.blogspot.com/2007/08/fix-publishing-pages-page-layout-url.html

There’s also a standalone executable and source code available here (the script often requires tweaking and recompiling to work, so having the source is a terrific help):

http://blog.thekid.me.uk/archive/2007/08/20/fixing-page-layout-urls-after-importing-a-publishing-site-in-sharepoint.aspx

One or the other usually provides the fix required.

UPDATE

if you're still having problems, there are a few things to watch for.

  • Firstly, checkout-out pages (and quite possibly drafts) will not be affected by these commands, so make sure you approve and check in all pages first.
  • If you're still getting the mysterious 'Unknown User' error on some pages chances are that the person who originally created your master/layout pages (or even site template!) no longer exists in the current site/collection. In this case you will have to temporarily add that user back, run the command again, and hopefully all will be good.

Good luck and please add a comment if you've found anything else or are still having problems.

SharePoint 2007 - Disaster. Recovery?

Nowhere on any Microsoft website will you find a clear and complete guide on what is obviously one of the most fundamental and critical aspects of any system – disaster recovery.

In order to save others much pain and suffering I have outlined my lessons learnt below:

  • It really, really helps if the environments you are working between match as closely as possible.
    • This includes - but is by no means limited to - ensuring that the root site is of the same type in both locations.
  • Farm-level backup does not include the following:
    • Items in the Global Assembly Cache (any custom DLLs)
    • Web config files
    • IIS web app settings
    • Customisations and some elements in the 12 hive

These items should be backed up separately and applied to the new location first.

The following is an approach to migrating a farm (single- or multi-server) from one environment to the other. It is provided here free of charge and should be used as a guide only. I have attempted to list and present these items in some form of chronological order but no doubt everyone's needs and tastes here will differ.

  1. Web Apps
    • Recreate these on the destination server(s) first. You don’t want to copy anything here because these would usually be using different host headers, URLs etc.
  2. Custom DLLs in GAC
    • These can just be copied across. I keep a separate folder of all custom DLLs on another box (dev) and just copy these to C:\Windows\assembly on the target server(s) – all WFE (web front ends).
    • These also need to be registered as Safe Controls in your web.config.
    • You can usually determine what your custom items are from the web.config files.
  3. 12 Hive
    • It’s quite possible that developers have made changes here. Usually they add any custom logos, images and page copies in here.
    • The good news is that the 12 hive from one default installation to the next is identical.
    • Modifications will usually have been restricted to the TEMPLATE folder so you can start by just copying that.
  4. Web.config(s)
    • You will have a web.config file for each web app on each WFE. Ignore the confusing existence of web.config files in the 12 hive CONFIG directory. These don’t appear to get used at all.
    • What no one bothers telling you is WHICH web.config file(s) need to be changed! There are dozens and it’s bluddy confusing. The ones you actually need to affect changes in are again on the WFEs only, within the relevant IIS folder – e.g. C:\Inetpub\wwwroot\wss\VirtualDirectories\www.yourwebapp.com80
    • Easiest method is to copy an existing one to the new location. Make a copy of the destination file first.
    • If you have a diff tool (there are dozens but I like the one that ships free with TortoiseSVN) you can compare them to see the differences for yourself.

There you have it. Four fairly simple steps (once you know what you need!).

Once all that is in place you should be able to do a Farm or site collection restore on the server and hopefully everything will just work for you. In our case we also had to reconfigure the following because MOSS seems to use hard-coded site roots in some areas:

  • Content Query Web Parts (and others based on it) – sometimes but not in all cases these need to be reconfigured
  • Send To links – this field only accepts an absolute URL so any values you’ve applied here need updating
  • Publishing Layout Pages – inheritance paths for these sometimes still point to the old server.
    • You can check this by trying to edit the Page Settings for any publishing page.
    • If you get an error then you are affected by this bug. It can be resolved using one of two methods described in another blog entitled Page Settings: Bad Paths - MOSS Restore Issues continued.

Once you’ve got the new environment up and running then using Content Deployment seems to be the easiest way to get new content across. The main issue I ran into here was that we wanted to use the same GUIDs but Content Deployment doesn’t like this.

Seems pretty strange when you consider that any custom solution, workflow, site definition etc., all use GUIDs natively to determine what content is being referenced!

Thursday 20 November 2008

Managing those slippery MOSS Web part Pages

What bugs me most about SharePoint is that there is almost always an application ASPX page that can provide exactly the functionality you're looking for.

Take Web Part pages for example, they have their own maintenance page but the only time you'll ever get to see the link for it is when one or more web parts on a page is causing problems. When this happens you get the usual generic error message we've all come to know and love, and a link to the holy Web Part Maintenance Page.

But what about when there is no error and you just want to manage the web parts for a given page - Close, Reset or Delete one or more? Fear not. Like many hard learnt solutions in MOSS, simply knowing what ASPX page to call (and with what parameters).

Simply add /_layouts/spcontnt.aspx?&url=[url] after your domain/server root with the appropriate path to the page you want to manage.

e.g. http://mysite/_layouts/spcontnt.aspx?&url=/subsite/Pages/mypage.aspx

Happy managing!

Monday 17 November 2008

Making MOSS accessible: a lost cause?

As an accessibility evangelist and someone from an open source background who fell head first into this new world of SharePoint and.NET programming I can tell you that this task is not for the faint-hearted. The effort required to make MOSS even remotely accessible (and I’m not just talking priority 1 and 2 checkpoints)is gargantuan.

To add to all the advice already given elsewhere, the most future-proof steps required to make your WCM sites accessible include:

  1. Specify an XHTML loose doctype in your custom master. Caveats:
    • You can’t use a strict doctype without losing functionality (because non-compliant code will not render as expected, if at all).
    • You can’t specify a doctype in your system master without losing valuable functionality (Datasheet View and Image Library functions notwithstanding).
  2. Rewrite all the layout code found in masters and layouts to be compliant. This is about the best start you’ve got. This includes:
    • Using custom CSS wherever possible. Delete built-in style calls and let your base HTML selector styles do the work.
    • Use custom ID selectors for layout to overwrite anything rendered by core.css. This also allows you to add all your skip link anchors and makes using a style switcher that much simpler.
    • Go as far as to remove the csslink tag in your master page if you’re really game and see what happens. I managed to reduce all native SharePoint CSS to 101 lines and call it last as an override.
  3. Don’t use the MS Minimal Master. It fails to include useful (if not essential) placeholders.
  4. Use Data Form Web Parts wherever you can.
    • Output for these can be controlled with XSL.
    • They don’t have to live within Web Part Zones.
  5. Visit Heather Solomon’s site and grab her minimal master (infintely more usable) and the CSS cheat sheets can be invaluable.
  6. Develop in FireFox first. FireBug is your new best friend. Then test in IE, use the Developer’s Toolbar, and add any ‘fixes’ to your CSS override.
  7. Having gone to all this trouble the last thing you need is for your content editors to spoil all your hard work by pasting content from Word!
    • Get Telerik or a similarly standards-compliant editor.
    • Provide a Writing For The Web content editor’s guide which includes simple steps on producing nice, clean, legible copy.

Even after employing all the recommendations made here, at the end of the day you still have to accept certain limitations and realities. We have managed to come out of this exercise with accessible master pages (and some layout pages) but there is little control over content that is rendered at run-time. Everything I’ve found either re-writes the rendered code after the fact or just helps to bloat it in another way.

Much of the controls that make up a page use seriously flawed legacy code. If only all web parts included the XSL editor!

Last time I looked the AKS did little more than add summary="layout" and slightly deplete the concentric ring of nested tables that make up a typical page. And while the Telerik editor _produces_ compliant code, it’s my understanding that it is still rewritten at page load by the ASP render class.

Best piece of advice? Just keep hammering MS on the SharePoint forums and hope that future versions will one day get there. I use a number of aliases. ;)