Another step toward 3.xx -- 2.47

[The Editor]

I have been able to successfully rework the skin and hg issues without
too much difficulty--at least to my satisfatcion. It was a difficult
compromise between simplicity and flexibility, but I feel good about
the end result.

First I created a much simplified BOLTgetlink function which takes a
"$start, $last" parameter (as well as less often used $myArray and
$path) and use this for skins, styles, and zones. The process it looks
for is this:

page: alpha,beta,gamma

start.alpha.beta.gamma.last.skinname
start.alpha.beta.last.skinname
start.alpha.last.skinname
start.last.skinname
start.alpha.beta.gamma.last
start.alpha.beta.last
start.alpha.last
start.last

For a skin, start and last would be code and skin. On a style code and
style. On a zone, like side it would be '' and side. This allows you
to set up custom skin zones this way:

alpha.beta.gamma.side.skinname

This may not seem quite so logical (I very much appreciated Marcos for
helping me to think this through, even if it ended up a different
conclusion), but it should be consistent as virtually everything
hierarchical runs this routine. To get a list of skin pages available,
just do:

[(search type=skinname)] and it should pull everything up, whether
skin,style,zone, or template.

If someone wanted to modify how the getlink function works, there is
also now a hook in the core for a myBOLTgetlink() function which can
be fairly easily modified from the core to some different order of
search.

Templates remain unchange. Just for the documentation here is how
templates are currently searched (and fmt's by the way):

1) if an action page, it looks on the action paqe for #template
2) it looks on the current page for #template
3) it looks for template.templatename.skinname
4) it looks for template.templatename

There is no hierarchical activity in templates/fmts. And currenty
there is no hook in the core for an alternate template selection
routine, but the latter could be easily added if desired. Just make
the request.

Simultaneously, I changed how skins are installed. When your skin is
set to say "black", BoltWire checks to make sure code.skin.black
exists in the wiki. If not found it goes to farm/skins/black and
copies over every page in the folder automatically, except those
ending in extensions: html, css, jpg, gif, png, db, htaccess, & txt.
This list is hardcoded currently, but could be made configurable. You
do not need any install list. To upgrade a skin, you simply delete
code.skin.black, and all skin pages are overwritten. Existing files
are overwritten without warning, so be careful with this upgrade
process. And you definitely want to check out your skins first to see
if it might overwrite any existing files you are concerned about.

Well, it's simple, fast, and the code is clean and much improved.
Marcos, if you want me to customize the getlink script for you, let me
know and I can do it. I think for most of the rest of us (unless you
are using zone.skin* pages) we should not notice any change with this
release. And you now have the advantage of hierarchical custom skin
and style pages, which is new. And best of all, everything is
consistent.

Another big step on the road to 3.xx.

Cheers,
Dan

P.S. I decided against changing the skin installation routine because
this current approach makes it very easy to work with skins. Just one
zip and you're done. And it keeps all your graphics, html, css, etc,
all together. Let me know if you notice any problems with the new
changes...

[jacmgr]

Dan that sounds great and very useful and consistent for the skins and
zones.

As for templates,

>
> There is no hierarchical activity in templates/fmts. And currenty
> there is no hook in the core for an alternate template selection
> routine, but the latter could be easily added if desired. Just make
> the request.
>

I think that it is good as is, except the docs on
http://www.boltwire.com/index.php?p=docs.concepts.search about
templating suggest:

"BoltWire will first look for a page of the format:
template.yourvalue, and use it for the template. If not found, it will
look for the exact page entered, and use it as the template. Finally,
if no template is defined, or the template is not found, the default
breadcrumb template will be used."

Maybe I misunderstand the sentence above, bit I assumed that if i put
in template='anyname-i-want' that the core would use the file I
specified regardless of its nameing convention (i.e. the word
'template' not in the name)? Anyway, that didn't work for me. I
would like to use it for this reason: Supose I have all pages of
'dogs.*' in a folder under pages then i could also put its templates
in the same folder instead of in the top pages folder. Right now it
seems all templates must be in the top folder. If the feature above
worked, then I could just name them dogs.template.breeds or actually
anything I wanted as long as i put the correct filename in the search
command.

This also allows me to zip up the dogs folder and everything related
to it (pages/templates,etc...) goes with it to another farm.

So as long as i could enter dogs.anyname-i-want and have bw find it in
the proper folder (dogs), then no heirarchical ability is no problem
for me.

[Marcos Cruz]

El/Je/On 2009-02-15 09:12, The Editor escribió / skribis / wrote :

> page: alpha,beta,gamma
>
> start.alpha.beta.gamma.last.skinname
> start.alpha.beta.last.skinname
> start.alpha.last.skinname
> start.last.skinname
> start.alpha.beta.gamma.last
> start.alpha.beta.last
> start.alpha.last
> start.last
>
> For a skin, start and last would be code and skin. On a style code and
> style. On a zone, like side it would be '' and side. This allows you
> to set up custom skin zones this way:
>
> alpha.beta.gamma.side.skinname
>
> This may not seem quite so logical (I very much appreciated Marcos for
> helping me to think this through, even if it ended up a different
> conclusion), but it should be consistent as virtually everything
> hierarchical runs this routine. To get a list of skin pages available,

I think this approach is original and effective, congrats!

Cheers,
Marcos

--
http://alinome.net

[blues]

hello Dan.
i just updated to 2.47 from 2.45.
some actions stopped working, like: edit, copy, create.
just a white page when invoking such actions.
i just updated the barn, and i haven't personalized those
actions in my field.
am i the only one?

blues

[The Editor]

Blues, I have tried this on Windows and Linux, with UTFpages on and
off, and no problem with any of these actions. Sorry I can't seem to
replicate this... Anyone else NOT notice the problem?

Is the problem when you actually execute the action form, or when you
load up the page with the action form on it?

Do you have any special index.php or config.php setting that might be
a factor? Plugins? Does your skin handle actions in any special
ways? If you want to send me any of these files off line to look at
I'll be happy to... Sorry for the problem. No clue what is going
wrong... Have you been able to downgrade and get your site working,
or was it a test site (where I could see a url). I'd like to help you
get going again, quick.

Cheers,
Dan

P.S. Do you have $errorReporting = true; in index.php? It might shed
some light, though I doubt it. Also, you might try a second download.
Every once in a while they seem to get a bit scrambled in the
download...

[blues]

On Feb 16, 6:11 pm, The Editor <edi...@fast.st> wrote:
> Do you have any special index.php or config.php setting that might be
> a factor?  Plugins?

this is it. disabling the gui plugin the site works perfectly again.
by the way, if you go on the boltwire site at the gui plugin page
(http://www.boltwire.com/index.php?p=solutions.javascript.gui),
the same problem appears :)
so i am not the only one after all. :)

thank you very much for your help, hope it will get fixed soon.

blues

[The Editor]

Change line 8 of gui.php from BOLTskinvars to BOLTsnippets. Should
work fine with that change.

I'll post the upgrade to the server.

Cheers,
Dan