There were many changes that I like, but several that were bad.
Listing the latter in order of decreasing importance:
<What links here> no longer indicates what links through redirects.
I think that this is a significant loss of function.
The watchlist no longer watches User: pages or Wikipedia: pages.
It's bad enough that User talk: and Wikipedia talk: weren't watched;
now it's worse.
There are a few links that are now available only from the Quickbar:
<Watch this page>, <What links here>, and <User contributions>.
Can these *please* at least be listed at the bottom of the page?
(I'd actually prefer to keep these items at the top, but the bottom will do.)
The new format is slightly too wide for my window with the Quickbar,
which however isn't a problem if I have the Quickbar turned off,
but I make heavy use of the first of these two links.
I can accept being condemned to an ugly display for my particular setup
if this makes things nicer for a wide class of other users,
but I don't see how putting *anything* *only* on the Quickbar helps *anybody*.
The watchlist also no longer displays nonexistent pages that I'm watching.
You may not believe it, but I actually look at this list.
A construction like "[[thing]]s" no longer mimics "[[things|thing]]"
if the page [[thing]] doesn't exist. This is difficult to read.
"~~~" doesn't change to my name in the <Preview> anymore, only in the <Save>.
This is largely cosmetic, but I still find the change undesirable.
The red colour of unwritten links is different from before --
in fact, hard to distinguish from the purple colour of followed links.
(The purple is provided by my browser, of course, but is very common.
This is M$IE 5 for SunOS Unix. Netsacpe 4.5 looks better than this,
but still worse than before.)
BTW, I haven't had any problems with response times --
indeed, <130.94.122.197> is much faster than <www.wikipedia.com>!
-- Toby Bartels
toby(a)math.ucr.edu
>> You know what would make writing unambiguous links easier?
>> I'd like to say "[[Mercury (planet)|Mercury]]" without
>> repeating "Mercury"...
That was actually one of my major motivations for rewriting
the software...it's been discussed on the list more times than
I can count.
How I implemented it in the new code is like this: a link in
the form [[mercury (planet)|]] (i.e., with an empty text form)
will be converted to [[Mercury (planet)|mercury]] upon save;
the context is just dropped for the text form. a link like
[[|mercury]] (i.e. with a text form but empty link) well be
replaced by [[Mercury (context)|mercury]] if the page has a
context in parentheses, or just [[mercury]] if it doesn't.
So, for example, the link [[|call]] on the page "Raise (poker)"
will be replaced with [[Call (poker)|call]].
I'm about to announce the running installation of the new
sofware on the new server soon--keep an eye out for it so you
can do some testing.
0
On Monday 01 July 2002 07:34 am, you wrote:
> I'd also like to suggest that in cases where one context of an article
> title is particularly prominent, we use a "disambiguation BLOCK" instead
> of a page -- that is, open with the standard disambiguation text and
> links, but run the principal article below on that page.
>
>
> tarquin
Sounds good to me - just have to work some type of acceptable format.
--maveric149
>OK... I guess I misunderstood. Sorry to make a fuss.
If you think usage of Netscape 4.X is high enough that
a lot of users will complain or (worse) silently go away,
then it might be worth, say, changing the default
settings, or finding a different solution. I do /want/
it to work well for everyone, I'm just resigned that it
isn't possible to make everyone happy--but it may very
well be possible to make more people happy than I am now.
0
> LOTS of people (like my whole family) use Netscape 4.7 and have
> no intention of upgrading it... it may be old but it's hardly
> obsolete, and I would suggest that it is not good policy to
> deliberately make the pedia inaccessible to ANY major browser.
I agree, and I tested with Netscape 4.7. The site is totally
usable and functional with Netscape 4.7--just not the sidebar.
The site is quite usable with the sidebar turned off, and works
great even with Lynx, which I also tested. The site is 100%
validated HTML 4, and will always be available from any browser.
The sidebar is an "extra" feature that may only work on more
standards-compliant ones (and actually it too works fine in
Lynx--which is better than Netscape in that regard). If I can
figure out how to get one of the sidebar options to work with
Netscape as well without screwing up modern browsers, I'll be
happy to do that too, but I haven't figured it out yet--the code
is good, Netscape just can't handle it.
It is not possible to make every feature, every user setting,
and every skin in all combinations work on all browsers. And it
would be equally bad policy to tell users of modern browsers
that we won't implement a feature for them just because some
people with old versions of Netscape won't be able to use it.
0
> In Netscape (which I tried first, intending to try to upload
> the Arabic-named file which I couldn't in Konqueror),...
Netscape 4.X has problems with the sidebar that I'm not going
to fix, especially a version as ancient as 4.08. 4.7 was for a
long time a mainstay of Unix machines, so I want the system to
be usable there, but there's two ways to do that: don't use the
quickbar at all (it can be turned off and the site should be
quite usable without it), and move to Mozilla, which should be
available on all those Unix boxes now.
> In Konqueror, the navbar is on the left before logging in and
> on the right after. Nothing is covered up.
Sounds normal. Before you log in, the system uses default settings
which are Standard skin and fixed-left quickbar. You probably have
quickbar set to right in your preferences, so it moves after you
log in.
0
A bug was just found in the way I converted the old database, causing
it to not update the fulltext index correctly, causing search to
fail. I'm going to have to recovert, so the new server will be
offline for 2-3 hours while that runs.
0
> I am now working at home, and the speed is a little better, but
> not what I had on the piclab server. What I get is the header and
> the sidebar, then a brief pause, then the title and a little text,
> then a long pause, some more text, another pause etc.
Curiouser and curiouser. The way the code works, it accumulates
the text for the page as the script runs, then sends it all at
once. Timing numbers look good for recent accesses, so something
is slowing down after the script finishes.
0
Yes, very odd. The timing log file looks like this:
0.38 /wiki/Main_Page
0.04 /w/wiki.phtml?title=Special:Userlogin&returnto=Main_Page
0.05 /w/wiki.phtml?
title=Special:Userlogin&action=submit&returnto=Main_Page
0.38 /wiki/Main_Page
0.04 /w/wiki.phtml?title=Main_Page&action=edit
0.21 /wiki/Main_Page
0.49 /wiki/Special:Randompage
0.06 /wiki/Faunus
0.05 /wiki/Special:Specialpages
0.34 /wiki/Special:Recentchanges
0.04 /wiki/Special:Statistics
0.04 /wiki/Special:Specialpages
0.49 /wiki/Special:Randompage
0.05 /wiki/Michigan_Technological_University
0.04 /w/wiki.phtml?
title=Special:Whatlinkshere&target=Michigan_Technological_University
0.50 /wiki/Michigan
0.05 /w/wiki.phtml?
title=Special:Recentchangeslinked&target=Michigan
0.16 /wiki/Special:Recentchanges
Which continues for a while, and then suddenly:
0.03 /w/wiki.phtml?title=Special:Userlogin&returnto=Main_Page
0.04 /w/wiki.phtml?
title=Special:Userlogin&action=submit&returnto=Main_Page
5.92 /wiki/Main_Page
0.86 /wiki/white
0.04 /wiki/Special:Preferences
0.06 /wiki/white
0.47 /wiki/Special:Randompage
3.55 /wiki/Hamas
0.06 /wiki/white
94.11 /wiki/Main_Page
83.64 /wiki/white
31.58 /wiki/Wikipedia:Sandbox
18.02 /wiki/white
1.55 /w/wiki.phtml?title=Wikipedia:Sandbox&action=edit
11.32 /wiki/Wikipedia:Sandbox
14.47 /wiki/white
0.04 /wiki/Special:Preferences
0.06 /wiki/white
0.04 /w/wiki.phtml?title=Special:Preferences&action=submit
0.06 /wiki/white
11.06 /wiki/Wikipedia:Sandbox
294.70 /wiki/Special:Unusedimages
0.55 /
...and then it goes back to normal 0.1s, etc.
The numbers represent the seconds between the main script
starting and the output being sent to the user, so it reflects
the time taken by the script itself and by the database queries
needed by the page. So maybe there's something in the way the
database is configured that's causing it to slow down sometimes.
I may have to put in some more detailed traces.
> That's very disturbing, yes. I will check into it. Bomis itself
> sits in the same cage on the same network segment, and is fast.
> So that can't be it, or anyhow that shouldn't be it.
>--Jimbo
>
>Magnus Manske wrote:
>
>> I just started testing the new server, or I would have liked to,
>> but is really awfully slow. It repeatedly refused connection, and
>> when it displays pages at all, it does so very slowly.
>> I know that's not the fault of the script (it was much faster on
>> the piclab server), and not my Internet connection either (other
>> sites work with normal speed). It probably ain't the new server,
>> either. So, could it be the Bomis bandwidth? That could explain
>> the "getting stuck" of the current software as well.
0
Yes, very odd. The timing log file looks like this:
0.38 /wiki/Main_Page
0.04 /w/wiki.phtml?title=Special:Userlogin&returnto=Main_Page
0.05 /w/wiki.phtml?
title=Special:Userlogin&action=submit&returnto=Main_Page
0.38 /wiki/Main_Page
0.04 /w/wiki.phtml?title=Main_Page&action=edit
0.21 /wiki/Main_Page
0.49 /wiki/Special:Randompage
0.06 /wiki/Faunus
0.05 /wiki/Special:Specialpages
0.34 /wiki/Special:Recentchanges
0.04 /wiki/Special:Statistics
0.04 /wiki/Special:Specialpages
0.49 /wiki/Special:Randompage
0.05 /wiki/Michigan_Technological_University
0.04 /w/wiki.phtml?
title=Special:Whatlinkshere&target=Michigan_Technological_University
0.50 /wiki/Michigan
0.05 /w/wiki.phtml?
title=Special:Recentchangeslinked&target=Michigan
0.16 /wiki/Special:Recentchanges
Which continues for a while, and then suddenly:
0.03 /w/wiki.phtml?title=Special:Userlogin&returnto=Main_Page
0.04 /w/wiki.phtml?
title=Special:Userlogin&action=submit&returnto=Main_Page
5.92 /wiki/Main_Page
0.86 /wiki/white
0.04 /wiki/Special:Preferences
0.06 /wiki/white
0.47 /wiki/Special:Randompage
3.55 /wiki/Hamas
0.06 /wiki/white
94.11 /wiki/Main_Page
83.64 /wiki/white
31.58 /wiki/Wikipedia:Sandbox
18.02 /wiki/white
1.55 /w/wiki.phtml?title=Wikipedia:Sandbox&action=edit
11.32 /wiki/Wikipedia:Sandbox
14.47 /wiki/white
0.04 /wiki/Special:Preferences
0.06 /wiki/white
0.04 /w/wiki.phtml?title=Special:Preferences&action=submit
0.06 /wiki/white
11.06 /wiki/Wikipedia:Sandbox
294.70 /wiki/Special:Unusedimages
0.55 /
...and then it goes back to normal 0.1s, etc.
The numbers represent the seconds between the main script
starting and the output being sent to the user, so it reflects
the time taken by the script itself and by the database queries
needed by the page. So maybe there's something in the way the
database is configured that's causing it to slow down sometimes.
I may have to put in some more detailed traces.
> That's very disturbing, yes. I will check into it. Bomis itself
> sits in the same cage on the same network segment, and is fast.
> So that can't be it, or anyhow that shouldn't be it.
>--Jimbo
>
>Magnus Manske wrote:
>
>> I just started testing the new server, or I would have liked to,
>> but is really awfully slow. It repeatedly refused connection, and
>> when it displays pages at all, it does so very slowly.
>> I know that's not the fault of the script (it was much faster on
>> the piclab server), and not my Internet connection either (other
>> sites work with normal speed). It probably ain't the new server,
>> either. So, could it be the Bomis bandwidth? That could explain
>> the "getting stuck" of the current software as well.
0