[ewiki] Re: changes to ewiki_control_links()
- From: Mario Salzer <mario@xxxxxxxxxxxxx>
- To: ewiki@xxxxxxxxxxxxx
- Date: Fri, 31 Oct 2003 04:34:40 +0100
Hi,
> I don't understand two of your changes to ewiki_control_links. It seems
> that you are mixing the old and new implementations of ewiki_auth. The
No, there is no mixing. Everything now just works with the new / corrected
ewiki_auth() function (no more backpassing/garbaging).
The ewiki_auth() previously may have back-passed-by-reference something
and could thereby destroy the contents of the callers wikipage $data array.
This is no longer the case.
> ewiki_auth() will no longer be garbaging data--so why is data being passed
> to ewiki_control_links() by reference?
The only reason to change the _control_links() call to use the pass-by-ref
&$data is for the minimicro speed enhancement when doing so. Additionally
any chained _auth plugins now had a way to tweak (but not to garbage) the
$data array. Nothing more.
The p-b-r &$data now is used for most interfaces, to achieve this little
speed gain, but also to allow tweaking some settings in it. For example
there is the "lastmodified" field in $data, which ["page"] plugins could set
(if there was a way) and this value then was returned as HTTP Last-Modified
header - what currently works for ordinary pages only.
#
> Resend: Stupid IE glitch -- fixed
> This may have gotten lost in the list switch over, can we make this change?
I didn't forgot this - I just didn't like your patch >;-)
Whatever, as there is no other way around this IE bug (investigation on
other workarounds failed), we of course have to change it. So the <br>
is now inside the <div> and preceedes the <hr noshade>.
This obviously doesn't hurt text browsers, but it may look silly for
pages actually using an .action-links CSS class.
We'll move it back, when IE7 arrives 2006...
mario
Other related posts:
