It was the right direction, I had simply missed a few calls to
BOLTutf2url.
Why would you want page names in url, ever? This is a mystery to me.
An important one, because utf8 problems are far too common.
Everything is working flawlessly in my version now, with the url
encoding only showing up as file names on the hard drive, and
temporarily in BOLTfilter to simplify the filter regexp.
Nothing else needs to bother about it. Ever.
Oh, well, some things in commands.php do things which should be
handled in engine.php, and may need to call BOLTutf2url, but thats:
a) engine code
b) easilly fixed
So much unneccesary code is removed.
Why do you want the url encoding internally? Thats a horrible idea!
Oh, while I'm writing:
May I suggest a small change for the sake of plugin developers?
EDIT: I think you did something like this while I couldn't post this.
(I've been having a problem getting to google groups, infitite
redirects)
Move the {?var} handling code into BOLTvars, to keep all the {} markup
handling in one place.
This means that plugins can easilly access these variables and have
them be filtered in the correct way. It's also quite intuitive, I was
really supprised when I found that I couldnt call BOLTvars for {?var}
vars.
EDIT: I may have mentioned the below a few times since this. It is
probably not session_write_close.
By the way, something in form markup processing is really slow. A few
hundred checkboxes are taking more than 3, sometimes 7, seconds to
parse on my server, where all other pages takes less than 0.5 s.
I think it might be the constant calls to session_write_close, since
this will provoke a file-write action, but I'm not sure.
On Jun 24, 5:03 pm, The Editor <[email protected]> wrote:
> I think you must have fixed this the wrong way. I don't have any
> problem editing pages with utf. Page names need to be converted to url
> encoding when checking to see if they exist. In fact page names should
> always be url not utf except when displayed in a page. I'm not sure
> you are heading down the right path here...
>
> Cheers,
> Dan
>
>
>
> On Wed, Jun 16, 2010 at 3:10 PM, DrunkenMonk <[email protected]> wrote:
> > Hurray!
>
> > After upgrading, *I can't edit pages with utf8 characters in their
> > name*!
> > The BOLTsecure method fails and calls boltabort.
>
> > The very simple reason is that pageLink is encoded as a url (which,
> > btw, is hell for all plugin developers or possibly just me, I don't
> > know) while _POST['boltkey'] is encoded as utf8.
>
> > Could we PLEASE use utf8, internally, always?
>
> > Given that it will probably solve my other bugs, noticed and
> > unnoticed, I'm just going to hack the engine to convert pageLink to
> > utf8 after it's checked it for valid characters
>
> > ...
>
> > The change did solve the problems I had noticed, but now whenever I
> > navigate to a page with utf in the name, I am forwarded to the edit
> > action.
> > I think this will be resolved when I empty my cash.
--
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.
