On Fri, Sep 18, 2009 at 3:09 PM, DrunkenMonk <[email protected]> wrote:
>
>
>> * Upgraded to our (experimental) skin, sweet as pi. (Version 3.14, get it?).
>
> I had some small problems with this, caused by conflicting
> code.snippet and code.style pages. If anyone else has problems, I
> recommend checking for those pages and renaming them as backups.

Anything I can fix? Or did you just not have a field style page?  Most
people shouldn't have problems upgrading unless they are relying on
the core code.style page. One fix is to quickly open and save that
page before upgrading. Same with code.skin. That way nothing is lost.

We will have possible problems if we have several skins hooking into
these variables. You might have it set to some wild color scheme,
install a different skin, and boom you got weird output. Unless you
create a code.snippets.myskin page. But then you can't use
action.skin, unless you rewrite it also. It's a bit tricky, but we'll
work our way through it...

>> * Added a skin action to allow easy modifications to core skin.
>
> I like. I managed to find a nice white on black combination thats easy
> on the eyes.
> You missed highlight_color.

There's accent_color, but we could add more. I just found these four
to cover most of the stuff in the skin.  In fact, all the colors used
in the skin.

>> * Added a {superadmin} var to identify superadmin(s). Used on home
>> page to help get you started.
>
> This is nice. I would like to take the opportunity to request a "use
> superadmin powers: []" toggle. This in order to be able to check auths
> quickly without installing a second browser. I currently spend a lot
> of time logging in and out to fix problems. I'm thinking the best way
> would be a hook before checking if one is in the superadmin group in
> checkAuth, with a custom check bypassing checkAuth to see if you are
> permitted to use the toggle itself.
> I'd write a plugin, but I'd have to mess with engine code slightly.

I've been having exactly the same need, though I'm not sure how to do
it. Generally, I open two or three browsers. I'm thinking of some kind
of preprocessing hook or something that allows a super admin to add
login=someid to the url of any page and have it temporarily give you
the permissions of the id. But it won't work right on form
submissions, because technically they are processed as part of the
next page. And the login get var won't be in the url. Perhaps there's
some other easy way to do it. I dunno.

>> * Also, did some work improving connections between functions and
>> system messaging (through comm2func).
>
> Yaay! Explain! I think I've been missing that.

Just that sometimes when a form called a function through comm2func
the output/warning messages didn't get sent back to the form messaging
system. I noticed this when tinkering with the email function. Though
it was working partially before, now I think it will get those
messages back more consistently.

>> * Escaped snippets in the form of $$page:mypage to prevent a strange
>> glitch in skins.
>
> Oooh! reminds me. How do I get an info variable without processing
> it's markup? My slogan is a [(quote)] command, I whish to be able to
> change it in action.skin

Have you tried doing

slogan: /=something **or** other=/

Not tried. But it should return the text escaped and therefore, the
asterisks rather than bold.

>> At some point we might need to add a getting started page with a few
>> tips on what to do first--but my zip just broke 100k. I love boasting
>> about that, so maybe I need to cut something else out. Ideas?  I hate
>> the inexorableness of feature creep, and I fight it like crazy. On the
>> other hand, it would be great to add a simple getting started tips
>> page, and/or some minimal help information...
>
> It's a good idea. Feature creep is bad, but the reason it's bad is
> mitigated with a good getting-started page.
> Grats on the 100k.

One option is to remove the site.language page from the core. It
serves no userful purpose except as a template for someone wanting to
create their own language file. We might do better to make it part of
a plugin for languages. That should get us under. That, or we could
make the skin action a plugin. But it sure is way fun!

> You could try using a better zip alorythm. You wouldn't affect the
> feature creep, and you wouldn't be able to feel as good about the
> download, so... it wouldn't have any actual positive effect.
> I'm going to write that down as my best suggestion ever.

Yeah, but it would give us bragging rights. Under 100k...   :)

Cheers,
Dan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to