Sean Barrett wrote:
>I take back nine-tenths of my earlier comment; you've done a fine job of
>incorporating the subpages. I have deleted all of them except
>Government and Geography, and I'll delete them Real Soon Now.
Aren't we supposed to redirect these instead of deleting them,
in case search engines have indexed them?
BTW, you missed [[/History]], probably because it isn't an orphan.
But it's been incorporated just like all of the others.
I made it a redirect for now.
-- Toby Bartels
I have integrated the subpages of [[Svalbard]] into the main article.
Every time I try to delete the subpages, I get a 404 error. But as long as
them there, people keep putting them back into the [[Svalbard]] article,
the comments on the talk page.
Can someone go into the database and get rid of these pages, so they'll stop
turning up in "orphans".
On Friday evening, a sad confession, indeed... I'm having no trouble
accessing Wiki. Somehow it's a volume problem I think. Which doesn't mean
the situation could not somehow be handled. It may be not just the number
of connections but also some grinding away process that's happening.
>>Also see this (but it's commercial, except for limited
>>exceptions, and there's no source).
>>Available in HTML and MathML versions.
>There was lots of discussion about that too (there's a
>Wikipedia page for it--check it out), but that's not an
>acceptable option because it requires Windows-only fonts.
Here's a nasty idea: use big PNGs, resized downwards to fit, for the
awkward characters (like square root and integral),
and use standard HTML tables, entities, etc, for the rest. It's not
quite as daft as it seems: only a few big PNGs would be needed, and they
would be cached by browsers.
Probably only worth considering to reject it, though: making it work
right on every browser and font set would be a nightmare, and I still
like the MathML / image combo best.
> Something just occurred to me: what about if, when we migrate
> to the new software, we have the "upload files" link be an
> option that is by default off...
I can certainly see removing it from the sidebar, since it can
be accessed through "special pages" anyway, and sidebar space is
at a premium. But I don't think it will be too much of a problem
to still allow anyone to use it when (1) it should no longer be
indexed by robots and (2) it will be a lot easier to clean up.
The only objection I can see is from regular "good" uploaders
who will have to go through an extra step to get there. I don't
want to get too crazy with user options either.
Hm, but another thing would have to happen for that to work: the actual page to upload would have to return an error message to people not logged in: "this function is not available to you because you are not logged in." Otherwise I could, for instance, put the upload files link on my user page and then it would get indexed anyway.
Hm, maybe just a robots.txt could take care of it? Or would both be better?
>>Something just occurred to me: what about if, when we migrate to the new software, we have the "upload files" link be an option that is by default off. That way the upload link will fall off the search engine
>That's an excellent idea!
A few problems I thought were important enough to fix: the quickbar on
Netscape 4.X (turned out to be an easy fix), additional page-bottom
links, CB indenting of lists, some validation tweaks, and redirects in
"what links here". In this last case I made it recursive, showing
three levels of links to redirects in-order.
I also expanded the logfile, which could be good or bad--because it
grows awfully fast, especially with a few instances of that python
script running. I'm managed to get a megabyte of logfile without any
slowdowns, but I imageine a full day or real user access may reveal
The slowest page in general is "Wanted pages", but I can't tell that
it's affecting throughput in general. Again, if we see slowdowns
tomorrow on general pages we may find out more.
As before, the test site is http://18.104.22.168/
I'm leaving at least one instance of the stressbot running. Others
are welcome, but I'm interested in realistic access at the moment.
Thanks for the reproduction steps--turns out this is the same
bug that Karen ran into: that a newly created page that previously
had broken links to it was not getting those links made "live".
That's been fixed now.
> I still think the script should disallow redirects to redirects,
> but anyways, here's a small bug: (if you think it's a big one I'll
> add it to bug tracker)
It does ignore double-redirects, and always has. I don't know
what you mean by "disallow"...I could intercept the page-save
function and check to see if the page being saved is a redirect
to a redirect and fail to save it, but that would be throw away
user edits that might be valuable, and it still wouldn't catch
the case where the user saved a redirect to a full page, then
edited that full page to be a redirect.
The reason I only went three levels of recursion on the what
links here page is that that's enough to spot double-redirects
and fix them.
> [what links here] is not correct because the redirect from
> "Redirect to a redirect" is missing.
You somehow managed to create the "Redirect to a redirect"
page without updating the link tables. I'm curious how you
managed that. When I edited that article and resaved it. it
>Fred, I understand your frustration. Part of that's unavoidable when
I know you do. ;-) We edit-conflicted each other probably 20 times just on September 11.
>with a wiki. In fact, it's much of the benefit. However, if you're working
>on a complicated article and would like people to stay away for a little
>bit, ask people to do so in the Talk for that article. It's always
or sometimes even in the comments--a simple "still working on this" usually works. Or you can write it offsite and upload all at once--I've done that too.