Skin activation

[mz]

Some observations:

Activating a new skin did not work for me even after setting skin.auth credentials and updating site.config. Setting in config.php works.

I found that skin.name.css is not used at all, even if the html file links to this file. style.css which is the third file in the skin folder and linking to it works. Deleting this file I saw that the default style.css is used.

Using {+title+} in the html file will give you the last part of the css file. {+:title+} works perfect, as well as all other data and info vars I tried. Even {+someotherpage::test+}.

The section "inline code" on page docs/concepts/skins suggests that you can use code in your skin files with == some code ==. This does not work or I misunderstood that section.

All in all I am very pleased.

Greetings, Martin

[Dan Vis]

Thanks for the feedback Martin! I'm still trying to get a grip on exactly how to best make these skins work myself!  If you could send me the entry you put in your site.auth.skins page I can see what's going on. Try doing something like *: butterfly and see if that doesn't work. In site.config, you use skinDefault, skinMobile, and skinPrint to change the default for those scenarios when no custom skin is set. Otherwise those are ignored. 

I really like the new site.auth.skins system as I can get very fine tuned in setting skins for different sections of my site. So for example, in my latest skin I have a version of NEO with a side menu and one without. Otherwise identical. So I can define which skin to use on any page or section of my site easily. Seems to be working great.

The code.skin.name.css file may have variables in it like {+text-color+} for example which css can't process if you just link to it. It's pulling the css if you link to it correctly, but css has no idea what to do with those. There's also data fields in some of those files. So here's how to edit the css. Go to site.skins, select the installed skin you want to edit, then click edit css. There's also an option to edit skin settings. This edits the code.skin.name.css page, but also automatically updates the style.css page with the correct values. That gives you the best of both worlds--a cachable external css that you can update at any time. 

Two notes on that last part... You do need to refresh the page to see your changes as the browser can cache it. And if your server caches it, your changes won't be visible either. One work around is to add ?ver=1.1 after the style.css in the link to it in the html file--and then change that number. It's cumbersome but it forces a refresh of the file. Very handy. I'm tempted to automate this process by adding a counter to the css edit page and then dynamically bringing in that by using style.css?ver={+counter+} or something like that. Trivial but time consuming. We'll see if there is demand.

I think the {+title+} works. Is it possible you were on a page that ended in css when you saw that? It should change dynamically with each page you visit.

The inline code was removed some versions ago. Alas, the docs are not updated for version 7 yet!  For now, use the new block markup. It's proving extremely useful and effective. Here are your main options:

 <<text 'some markup'>>  (this is equal to ==some markup==) 

<<function forward some.page>>  (runs some function)

<<markup some.page>>  (same as above actually)

 <<code code.embed.whatever>>  (inserts code from a code page)

<<cache some.page expires-86400>>  (same as markup but caches html for performance)

You can also add conditionals to those lines to control when they are triggered. These only work in skins, but they give you virtually unlimited options for how the skin runs. If you have edit permissions on BoltWire you are welcome to help update the docs on this point...

Cheers,

Dan

--
You received this message because you are subscribed to the Google Groups "BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email to boltwire+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/boltwire/18e293a3-eea7-4f5c-8e3b-4ff5991d4793n%40googlegroups.com.

[mz]

You are right and I was wrong. Sorry!

I did not remember the notation before the colons of the auth files. My last edit was a couple of years ago.

Maybe you put a legend on top of the list to refresh memories. Anyway: *: skinname works perfect.

{+title+} gives me always "css" when <title>{+site+} | {+title+}</title> in two different html files even after switching pages. This is a minor issue when you know you can use {+:title+} without setting any data vars.

Another minor issue in html files:

It can be my installation, but {+somepage::some-info+} works, {+somepage::some.info+} with dot works not. 

<<function info field=some.info page=somepage>> does not help either as long as you keep the dot in the field name . 

Using the function, the page parameter can contain a dot (page=some.page). But not with the short notation:  {+some.page::some-info+} does not work in html files.

