* turned off by default (set $wgAdvancedSearchHighlighting to turn on)
* reverted r26269, \b doesn't interact very good with unicode data,
so it broke highlighting of words that end/begin in nonascii chars
completely
* small bugfixes in unicode handling, tested in more languages
* $wgSearchHighlightBoundaries need to be set to "" for CJK wikis
* benchmarking: on typical simplewiki data, the code is around 4-5 slower
(according to noc.wikimedia.org the old code profiles to about 0.8%),
but can be up to 20 times slower on featured-size articles
* update release notes (also for r33400)
* fix profiling errors in SpecialSearch
Currently in experimental mode, use $wgAllowImageMoving to enable it.
Known issues:
* Doesn't work with rev_deleted
* May also have some security and caching issues.
Ugh! Somebody please clean up this duplicated code.... allpages and prefixindex have lots of duplicated bits. I swear one used to be a subclass of the other, did they get copied? Or did I do that years ago and forget? :D
* r34072 -- new highlighter code; looks a bit expensive, not fully tested yet.
* r33489 -- broke search result highlighting all around
* Part of r32350 -- bring the color back to search highlighting so we can see our results again. Why was this removed without comment?
God I wish this browser would finish dying. :D
The particular situation was that the session cookie was getting eaten as "disabled", thus not sent back to the server so your session state never quite happened. Other cookies on submit seemed to come in intact, but without the session cookie you'd get a big fat error message, even if you set the long-term login cookie option.
Mac/IE seems to always *see* the HttpOnly cookies, but it sometimes marks them as "disabled". It seems to be incorrectly parsing the options after the path, sometimes seeing "/;" as the path instead of "/". Failure is more likely if there's no expiration option (as with the session cookie), or if there *is* a secure option set.
Anyway, just set up a user-agent blacklist $wgHttpOnlyBlacklist and copied the Mac/IE entry over. The HttpOnly setting now gets ignored for blacklist hits as well as for old PHP versions, the check being encapsulated into wfHttpOnlySafe().
Also added some logging for cookie settings, around the setcookie() and session_set_cookie_params() calls.
snippet extraction:
* prefer text hits over matches on images/templates/tables, making the
snippets more readable and relevant
* cleanup wikitext
* prefer snippets with exact query match - works only for whole phrases
* drop the old context calculation and replace it will a more flexible one
that does a better job keeping snippets of constant width
* if the first line of the article matches whole query show only one snippet
* manually lower/uppercase non-ascii chars so that words in e.g. cyrillic
are also case-insensitive
* workaround for php limited utf8 support so that snippets end up being of
constant char-size over single and multiple byte text
* if there is no text match for some reason, show beginning of the article
Warning:
* haven't done performance testing, might not be safe to go live, although
I don't see any immediate problems with it
Files marked as being larger would be horribly client-side scaled on Image: page inline display for users who set their options up to 1280 or larger. 2048 is still not insanely-huge while still encompassing common screen sizes.
White borders around the highlighted row are removed by collapsing cell spacing and moving the padding inside.
Now using CSS system colors where supported for background, foreground, and highlight colors instead of hardcoded values. These will fit in better with the native controls, especially when high-contrast themes are in use (say, black background, yellow text, and green highlight... :)
Some caveats...
IE 6 and Firefox 2 on Windows look great.
However, a couple caveats on Mac OS X:
* Firefox 3 looks perfect!
* Firefox 2 and other older Gecko browsers, Opera 9.2, and Safari 3.1 provide the *text selection* colors for Highlight and HighlightText, which differ from the *list selection* colors on Mac OS X 10.2 (?) and later. This is technically wrong for what we want, but will at least match the general color selection.
Note that -moz-mac-alternateprimaryhighlight provides the correct background color on Firefox 2/Mac, but IE 6 and Firefox 2 on other platforms don't properly handle a fallback if it's specified straight in the CSS. We could switch it in with JS, but there's not much reason to I think. It still looks and feels fairly native.
* Safari 3.0 and earlier appear to wildly fail with the system colors, though I can't easily test them. There was an ugly WebKit bug where most of the system colors were implemented wrong; Highlight and HighlightText *both show up solid white*, making your text nicely illegible. Since they're implemented (even though wrongly) you can't even set default colors and let them fall through.
See https://bugs.webkit.org/show_bug.cgi?id=6129
I've worked around this by checking the reported WebKit version in the JS and using an alternate class with the hardcoded colors for anything older than what I see in Safari 3.1 (WebKit 525).
Haven't tested anything on Linux; it wouldn't hurt to do a quick sanity check on Konqueror.
Adds the appropriate id for Modern skin to the set of justify CSS thingies.
This isn't totally satisfactory; the various skins should be refactored to unify this stuff better, but it'll do for now.
