I don't think this can be changed easily. It's actually not done by
the markup, but the entire zone is now run through htmlspecialchars to
properly escape all html characters. It is the only way to get valid
xhtml. This means < and > are also escaped.
What I had to do in the markup table was either
1) rewrite patterns to match the escaped versions code
2) write string replacements in functions that used things like &&.
My recommendation would be to do the same. Near the top of your function:
$query = str_replace('&', '&', $query);
The upside is, that now in the core only one main character is encoded
in the raw page files (<). So we have in some ways actually simplified
the handling of the source files. Sorry for the inconvenience. It
took about 10 releases to get the character encoding finally working
more or less properly. I really don't want to tap into that can of
worms again.
Cheers,
Dan
P.S. Another idea is to create a markup rule just before your query
that converts & to & in the page content, but then you risk
invalid xhtml. It is much less efficient, than simply modifying the
query. Not to mention other potential complications. :)
On Tue, Dec 1, 2009 at 8:23 AM, DrunkenMonk <[email protected]> wrote:
> I'm having trouble upgrading to 3.3 from 3.2.1, since my && are being
> treated differently. As such, when I use them in mysql commands, they
> seem to be converted before the markup has a chance to process them,
> with the result that mysql doesnt recognize them.
>
> There's a workaround, I guess, since mysql will accept the word "and"
> as well as the logical "&&". However, I would prefer to be able to use
> my files as is.
>
> Is it possible to change the engine so that the replacement is done
> after function markup? Surely this would be the best way, since all
> commands receive text and will want to receive as simple input as
> possible.
>
> Am I making sense?
>
> This would also have the benfit that code outputed from functions will
> be treated correctly.
>
> I suppose this will still give problems in the session version.
> Perhaps adding a filtering rule in the mysql code is better, but I do
> not really want to change raw input if it can be avoided.
>
> Or perhaps I'm wrong about the cause.
>
> On Nov 13, 12:42 am, The Editor <[email protected]> wrote:
>> I've just released an official 3.3 stable release (just one minor fix
>> from 3.2.11), as well as an updated 3.2 release (with one critical
>> security fix from 3.18). If you scroll down on the downloads page,
>> you'll see special attention given to the 3.2 release. I'm not sure
>> how best to highlight these releases, other than perhaps a special
>> section of the downloads page... Suggestions? I've also updated the
>> downloads button on page main, and intend to keep it always pointed to
>> the latest stable release.
>>
>> Thanks to everyone for all their help and patience during the trying
>> changes of the 3.2 series. Hopefully 3.3 will hold us securely until
>> we get to 3.4. From now on, hopefully just nice solid jumps with all
>> the experimental stuff in between.
>>
>> I'm already itching to tackle the 3.4 goals. Next week. I'll be away
>> again for the weekend, but next week my schedule looks a bit lighter.
>> It will be nice to actually get caught up on some stuff!
>>
>> 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.
>
>
>
--
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.
