> > According to official site it says that admins are editors, editors
> > are members, and members are guests.
> > So I think this would be more resonable.
>
> I had gone ahead and made the change, but then decided against it
> because of this ambiguity. And also because it is so easy to add this
> line to a config file if desired. I wonder if we shouldn't make the
> groups that can create form configurable, so we could give admins a
> bit more flexibility... Perhaps via a config file only, to avoid
> opening security holes though site.config... Just an idea.
>
It would be a good idea to make form creating configurable.
But so far we can still erase all @editor in auth files so that
@editor only grants form creating permission, and the user could still
manage the realistic auth by making other groups. So I still think
@admin, @editor, @member, @guest hierarchy reasonable, and we could
maybe later make some change in special feature for @admins just like
form creation permission.
>
> > BOLTcodePageGroup is a function I added to engine.php, to unify and
> > simplify all likely things
>
> > function BOLTcodePageGroup($page, $type='MAIN') {
> > ## RETURNS WHETHER A PAGE BELONGS TO CODE PAGE GROUP, WHICH MEANS THAT
> > IT IS DISPLAYED IN CODE BOX
> > return (BOLTpageCheck(BOLTconfig('BOLTcodePages',
> > 'code').'*,'.BOLTconfig('BOLTtemplatePages', 'template').'*',$page)
> > && ! BOLTpageCheck(BOLTconfig('BOLTcodePagesExclude',
> > 'code,code.embed,template'),$page));
> > }
>
> I'm not sure I want to go this route. I'll file the idea around, but I
> think making this configurable this way could introduce security
> issues if you have an unwise administrator. I'll file the idea away
> and if a convincing case can be made for this, I'll be happy to add
> it.
Actually I don't like the fact that code, code.embed, and template
pages under "code" hierarchy (I mean, displayed in a source box) but
not so. I just like programs to be well-modalized. To better manage
them I create this function; or I'd prefer to make those pages not
exceptions.
So far it is used here and another place is BOLTgetzones making "code"
pages:
old:
if (substr($link, 0, strpos($link, ".")) == $BOLTcodePages || substr
($link, 0, strpos($link, ".")) == $BOLTtemplatePages ) {
if ($link != 'code.embed') $out = "<div class=code>\n" .
BOLTcharEncode(htmlspecialchars($out, ENT_NOQUOTES), 'lines') . "\n</
div>";
}
new:
if (BOLTcodePageGroup($link)) {
$out = "<div class=code>\n" .
BOLTcharEncode(htmlspecialchars($out,
ENT_NOQUOTES), 'lines') . "\n</div>";
}
>
> >> > 19.Modified "action.data" so that it works correctly. Interestingly,
> >> > in the old version fieldname were mismatched, however it still worked
> >> > in v3.3.1 and earlier.
>
> The list function performs several important functions--it is probably
> better to keep it. I don't think I'll go back to worry about 3.3.2 if
> it is working now. Perhaps some change you made to your version might
> have impacted it inadvertantly.
Oops, maybe I just missed something but I did not work in pure v3.3.2.
Anyway I tested again in v3.3.3 it did work, so it may be OK to keep
it.
>
> I wonder if it wouldn't be helpful to simply remove all the defaults
> from the core php code and force it them all to go into the
> site.messages(.language) page. It should shorten the code a bit, and
> force me to keep things current. As it is, it is simply too convenient
> to add a message here and there and forget to add it to the
> site.messages page. As you can see, this has happened often. :) It
> would take some cleaning up, but in the long run it should be a
> worthwhile investment of time. What do you think?
Yes, I did and do think we should do something to collect all configs,
messages, languages, and maybe other system params in clear lists at
specific initial routine block instead of putting them here and there.
For configs, I think we could make another function like BOLTsetConfig
which takes a string in the identical pattern and sets the config
array (also modify the config init part) so that users wouldn't get
troubles by directly setting config array and get problems by adding
"BOLT" or not using lowercase as the index name. And we can then put
default config values alltogether in init routine instead of making
them everywhere.
We could still keep BOLTconfig as current so we can still set a
default value for some special functions seperately, and also to get
backward compatibility for old plugins. Also, I don't think that we
really need config name started with "BOLT". what about allowing no
"BOLT"?
For messages, I wonder if we need site.messages actually? It seems
that we are messed since site.messages and site.languages could both
affect the message output.
Would it be better to define all system messages directly in an array
variable in the core, and make site.language the only way to modify
message output? (A problem is that if language is configured to be
default the site.language is ignored. But we can simply add a
"site.language.en" and put only system messages and the "translation"
in it if we do need to change the messages in English.)
>
> >> > 21.Fixed several typos and nonsense or missense lines seen anywhere.
> > old: if ((!isset($BOLTarray['nextpage'])) || ($BOLTarray['nextpage']
> > == '')) $BOLTarray['nextpage'] = $pageLink;
> > new: if (empty($BOLTarray['nextpage'])) $BOLTarray['nextpage'] =
> > $pageLink;
>
> Cool. That's a new command for me... :)
empty() is useful in many places. Maybe we would find more places
which using it is better in the future:)
> > It was my fault now noticing "editlines" param in Xedit and Xcreate,
> > so just ignore it.
> > But I don't think the transforming \n to linebreak is necessary since
> > someone could simply type an "enter" to do equal thing. Even it's
> > configurable, I'd prefer the default is not doing it (maybe modify
> > action.edit, aciton.create, and action.copy?).
>
> Many times it is convenient to insert a line break into a form session
> value, something like this:
>
> [text name]
> [text email]
> [box contents][box]
> [session body "Name: {=name}\nEmail: {=email}\n\n{=contents}..."]
>
> That's the purpose. We may change this in the future to only make it
> happen for session inputs, and never normal html inputs.
Well.. We probably put it at the wrong place, because putting it in
Xedit just make inputing:
[session body "Name: {=name}\nEmail: {=email}\n\n{=contents}..."]
actually same as the following:
[session body "Name: {=name}
Email: {=email}
{=contents}..."]
>
> > I'm lasy so just point out. The most significant is that ^footnote is
> > no longer available.
>
> That's odd. I don't see that on site.help. Maybe I'm missing it...
>
> > Others I'll report if I have time....
>
> That's kind of how open source advances. A little bit at a time, as we
> find time. :)
woops, it disappeared in v3.3.3, maybe it's my fault...
Maybe we could add more markups like /= =/, /* */, <box>, <code>,
<markup>, <html>, ` or so... I recalled that when I first touch
BoltWire I don't know there are so many useful markups that I can use
in the help file.
> >> > 2) When saving data via a form, the system does not properly check
> >> > auth.data
>
> >> In my test this seems to work either way. If I am mistaken, send me an
> >> offlist email with more specifics.
>
> > No it doesn't. It doesn't check write auth at all so anyone can write
> > data to anywhere. In BOLTauth:
>
> > old:
> > if (strpos($line, ": ") === false) continue;
> > $f = substr($line, 0, strpos($line, ": "));
> > $f = str_replace('{id}', $BOLTid, $f);
> > $v = trim(substr($line, strpos($line, ": ") + 1));
>
> > new:
> > $pos = strpos($line, ": ");
> > if ($pos === false) continue;
> > $f = substr($line, 0, $pos);
> > $v = trim(substr($line, $pos + 2));
>
> > The keypoint is "1" to "2", others are just some optomization.
>
> I think it does work. The trim clears out the extra space at the
> beginning just fine. But it is changed to 2 now, as that is more
> precise.
Oops...I must be giddy. What we really need to fix is the following
block from 1 to 2:
if ($type == 'data') {
$page = substr($check, 0, strpos($check, ":"));
$check = substr($check, strlen($page) + 1);
}
>
> >> > However I still think it's not good to write it this way, which may
> >> > lock the superadmin himself.
>
> >> Good point. Seems the easiest way is to wrap the whole little routine in
> >> if (BOLTingroup('admin') === false) { }
>
> > No it wouldn't work. Because login page will be locked.
>
> To login, you just use &action=login
I am sure we can't because we are not considered @admin before logging
in. I did a test in v3.3.3 and it proved.
And what I meant to is to permit only superadmins instead of @admin
but it's OK if you think so.
>
> >> > 10.Fixed a mistake of 3.3.2f while parsing [messages] before getting
> >> > zones so that function messages are not showed.
>
> It seems function messages work in the main BoltWire core. I am not in
> any way planning to move messages from BOLTmakepage to BOLTdomarkup.
> I've tried both ways more than once--but to get a full system wide
> return of all messages from all zones, it cannot be done in
> BOLTdomarkup. So I really think it needs to stay where it is.
Yes we can and it's tried and proven. In my process we first replace
[messages] in BOLTdomarkup to <div class="message" /> and make a total
replacement again after doing markup.
It's a little complicated but the benefit is to reduce the hardcodes
and to increase the freedom for users to further manage the markup
rules. And in any point <div class="message" /> is a string that
cannot be input in anyway so it would never mass up any markup rule
except the one which means to create a message block. Also it won't
make /= [messages] =/ or something like that work. Same for [results].
--
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.
