How does the user preferences table stores the user's preferred stylesheet?
Is it just an index number, or does it contain the URI for the stylesheet?
If the latter, may I suggest that we allow users to specify the location of
a personal style sheet for wikipedia.
For example, I could then take the Cologne blue stylesheet, change the
things I don't like about it (such as the article text size) and host it on
my own webserver*, point to it from my wkipedia preferences, et voila - a
fully customized view of wikipedia, but I am actually reducing the load on
the wikipedia.org servers by not getting a stylesheet from them.
*actually, I could access it from my PC via file:// protocol, but hosting
it on the web gives me a mobile profile that I can use form any computer.
--
Richard Grevers
>Unfortunately, no browser (not even Opera which would rate
as the most
>configurable by far) yet allows you to define a site-
specific user
>stylesheet with a bookmark. Does anyone think it would be
worth changing
>the table structure to store 80 bytes rather than a couple
in order to
>provide this feature?
Fortunately, if you use put !important like
color: #333333 !important;
you can override site specific stylesheets.
After trying MySQL 4.0, I also want to try implementing a
rendered page cache. Using the test suite, I investigated
the issues involved and found the following: All 12
combinations of Skin and quickbar don't affect article
content (well, Nostalgia skin eliminates the page title, but
we can define "content" around that). Likewise, other
options can be worked around. The problematic ones are auto
header numbering and question-mark links.
I think I can probably work around header numbering by
always including them, putting them in a <span> and setting
the visibility in CSS. That will have the side-effect that
old non-CSS browsers will always get numbered headings
whether they want them or not. I can live with that.
The "?" links are another matter: I can't think of a clean
way to offer both options; i.e., links on the whole word
with some style, or links only around the "?". How much
screaming do you think would take place if we simply
eliminated the "?" links, and just made two link style
options (one sedate and one loud)?
--
Lee Daniel Crocker <lee(a)piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
Hi, this is Marumari (from en Wikipedia). I've been a UNIX sysadmin for
quite some time now, and I was wondering if it would be possible to
assist in the sysadminning of wikipedia.org? I've spent quite a lot of
time doing performance tweaking on Linux and Solaris, so I think I could
help a lot.
Talked to thechef in #wikipedia, and he said this was definitely the
place to ask. Thanks!
--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN
Rather than to the emergency fix-Wikipedia address, please send
correspondance about the software internals to the developers' list at
wikitech-l(a)wikipedia.org. (CC'd)
Also, if running a public server, please change the error message in
DatabaseFunctions.php to list an appropriate contact address. We won't be
very happy to get a dozen worried e-mails from random people that _your_
site is down, and it won't help inform you. :)
On Wed, 19 Mar 2003, Timothy Taylor Moermond wrote:
> Warning: mysql_pconnect() [function.mysql-pconnect
> <http://www.php.net/function.mysql-pconnect> ]: Access denied for user:
> 'wikiuser@localhost' (Using password: YES) in
> c:\inetpub\wwwroot\phpwiki\newcodebase\DatabaseFunctions.php on line 26
> Could not connect to DB on 127.0.0.1
Is mysql set up correctly? Did you use the right password? Is the user set
up with appropriate access with the database? Is it named correctly? Did
you use maintnenance/wikiuser.sql with appropriate local changes to
configure the user for access to the database?
-- brion vibber (brion @ pobox.com)
I've been trying to profile the system to find the bottleneck.
Some simple disk monitoring showed very high levels of disk activity,
both read and write, yesterday. This is surprising, as the site should
be able to run mostly out of memory, except for writes to update the
database when pages are edited.
Rates were around 250 reads/second and 250 writes/second.
Disk heads and spins are a very scarce resource, and contention on them
will make any existing database locking problems far worse. I've got a
couple of questions which might help me:
* Can someone who knows the code tell me whether there is much use of
intermediate files in the Wikipedia software?
* Can someone who knows the hardware tell me how many drives are in the
RAID, and what RAID level is used?
Neil
(cc'ing to wikitech-l)
On Wed, 19 Mar 2003, Richard Grevers wrote:
> But I would never expect the latter with other sites. However, the
> separation between wikis is not at all evident to the newcomer. Indeed, my
> first assumption was of a single user database across all wikipedia
> entities.
This is planned, but (surprise!) not yet implemented. It requires either
that all wikis are in one database (which would require more code to deal
with languages and sections separately) or talk to two databases, one
local and one common.
The latter approach is already being started with some experimental code
Magnus has done for the interlanguage links, so in the short term we'll
probably go that way. (Once someone has time to work on it...)
> While we are discussing log-ins, what is the expiry time for keeping logged
> in status? It seems to be rather short - only an hour or so. While I don't
> necessarily want to use cross-session cookies, it would be nice to stay
> logged in for an entire browser session. Sometimes I find that I have
> edited an article anonymously because my login has expired in the meantime.
> One option could be to default to session-long logins but to have a
> checkbox "this is a public computer" which would introduce a 30 or 60
> minute limit.
*Side usability note: it's easy to misinterpret from the layout that the
'remember my password' checkbox applies only to creation of new accounts.
This should probably be changed.*
Our whole login/cookie system is crying out for improvement. I've never
messed with it much because I'm not 100% sure how it works. ;)
We partially use PHP's session management, and we also set some other
cookies. I don't know what the default timeouts are. PHP session cookies
are IMHO problematic, because it asks to set a cookie *the first time you
touch the site*. I'm sure I'm not the only one who blocks all cookies by
default unless I'm deliberately logging in to a site; and we do not
gracefully handle the case where someone tries to log in with cookies
disabled.
(We print a blithe "success!" message, but the next page they visit is
logged back out, because the session cookie isn't passed on. PHP session
stuff has some funky link munging, but a) we prevent them from being put
in on most pages by using absolute URLs, and b) with our current url
rewriting configuration the information would be lost in most cases. And
c) putting session information into URLs is *serious* bad mojo, with great
possibilities for session hijacking.)
Better would be to only set cookies at login time, and to pull a redirect
in the login process so we can reload and check that the cookie stuck. (Or
we could check for the cookie in javascript, but I hate relying on
javascript. Someone with both cookies and javascript disabled/not
available should also be able to be told that they can't log in.)
-- brion vibber (brion @ pobox.com)
The watchlist is just damn slow. Would anyone care to take a look at it
and find a way to make it more efficient?
Currently:
SELECT DISTINCT
cur_id,cur_namespace,cur_title,cur_comment,
cur_user,cur_user_text,cur_timestamp,cur_minor_edit,cur_is_new
FROM cur,watchlist
WHERE wl_user={$uid} AND wl_title=cur_title
AND (cur_namespace=wl_namespace OR cur_namespace=wl_namespace+1)
ORDER BY inverse_timestamp {$dolimit}
This ends up EXPLAINED as:
+-----------+------+----------------------------------------------+-----------+---------+--------------------+------+----------------------------------------------------------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
+-----------+------+----------------------------------------------+-----------+---------+--------------------+------+----------------------------------------------------------+
| watchlist | ref | wl_user | wl_user | 4 | const | 1 | where used; Using index; Using temporary; Using filesort |
| cur | ref | cur_namespace,cur_title,name_title_timestamp | cur_title | 255 | watchlist.wl_title | 1 | where used |
+-----------+------+----------------------------------------------+-----------+---------+--------------------+------+----------------------------------------------------------+
Temporary table and filesort are not friendly.
-- brion vibber (brion @ pobox.com)