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.
