I decided to take a night off to really look at how this skinning functionality will work after trying to get the site to work other skins.
I believe that I’m not a total fool, and hoping because it’s a beta version, that this is the reason I can’t get a single skin to work as expected.
I uploaded a legacy skin through the skin uploader -as per instructions…
Not wanting to take any chances, I installed the Default GRAY skin from the DNN 4 build. I thought to myself – what could go wrong….

I followed the prompts as best I could – to enable the default skin to be uploaded.
Not able to preview or display, no errors, just nothing, so not wanting to be put off, I thought I’d take a look at the skin that works, zip that up and install it.
From all accounts, I thought it was successful – no errors that I could see. However, not able to use it, so moved on to the ‘new method’ of skin installation.
So after that didn’t work when I had installed about 4 different current skins, I decided to move on the new method of installation.
This is the process of installing new skins from the Host / Skins area.

I didn’t want to ignore the file restrictions, clicked next..
Although I had made some changes to the DNN file, I obviously don’t know all the correct methods and I checked out the DNN file in the users online module which had the parameters for the owner, version, url, email etc, but could not find any code at all to put into the skin dnn file, so my guesswork was wrong.
Unfortunately, I couldn’t find anyone to to ask about this, since no one I know except the core team who talk about this release, has even installed the beta. I’m sure in the release there will be more information, otherwise the whole point of doing this would be useless since there is no facility for anyone to ‘check’ any licenses – eg.. the code hasn’t been provided.

I did see some code regarding dependencies, and I’m not sure where it will fit. The release notes is where I would be putting information about the versions it’s been tested on or if you need to check you have the right modules or skinobjects installed.

As stated already, the licensing text, if activated, would mean you can’t install this skin unless you agree to the terms and conditions of the license.



Once the skin is installed, clicking the blue pencil on left takes you to this section here – where further information about the skin is available.
Clicking on the ‘manage skins’ takes you to the original page for parsing, using the skin editor and previewing skins.

This is an example of a module that has the licensing completed – so at a snapshot you can see an excellent overview of the whole install.

Interestingly enough – I couldn’t find out how to assign a skin to a portal, so I am wondering now if the skins are all to be installed via _default.
I installed a skin, as HOST under the Admin/Extensions/ skin section, and this it how it rendered in the picture below, but I was unable to see it in the FileManager location, even after synchronising and clearing the cache. So unless I’m missing something, they do appear to be all listed under host.
I went looking for check boxes and pages that might help me.
In the Admin/site settings, where you once could upload a skin, as host, to that portal, that option is no longer visible.
In the Host/Settings, where you can upload a skin, clicking that link takes you to the legacy pages only, so I’m thinking there is still work to be done in this area.

To successfully install a new skin using the ‘dnn 5′ method – you will need to ensure you have all the files that make up package, or at the very least the .DNN file which is displayed here in this image, which comprises of the dnn file, the release notes and license files to be within the skin folder.

You can’t just change the name of the skin file now – you have to open the dnn file that resides in the folder and make changes to it – which I found out after a few change/upload/redo sessions. It does seem pretty logical and it’s a positive step foward to making DNN consistent in how you manage files – whether they be skinobjects, modules or skins.
The DNN file to date – (and it may change because it’s in beta mode still) contains information that is displayed as part of the installation process where a skinning person can display important information about the skin.
Here are some of the key elements I noted
Vendors Section
Package Name – That is the name of the Zip File from my understanding (now remember this is just first instance assumption here, so I’m not saying it’s gospel ok.
Friendly Name – That appears to be the name that is in the ‘Skins’ window under Host, and most likely in the Extensions/skins area
Description – Gives you an option to tell more about the skin
Dependencies – I noticed only one Dependent tag – I would assume this could allow you to disclose what menus or perhaps something non core?? Just a guess here, but it could appear to be the right place to put this – considering alot of skins use third party menus – eg.. I rarely use anything but the Snapsis Menu these days – much faster, lighter, SEO friendly and accurate.
Components
Skin files – This section relates to the skin files directly – pretty obvoious I know – but here’s how I’ve seen it work.
Skin File Name – that is the name that appears in the skin selection option. Why so many choices I’m not sure. I would think that for those skinning specialist who bother to take the time to think out their skin layouts and packaging, it will work well. Unfortunately, I find that alot of skins we buy off the shelf are lazily packaged. Just turn them out for a quick dollar and make the end work to install skin pacakge after skin package and containers that don’t match up name wise. Ok that’s nit picking, but hey – it’s my blog and my opinion. I would like ot investigate the structure further, since I’ve always been an advocate of following the system of packaging as per the original documentation back in the olden days – and I am under the impression that this just adds further polish the process.
Skin File – From my understanding here, it’s a list of the files that actually make up the skin pacakge, including the images, file names, css and xml files. I would assume (correctly I hope) that if you had js files or swf files then they would also be listed here too.
It goes through the process and allows you specify the thumbnail name (which at the moment is generated automatically when you upload a file with a filename.jpg file. So now you could specify a different image for thumbnail and for full image. This is a really good idea – I remember back in… 2004 I think, I can’t remember, perhaps 2005 that I requested that a .gif file or another extension apart from .jpg be allowed for the skin previews because I was able to cut the size of the package down tremendously by using .gifs, however, that function wasn’t available.
So 3 – 4 years later, my little wish might actually be possible. That to me is a real plus – and surely should give every skinning professional the ability to package their skins correctly and optimised in size for display. I like the idea of the two file options. It does make for a little bit more work, but from the user perspective, it’s going to be a nice way to display information.
In this default skin package, that was all the xml parameters I found. I’m sure there may be a few more that come to light as time progresses, but as a first snapshot of the strucure of the files, it’s really a positive move to see skins and their role fall in line with the module developers.
In fact, it’s great to see so much work behind the scenes for the administrator.
In summary -
I’ve not been able to test the skinning functionality for the simple reason of not being able to display any new pages. However, I was able to add in the the necessary files into a DNN-GRAY skin and upload successfully and I called NinaTest, so I get the idea on how it’s meant to work.
I may convert some of my dnn skins to test on dnnbeta but at this stage, I’m feeling that there isn’t a whole lot more I can do apart from test modules, until another release comes out where I can actually create sub pages. There are quite a few broken elements in the build at the moment, filling up the logs wth many entries, and the scheduler wasn’t working for me to turn these things off, so I will wait until another release, hopefully will get access to another later build and then have another look.
I am hoping there is going to be alot more than I see. From the last talk about this amazing ‘Cambrian’ release, taking us to the next generation of web, at this point, it’s not quite there, however, the uncoupling of the modules seems to be a good step forward from what I have been told and this means that in the next couple of years, we may see some steps forward of integration of the ‘web 2.0′ functionality.
From my perspective, it seems that DNN is going through another major structure, hence the 5.0 naming, but the lack of openness in this ‘open source’ project and the talk of delays end up making the shining star lose it’s lustre and glamour. I certainly hope this is not the case, and that the release will provide the new end user audience.
With close to 70,000 DNN users subscribe on the XD Network, in the very near future XD Design will be sharing some new and exciting announcements and free skins, and I’m still working on the logistics of converting our skins to DNN 5 and getting some more new free skins online in the near future.
So this is it for me until I get another release to work with that will allow me to do a little more. I’ve spent over 20 hours here installing, checking out, reviewing and writing about what I see the DNN 5 release offering. I will go through the site once more and give my summary on whether I think this is a release to get excited about and if it’s really been worth the 8 months of waiting for a beta.
Nina Meiers
I haven’t gone through the DNN 5 beta yet (even though I have a copy), so I cannot speak to your experiences. However, it sounds like this beta is a half step complete from what was discussed in this blog entry on the DNN site.
Hi Will, that build was made available for download for those who have products for sale on Marketplace. Both VS2005 & VS2008 solutions are 4th June, 12.10AM and the DotNetNuke DLL is dated 4th June 12.07AM. Without looking at the actual build number, I cannot give any further details.
I was away in New Zealand so was unable to test any earlier – I came back on 19th June, and upon asking if there was a later version, was told there wasn’t.
I am sure the core team and those closely associated will have their own builds and testing in place. That’s how it normally went when I was in the core team, which I felt was a special sort of madness delivering solutions on betas.
Nina Meiers
Thanks for looking into this Beta Nina. I share similar concerns about the openness of the DNN project, and would love more useful information on the "upcoming" 5.0 release.
Cheers.
I also share the same concerns. Maybe it’s time for a fork or two?
Well, I do have a fully compiled version of DNN – built by John Mitchell but not released yet – it’s a corker… fast, slick, only a few dlls in the build, and we run all modules in there except the non compiled ones – - they have to be compiled separately.
I call it DNN on STERIODS – it has less calls back to db – it really is a nice slick build. I just upgraded a site to 4.8.3 and the upgrade files were just over 1.5 mb – nothing touched the web.config.
It’s just nice to work with something that is what I feel a commercially suitable application, ideal for hosting and somewhat optimised already out of the box.