So, I had saved my answer in a text file until google groups worked
for me again, and here it is, second attempt:
> Where is this happening exactly? Things seem to be working properly
> for me... I suspect this is only happening because you have already
> gotten rid of the implode line you didn't like below... :)
It's the magic quotes line. It doesnt take into acconut that post
variables can be arrays, and treats them as strings.
you want, I think,
if (get_magic_quotes_gpc() == 1) {
foreach($_GET as $field => $value)
if( is_array($_POST[$field]) ) $_POST[$field] =
array_map(stripslashes, $value);
else $_POST[$field] = stripslashes($value);
etc
It looks like you're combining GET and POST into POST, is that on
purpose? Or is that me?
> I'm willing to do this, and I appreciate the problems you mention of
> not being able to use commas in post arrays, and of null values
> getting stripped out. But we need to think through the implications
> and try to avoid breaking other things in the process. I use the csv
> format because we have excellent csv handling in BoltWire, and these
> capabilities are integrated all through the BoltWire system making all
> kinds of things possible. If we drop this and leave the arrays as
> arrays we have several problems:
I've tried it on my engine, and it currently works fine. I was
surprised at how little needed to be changed.
> 1) We find ourselves sending an array through htmlspecialchars in
> markups.php, line 23. We could set this up as a separate function or
> perhaps tap into BOLTarray rather than $_POST and filter things there,
> but I'm not sure we want to do that. It would open up the possibility
> of having session values available as a {?field} variable... But then
> we lose GET variables and cookies. Not good. Regardless this is not
> insurmountable...
>
> We could also possibly use array_map as you suggested, though I've not
> used this function much. How would this part of line 23 be rewritten
> using that?
>
> htmlspecialchars(\$_REQUEST['$1'], ENT_NOQUOTES, 'UTF-8')
This is for {?var} markup, isnt it? I havent changed this in any way,
I don't see why I would need to.
I access the resulting arrays in BOLTarray. The _REQUEST variables are
never sent as arrays, so I don't mind them much.
Its the [check input[] "id string"] things I primarily want in array
form.
> 2) The list function shouldn't be wrecked directly by this change, but
> there are a good number of functions which can take a csv parameter to
> generate dynamic output. Having POST array values automatically fixed
> to work with this makes all kinds of dynamic possibilities,
> possible... If anything, we should not only make this possible via
> forms, but also through the {?field} var directly, which doesn't seem
> to be the case at present. Leaving the post arrays as an array would
> make this impossible--esp considering there is no way to post an array
> into a page. I'm actually suggesting here rewriting the line above to
> something that converts an array INTO a csv list when injected into a
> page.
I'm not sure what you're talking about.
> 3) And then all the commands. Many take csv lists to perform actions
> on multiple pages for example. These could be rewritten to use the
> array directly, but it would be a job, and who knows how many plugins
> would be affected... I suspect it might be quite a while before all
> those bugs got worked out. And I'm not sure what the gains are...
So far, no plugins I use are affected, except ones I wrote.
For my plugins, I wrote a BOLTfilter_array function which returns an
empty array if the variable was empty (no checkboxes checked).
I then simply did a reg_exp replace across all my plugins, replaceing
any explode(',',\s?$BOLTarray['.*'] etc with
BOLTarray_filter($BOLTarray['']).
Basically, if you have a variable which used to be an array, good
heavens, you will want to use it as an array. Unfortunatly, empty post
varialbes from checkboxes seem to be an empty string and not an array,
so array_filter will sometimes break things.
Here's a gain for you:
I use boltwire as a front end for a business-system, as I'm sure I've
mentioned.
A few of my users are on my case about using swedish notation for
currency, as in 123,55 Kr instead of 123,55 Kr.
Without my version of the core, this would be impossible, because:
[text price[] 0] Kr [text amount[] 0] units
will parse the prices incorrectly when exploding around ','.
For no good reason, because you've imploded a perfectly good array in
the first place.
> 4) The other issue to consider is, are there easier ways to accomplish
> the same objectives without breaking everything above? I'm not sure
> what you are trying to do, but the POST value itself is never changed.
> Is it possible to tap into that directly rather that tapping into the
> BOLTarray? In which case we could have the best of both worlds. This
> should be easily doable if you have a custom plugin of some sort. If
> it is a core function, which? Perhaps we can tweak it to use POST
> rather than the BOLTarray...
... yes, I suppose, but I don't want to go there.
If I need to bypass my content generator to write plugins, I may as
well not use it in the first place.
The bolt array is a good thing. It's handy.
Oh, maybe I'm making a bigger deal of this than I need to. I'll get
back to you.
All I really need to do is get you thinking like me regarding the utf8
issues, so utf8 stops breaking every other release.
Everything else has workarounds.
>
> > I'm going to remove it in my version. Then, I'm going to remove a
> > bunch of much slower for loops in favour of the much faster
> > array_merge function (eg, in BOLTsecure), array_map function
> > (stripslashes) and the array based replace functions in the strip_utf8
> > function which will speed that up considerably.
> > Then, I'm going to keep group memberships as an array, and change
> > ingroup to use in_array() instead of the slower grep functions.
> > Then, I'm going to realize that I wont be able to go back to the main
> > releases for a very long time. I will cry a little, but my site will
> > be faster for it.
>
> Not sure this is the best time for you to do this, as we'll be making
> some really big improvements to our form processing capabilities once
> we get the 3.xx bugs out and switch to 4.xx.
I'll keep an eye on them and patch them in. :/
>
> The license of course allows customization to your heart's content,
> but not a redistribution (ie, a fork). To strengthen the core, it
> takes a bit patience and good communication. I'll repost my overview
> of how this process works below...
I wouldn't want to fork off even if I could.
> >> > for changes to get implemented, they need to come as specific patch
> >> > proposals I can examine and digest. (ie, line 100... line 200...).I
> >> > I don't really have time to do a full examination of all the changes you
> >> > have made. And as a result I don't know what the changes are, whether
> >> > they are good or bad, or all the implications. I also want to make
> >> > sure I only use code I understand fully myself. I'm enthusiastic about
> >> > improving the core, but I want to oversee each improvement, and with a
> >> > major rewrite like this, I can't realistically do that. I feel
> >> > something of a responsibility in this area for all the other people
> >> > using BoltWire.
>
> Some of your ideas sound interesting, but generally, I think BoltWire
> is quite fast because it uses simple string manipulation functions
> rather than array handling functions. If you have done some specific
> benchmarking and can demonstrate improved speed, I'll make the change.
> We all want things to work faster, just make the case and it will
> happen. I'm happy BoltWire can be a framework for your web development
> needs, but I do wish you could work with the community in
> strengthening the core code rather than branching off like this. It
> may be easier to change things in the short run, but the core would be
> stronger if we work together. And your contributions would be of
> benefit to more people.
I had a lot of problems with spead until yesterday, but they turned
out to be mostly pluggins (not mine).
I did get a spead increase of several seconds when I rewrote the toc
pluggin to build an array and implode it at the end, as opposed to
strings and the .= operator, but I havent found anywhere in boltwire
where this needs to be used, yet.
... The 3-7 second delay in my form intensive page just got put into
new light, though. must test that...
Anyway, my point is that quite often a big gain would be readability
and more compact code, the speed gains are probably less than I first
thought. Basically, any speed gains are overshaddowed by the parser at
this point. But then, there are string functions there that may like
some array lovin'.
My biggest concern is that quite often you move away from a perfectly
good array in order to concatenate a string, only to use reg_exp
functions which beg for problems with commas, when a in_array call
would have been faster, more compact, and safer.
Regarding the branching off thing, it's propably gonna happen in some
way because I'm impatient and on a schedule, but it doesnt have to
mean I can't contribute to the community.
Above all, as it stands, pluging boltwire into my database member
management required an edited engine, because of group memberships.
In fact, if I set up a subversion or mercurial repository on my server
for Boltwire, and made a branch for my versions, we could probably
patch in changes between us pretty easilly, but I've never tried this
before. Generating patch files would be easy though.
In fact, theres a good chance I could do this for my version, and keep
a "trunk" version updated from your server myself, then patching in
changes to my version. I will try this, I think. You don't have
problem with what essentially amounts to a file mirror, right? If you
do, I can make it private.
I'll check up on your other changes above, there may be something I've
not though about.
On Jun 24, 4:12 pm, The Editor <[email protected]> wrote:
> On Tue, Jun 22, 2010 at 6:28 AM, DrunkenMonk <[email protected]> wrote:
> > I've got another bug, it seems. My $_POST variable is being
> > (innefectually, it should have been done with array_map(stripslahes,
> > $_POST) ), sent through stripslahes, which means that my _POST arrays
> > are being converted to the string 'ARRAYS'.
>
> Where is this happening exactly? Things seem to be working properly
> for me... I suspect this is only happening because you have already
> gotten rid of the implode line you didn't like below... :)
>
> > This wasn't happening before, what is "get_magic_quotes_gpc"?
>
> A really yucky php thing that escapes values, often automatically to
> get them ready for a database. So you have to check if it is turned on
> to know whether or not to strip the escapes out... That took a long
> while to finally figure out...
>
> > Also, Dan, I *want* my variables in array format, so I can use the
> > array functions, and not get the added pain of not being able to
> > handle commas in the post values.
> > the implode(",", $value) thing in BOLTsecure is ONLY bad for me, in
> > every way.
>
> > The implode thing even stops my arrays from being synchronized, as it
> > filters away empty inputs. This is Very Bad (tm)
>
> I'm willing to do this, and I appreciate the problems you mention of
> not being able to use commas in post arrays, and of null values
> getting stripped out. But we need to think through the implications
> and try to avoid breaking other things in the process. I use the csv
> format because we have excellent csv handling in BoltWire, and these
> capabilities are integrated all through the BoltWire system making all
> kinds of things possible. If we drop this and leave the arrays as
> arrays we have several problems:
>
> 1) We find ourselves sending an array through htmlspecialchars in
> markups.php, line 23. We could set this up as a separate function or
> perhaps tap into BOLTarray rather than $_POST and filter things there,
> but I'm not sure we want to do that. It would open up the possibility
> of having session values available as a {?field} variable... But then
> we lose GET variables and cookies. Not good. Regardless this is not
> insurmountable...
>
> We could also possibly use array_map as you suggested, though I've not
> used this function much. How would this part of line 23 be rewritten
> using that?
>
> htmlspecialchars(\$_REQUEST['$1'], ENT_NOQUOTES, 'UTF-8')
>
> 2) The list function shouldn't be wrecked directly by this change, but
> there are a good number of functions which can take a csv parameter to
> generate dynamic output. Having POST array values automatically fixed
> to work with this makes all kinds of dynamic possibilities,
> possible... If anything, we should not only make this possible via
> forms, but also through the {?field} var directly, which doesn't seem
> to be the case at present. Leaving the post arrays as an array would
> make this impossible--esp considering there is no way to post an array
> into a page. I'm actually suggesting here rewriting the line above to
> something that converts an array INTO a csv list when injected into a
> page.
>
> 3) And then all the commands. Many take csv lists to perform actions
> on multiple pages for example. These could be rewritten to use the
> array directly, but it would be a job, and who knows how many plugins
> would be affected... I suspect it might be quite a while before all
> those bugs got worked out. And I'm not sure what the gains are...
>
> 4) The other issue to consider is, are there easier ways to accomplish
> the same objectives without breaking everything above? I'm not sure
> what you are trying to do, but the POST value itself is never changed.
> Is it possible to tap into that directly rather that tapping into the
> BOLTarray? In which case we could have the best of both worlds. This
> should be easily doable if you have a custom plugin of some sort. If
> it is a core function, which? Perhaps we can tweak it to use POST
> rather than the BOLTarray...
>
> > I'm going to remove it in my version. Then, I'm going to remove a
> > bunch of much slower for loops in favour of the much faster
> > array_merge function (eg, in BOLTsecure), array_map function
> > (stripslashes) and the array based replace functions in the strip_utf8
> > function which will speed that up considerably.
> > Then, I'm going to keep group memberships as an array, and change
> > ingroup to use in_array() instead of the slower grep functions.
> > Then, I'm going to realize that I wont be able to go back to the main
> > releases for a very long time. I will cry a little, but my site will
> > be faster for it.
>
> Not sure this is the best time for you to do this, as we'll be making
> some really big improvements to our form processing capabilities once
> we get the 3.xx bugs out and switch to 4.xx.
>
> The license of course allows customization to your heart's content,
> but not a redistribution (ie, a fork). To strengthen the core, it
> takes a bit patience and good communication. I'll repost my overview
> of how this process works below...
>
> >> > for changes to get implemented, they need to come as specific patch
> >> > proposals I can examine and digest. (ie, line 100... line 200...).I
> >> > don't really have time to do a full examination of all the changes you
> >> > have made. And as a result I don't know what the changes are, whether
> >> > they are good or bad, or all the implications. I also want to make
> >> > sure I only use code I understand fully myself. I'm enthusiastic about
> >> > improving the core, but I want to oversee each improvement, and with a
> >> > major rewrite like this, I can't realistically do that. I feel
> >> > something of a responsibility in this area for all the other people
> >> > using BoltWire.
>
> Some of your ideas sound interesting, but generally, I think BoltWire
> is quite fast because it uses simple string manipulation functions
> rather than array handling functions. If you have done some specific
> benchmarking and can demonstrate improved speed, I'll make the change.
> We all want things to work faster, just make the case and it will
> happen. I'm happy BoltWire can be a framework for your web development
> needs, but I do wish you could work with the community in
> strengthening the core code rather than branching off like this. It
> may be easier to change things in the short run, but the core would be
> stronger if we work together. And your contributions would be of
> benefit to more people.
>
> 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.
