Short quiz:
Performance bottleneck for <math>-using pages is ...
a) texvc
b) latex
c) database
The answer is of course c.
One query is done for every occurence of <math>something</math>
to check if it's cached. Usually it is, and neither texvc nor latex
is run.
The solution would be to make only one such query per page,
and if something's missing run texvc only once and pass all
math formulas to it, and then update database in single INSERT
query.
But that has low priority for me - it's pretty fast as is,
and no Main Page uses <math>.
Wiki text:
<!-- ala -->ma<!-- kota -->.
PHP matches <!--.*-->, so output is:
.
instead of:
ma.
Fix:
change to <!--.*?-->
Around line 1026 in OutputPage.php
I have a preliminary version of the promised offline reader with parser
working. Some issues:
* The parser is basically single-pass. I do an additional pass for the
<nowiki> elements, though.
* The parser already supports all wiki syntax, except <math>.
* It doesn't check for correct HTML, though.
* I am only using the article namespace. All other namespaces are linked
to the online version, with a different color.
* No images yet, but basically because I didn't bother with the download ;-)
* There's also a function that converts the database dump into many
files, one per article. This would be run on the "vendor" side.
I have tried the German database, and it works pretty well. I am a
little worried about the wxWindows HTML component, though. One thing it
doesn't support are HTML entities like "Ӓ", which I automatically
replace with a "?".
There's no search function yet, and no fulltext index is created. But,
that shouldn't take a lot of work, compared with the parser.
I can mail a Windows .exe (~600 KB zipped) to anyone who'd like, and a
howto for converting the mysql dump.
Tomorrow.
Magnus
WystBąpił błąd składni w zapytaniu do bazy danych. Mogło to być spowodowane przez złe sformułowanie zapytania (zobacz Przeszukiwanie Wikipedii) albo przez błąd w oprogramowaniu. Ostatnie, nieudane zapytanie to:
SELECT cur_id,cur_namespace,cur_title,cur_text FROM cur,searchindex WHERE cur_id=si_page AND ( (MATCH (si_title) AGAINST ('caU8c582ka')) ) AND (cur_namespace=0) LIMIT 0, 20
wysłane przez funkcję "SearchEngine::showResults". MySQL zgłosił błąd "1191: Can't find FULLTEXT index matching the column list".
I probably won't get to any of this for a while as I've promised to fix
up that conversion script, but some thoughts...
Client-side caching of page-views and and recentchanges are allowed
(currently only for IE 5.5+ as Mozilla and IE 5.0 have had difficulties
refreshing and I haven't had chance to test with other browsers).
The reported last-modified date is the edit date of the article revision
(or for Recentchanges, the last modified article). On load, the browser
sends this back to us in an if-modified-since header; if it's identical,
we tell it to use its cached version, else we send out the new time and
continue (see OutputPage::checkLastModified() ). We force this check on
every attempt to load the page by pre-expiring it and sending a
'must-revalidate' cache-control header (see OutputPage::output() ); this
requires a round-trip to the server, but we avoid most of the heavy
lifting by doing the time check quick and getting out before querying a
hundred links and parsing whole pages of gunk.
(Recentchanges changes so often there's probably no point to caching it
though...)
Some problems: this does not take into account secondary changes: linked
articles are created and deleted, users log in and out or change their
display preferences. This can lead to incorrect display, which isn't
always cleared by a refresh -- by default, refresh in IE sends the
if-last-modified and obeys the 304 Not Modified. Users don't generally
know about the Ctrl+Refresh force reload trick.
Links might be solvable by adding a "last_touched" timestamp field to
cur; this would be set to edit timestamp on save, and whenever a page is
created or deleted, all pages linking to it would have their
last_touched reset to the current time. We then use this as our basis
for cache comparisons, forcing reloads of pages whose links should show
different. (And if changes to the software are made that change
rendering, we can invalidate caches for the whole wiki with a sweeping
UPDATE statement.)
Things like user settings and logging in and out might be solvable with
session variables; an invalidating event would set a sort of 'cache from
here on' time, and any earlier last mod would get pushed up to there.
Other problems: I added the caching support in the first place because
with the pages marked as uncacheable IE was forcing reloads on every
pass through the 'back' and 'forwards' buttons. Usually this is simply
an inconvenience -- more time spent waiting for the server, and more
load on the server increasing the time spent waiting. When editing,
however, this can cause data loss; some people will click the links from
the sidebar to get additional information, then hit 'back' to return to
their editing session. Oops! The page was reloaded. Is it safe to mark
the edit pages as cacheable? What do we have to do to them to mark them
properly?
-- brion vibber (brion @ pobox.com)
Hi, I've posted a request for help at the
intlwiki-l but have received no answer
yet on how to change to the new software
for vo.wikipedia.com to vo.wikipedia.org
Can someone here help?
Also, could you point me to how-to's
on page background tweaking etc.
Does this entail the software client or
is it through the web that it can be
accomplished?
I like the job the Eo group have done
with the look of the Esperanto Wikipedia.
Kudos!
Cheers,
Jay B.
Am I slowly senile, or is there a new link on the left side saying "My contributions"? I tried to find this on the Swedish language file to translate but couldnt see it.
- Dan Koehl
The last software upgrade seems to make it impossible for administrators to
make SQL queries on the danish wiki.
When I go to the Speciel:Asksql page I get this message:
Parse error: parse error, expecting `T_OLD_FUNCTION' or `T_FUNCTION' or
`T_VAR' or `'}'' in /usr/local/apache/htdocs-da/w/SpecialAsksql.php on line
67
Fatal error: Cannot instantiate non-existent class: sqlqueryform in
/usr/local/apache/htdocs-da/w/SpecialAsksql.php on line 13
Regards
Christian List
_________________________________________________________________
Få Hotmail på mobilen http://www.msn.dk/mobile
Nothing can be saved on Polish Wikipedia after last software upgrade.
Example on sandbox:
Wystąpił błąd składni w zapytaniu do bazy danych. Mogło to być spowodowane przez złe sformułowanie zapytania (zobacz Przeszukiwanie Wikipedii) albo przez błąd w oprogramowaniu. Ostatnie, nieudane zapytanie to:
INSERT INTO old (old_namespace,old_title,old_text,old_comment,old_user,old_user_text,old_timestamp,old_minor_edit,inverse_timestamp) VALUES (4, 'Brudnopis', '[[en:Wikipedia:Sandbox]][[nl:Wikipedia:Zandbak]] http://www.3c.1lo.rz.pl strike
To jest tekst
', '', 65, 'TheStructor', '20030206085027', 0, '79969793914972')
wysłane przez funkcję "Article::updateArticle". MySQL zgłosił błąd "1054: Unknown column 'inverse_timestamp' in 'field list'".