Inlining css and javascript is for me the superior solution and I will stick with this as long as I can keep the css under 1000 lines (easy). This is not expensive for mobile users because it is compressed and therefore does not add much to the page weight. I would estimate gzipped inline css and js count up to 20kb if its long - the weight equivalent of a single thumbnail image. More expensive for mobile are the second and third roundtrip to get the css and js files separately. Here are the milliseconds going you like to avoid. On desktop the weight is not a problem at all. 

Inlining is much easier to manage on your (BoltWire) side, too. Maybe you rethink your decision, going for a design switch?

In the past you gave a lot of docs update nuggets in your answers right here.

I suggest that everyone who gets an answer like this copies the relevant part of the text and post these lines with a new common headline like "Docs-Update: docs/concepts/skins".

This would be easy to find.

Greetings, Martin

[Dan Vis]

I think the issue with {+title+} and {+:title+} may be something else. Seems the edit html page is processing those in the edit box, so when your changes get saved it stops being dynamic, if you don't catch it. I thought I had that fixed, but it's a tricky problem. I'll do some more tinkering and make sure it's working properly.

I did test your point about having dots info field names (some.info) and it is not a problem for me using the <<function>> option. But the problem with the {+page::field+} format seems to be the colons break the pattern. It was not really designed for that, but it's an easy fix. Just add a "." to the pattern on engine.php ~line 151. I'll add that to the next release. Don't see any reason to not make that available.

You do make a good point about the css. I read this discussions ( https://stackoverflow.com/questions/8284365/external-css-vs-inline-style-performance-difference ) and while there are pros and cons, it seemed to support your conclusion that small files can be embedded just as easy as doing an external link. It would make things easier for me too. I love the idea of having a single skin html file!

But here's why I'm not sure I want to go to that approach. 1) You can always embed the entire css file in the header of your html file and you don't have to link to an external css file. So you can do what you want no problem. But 2), for those who prefer an external css (I find it easier to maintain) you need a system more like what we have now. In other words, our current system allows both approaches, no problem. And 3) To allow the instant editing of css and even html settings, I need a way to keep a template with the placeholder codes (for colors, etc), which is separate from the css actually used (where the colors are already selected). Now that can be generated dynamically of course, without much trouble, but that adds to the processing time--as the css has to be regenerated each time and then downloaded. 

As it is now, we generate the desired final css, it's get cached online, and then downloaded and cached on the local browser too. So you get time savings on both ends. I think for simple skins it might be worth doing it inline. But to maintain all our options, I think we need a more robust solution.

Just my thinking here... :)

Cheers,

Dan

PS. I love the tip about tagging helpful notes here for inclusion in the docs. Would it be worth it to create a forum section where these things could just be cut and pasted into. Then periodically, I (or someone) could copy those to the appropriate pages. Or for that matter, if there's an existing page, it could just get posted into the comments so it's available right away, and the pages could get updated that way... That would be much easier for me, but maybe too much of a hurdle for others?

To view this discussion on the web visit https://groups.google.com/d/msgid/boltwire/c64e34fd-43c9-4070-bd8a-6ef6edcd175dn%40googlegroups.com.

[mz]

I can volunteer to skim your notes here to see what qualifies for a doc update and will repost the relevant lines. This system here is not the most comfortable, but search works, and it is a fantastic archive.

Just today I looked for the former TOC plugin, found the discussion quickly, from 2009!

Greetings to all BoltWire seniors, Martin

[Dan Vis]

Funny you mention this, I just added an updated toc plugin to the core for a project I'm working on. Much better than before! 

Will be in the next release.

And yes, feel free to point out anything we need to add to the docs. I've been working extensively on that and the comments should finally be working well on all the docs pages. So if you see something, one option is to just dump a cut and past comment on the appropriate page. I'll see it and can add to the main text if desired, or just leave in the comments.

Thanks for all your help Martin!

Dan

Climb higher in your walk with God...

WWW.FASTMISSIONS.COM

To view this discussion on the web visit https://groups.google.com/d/msgid/boltwire/2f6dd1a0-e12d-473d-80a9-d8cfbbdb0a3fn%40googlegroups.com.