Ideas on editing the _layouts/global application pages?

I made a post recently that deals with a major shortcoming in WSS v3 customization, the fact that 1/2 the pages in a WSS v3 site, the “application pages such as viewlsts.aspx, create.aspx etc” are not editable at the site level because they and the master page they inherit from, application.master reside in the _layouts folder on the file system and are shared by “all sites”.  Editing one means you change them for all sites.

Long story short, you cannot customize all the pages that make up a WSS v3 site, you would be left 1/2 your site looking default and 1/2 looking customized.

This is a HUGE pain point that needs to be addressed now while there is still time.  The community really needs to rally together to voice their concerns on this matter – It’s too late when you have 3+ years to wait for a new product.

If you are not totally aware of what I’m talking about – Create a WSS v3 site.  Open it in SharePoint Designer 2007 and add an image or a bit of text inside the first column in the first table in the document.  Take a look at your site in the browser and you will notice your changes.  Now click on a “view” such as Lists, or create a web part page “anything administrative”.  You will notice that even though you changed your “master page”, you cannot see your changes.  That’s because those pages inherit from application.master which is not editable at the “site level”.

This is a call to the community to rally together to voice your concerns to the SharePoint Team on this issue (using the appropriate channels), Blog about it, post it in the newsgroups for discussion, try to get it some attention.

I am also looking for nifty ideas from the community on ways to work around this.  It would make for a great www.codeplex.com project.  Something along the lines of a feature/site definition?  Something that allows you to specify a custom master page for the application pages?  If you have any ideas I would love to hear them.

You may also like...

