Also makes SQLite path configurable in the installer.
$wgSQLiteDataDir wasn't being initialized in DefaultSettings.php, potentially open to register_globals attacks. Now initialized to '', which gets interpreted as default.
Now adding only the options for the relevant DB to the generated LocalSettings.php
This is a complete rewrite of Database::tableName.
The new tableName also has no PHP errors, and outputs a cleanly quoted table name 100% of the time.
This should solve bug 2396
* 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.
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.
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.
The setup code was using a MonoBook-specific div ID to insert the results container into. Swapped that for the plain ol' document.body and fixed the styles for MonoBook and Modern so it gets the scale-up fix for the font size (they both use a weird system where they shrink the font size on the body, then scale it back up inside.... very wtf territory!)
Added setup for form and input IDs used for the second search box on Cologne Blue, and copied those IDs over to Nostalgia and Classic skins.
Note that the drop-down is a bit unsatisfactory on the page-bottom search boxes in Nostalgia, Classic, and Cologne Blue, as it tries to squish in at the bottom of the page, and you only get two lines of data. The sidebar search boxes are also not very wide, which makes results pretty cramped.
allow specification of which namespaces a sitemap will be generated for. Defaults to false, indicating all namespaces should have a sitemap generated
for them.
* check in a new ajax suggestion engine (mwsuggest.js) which uses
OpenSearch to fetch results (by default via API), this should
deprecated the old ajaxsearch thingy
* extend PrefixSearchBackend hook to accept multiple namespaces for
future lucene use (default implementation however can still
process only one)
* Added to preferences, also a feature to turn it on/off for every
input (disabled atm until I work out browser issues completely)
* WMF wikis probably won't be using API to fetch results, but a
custom php wrapper that just forwards the request to appropriate
lucene daemon, added support for that
SpecialSearch:
* moved stuff out of SpecialSearch to SearchEngine, like snippet
highlighting and such
* support for additional interwiki results, e.g. title matches
from other projects shown in a separate box on the right
* todo: interwiki box doesn't have standard prev/next links to
avoid clutter and unintuitive interface
* support for related articles
* The date-split view is visually disjoint; loss of distinguishing bullets makes the lines harder to read and distinguish, while the extra date headers cause significant vertical expansion of log lists when searched on specific criteria.
