Wikitech-l February 2002

wikitech-l@lists.wikimedia.org

10 participants
70 discussions

Versions of software
by Axel Boldt 18 Feb '02

18 Feb '02

What versions of apache, php and mysql is everybody using? I want to include the most appropriate versions in the README. Myself: # ../bin/mysqld --version ../bin/mysqld Ver 4.0.0-alpha for pc-linux-gnu on i686 http://127.0.0.1/server-status Server Version: Apache/1.3.20 (Unix) PHP/4.0.6 I suspect that my intermittent database problems have to do with the 4.0.0 mysql and its handling of fulltext indices. I'll downgrade shortly. Axel

3 2

repeated mysql_select_db() calls
by Axel Boldt 18 Feb '02

18 Feb '02

Hi, I started my mysqld with --log and found that we are constantly and pointlessly selecting the wiki database. I combined all those calls in getDBconnection() and made sure that we only call mysql_select_db() and mysql_pconnect() when we really need to (i.e. once), using a new global $wikiDBconnection. Axel

1 0

Boolean search
by Larry Sanger 17 Feb '02

17 Feb '02

Boolean searching would be cool. If not that, then at least "search within results." Larry

2 2

Sysop status
by Larry Sanger 15 Feb '02

15 Feb '02

For a few glorious days, I had sysop status. I no longer do. Magnus knows at least a little about the problem, but if any of you know as well and can fix the problem, that would be great. The problem might be related to a login problem we still have. When I go to any page and press "Log out" and then "Log in", I come to a page that says: "User Larry_Sanger1, you are already logged in!" If I then attempt to log in as "Larry Sanger", which I *suspect* (don't know) has sysop status (whereas "Larry_Sanger" does not), it tells me: "Larry Sanger, you are logged in!" Moreover, the link in the upper right hand corner is to "Larry Sanger"'s homepage. Hopefully, I then go back to the Main Page only to find that I am once again "Larry_Sanger" (so says the upper right corner link) and do not have sysop privileges.

1 0

Problems with saving changes?
by Axel Boldt 14 Feb '02

14 Feb '02

I am running the current CVS version locally and updated my database scheme. Search, RecentChanges, edit and preview works fine, but if I try to save my changes, they are all lost and the file is back to the previous version. It doesn't happen for all files, and I don't know what the difference is (two example problem files are the main page and "British Queen"). It's not a browser cache issue, since when I try to edit the page again, the wiki text is also reverted to the old version. I can write to the database, since the page counters change correctly. Does anybody see that problem? Axel

1 0

Sourcing in wikiTextEn.php later
by Axel Boldt 14 Feb '02

14 Feb '02

With my new checkin permission, I went to work happy as a clam. I added a README file and the GPL license in COPYING. The file wikiTextEn.php uses the $THESCRIPT variable, and it therefore has to be included at the end of wikiSettings.php, after wikiLocalSettings.php has been read. I made a new variable $wikiLanguage which can be set in wikiLocalSettings and which determines which wikiText file is included later. Axel

2 1

Re: [Wikitech-l] about changing edited text
by Brion Vibber 14 Feb '02

14 Feb '02

On mer, 2002-02-13 at 17:24, Jimmy Wales wrote: > Brion Vibber wrote: > > I'm not sure what advantage would be gotten out of storing a version > > that has had HTML tags worked over, but still needs the wiki code > > converted into HTML every time we load it. We get more speed by caching > > the completely parsed version, or more storage savings by reparsing it > > every time and not storing anything but the the editable text. > > It's worth noting that on the live server, I see no material difference when > I turn caching on or off. Interesting. I have to wonder whether this means caching is for some reason not working at all... It seems to be disabled and/or broken at the moment, unless someone sneaked in and fixed the other-languages bug while I wasn't looking. I ran "ab -n 10" on a couple pages running on my test server with various states: caching on, caching off w/ no removeHTMLtags() call, caching off with the old removeHTMLtags() code, and caching off with my new as-yet unoptimized but more secure version of removeHTMLtags(). The pages per second figures from three trials each: Beryllium (large HTML table, various other tags) * cached 2.06 2.06 2.16 * none 0.94 0.95 0.95 * old 0.90 0.90 0.89 * new 0.47 0.48 0.48 Esperanto-wiki mainpage: (a few <b>, <i>, and <font> tags) * cached 3.26 3.13 3.47 * none 1.84 1.83 1.76 * old 1.82 1.80 1.80 * new 1.58 1.62 1.58 > Also, space is really cheap these days. And we're not in any immediate danger > of running out of it. Very true. -- brion vibber (brion @ pobox.com)

3 5

about changing edited text
by Chuck Smith 14 Feb '02

14 Feb '02

> > So, if these HTML tags are *never* used anyway, > why can't we replace them > > with < and > just prior to saving an edited > article? > > I just have two objections: > > First, it violates the principal of least surprise; > the user doesn't get > the same thing upon a re-edit that they left during > the last edit. This > is particularly annoying for people who are putting > complicated tables > into articles (cf. [[Beryllium]] and [[Periodic > Table]]) -- if they do > one thing wrong, POOF! Half their table <tags> > suddenly turn into > <tags> and instead of fixing one tiny mistake, > they fix one tiny > mistake AND change a lot of <>s back into <>s. > Conclusion: bad for users. > > Second, enforcing the limited subset HTML is just a > part of the wiki > parsing. Doing that on save is fine, but is > basically doing half the > parsing job and caching that, then doing the other > half when we display > the page. Why stop there, when we could just parse > the wiki-specific > code while we're at it and save the final result? > Conclusion: what exactly is our goal here? To save > processing time on > page load? This is most effectively done by caching > the completely > parsed version, both HTML and wiki -> HTML. My first thought when I read this was to have two seperate versions of the page. One for the server and one for the editor. Basically when someone saves a page, this creates an html page and saves a seperate wiki page. This way all processing would be done only when someone saves a page rather than everytime someone loads a page? Is there a flaw in my reasoning other than the database doubling in size? I guess it depends on which is more important: space or speed? Chuck ===== Venu al la senpaga, libera enciklopedio esperanta reta! http://eo.wikipedia.com/ ==== Junuloj! Filadelfio, Usono 15an-17an de Februaro http://unumondo.com/cgi-bin/wiki.pl?Filadelfia_JES _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com

2 1

Faster! Thanks!
by Larry Sanger 13 Feb '02

13 Feb '02

Just as the announcements page says, Wikipedia is a lot faster now. Thanks to everyone who made it possible. A quick-loading Recent Changes page is a beautiful thing. Larry

3 2

Slow parser
by Magnus Manske 13 Feb '02

13 Feb '02

I just ran "ab n=10" for an atricle (with cache turned off) and deactivated some functions to see where the slow parts are. Full rendering : 4.99 sec removeHTMLtags turned off : 3.319 sec It seems removeHTMLtags is responsible for 1/3 of the *total* runtime, which includes apache, php calling, and a thousand other things that can't be avoided. So, if these HTML tags are *never* used anyway, why can't we replace them with < and > just prior to saving an edited article? I'll be gone tomorrow until Saturday, and I doubt I can hack it today, so it's up to you... Magnus

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2002