48 Responses

  1. Stephen Kaye says:

    I’ve developed a feature that when activated on a web application allows the site administrator to specify the url to an alternate master page per site (SPWeb) which is then inherited by sub-webs. This allows multiple versions of the application.master to be used per web application (only one per site though)

    Read my blog and download the solution with source code at http://stephenkaye.blogspot.com/2008/03/how-to-customise-applicationmaster-file.html

  2. Curtis says:

    Ted Pattison has come up with a workaround that essentially allows you to add a line to the web.config file and reroute the application.master file to another file on a per site basis. It’s called SuperBranding and it’s on CodePlex.

  3. Mano Mangaldas says:

    Even though Microsoft has not addressed this issue, here is what they have to offer as a work-around. This solution is mostly based on what all of you have been talking about.. but atleast it is official..

    http://support.microsoft.com/kb/944105/en-us

  4. Mano Mangaldas says:

    Even though Microsoft has not addressed this issue, here is what they have to offer as a work-around. This solution is mostly based on what all of you have been talking about.. but atleast it is official

  5. SANDEEP says:

    Hi Shane,

    I am also facing the same issue of customising the files in _layouts folder.I had followed some methods like changing the local path in virtual directory but it went invain.Can any body plz suggest how to customise the file and brand even the application pages

    Waiting eagerly for help

    Thanks in Advance

  6. Thomas Glod says:

    The application.master contains several place holders that are used by the pages in _layouts. I have tried to modify a regular sharepoint master page to use it as application.master. This is how i did it:

    – start with a standard sharepoint master page, in my case I used the blueband
    – save the master page to disk together with all css and images (you have to find your way around sharepoint)
    – edit the standard masterpage and save it as my.master
    – use my.master on your sites. this works great on all the regualr pages
    – It is by this time you notice that all the pages in _layouts still look in the same old way. this is because they use the application.master
    – to change application.master to look like my.master you have to add all the place holders that are used in application.master to my.master

    In my case the following place holders where used in application.master and not in my.master

    PlaceHolderGlobalNavigation
    PlaceHolderSiteName
    PlaceHolderTopNavBar
    WSSDesignConsole
    SPNavigation
    PlaceHolderLeftNavBarDataSource
    PlaceHolderLeftNavBarBorder
    PlaceHolderPageDescriptionRowAttr
    PlaceHolderPageDescriptionRowAttr2
    PlaceHolderFormDigest
    PlaceHolderUtilityContent

    Above all this there can be problems with css and javascript included in the application.master that you have to add to my.master..

  7. Josh says:

    Opps sorry, used incorrect tags, forgot HTML was enabled. Heres what I wanted to say:

    Does Jim’s solution work with Sharepoint portal 2003? Or does it only work for those just using WSS? I am lost on step 3:

    3. In IIS manager, change the local path of the _layouts virtual directory in the WSS web application you want to customize to c:\MyNewLayouts\.

    In IIS i can navigate to

    SERVER | Web Sites | Default Web Site | _layouts | Properties

    and then change the local path but I fail to see how that would solve my problem. There is only one other Web Site inside of SERVER | Web Sites and thats SharePoint Central Administration, so its not like it lists all my sites i create inside the IIS manager. Is it supposed to? Or must i create it inside IIS?

    Thanks for your help

  8. Josh says:

    Does Jim’s solution work with Sharepoint portal 2003? Or does it only work for those just using WSS? I am lost on step 3:

    3. In IIS manager, change the local path of the _layouts virtual directory in the WSS web application you want to customize to c:\MyNewLayouts\.

    In IIS i can navigate to SERVER

  9. grayghost says:

    any news on the method that you mentioned back in January Shane?

  10. Geoff says:

    Shane,

    Any news on that other solution? I’d love to avoid copying my _layouts folder…

  11. Zach says:

    I’ve tried to implement Jim’s workaround, but as soon as I customize the application.master file in my new layouts location, I get and “Unknown Error”. Is there a customization step that I may have missed? Do any special permissions need to be applied to the new layouts directory? I’ve already copied the permissions that were on the original layouts directory to the new one.

    Any help here would be much appreciated.

  12. Raja says:

    This is not THE best solution but would work as a temporary fix. Check this article:
    http://www.sharepointblogs.com/dwise/archive/2007/01/08/SingleMasterPage.aspx

  13. Sash says:

    Brett, I am trying to implement the same but having problems trying to figure out how and where to make changes to the site to make it use the pages and styles from the new folder created under _layouts folder.
    Can anyone please provide with some steps or any site describing this process or any documentation on how this is implemented this. Thanks for the help.

  14. Brett says:

    Personally, I’m implementing Jim’s plan…

    Except, for WSS 3.0 use: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\template\layouts\ – that’s where the files are.

    In WSS 3.0, you’d create a web application, tied to an IIS site, and you’d have a custom /_layouts for each web application. It would keep the files isolated from one another, prevent any overwrites from updates, service packs, etc, and minimise the amount of code surgery you have to perform on these files. To get a consistent UI for both site pages and content pages would then only require customising default.master in master page gallery, and application.master in your new /_layouts folder. You wouldn’t need to put any additional code into any of the dependent pages, etc. It’s not a small footprint, but it’s clean, isolated, and offers the greatest flexibility.
    You should still be able to install updates, and overwrite these files, barring application.master.
    I used the same method for my sites in V2, and I plan to use it now. I can serve multi-tenanted, disparate web applications in a SaaS framework, fully customisable whilst maximising my hardware and software infrastructure.
    I did have it in mind to recode application.master to itself inherit from a custom .master file. But, my quick attempts just left threw up errors. With more time on-hand, that would definitely be something to look into.

  15. kiran says:

    I have the following declaration on the page layout

    navMenus.aspx contains c# code – methods. The methods are called on the
    pagelayout. Everything works so far.

    When I change some code in navMenu.aspx the page layout does not pick up the
    change. After doing a number of things i figured that., If i simply change
    something on the page layout and save it., then it picks up the new changes
    of navMenus.aspx

    This is totally wierd. Is there a Page attribute that need to be set on the
    pagelayout that automatically picks up the changes within navMenus.aspx.

    Any help is highly appreciated.

  16. Guilherme says:

    Honestly, I don’t get why Microsoft didn’t redesigned the whole thing :(

    All these of keeping SharePoint files inside CommonFiles\OLD\legacy\12\OFFICE.net\1033\Shared\___layout\_oldFrontpage looks sooooo ugly and hard to maintain…

    Backwards compatibility is really a good thing when everyone uses the old version of the product. And, 95% of the users going for WSS 3.0 never used WSS 2.0.

    WSS 3.0 sure looks good, but you are absolutely right about this post.

  17. shane says:

    Dan,

    We have a solution which works but we’ve not yet had the time to really do a final screening of (best we can) security. The solution will be released as a (use-at-own-risk) type scenario to the community. Microsoft of course cannot endorse such as solution, but we’ve yet to uncover anything terribly “unsecure” after having several security experts look at it. I’ll post it on my blog the moment it’s released.

    The other solution you mention I am sure can work well in some situations. Our goal is to do this with minimal footprint, and administration. I don’t know of a problem with that solution. With the one we’ve been working on, it’s browser based which was a major part of what we wanted to accomplish.

    Shane

  18. Dan says:

    Jim’s work around seems to work for me…………..

    1. Copy _layouts files in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\template\layouts\* to new folder, for instance, c:\MyNewLayouts\*

    2. Customize these files in c:\MyNewLayouts\* to whatever you want.

    3. In IIS manager, change the local path of the _layouts virtual directory in the WSS web application you want to customize to c:\MyNewLayouts\.

    then you are able to have customized _layouts pages for just a single WSS application without changing ‘ALL’ sites.

    any problems with this method?

  19. Dan says:

    Any updates yet on changing the application.master? Could this be done via the onet.xml?

  20. Mike says:

    Now that Sharepoint has RTM’d has there been any progress on this issue? Not surprised that MS failed to address it in RTM (busy, busy on other things, I guess) but it is causing my development team tremendous difficulty providing consistent branding across our Sharepoint deployment. So, any news?

  21. shane says:

    Peter,

    A group of us have been working on several solutions to remedy this. While I cannot release source right now I can tell you that we do have several “working” models.

    Important Note: It’s very likely that in the end Microsoft will be unable to endorse the solution we provide but they have been very helpful in taking the time to look at our solution and offer advice – especially around any potential security risks”.

    The Product Team(s) currently have obviously very heavy workloads as they prep for release, but they’re also taking the time to look at our most recent solution which I’m very excited about. Should our most recent solution prove to not pose security risks, we will make it available publically.

    I can’t offer a whole lot on it yet but the general idea is you make a copy of the application.master on a per-site basis allowing per-site customization of it.

    Hang in there we’re working on it!

  22. Peter says:

    Hello,

    Has anyone come up with a solution to the customized _layout-pages problem yet? I really want to customize /_layouts/viewlsts.aspx, as this page is part of the public WSS pages that most people in a customers organization would be seeing sooner or later. I have a really bad feeling about this, especially now where Beta2TR is out and the issue is still unsolved.

  23. alex says:

    This is an old topic now but I bumped into this video – and these resources – which were of GREAT help in getting a consistent look & feel for customizing sharepoint 2007 – they deal on site definitions and templates, changing master pages etc..

    I hope this is of help – has been for me:

    Video:
    http://download.microsoft.com/download/6/3/2/632e16bb-b996-4e08-8218-f5c82c6b7f61/WS304_Ohri.wmv

    Links:
    http://madhurahuja.blogspot.com/2006/09/site-definitions-demystified-creating_03.html
    http://www.sharepointblogs.com/tbaginski/archive/2006/05/31/8013.aspx

  24. Shane Perran says:

    Alex,

    This is a topic that could use many hours discussion. The readers digest version however is that what you are doing is ultimately not-supported by Microsoft.

    The main reason for that is that there could be files overwritten in the future during patches/updates. On top of that they simply do not have control over the unlimited possibilities that people could accomplish by editing default files.

    That being said, I’ve known several organizations to travel that path without incident – you just need a REALLY GOOD backup story and disaster recovery plan.

    In SPS2003 you could override the default CSS by pointing to a custom CSS file which was great. I have not come across this in MOSS 2007 yet but definatelyhave a look for it. If you can do your customizations via CSS edits, then backing up your images prior to overwriting them really shouldn’t be much of an issue.

    If you travel this road I would strong advise keeping a running log of the changes you make and backing up every single file (OUTSIDE) the 12 HIVE. I would also suggest keeping the folder structure the same for the backup.

  25. Alex says:

    Thanks Shane –

    Been giving this a whole lot of research and thought..

    I very new to the whole SharePoint system, making a ‘best practice’ choice pretty difficult for me to make.

    My scenario/situation is a server solution deploying MOSS-2007.. I want to change the whole layout of all pages everywhere (which I achieved changing default and application master pages).

    Per your suggestion I looked into making custom themes. I did this pretty fast to my surprise, deploying a “custom” theme (aka: renamed classic to whatever and added entries to xml/xsd files to make it show up).

    Thinking back to “deployment”… I am thinking about making this into an MSI or at the very least some sort of batch/exe automation to replace static files with my changes, add the theme etc..

    I want to see if this is what was along your train of thought or if you envision something more practical or all around more beneficial.. My greatest beef with the idea of batch replacing files is that (as it stands right now) I made very “brute force” changes – meaning I replaced hex colors in the core.css, calendar.css etc.. and photoshopped some of the boilerplate artwork in the “images” directory to match the color scheme of my choice..

    As you can tell if you follow what I did, my changes are irreversible (unless I make my deployment tool first back up existing files I will be replacing)..

    Anyway – before this post gets any longer – I would really like to hear your input on my approach (and yes, feel free to call me an animal :) ) I don’t know if there is a better way or in general some alternative to deploying a customized “look & feel” in a more civilized fashion..

  26. Shane says:

    Alex,

    The best way I’ve found thus far is.

    1) Creating custom site definitions and using alternative CSS.JS
    2) Creating THEMES (CSS based) – Themes apply to the entire site (ALL pages)
    3) Customizing the master pages/page layouts + a custom theme – This is my person favorite thus far.

    Cheers,

    Shane

  27. alex says:

    Shane – Thanks for the QUICK reply!!

    I had seen Jim Yang post a “workaround” and given the beta situation and my need to customize ‘today’ … I wanted to at least get a workaround until the problem is fixed (however they may decide to)…

    I am as shocked as anyone who dived into this customization task and seen how things are set up right now… I agree dont want to show my clients a “halfway customized” page with the sharepoint mini-four-guys logo appearing on ‘some’ pages etc etc…

    summary – For the time being I was wondering if there is a kosher way for me to customize my sp site! :)

  28. Shane says:

    Alex,

    I didn’t actually suggest a fix. I was pointing out the actual problem.

    This post is meant to generate discussion around the topic and hopefully flush out some solutions.

  29. alex says:

    Jim –

    Your workaround does not seem to work for me. I am using v3 – it seems that changing the _layouts virtual directory is still a global setting, I dont follow what you have suggested – has anyone tried this?

  30. Erin says:

    I’ve been reading a lot about customizing Sharepoint installs lately, and I’m just appalled that you can’t customize all the pages on a site.

    Please keep up the good fight; I’ll be checking for updates.

  31. This is a major pain having 2 sets of master pages to deal with.

    Central Services is now just another site which uses pages in the _layouts directory. I want to maintain the standard look for central services but customize for the rest of my sites.

  32. shane says:

    Bryan,

    While I do not know specifics of your case, it’s just as possible that the classes you seek are:

    1) Not yet fully wired due to beta bits
    2) Applied inside the code of a control which will require you to do a little more footwork. Basically you need to determine the class by looking at the rendered code (view source).

    PS: If a class does not exist I would encourage applying a theme and adding the class to the theme to check your results. If you still get nothing try old faithful (IISreset). If you still get nothing my last (unrecommended) advice would be to add the class to the global.css file.

    If after all of those you still get nothing blame it on beta-bits!

    Good luck!

  33. Is this why I seem to be incapable of finding particular classes or IDs while searching “all files” within SharePoint Designer 2007? For example, I need to find “” and modify the code to use divs instead of table cells. Is it because the code for this is elsewhere on the file system and not otherwise editable?

    I’m really struggling with the setup here, and would appreciate some help. Shane, you seem to be the only person so far writing about customizing SharePoint 2007. Thanks for your efforts!

  34. Todd Bleeker says:

    When I get the definitive answer here I will post a comment unless it is a public blog post by the team and then Shane will probably beat me to it.

  35. shane says:

    Hey Guys,

    I have since writing this talked with a dozen or more people about the issue. Everyone has their own opinions – lets wait for the SP team to get their thoughts together on this – I am very confident the guys will formally address this issue with a sensible explanation as to why/what you should and should not do.

    I realise there are a lot of complexities in these master pages, but like all things there will be workarounds.  I was on the phone with Todd and a Microsoftie a couple of nights ago, and we had a lengthy discussion on this topic. 

    Don’t worry – it has been and is being very much noticed. Keep the faith!

  36. Gustavo CR says:

    Jim’s solutions seems to be working for me in WSS 3 so far (10 minutes). I just made a copy in the same parent folder.

  37. Jim Yang says:

    This workaround is in WSS v2, I think we can do same way in WSSv3

  38. Jim Yang says:

    My workaound is:

    1. Copy _layouts files in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\template\layouts\* to new folder, for instance, c:\MyNewLayouts\*

    2. Customize these files in c:\MyNewLayouts\* to whatever you want.

    3. In IIS manager, change the local path of the _layouts virtual directory in the WSS web application you want to customize to c:\MyNewLayouts\.

    then you are able to have customized _layouts pages for just a single WSS application without changing ‘ALL’ sites.

  39. Ray Ranson says:

    Wow full circle experience here…. My team mentioned this on our Office12 preview visit to Redmond in Feb. A WSS Uber manager gave a master pages demo and we noticed that as he continued on that the admin pages did not apply the new master page. He mentioned something to the effect that, designs on applying master pages inheritance into the _layouts / hive was not really on the radar. Reminds me of your previous blog relating to themes and general customization. http://www.graphicalwonder.com/?p=425. I have completed a few customization POC’s and I think that there should definitely be some enhancements made and hope that the SDK is more thorough than V2. Your codeplex community project for admin / application master definition is a great idea.

  40. Ken Wong says:

    If I understand you correctly … what I original suggested would solve the problem because the web control would be able to get the context SPSite/SPWeb object. So if u are browsing to a _layouts page in site1 it would get the SPSite object for site1 and if you are browsing to a _layouts page in site2 it would get the SPSite object for site2. [done via SPControl.GetContextSite/Web (Context)]

    Once you have the appropriate SPSite/SPWeb object, you either map that to a its own application master page via a cached xml file (easy solution) … or you have it stored in one of the custom fields in the SPWeb object. Once you have this you have a _per site_ application master page value.

    From here the web control will change the _layouts page’s master page dynamically. I’m not absolutely sure this is possible via a web control embedded in a page; I’ve seen it done only in the page’s events handlers.

    Regardless, if the above works there are still two facts that make this a crappy solution:
    1. you need to embed this web control in every aspx page in the _layouts directory
    2. modifying stuff in _layouts directory is not supported … with new service packs … all of your _layouts pages could be overwritten and then u would need to redo #1

    I hope I understood you correctly and that my explanation is clear.


    Ken

  41. Isaac says:

    I completely agree, i’m going to send an email to our Microsoft rep stating so.

  42. Shane Perran says:

    What I mean is “ALL” sites reference the pages in the _layouts directory. If you change one for one site, you change it for them all.

    The problem is that you cannot customize the application pages on a site by site basis and this all but nullifies the fact master pages are even being used.

    We need separation site by site.

  43. Ken Wong says:

    Having said what I said above. In most cases, unless you have more than one site differently branded site on the same machine, it shouldn’t be a problem to modify the _layouts/application.master to conform to custom master page.


    Ken

  44. Ken Wong says:

    I don’t think I understand what you mean by “how does that solve the fact that the same files are referenced”.

    As for “copying these files to the content database” … I was suggesting modifying the all the files aspx in the _layouts directory on the file system. Of course this is usually an unsupported customization. This is why I said to retain the original files that are going to be modified.

  45. shane says:

    That was my initial thought as well – perhaps a feature that does all that for you. Then I started thinking; how does that solve the fact that the same files are referenced and it didn’t sound so great.

    Do we have to copy “all” these files to the content database? Is there a more elegant solution?

    Only time will tell!

  46. Ken Wong says:

    Here’s a thought:

    Create a web control that will be embedded in all the _layout pages (yeah .. i know its alot of work … and u will need to make a backup of the _layouts files you change). The web control will examine the SPSite/SPWeb object and change the master page of the page. You can store which master page per site in one of the custom fields or put it in an xml mapping file.

    When in the page life cycle is important … probably on init or something.

  1. July 16, 2006

    […] I wrote an article recently which questions the architecture of WSS v3 master pages, more specifically the shortcomings of WSS v3 customization when it comes to the application pages which reside in the _layouts folder. I was happy to see just how much discussion this has generated as this was my intention from the start. […]

  2. February 14, 2007

    […] People are complaining that WSS 3 application pages (aspx pages in _layouts virtual directory) are not as easy as content pages to customize. The fact that the application pages  are shared among all the sites prevents them from being customized for a specified site. […]

I would love to hear from you.

%d bloggers like this: