How to create multiple containers?


Author Message
Craig

Posted: 3/18/2010
Quote message 

I've read on here that you can get round Artisteer's limitation on containers (ie, the fact that you only get two) by exporting multiple versions of the skin. OK, I can grasp that in principle, but I need some help with the specifics.

I am presuming that once I have created a second version of my skin, I can take the two new containers (ie, Article and Block) and add them into the Containers folder of my original version. I guess I will have to rename some files (eg, Article1, Article2 etc) so I don't have files of the same name.

So my question is simple: Is that all there is to it? I just add the new ascx files to my Containers folder and rename them? Nothing more needed? Or is it actually not that simple..?

I'm still pretty new to DNN and I'm brand new to Artisteer, so thanks for helping the newbie with a dumb question. ;o)
 
Brian

Posted: 3/18/2010
Quote message 

Unfortunately, this is not as simple as a rename-copy-paste operations. It can be done but there are many things to keep in mind plan to make this work without brain damage. The key is planning and prioritizing.

Artisteer uses the same names for all images used in a skin. You may not be using every variable, but if you do use it across skins, containers, etc. they all have the same name so you need to account for that. For instance; blockA and blockB will both have a background image. BlockA’s background image would be replaced by your second unless renamed. If you rename it you will have to change the image reference in the blockB.ascx and additionally in the style.css, which will need an entry for the new block. In order for the block to be used once you install the skin, you will also have to add the block, its images, and anything else to the Skins .dnn file. This file is nothing more than a very thorough XML file.

Please keep in mind, this is not an exact science. I suppose you could also just build 2 or more skins, install them all and then mix and match containers (blocks) from each. That might be the easiest option.

I hope this helps…

 
Dan

Posted: 3/19/2010
Quote message 

I have not tried this but I think this would work.

Make 2, 3 or more skin packages and install and use them as needed. Rename them as needed of course. If you have a site with many pages and you use a default skin/container, this could make global changes a problem since you will need to manually designate the skin/container that is not the default.

I hope that makes sense.

I frequently change the skin on my site. This is very easy since I use defaults. I simply upload a skin change as the same skin/container name and it overwrites the previous instance.


 
Craig

Posted: 3/20/2010
Quote message 

Quote Brian:

I suppose you could also just build 2 or more skins, install them all and then mix and match containers (blocks) from each.


This seems to be what Dan is suggesting too? I tried it but it doesn't work. The skins seem to interfere with each other somehow (?) with the result that I can't mix and match the blocks - they always come out the same. I've uploaded five versions with the hope of having five different blocks, but no joy. :(

So am I going to have to deal with all that renaming of ascx, css and dnn files? Or is there something obvious I'm missing..?
 
Craig

Posted: 3/20/2010
Quote message 

OK, here's what I've discovered.

I've uploaded five different versions of my skin, the only difference between the versions being that they have different 'blocks' (containers). I leave the Site Settings container setting as Not Specified.

Then I can specify different versions of my skin for different pages (under Page Settings, obviously) and this gives me different containers on the different pages. I realise now that this is what Dan was saying above.

I have found no way of being able to 'mix and match' the containers from the different versions on the SAME page. If anyone knows how to do that simply, I'd love to know!

Thanks for the replies so far - it's nice to get help. :-)
 
Dan

Posted: 3/20/2010
Quote message 

I don't see why you cannot mix a container from one "skin package" and use it with another.

You should be able to pick any of the container skins. Each of the skin installs should have thier own set of container skin.

Such as:

SkinA
ArticleA
BlockA

SkinB
AtricleB
BlockB

and so on ...

In the settings, you should be able to select the specific container/module skin.

In my example you should be able to select any of the following:

ArticleA
BlockA
ArticleB
ClockB

I will give it a try. There is no reason I can think of where Artisteer would limit which of the container skins is available to use.

Dan


 
Craig

Posted: 3/20/2010
Quote message 

That would be great if you give it a try, Dan. I really appreciate the help!

I have tried, but I can't (to use your examples above) specify that I want to use SkinA, with this module in BlockA, this one in BlockB, and this one in ArticleA.

The mix of A and B doesn't work. What I find is that if I'm using SkinA, I cannot use BlockB. It will actually give me BlockA, even though that's not what I specified.
 
Dan

Posted: 3/20/2010
Quote message 

Everything works as I expect it to, Alternate module skins are available globally.

Send me an email: dws at twinsburg dot com if you need some screen shots.

Thanks, Dan
 
Craig

Posted: 3/21/2010
Quote message 

Thanks, Dan, for taking the time to look at this. I really appreciate the help. But it ain't working like that for me.

If I have the page set to SkinA, even if I specify BlockB for a container it actually gives me BlockA. Then if I change the page settings to SkinC, it automatically changes the containers to BlockC. Very frustrating.

