We all know the pitfalls of messing around with default MOSS files and that the basic rules are always to create and modify your own rather than the defaults. One of the main reasons for this is ongoing support for the product from MS (they wont support cusomised changes to defaukt files) as well as the impact of service packs and hotfixes (they generally overwrite default files and hence any changes you made to them).
Now in most cases we dont always know about changes we need to make, and when we do it is sometimes neccessary to change the default files as previous sites are now linked to those files; take the CORE.js and Viewpage.aspx files as examples:
- CORE.js controls things like context menus and other nice things.
- Viewpage.aspx is the default page used to create list pages like "Allitems.aspx"
Example:
Recently I needed to modify the CORE.js file to fix a problem with emailed links (some people could not open the link as it was an encoded URL), now rather than modifying the default CORE.js I made a copy and renamed it ClientCore.js, made the changes and replace the reference to the CORE.js in all my custom pages.
Problem: Most list pages are created from the "Viewpage.aspx" page, this page has the default.master as it's master page and I do not want to mess with a MOSS default file.
Solution: Make a copy of the "Viewpage.aspx", change the default.master to my custom master (that references my ClientCore.js instead), change the references in my custom Document Library SCHEMA.xml to create views from the new page. There we go.
Problem: All previous document libraries have been created from the original file with the reference to the original Core.js.
Solution: None really, unless I change the default Core.js / add a the code manually to all preivous libraries. As soon as I apply a hotfix / sp the changes are going to be overwritten.
The real solution?
Planing, planning and paranoia: Now days I automatically ensure I make copies of the files I know / suspect will need to change and ensure that I make references to them; specifically:
- Core.js
- Viewpage.aspx
- default.master
- (and some others)
What about updates?
This is another problem with no quick-win situation: when a SP or Hotfix does come along and makes changes to the Core.js for instance that are neccessary I simply copy those changes accross into my customized file (look at the documentation, all changes are recorded).
Conclusion:
I know most will disagree with my methods, but when you are facing large, multi farm environments where changes / fixes need to be made after deployment this really works out easier for me. Schlep in the begining to make my life easier in the end :)
Your feedback and ideas would be appreciated on this!