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 schrieb am Freitag, 24. Juli 2020 um 19:47:33 UTC+2:
> 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?
>
>
> On Wed, Jul 22, 2020 at 3:14 PM mz <tcc.p...@gmail.com> wrote:
>
>> 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 schrieb am Mittwoch, 22. Juli 2020 um 18:23:45 UTC+2:
>>
>>> 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
>>>
>>> On Wed, Jul 22, 2020 at 10:00 AM mz <tcc.p...@gmail.com> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>> <https://groups.google.com/d/msgid/boltwire/18e293a3-eea7-4f5c-8e3b-4ff5991d4793n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>> 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/c64e34fd-43c9-4070-bd8a-6ef6edcd175dn%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/boltwire/c64e34fd-43c9-4070-bd8a-6ef6edcd175dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/boltwire/2f6dd1a0-e12d-473d-80a9-d8cfbbdb0a3fn%40googlegroups.com.
