The ProcessList method has changed and now it only substitutes the href/url paths in htm and html files, not ascx and css files. Take a look at line 221 of components\Skins\SkinFileProcessor.vb. I compared it to DNN version 2, and sure enough it used to include files with ascx and css extensions.

Does anyone now why it changed? I can probably convert my ascx files to html, but my css files contain a lot of image references. I don't see how I can fix them now. Certainly I don't want to move those styles to the htm files. I'm about ready to just hack the DNN code to get it working, but there must be reason for this, right? Its not a bug is it?

Here's the hack...

	' choose processing based on type of file


	Select Case objSkinFile.FileExtension





                    Case ".htm", ".html"


                        ' replace paths, process control tokens and convert html to ascx format


                        Me.Message += Me.PathFactory.Parse(objSkinFile.Contents, Me.PathFactory.HTMLList, objSkinFile.SkinRootPath, ParseOption)


                        Me.Message += Me.ControlFactory.Parse(objSkinFile.Contents, objSkinFile.Attributes)


                        Me.Message += objSkinFile.PrependASCXDirectives(Me.ControlFactory.Registrations)





                    Case ".ascx"


                        Me.Message += Me.PathFactory.Parse(objSkinFile.Contents, Me.PathFactory.HTMLList, objSkinFile.SkinRootPath, ParseOption)





                    Case ".css"


                        Me.Message += Me.PathFactory.Parse(objSkinFile.Contents, Me.PathFactory.CSSList, objSkinFile.SkinRootPath, ParseOption)





                End Select

But its odd how the CSSList property still exists. It makes me wonder if this code was removed accidentally. Can anyone confirm this is a bug?

I think this thread is interesting for you: view post 858749
I don't think it's a bug, but don't know that much about it...

Don't hack this... its for your benefit if you use it correctly. Here's the reason and the way it works.

~ We used to have a great deal of difficulty with portability of HTML (and some ASCX) skins. People copied them from one portal to another and they woudln't work becasue the image paths contained explicit references (e.g. \Portals\0\Skins\MySkin\Images).

~ The option in the Skins viewer to (re)parse a skin created all kinds of havoc for ASCX skins because the paths were doubled... (e.g. \Portals\0\Skins\MySkin\Images\Portals\0\Skins\MySkin\Images).

~ In 3.0.12, we removed the parsing of the ASCX file in favor of providing a static variable which can be used in your ASCX which will make it portable (<%= SkinPath %>). So now you can just create your ASCX skin as you normally would, and then append this variable to the front of any image path for your package (e.g. src="<%= SkinPath %>Images\myimage.jpg"). The variable will dymanically insert "\Portals\0\Skins\MySkin\" which makes your ASCX skin completely portable.

~ There is only ONE caveat with this. Which is that the variable cannot be used with tags that are also "runat=server". So if you're applying a background to a content pane (for example), this will not work:

<td BACKGROUND="<%= SkinPath %>image.jpg" ID="LeftPane" RUNAT="server" VISIBLE="True"></td>

But this will:

<td BACKGROUND="<%= SkinPath %>image.jpg">
<div id=”LeftPane” runat=”server”></div>
</td>

Alternatively, you can set the background image using CSS.

The ONLY reason pathing used to be used in CSS at all was to preserve it for some older browsers which did not implemente CSS appropriately (e.g. Netscape 4...). But those days are gone. CSS uses paths relative to the location of the CSS file... so this should be as everyone wants it to work. No more path substitutions.

We've been able to apply this successfully to every skin we've encountered. There should be NO reason to hack any code on this as long as you construct your skin with an understanding of the SkinPath variable and how CSS works.

Cheers,
Scott

Thank you Scott. That's what I needed to know.

mrswoop -

Maybe this is something should be included in the skinning documentation? I did not see it there.

Documentation updates are in progress...