On Tue, Jan 5, 2010 at 11:00 AM, Danny <[email protected]> wrote:
> I'm being busy so just reply briefly. Easy things go first, and
> debates go last.
>
>> > 1. Added a line to the initialization routine in engine.php so that
>> > all admins actually have 'editor' membership as official site
>> > mentioned:
>>
>> > if (strpos(",$BOLTmemberships,", ',admin,')) $BOLTmemberships .=
>> > ',editor';
>>
>> This may be a good idea, but I'm not fully convinced it is needed in
>> the core. Superadmins already have super privileges, and there may be
>> times you grant editors different powers from admins. It seems more
>> logical to me to add people individually to the appropriate lists,
>> even if it means adding them to more than one list. It is also easy
>> enough to do this in a config file or a plugin. But if the group feels
>> differently we can change the default behavior to this.
>
> 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.
Perhaps we ought to update the docs? What if for example you want to
generate some kind of output based on your list of editors--using the
group.editor page. Your admins would get left out. That could lead to
confusing results if in some situations they are counted as editors,
and not in others. Rather we should say, in the default setup admins
can do anything editors can do plus more. Something like that.
Hmmm, that's technically what it does say in the
docs.concepts.security page. Maybe it is ok as it is.
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.
>> > 4. Besides 3, added an escape for $myquery so that search results
>> > containing encoded UTF-8 urls are not transferred back to UTF-8,
>> > making a mistake link like <a href="??">??</a>.
>>
>> Can you specify where you put this? Normally that variable is used to
>> carry values from one page to another (via sessions), so they cannot
>> be escaped. Unless you are talking about having them escaped after
>> they are retrieved from the session for the next page. I would think
>> the place is engine.php, lines 178-180, but there is no myquery there,
>> so I'm not sure what you mean...
>
> In BOLTdomarkup:
> $out = str_replace('[results]', $myquery, $out);
> $out = str_replace('[results]', BOLTescape($myquery), $out);
>
> If the value is not escaped, contents containing '%xx' would be
> further changed back to UTF-8.
Ok, thank you!
>> > 10.Modified the rule of /= =/ in markup.php by removing the
>> > unnecessary call of BOLTescape (done in BOLTcharEncode) and changed
>> > the encode parameter to "lines" so that multi-lines are displayed
>> > properly.
>>
>> You are right about the first point. As for the second, do you mean
>> you changed the default fmt from '' to 'lines'? I'm not so sure about
>> that. Can you give me an example of where the display is not correct?
>
> old: MarkUp('pre', 'nomarkup', '/\/\=(.*?)\=\//se', "BOLTcharEncode
> ('$1', ENT_COMPAT, 'UTF-8')"); // /=no markup=/
> new: MarkUp('pre', 'nomarkup', '/\/\=(.*?)\=\//se', "BOLTcharEncode
> ('$1', 'lines')"); // /=no markup=/
>
> Just to make multiline text displayed as multiline instead of single
> line, like:
> /=
> test
> test2
> test3
> =/
Very nice. Thank you again.
>> > 12.Modified markup.php so that HTML tags with post-blanks or post-
>> > slashes like <br /> are allowed. Also fixed a problem for edit-
>> > conflict box displaying disorder by not recognizing <br />s.
>>
>> What rule did you use... Doesn't it allow invalid possibilities,
>> like: <i /> or <b />? Do we want that? Not sure we do actually...
>
> As I said, the major purpose is to support <br />. I didn't filter the
> possibilities like <i /> but since it's still validate html form, I'd
> like to just leave the problem to the user if he types something like
> that.
>
> By the way, I'm too lasy to filter </xxx/>, if you think it's a big
> problem you can modify it.
>
> old: MarkUp('style', 'html', '/<([\/]?)([a-z0-9]+)>/ie',
> "BOLTMhtml('$1', '$2')"); // allowed html
> new: MarkUp('style', 'html', '/<([\/]?)([a-zA-Z0-9]+)( ?\/?)>/
> ie', "BOLTMhtml('$1', '$2', '$3')"); // allowed html
>
> also modify BOLTMhtml to:
>
> function BOLTMhtml($slash1='', $command, $slash2='') {
> ## FUNCTION THAT TAKES HTML SAVED ON A PAGE IN AN INACTIVE FORM AND
> REACTIVATES ALLOWED HTML RULES. SEE BOLTattrs FOR A LIST OF ALLOWED
> HTML RULES
> $BOLThtml = BOLTattrs('html');
> $command = strtolower($command);
> if (!empty($slash1)) $output = "$slash1$command";
> else $output = "$command$slash2";
> if (in_array($command, $BOLThtml)) return "<$output>";
> return "<$output>";
> }
Ok, I added this with just a few slight modifications. I'm not sure
the possibility of allowing really strange html into a page is a great
idea, but it does maintain the purpose of allowing people to pretty
much cut and paste most simple html from another site directly into
BoltWire. And setting up a separate rule just for <br /> is perhaps a
bit of overkill. We may revisit this at another time--when we look at
vertical linespacing again.
>> > 17.Modified BOLTFpreview in functions.php so that on previewing page $
>> > escaped by `, <code> or /= =/ no more displayed as $, and '~data~'
>> > no more displayed as '~data~'.
>>
>> Would you be so kind as to post your fix so I could incorporate it
>> into the core?
> I've change a bit..
>
> if ($args['output'] == 'escape') return BOLTescape($preview);
> // $preview = str_replace(Array("\r\n", "\r", '~data~', '<'),
> Array
> ("\n", "\n", '~da`ta~', '<'), $preview);
> $preview = BOLTsaveEscapes($preview);
> $preview = preg_replace('/([\\n]?)\[form(
> (?:"*.?"|\'*.?\'|\[\]|\]\]|
> =\]|[^\]])*)?\]/', '$1', $preview);
> $preview = preg_replace('/([\\n]?)\[session(
> (?:"*.?"|\'*.?\'|\[\]|\]
> \]|=\]|[^\]])*)?\]/', '', $preview);
> $preview = preg_replace('/\[\(preview(.*?)\)\]\n?/', '',
> $preview);
> if (BOLTcodePageGroup($pageLink)) return BOLTMcode($preview,
> 'preview');
> // if (substr($pageLink, 0, 5) == 'code.') return
> BOLTMcode($preview,
> 'preview');
> $preview = BOLTdomarkup("\n$preview", $pageLink, '', '',
> false);
I may be missing something but I think an easier way to do this is to
simply remove the $ and ~data~ string replacements earlier in the
preview function. It shouldn't hurt anything to have these in the
preview. If saved later, they will be taken care of then.
I also note the BOLTMcode function should have 'code' for the second
parameter, not preview.
> 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.
>> > 18.Fixed "site.join" so that it doesn't show ugly "adminAdmin";
>> > duplicated 'editor' and 'admin' were also excluded.
>>
>> Thanks. Just added... (but to action.join).
>
> Still broken. Suggest:
> old: Select group: [select which][option admin][option editor]
> [(search group=group template="=[option {+p2}]"
> exclude=template.admin,template.editor)]
> new: Select group: [select which][option admin "Admin"][option
> editor "Editor"][(search group=group exclude=group.admin,group.editor
> template="=[option {+p2} {+page}]")]
Arrgh! You are right. Embarrassing mistake. Thanks! And better to use
the capitalized words as you suggest. I ended up with
[select which][option Admin][option Editor][(search group=group
exclude=group.admin,group.editor template="=[option {+p2}
{+title}]")][select]
>> > 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.
>>
>> Can you explain what is incorrect about that data action? I have not
>> noticed any problems with it?
>
> I don't know why action.data now works in 3.3.3, but it didn't work
> (cannot add a data or change a data via the form) in 3.3.2 and worked
> in 3.3.1. And it worked after the modifying:
>
> old: [text list_fieldnames "{?fieldnames}" size=40] [submit
> value='New Fields']
> new: [text fieldnames "{?fieldnames}" size=40] [submit value='New
> Fields']
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.
>> > 20."site.language" do not contain several system messages, which were
>> > also included in the pack.
>>
>> If you can list them, I'll add them...
>
> Oops, it's so long a list...
Ok, I copied these to my notes and will add them soon. Perhaps for the
next release or so. I want to compare them with some of the work
Markus has done on cleaning up the internationalizations.
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?
>> > 21.Fixed several typos and nonsense or missense lines seen anywhere.
>>
>> If you want to see those included in the core please specify them. I'd
>> rather not have to download your version and try to track down every
>> change you've made. It's much easier for me to one by one go through
>> and evaluate your proposed changes and then either incorporate them
>> into the core or not. That's basically how the system here has worked
>> to date.
>
> Typos, missense, and optomizations: small things, some may just be
> funny. just to be picky.
>
> 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... :)
> old: MarkUp('if', 'if*', '/\[if\* (.*?)\](.*?)\[(if\*|else\*)\]/se',
> "BOLTMif('$1', '$2', '$3', '*')"); // [if]
> new: MarkUp('if', 'if*', '/\[if\* (.*?)\](.*?)\[(if\*|else\*)\]/se',
> "BOLTMif('$1', '$2', '$3', '*')"); // [if*]
You do have a good eye. Wow...
> old: MarkUp('form', 'func', '/<\((.*?)\)>/e', "BOLTMfunc
> ('$1')"); // [(func params)]
> new: MarkUp('form', 'func', '/<\((.*?)\)>/e', "BOLTMfunc
> ('$1')"); // <(func params)>
I'm impressed... Seriously. I love your powers of observation and
attention to detail. Thank you!
> old: function BOLTtranslate($text, $language='', $reverse=0) {
> ## THE TRANSLATION ENGINE IN BOLTWIRE FOR SWITCHING KEY PHRASES TO YOR
> CHOICE OF LANGUAGE OR BACK
> new: function BOLTtranslate($text, $language='', $reverse=0) {
> ## THE TRANSLATION ENGINE IN BOLTWIRE FOR SWITCHING KEY PHRASES TO
> YOUR CHOICE OF LANGUAGE OR BACK
Got it.
>> > 3)b) I haven't fully understand what BOLTstripslashes does but if I
>> > adds this line:
>> > BOLTreplace("\n", '\n');
>> > before the line:
>> > BOLTreplace('~data~', '~da`ta~');
>> > all input '\n' wound not be replaced by a line break;
>>
>> Why would we want this?
>
> 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.
>> > 4. The documentation of markup table in the help system is out of
>> > date.
>>
>> Specifics?
>
> 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. :)
Thanks again for all the suggestions. I'll reply to your other emails
one by one. These are lot's of good fixes--even if small, they all add
up.
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.