If I leave the Page Settings skin as Not Specified, it relies on the overall Site Settings, but with the same result. I always get the Block that goes with the skin specified under the settings. :(

I can't figure out why I'm having trouble with this and you find it works perfectly... I'll just go and bang head against a wall for a few minutes and then try again...
 
dan

Posted: 3/22/2010
Quote message 

I was able to reproduce Craig's situation.

DNN 4.9 skins installed under host cannot use containers from other skin packages.

If installed under admin, containers from other packages can be used.

It seems line the host installs want to only use containers from the same skin package.
 
Jeff

Posted: 11/24/2010
Quote message 

Quote Peter:

As admin cant anly longer install skins in V5 (I think) the work around of using the admin account can no longer be done.


But a host account can install skins at the admin level. These are limitations of DNN, not Artisteer or Artisteer skins. Might want to bring them up in the DNN forums.

Jeff

 
Peter

Posted: 11/25/2010
Quote message 

Thanks Jeff

"But a host account can install skins at the admin level"
Can you say how this works in 5.5? Every permutation ive tried doesnt achieve it so far.

I agree that host/admin is a dnn limitation;
but only two containers per skin; or all skins have the same named containers that cant be mixed, is still an Artisteer limitation is it not?


 
pat

Posted: 11/25/2010
Quote message 

Yes.. slight problem.. Host is the only way to install skins from the module definitions... however dnn5.5 does support 'versions'. So saving the skin as a different version should work.

Also try ticking the 'host' radio button in the settings area. This will give you access to all the skins and containers. Yous hould then be able to choose the one you want.

Hope that helps
 
Pat

Posted: 12/18/2010
Quote message 

I have had this issue as well.. wanting to use different containers.. so I also did 5 versions of the skin, each with different containers.

What we found with dnn5 is that there is an issue if you want to use a different container to the default skin on a page (if you have multiple skins)... it simply won't let you. We are not 100% sure if there isnt something in DNN5 or the artisteer css which causes this.

A part solution to this is to select a different skin for the page you want a different article colour on, but you are then stuck with the block / article that comes with that page.

Dnn5 does not want to let you pick an alternative skin. This issue was never a problem with dnn4.

All the container options are visible but it seems you can only use the one associated with that pages skin.
 
Dennis

Posted: 1/7/2011
Quote message 

These posts are baffling, not to mention, so are some of the issues everyone faces with regards to DNN and Artisteer. Let me provide some research I have done as well as my own skin development.

First - Artisteer Architecture:

Artisteer does a terrific job in allowing all of us to build very nice looking skins for DNN and easily export them without any regard or knowledge for how and why the skins and containers work. However, as with most things in life when we are not familiar with how the engine works we cannot diagnose what is wrong when it breaks.

Artisteer utilizes a single CSS file to manage all aspect of the skin that is created. However, in doing so they also include the CSS for the Articles and Blocks which in DNN these are all considered Containers. As one post early mentioned, Artisteer gives you little control over the naming convention. Why is this a problem?

When Artisteer exports the skins it utilizes a templated naming system. Meaning, each file and CSS is always named the same. So if I create a skin called, "Test" and another called "Test2", if I were to look at the CSS and files exported I would find the naming conventions within the CSS the same even though the skin is being called Test and Test2.

Example:

.art-block
.art-article

Both of these are class styles from the a typical stylesheet created by Artisteer. These class styles are embedded in the style.css file which gets created by Artisteer. So now the fun begins :-)

Because these stylesheets are loaded based on the skin you choose for the page they are not specific to the container that you choose for any DNN module. So what does this mean. Let's say we choose 'Test' as the skin we are going to use for our home page. When that page is loaded it loads the CSS associated with the 'Test' skin. However, let's assume we want to use the 'Test2' block on our home page. This is where the problem happens. Because the block does not have its own specific CSS file it is pulling from the CSS of the main Skin 'Test'.

Is this beginning to make sense?

Therefore, you think you are choosing the block 'Test2', and indeed you are, however, the graphics associated with 'Test2' will not appear because the graphics, colors and other features are associated with the skin 'Test2'. Therefore, because 'Test' is your default skin for the page you will see the resulting images, colors, and layout for 'Test'.

I know this is confusing but if you read it a couple times it will make sense.

Second - The Fix for Artisteer

Artisteer needs to fix some of the architecture to allow all of us to easily pull this off without retooling and intervention.

What needs to happen?

Artisteer would need to export each skin with the name of the skin embedded into each class style in the CSS. For example something like:

.art-block-Test
.art-article-Test

It also needs to create a CSS file specific to the Article as well as the Block when they are exported. This means there would need to be a file called Test.Article.css, Test.Block.css, Test2.Article and Test2.Block.css.

This means with each skin created there would be three CSS files in the export. 1. skin.css 2. article-{name of skin}.css 3. block-{name of skin}.css

This would solve the issue for everyone because then you could choose any block or any article and it would appear properly because its corresponding CSS file would be loaded when the page loads.

This type of functionality would be useful for so many users. However, I am not familiar with the applications such as Drupal or Joomla so I do not know how this architecture change would affect those skins needed for the other CMS programs.

Third - The Nightmare Workaround

