I'm bumping in on this one too...

I haven't ever attempted it, but I'd give it a go if there are other people that might think it's useful. What are the requirements/reasons/wishlist for the reskin? I'd imagine it could be a bit of a nightmare if it's not a controlled process and maybe the core team wouldn't want you to do it as it might dilute the umbraco brand/ethic. What are other people's thoughts? I think it might be a case of it's not broken, don't fix it. But it could be interesting to see another take on the backend all the same.

Hey,

Thanks for the discussion.

The reason is that the client has an existing system and they want to (within reason) make the replacement as close as possible (navigation etc) to the original to minimise the amount of training for users. The content is managed by ~200 people (all with small niche areas of expertise) and are geographically dispersed.

Jay

I'm curious about this too! :-D

I have one client who has been threatening to do this for a long time... now that the back-office UI is MIT, I might be asked to do this very soon.

Since the back-office is built up using iframes, it would be tricky to start re-arranging the components - of course, its doable, but as Jay said, upgrades would become impossible/nightmare!

My advice would be to stick with pure CSS and jQuery to make any specific DOM changes; (adding classes, etc).  I'd be tempted to suggest even only overriding the default CSS styles, as replacing them all would be a full-time job too!

Cheers, Lee.

This has been raised before (http://our.umbraco.org/forum/using/ui-questions/7598-Backend-global-styling?sort=karma) and my original answer still mostly rings true for me...

abandon hope all ye who enter here

probably not really as bad as all that, but from what looks I've had at the backend the fact that it's been made as "modular" as possible also makes it a complete PITA to try and customise.  I would like to see examples of other customisations though

Dan

Ok here goes...

This is going to come up very soon for our own client work (after the MIT licence was applied to the backend) so I thought I'd take another look at it.

I went with the approach of only overriding css via a new file and not editing existing css. The more I think about this however it may actually best to append the css to an existing css file, to avoid having to edit each page/frame specifically.  i think actually editing the markup will cause too much pain in the future to even consider it.  What if a critical security release comes out?  is the client going to want to pay twice for you to skin the admin in 4.5.6 if files change?  Would you manually have to diff all the admin files for each release? 

The thought of dreading a new umbraco release instead of looking forward to it makes me worry!

So here's what I did:

• Created a custom.css file
• Used a heck of a lot of !important rules (!ugly)
• added it to the necessary pages manually.

In /umbraco/umbraco.aspx just before the closing tag...

<link rel="stylesheet" type="text/css" href="/umbraco_client/ui/custom.css" media="all" />

In /umbraco/editcontent.aspx and In /umbraco/dashboard.aspx

<asp:Content ContentPlaceHolderID="head" runat="server">
   <link rel="stylesheet" type="text/css" href="/umbraco_client/ui/custom.css" media="all" />
</asp:Content>

And I stopped there - there's also editMedia.aspx etc etc. 

And here's the CSS... the abundance of !important rules is very nasty but I was in a hurry...

div#topBar {
    background: #f7f7f7;
    border-bottom: 15px;
    border-bottom: 1px solid #ccc;
}

div.boxhead h2 {
    background: white !important;
    padding: 10px 0 5px 0!important;
    font-size: 14px !important;
    color: #666 !important;
}

div#treeWindow_content,
div.boxbody .content,
div.boxbody .innerContent{
    background: none !important;
    background-color: #f9f9f9 !important;
}

div.boxbody .content{
    border-left: 1px solid #ccc !important;
}

div.boxfooter,
div.boxfooter h2,
div.boxfooter .statusBar,
div.footer div.status,
div.footer h2  {
    background: none !important;
}

div.footer h2,
div.boxfooter h2 {
    border-top: 1px solid #ccc;
}


/* Editcontent page */

div.header ul {
 padding-top: 28px !important;
}


div.tabpagecontainer,
div.tabpage,
div.tabpagescrollinglayer,
div.tabPageContent {
    background: #fff!important;
}


/* menu and tabbar */

div.menubar {
    background: #f9f9f9;
}

li.tabOn,
li.tabOff {
    margin-right: 2px;
}
  
li.tabOn a,
li.tabOn span {
    background: #f9f9f9 !important;
    
}

li.tabOn {
    border: 1px solid #ccc;
    border-bottom: none;
    float: left;
}

li.tabOff a,
li.tabOff span,
li.taboff nobr {
    background: #f4f4f4 !important;
}

li.tabOff {
    floaT: left;
    border: 1px solid #ccc;
    border-bottom: none;
}

li.tabOff a:hover,
li.tabOff a:hover {
  background: #e1e1e1 !important;
   text-decoration: none;
}

li.tabOn a:hover {
   text-decoration: none;
}


div.propertypane {
        background: #f9f9f9 !important;
}

And here's the (to my eyes) only very slightly improved look of the admin

Good luck!

Dan

Thanks chaps,

Thanks. It's nice(?) to know that I'm not the only one about to hit it.

I think I'll actually agree with Dan's:

abandon hope all ye who enter here

It feels like the combination of iFrames/modular approach and the risk of breaking it badly means that the sensible thing is try and convince the client it's a bad idea ;-)

If they still want to proceed then I may try and use custom icons for the sections and something similar to Dan's css there to just use custom colours that match the clients colour scheme and leave it at that. Any more than that is going to be unmaintainable (at reasonable cost) I think.

I assume that (prior to MIT of 4.5) th ePro licence just gave you the right to modify it, no additional guidelines?

Thanks again

Jay

Hi Jay,

That's correct, prior to 4.5 you needed a pro license to modify the back end. That gave you the right to change it as much as you like I think. I've spoken to a couple of people about this in the past, and I think most of the customisations that I've heard about have mainly been re-badging the back end with client logos and changing colours slightly, nothing too major, so as to avoid causing major headaches with upgrades.

Hi Tim,

Cheers, I think the rebadging and retraining existing users is the sensible move.

Jay

Digging this one back up...I remember when first started with Umbraco 4.x I read something about a pro license and how it allowed you to skin the back-end.

I was speaking to a digital agency who would be quite keen to start using Umbraco if they could badge it to look their own product and change the url from domain.com/umbraco to something of their own choosing.

Looking at the current Umbraco website though I cannot find any information about being able to do this. Is it still an option?

Regards,

Matt

Hiya,

You can still re-skin/badge the CMS, as I think that's still open sourced, you can change the umabraco path for the cms folder, see this forum thread: http://our.umbraco.org/forum/ourumb-dev-forum/bugs/7060-Changing-the-umbraco-directory-to-enhance-security, also see: http://our.umbraco.org/m?mode=topic&id=19081

Hope that helps!

:)

Thanks Tim,

I looked at those posts and it seems it may be opening a can of worms to try it.

is working on a reply...