Arpan Shah has a good post on things to consider in preparation for the upgrade to SPS/WSS 3.0. I generally make a concerted effort to toe the line with regards to guidelines from Microsoft but when something is seriously out of whack I have to take exception. Two of the 'Golden Rules' of SharePoint customization that Arpan repeats in his post have me seriously concerned that Microsoft is not taking into account their customer's desire to fully customize SPS in the next release; namely, 1) Database access, and 2) File/Definition modifications. As Arpan states:
1. Don't touch the database. Modifying is a big no-no... reading it -- there's no guarantee that the schema will be the same. If you want to ensure a smooth upgrade, don't touch it or use partner technologies that modify the database.
2. Don't modify out of the box files/directories/stylesheets, et cetera. Whenever possible, you should be creating copies and then modifying vs. modifying the out of the box files. Service Packs or future versions can overwrite files and you can lose your customizations. Net/net: follow customization guidelines!
This is all well and good but both of these 'rules' completely ignore the realities of full-scale customization. First, I defy you to create a portal-wide, collapsible, dynamic navigation menu (a la MSDN menus) or a nested drop-down navigation bar that includes both SPS areas and WSS sites without reading from the database. Sure, you can cobble together an object-model server control but it will be a) V-E-R-Y S-L-O-W and b) very buggy. Not to mention the fact that you can't make the association between WSS sites and SPS areas without reading from the WEBS and SITES tables. I completely support the notion that modifying the database is BAD IDEA but not being allowed to read from it overly restricts development and customization.
Second, you absolutely cannot deploy a fully branded and customized portal solution without modifying the SPS, SPSPERS, SPSMSITE, and SPSSITES site definitions. Add WSS sites and you must also customize the STS definition (although you can work around that limitation by getting fancy with the WEBTEMP.XML files). What good are stand-alone area customizations if they don't integrate with the rest of the portal? We're talking about customizations far beyond portalheader.aspx and alternateheader.aspx - full page layout and design changes cannot be achieved without editing the core definitions. (NOTE: You can modify WEBTEMPSPS.XML and replace the default definitions with custom definitions using the same ID but it doesn't always work right, especially when replacing the SPS definition, and besides, according to the guidelines, we're not supposed to modify the base XML files either).
Third, administration pages are a unique animal unto themselves. At last count I have discovered at least half a dozen shared code structures just for admin page headers (sorry to disappoint, but alternateheader.aspx only works in about a third of those pages, and it's functionality is limited at best) and a bunch of stand-alone configurations. Many don't include references to custom CSS files or all the code registrations necessary for including server controls (you do want a common navigation scheme at the top of ALL your pages, don't you?). Remember that many of these pages are accessed regularly by portal users - spsviewlsts, lstman, aclinv, catman, create, listedit, and so on - so modifying them is required if you wish to maintain any sort of continuity in portal design.
I understand that customization in the current product is tricky at best but v.Next is supposed to address that issue, is it not? I thought so but Arpan's post makes me wonder if that will be the case. Word to the mother ship - CUSTOMERS DEMAND CUSTOMIZATION!!! Neglect the ability to customize the product and customer satisfaction will plummet. I sincerely hope this requirement has been taken into consideration and the final release will take full advantage of .NET 2.0 features to provide scalable, extensible customization options without restricting the customer to a less-than-desireable mish-mash of 'works here but doesn't work there' compromises.
Don't get me wrong - SharePoint is a great product and I appreciate the customization flexibility that Microsoft has given us (even if some of it is inadvertent). I also appreciate the wisdom from on high provided by Arpan, Fitz, Maurice, and others. I just hope that the lessons of v2 influence the features of v3 inasmuch as customization is no longer an option but a requirement.
For those of you that have already done extensive customization to your portal deployment, here are some practical suggestions to prepare for the v.Next upgrade:
1. Insure that you have copies of all the original, unaltered files, definitions and directory structures.
2. Make a copy of all modified files, definitions and directories.
3. Make a copy of all database additions, such as stored procedures, logins and custom indexes.
4. Prior to upgrading, restore the original files/defs/dirs and remove any custom CSS files, images, etc. from the 60 hive.
5. Remove all database additions.
6. Perform the upgrade to a test portal.
7. Determine what impact the new changes have on your customization scheme and modify/redeploy accordingly (many of the hard-coded mods my no longer be necessary as Master Pages will replace much of the file-by-file alterations necessary in the current version).
8. Revise your database additions to account for any schema changes and redeploy.
9. Test and modify your web parts and server controls (especially those that read from the DB).
10. Test, test, and test again, then downgrade the live portal deployment to a basic install, upgrade to the new version, and deploy your customized portal elements.
Bear in mind that these are just suggestions - without having the new version to test against there is no way of knowing what the actual procedure will be. The more extensive the customizations the sooner you should begin testing and planning the upgrade to v.Next for your clients/organization.