So based on everything I explained you need to dissect the current skin.css file and extract out of it each piece of data. This means you have to separate the:

skin classes
article classes
block classes

Then you have to create a css for each of these. You then need to include the css file in the ascx page of each of three aforementioned areas. You have to rename each of the classes within the css file to a unique name as mentioned early in this post. You then need to make sure those name changes occur in each of the three ascx pages in the cssClass for each element on the page. If you fail to make the naming change then you will have a container with missing pictures.

This is really a complicated process and one that requires the utmost care and attention to detail. If anyone in this community has an easier method I would be interested in hearing your ideas.

All this being said Artisteer is still the leading product for creating quick skins that look terrific. I just wish they would figure out an easy solution to allow user (all of us) to export multiple containers. They could do this through allowing a user to export only an article or block and have the program create the proper naming conventions within the export.
 
Peter

Posted: 1/11/2011
Quote message 

Many thanks for the very useful clarifications & summary Dennis. I think I need to revise and improve on my rudimentary DNN skinning skills. (But I thought id overcome this by purchasing Artisteer :-) , before hitting this limitation:-/)

I do agree that Artisteer it is still a tremendous product, and the addition of better multi (>2) container ability would enhance it so much, for DNN anyway and increase its take-up im sure

Is anyone from Artisteer looking at this anymore? Some older posts suggested it was on the roadmap for development. Is it still on the roadmap? The news about v3 mentions joomla and particularly drupal enhancemnents, but no mention of DNN specifically.

I originally contacted support directly & got a reply saying effectively "thats how Artisteer works". Its hard to tell from the posts which replies are from users and which (if any) from support / development so if anyone from Artisteer could comment that would be much appreciated. Thanks.
 
OOKIE

Posted: 1/14/2011
Quote message 

I am running into the same issue. In older versions of DNN, we were able to upload containers, and skins separately, and I believe you still can. But with Artisteer, if you upload a skin the older containers will not function correctly with an exported skin. I do agree that this is an amazing product and agree with Peter about providing more flexibility for DNN developers when it comes to containers. But for sure, block, article should be exported as separate entities for easier modification, or have greater control in Artisteer for these items.
 
Steven Webster

Posted: 1/17/2011
Quote message 

Dennis really documented the issue with blocks and articles as "containers" on DNN well. Keep in mind that when you install the containers and skin as a package, they are indeed seperate entities.

If you install under the HOST menu you can look in the portals/_default\containers/yourskinname and see the files block.ascx and article.ascx. These will be available to all portals on that installation...but since the CSS lives on the skin if you use these containers on another skin they wont look correct. (no css classes found)

If you install under the Admin menu then they will be in your specific portal (and only accessible to that portal) somewhere like this: portals/0/containers/yourskinname. Again, these are meant to work only with the corresponding Artisteer skin.

I agree that the "correct" way to handle this would be to:

1. Allow designers to specify more than one block/article, etc. with names that make sense.
2. Extract the CSS references from the skin style.css into each container folder
3. Allow for CSS prefix control (in 3.0 beta)

I have been able to go into each block or article file, copy them, make some changes, rename them and use them within the site. Simple changes like Article-No Title as an example.
 
Peter

Posted: 1/27/2011
Quote message 

In a technical support reply Ive been told that the developers will consider the muti containers for future. Here's hoping!

I cant see how to install skins under admin in 5.x. Ability Seems to have gone after V4?

Steven - When you say

"I have been able to go into each block or article file, copy them, make some changes, rename them and use them within the site. Simple changes like Article-No Title as an example."

Sounds worth a shot. Would it be possible to be more explicit as to the necessary steps. Or could you provide a before and after examples that can be compared ?

Many thanks
 
Steven Webster

Posted: 2/2/2011
Quote message 

Peter,
Skins are installed in 5.x under the Admin Extensions menu (this is part of DNN's larger move to treating everything, skins, modules, objects, providers as extensions).

A simple example would be to install your Artisteer skin package on the portal. Then navigate to the containers/myskinname folder on your portal and make a copy of the Articles.ascx file. Rename it something like Articles-NoTitle.ascx.

Then using notepad or an editor (I use Visual Studio) make some changes to the container. In this case I want to remove the container title so I remove the container title skin object between the H2 tags (I remove these tags too). Additionally, I usually set the shor print icon settings to false in the footer.

Then save your work. Now when you go into the settings for a module you will have a new option called Article-NoTitle

You can get far more complex with these changes...but they work well.

Again, just remember that the CSS lives in the style.css for the skin and not in the container folder.
 
_Villamizar_

Posted: 2/2/2011
Quote message 

Is it psible to create a social network with aristeer?
 
Peter

Posted: 2/4/2011
Quote message 

Steven:
Many thanks for the guidance - I shall give it a shot. If any further useful info arises from the experience Ill report back here.


 
Pat

Posted: 4/5/2011
Quote message 

Dennis.. great post!!!

Artisteer is a great tool. There are limitations but hopefully the development team will add in the extra functionality we are all after.