>Eclecticology wrote:
>
>The ISO format is based on numerical dates. Thus for the example it would
>be 2003-06-24. It includes hyphens and has leading zeros for days and
>months. To the extent that I have been applying them I would enter such a
>date as [[2003]]-[[06-24]]. The first hyphen is outside of the link, and I
>have written redirects for the numerical dates on an as required basis.
I didn't bother putting that one in because there didn't seem to be much
support for it on the voting page. I can put it in if you want. It will be
infinitesimally slower than the rest due to the need for month name->number
conversion.
>tarquin-
> > It seems a little bats that at a time when our databse is struggling,
> > we're adding more load to the system for something so trivial.
>
>This should not add substantial load if properly coded, since it's just a
>search/replace operation with a fairly specific match (only triggers on
>linked dates).
That's my thinking too, although I haven't tested it. There's no extra DB
access, which by far forms the lion's share of the time required to display
a page. CPU load is about 5-6 lightweight preg_replace calls. They all match
a limited number of characters, and start with "[[". I thought long and hard
about various possible implementations: say, a single more complex regex
plus some PHP code to distinguish between the various cases, but I decided
that would take longer. Ditto for somehow incorporating it into
replaceInternalLinks(). The only faster thing way I can think of is writing
it in C. Setting up the regular expressions from the month name array is
done once per script run (stored in static variables), so if a tight loop of
addWikiText calls is slow, it won't be my fault.
>It will help us present a consistent picture throughout all
>our pages while not giving up some editorial liberty. I therefore fully
>support the implementation of this feature, unless the code is completely
>nuts ;-)
Yes, well you'll be able to judge that for yourself soon if I stop typing
emails and start doing some real work. :)
-- Tim Starling.
_________________________________________________________________
Hot chart ringtones and polyphonics. Go to
http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=174&refer…
Hi, folks!
I just wondered whether ppl think it's a good idea to copy wiki.png to
the installation path when calling the update script ("php4
update.php"). IMHO it isn't. A working setup will likely have a
customized logo that it doesn't want overwritten. IMHO only code should
be updated.
Alternatively we could just change the copyfile method so it doesn't
abort if a file can't be written.
Any comments, criticism, ideas, hints, objections? Else I'll just
comment the concerning line out.
Bye!
Matthias
For quite some time, we've been outputting HTML pages with a
half-doctype declaration, with no DTD specified:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Browsers interpret such a doctype as not quite reliable, and render
pages in so-called "quirks" mode for backwards compatibility with the
parsing and rendering bugs of earlier versions. It's been occasionally
suggested that it's superior to include also a URL to the DTD, which
will put browsers into a stricter, standards-compliant mode:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
A couple days ago I slipped this in. All well and good in Mozilla, but
in Internet Explorer 6.0 (I haven't tried 5.x) this triggers a selection
bug, such that trying to select text with the mouse selects everything
from the beginning of the document to the point where you've got the
mouse, instead of the portion of text you're dragging over. Not very
helpful.
Since, unfortunately, a lot of people use this dreadful program, and
this is a _really_ annoying browser bug, I've temporarily taken the DTD
reference back out, so we're back to quirks mode, where selection works.
Sigh...
-- brion vibber (brion @ pobox.com)