MediaWiki-l October 2011

mediawiki-l@lists.wikimedia.org

54 participants
52 discussions

Re: [Mediawiki-l] MediaWiki 1.18 release plans
by Sam Reed 27 Oct '11

27 Oct '11

I was planning on working on the 1.18 release last week, however most of my time was absorbed with Contest related work, meaning this didn't happen. As of writing this email, there are 27 outstanding revisions tagged as 1.18 [1]. 26 are new, one is fixme. All revisons don't have to be merged to the REL1_18 branch at this point. Any major bugs that have been in fixed (that are applicable in 1.18) should be backported if they haven't been already. Helps limit the number of duplicate bug reports we may get. On the bug front, there are numerous outstanding bugs, not all of these need to be fixed for 1.18 [2][3]. Please feel free to remove them from being tarball blockers The intention is to push a beta out this week (today? maybe.. Certainly by the end of the week) Certainly, if anyone knows of anything that really "needs" to be in the beta, please let me know ASAP. Sam [1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/1.18 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=28425 - Tarball bugs [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=29876 - WMF Deployment related bugs

1 0

MediaWiki performance tuning - the next step?
by Daniel Barrett 27 Oct '11

27 Oct '11

I run a MediaWiki 1.17.0 site for 3000 users (see the architecture below) and would appreciate some tips on improving performance. Specifically, what should we try next, given our current setup? (I have read http://www.mediawiki.org/wiki/Manual:Performance_tuning.) The platform is a single VMware virtual machine (CentOS Linux 5.6) with two CPUs (2.5GHz Opteron) and 3 GB RAM. The whole MediaWiki/LAMP stack runs on this VM, including mySQL. This is on a fast intranet, so network speed is not an issue. Other statistics include: * Page views per day: 22,000 (about 30 hits per minute during peak hours) * Edits per day: 1200 * Users: 1800 registered editors and 1200 anonymous readers * Titles: 100,000 * Revisions: 850,000 * Page rendering time (based on the embedded HTML comment at the bottom of each page) is about 0.25 to 0.5 seconds today. * System load average usually runs between 1.00 and 4.00. A little swapping occurs (around 135MB swap in use) * RAM buffers free: around 2.3 GB right now. * PHP 5.33, mySQL 5.0.77, httpd 2.2.3 For caching, we use eAccelerator (huge improvement) and $wgMainCacheType = CACHE_ACCEL. Another important detail: Unlike Wikipedia (and most other wikis), approximately 10,000 of our pages make live SQL queries to non-MediaWiki databases, pull in the results, and display them to the user. This is important for our business, and our users are accustomed to seeing up-to-the-second live data. (So we have not investigated Squid, for example, which I think would cache the rendered pages and therefore lose the "up-to-the-second" live data.) The problems I am seeing are: * Sometimes an individual "Save Page" operation will sit for 20-30 seconds before completing. * Occasionally some pages take a long time to render (10-15 seconds) for no discernable reason. (This is not due to the live SQL queries mentioned above.) I'd like to eliminate these delays and decrease page rendering time to 0.1 second or less. I have determined that our extensions do not slow the wiki down much. After removing all of them, the speed stays about the same. Given our architecture, what's the best next step we should investigate to improve performance? * File cache or Squid? (And is there some easy way to tell Squid to exclude our dynamic SQL pages? They all run a particular wiki extension, so if there's something programmatic we can do in the extension, that's great. I am not very familiar with Squid.) * memcached? * Increase number of CPUs? * Multiple front-end servers? * Change from a VM to a physical machine? * Move mySQL to a separate server (possibly physical)? * Something else? What additional measurements would be most helpful in making this decision? Thanks for any advice, DanB

2 1

Extension:Chemistry question
by John W. Foster 26 Oct '11

26 Oct '11

I'm getting this error when I run Update.php on my site. > myname@mysystem:/home/myname# php /home/myname/mediawiki-1.17.0/maintenance/update.php > PHP Warning: include(/home/frosty/mediawiki-1.17.0/extensions/Chemistry/ChemicalSources.alias.php): failed to open stream: No such file or directory in /home/myname/mediawiki-1.17.0/includes/LocalisationCache.php on line 411 > PHP Warning: include(): Failed opening '/home/myname/mediawiki-1.17.0/extensions/Chemistry/ChemicalSources.alias.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /home/myname/mediawiki-1.17.0/includes/LocalisationCache.php on line 411 > MediaWiki 1.17.0 Updater > I am trying to install Extension:Chemistry & getting this error. Any ideas on how to fix this? I have the required entries in LocalSettings.php > require_once("$IP/extensions/Chemistry/ChemFunctions.php"); > > # (for the ChemFunctions tags) > > require_once("$IP/extensions/Chemistry/SpecialChemicalsources.php"); > > # (for the Special:Chemicalsources page)

2 4

MediaWiki 1.18 release plans
by Jeroen De Dauw 26 Oct '11

26 Oct '11

Hey, I'm curious to what the release plans for 1.18 are. 1.18wmf1 has been deployed on the wmf wikis, but still there is no beta release for 1.18. For when is such an initial beta planned, and what's the target data for the actual 1.18 release? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

10 11

can't block edit war
by Helmut Hullen 25 Oct '11

25 Oct '11

Hallo, I have (since some months) problems with a machine/robot which fills some pages with pure nonsense (and deletes sometimes the old contents). http://arktur.de/Wiki MediaWiki 1.17.0 >From the log file, from perhaps hijacked clients: 46.100.171.23 - - [22/Oct/2011:02:15:20 +0200] "GET /Wiki/index.php?title=Zusatzprogramme:kopiere&action=edit HTTP/1.1" 200 15984 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" 46.100.171.23 - - [22/Oct/2011:02:15:34 +0200] "POST /Wiki/index.php?title=Zusatzprogramme:kopiere&action=submit HTTP/1.1" 302 - "http://arktur.de/Wiki/index.php?title=Zusatzprogramme:kopiere&action=edit" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" 46.100.171.23 - - [22/Oct/2011:02:15:42 +0200] "GET /Wiki/index.php?title=Zusatzprogramme:kopiere HTTP/1.1" 200 11027 "http://arktur.de/Wiki/index.php?title=Zusatzprogramme:kopiere&action=edit" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" 46.100.171.23 - - [22/Oct/2011:02:15:47 +0200] "GET /Wiki/index.php?title=Zusatzprogramme:kopiere HTTP/1.1" 200 10593 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" 203.160.123.161 - - [22/Oct/2011:02:32:52 +0200] "GET /Wiki/index.php?title=Texte:Rembo-Installation&action=edit&section=1 HTTP/1.1" 200 15440 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" 203.160.123.161 - - [22/Oct/2011:02:32:57 +0200] "POST /Wiki/index.php?title=Texte:Rembo-Installation&action=submit HTTP/1.1" 302 - "http://arktur.de/Wiki/index.php?title=Texte:Rembo-Installation&action=edit&…" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" 203.160.123.161 - - [22/Oct/2011:02:33:07 +0200] "GET /Wiki/index.php?title=Texte:Rembo-Installation HTTP/1.1" 200 41623 "http://arktur.de/Wiki/index.php?title=Texte:Rembo-Installation&action=edit&…" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" 203.160.123.161 - - [22/Oct/2011:02:33:14 +0200] "GET /Wiki/index.php?title=Texte:Rembo-Installation HTTP/1.1" 200 41183 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" The "POST" operation shows the return level 302, but the page is changed. I've included "ConfirmEdit" and "MathCaptcha" - doesn't help. Maybe "MathCaptcha" doesn't work ... Allowing write access only for registered users doesn't help. Where's the hidden entry for this nasty robot? Viele Gruesse! Helmut

3 3

MediaWiki unit testing and non-MySQL databases
by Brion Vibber 25 Oct '11

25 Oct '11

Hey all -- I've got a stack of issues discussed during the last couple months' conferences and hackathons to raise, so there may be a few more manifestos on the way. But don't worry, this one will be short! I had a great chat at the New Orleans hackathon with D J Bauch who's been working on maintaining MediaWiki's MS SQL Server support, and also had a very useful email chat a couple weeks back with Freakalowsky who's put a lot of work into MediaWiki's Oracle support. Long story short: though traditionally MediaWiki developers have put very little work on our own into maintaining non-MySQL compatibility, there's still lots of folks interested in running on them... AND THEY ACTUALLY MOSTLY WORK! At this point I think it's a bit crazy of us to keep on marginalizing that code; some folks running their own instances will need or want or prefer (or be forced by office IT) to run on some "funny" database, and we shouldn't stand in their way. More importantly, keeping things working with multiple DB backends helps us to keep our code cleaner, and reduces our own hard dependencies on a particular product line. There are two main impediments to keeping code working on non-MySQL platforms: * lazy code breakages -- us MySQL-natives accidentally use MySQL-isms that break queries on other platforms * lazy schema updates -- us MySQL-natives add new schema updates into the system but only implement them for MySQL The first could often be helped simply by having automated testing run to make sure that relevant code paths get exercised. Often there's just a function that's used, or lazy use of LIMIT/OFFSET, or GROUP BY in a form that other databases are pickier about. Just flagging them from the testing can often be enough to make it easy to fix. The second is a bit harder, but again testing can help flag that something needs to be updated so it doesn't wait until too late for the next release, or something. I'd like for everybody who's working on MediaWiki on non-MySQL databases to make sure that the phpunit test suite can run on your favorite platform, so we can see about getting them set up in our regular reports on http://integration.mediawiki.org/ci/ Green bars are your friend! :) -- brion

3 2

Re: [Mediawiki-l] MediaWiki-l Digest, Vol 97, Issue 9
by Norman 23 Oct '11

23 Oct '11

Dear Group. Last night, I spoke with my webhosting technical support (iPower.com) and was told that their servers are running php5.2.17, and they have no plans to upgrade to php5.2.9, which is what mediawiki requires. So I presumed that there was not way to make it work on iPower servers and so I uninstalled it. The wiki that is current up is PmWiki, which seems to run perfectly fine but without some features of mediawiki which I like a lot better. I thought about installing legacy version of mediawiki 1.6.5? but the warnings of insecurity scared me out of that. Thanks for looking into it but without the proper modules, I guess having mediawiki hosted at my account is not possible and I just paid for 2yrs too so no chance of moving. :( Norm T. ===================== On Thu, Oct 20, 2011 at 6:12 AM, <mediawiki-l-request(a)lists.wikimedia.org> wrote: > Send MediaWiki-l mailing list submissions to > mediawiki-l(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > or, via email, send a message with subject or body 'help' to > mediawiki-l-request(a)lists.wikimedia.org > > You can reach the person managing the list at > mediawiki-l-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MediaWiki-l digest..." > > > Today's Topics: > > 1. Re: PostgreSQL error (John W. Foster) > 2. Re: Upgrading to 1.17 (Brion Vibber) > 3. Re: Upgrading to 1.17 (Eric Armstrong) > 4. Re: MW seems to get confused when IP address of client > machine changes while user is logged in (Brion Vibber) > 5. Problem with user page, talk page, other pages, not > displaying (Norman) > 6. Re: Problem with user page, talk page, other pages, not > displaying (Daniel Barrett) > 7. Re: Problem with user page, talk page, other pages, not > displaying (Steve VanSlyck) > 8. Re: Problem with user page, talk page, other pages, not > displaying (Daniel Barrett) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 19 Oct 2011 09:49:47 -0500 > From: "John W. Foster" <jfoster81747(a)gmail.com> > Subject: Re: [Mediawiki-l] PostgreSQL error > To: MediaWiki announcements and site admin list > <mediawiki-l(a)lists.wikimedia.org> > Message-ID: <1319035787.3926.12.camel(a)beast.home> > Content-Type: text/plain; charset=UTF-8 > > On Mon, 2011-10-17 at 16:47 -0400, Bret Bailey wrote: >> I changed my media wiki configuration. I am now trying to install it with mysql database. I have the everything installed, but when I go to the main page, I get the following error: >> >> A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: >> >> (SQL query hidden) >> >> from within function "IndexPager::reallyDoQuery (LogPager)". Database returned error "1146: Table 'my_wiki.tag_summary' doesn't exist (localhost)". >> >> When I query the mysql database, the tag_summary table is not there. How do I go about getting this data? >> >> Thanks. > -------------------snip------------------------ > Did you do a complete new installation? > With a new database created in MySQL; > Or did you use the postgres database & export it to an .sql backup??? > If you used an exported data base, did you run update.php command > from /yourwikiname/maintenance/?? If not do so. > If you used an exported data base, MY Experience is that you need to use > PhpMyAdmin or some other interface to 'import the backup into your newly > created MySQL database. > If you are starting from a fresh install with a new basically empty > database. then check to see if this is an Extension error message. You > may have installed an extension that is not working properly. Disable it > by commenting it out in LocalSettings.php then restart apache or what > ever web server your using & check it again. > Good Luck > frosty > > > > > ------------------------------ > > Message: 2 > Date: Wed, 19 Oct 2011 10:30:33 -0700 > From: Brion Vibber <brion(a)pobox.com> > Subject: Re: [Mediawiki-l] Upgrading to 1.17 > To: eric(a)longjump.com, MediaWiki announcements and site admin list > <mediawiki-l(a)lists.wikimedia.org> > Message-ID: > <CAFnWYTkAXTLFKFmEQ4dbWnNxv8cHWfVQG_XBx-kfi8_=o_aBbw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Oct 18, 2011 at 6:56 PM, Eric Armstrong <eric(a)longjump.com> wrote: > >> The download page for 1.17 has the (somewhat scary) comment: >> >> >> >> If your MediaWiki installation is heavily modified, it may be difficult to >> incorporate the latest official changes/updates. (So here's version 1.6.5. >> It's good for maybe a year.) >> >> >> >> I accept the need to do whatever integration is necessary-especially since >> the one-year clock has been ticking for a while now--but I need to know: >> >> a) What constitutes "heavy" modification? >> --We have a installed a number of plugins, have defined some variables, >> have created several customized skins. Is that heavy or light? >> > > It's not clear from the above whether you've modified MediaWiki at all, or > if you've just dropped in extensions and skins with no modification > whatsoever. > > If you changed files that were distributed with MediaWiki, then you've > modified it and it's up to you to figure out how to perform those > modifications on the new version. > > Extensions, skins etc can still be problematic, for instance if they make > assumptions about internal interfaces which have changed. Skins are > particularly fragile, as it's a poor interface to begin with and has never > been very stable. > > You're also more likely to see errors related to extensions exacerbated at > upgrade time; for instance if you also upgrade PHP you may encounter new > problems related to changes in PHP's handling of references in function > parameters. You may also find that updates in core that clean up old > incorrect use of references cause extensions that have not been similarly > cleaned up to require modification. > > >> >> b) What, in general, should be the migration process? >> I'm guessing there are other kinds of modifications that could be done. >> So ideally the upgrade notes would include a taxonomy of cases: >> - If you've done "X", you'll need to do "Y". >> > > > 1) Make a testing/staging copy of your site -- if you are not already doing > this you are in trouble :) > > 2) Upgrade the testing/staging copy following standard procedures in the > instructions (pull in updated code, run the updater script) > > 3) Test that everything works. > > If anything doesn't work as expected, debug and fix it. Follow normal > debugging procedures that all software developers and system administrators > are familiar with, such as testing small changes, turning individual pieces > on and off to localize the source of a problem, etc. Make use of error > messages produced directly in output and in system logs. Check the source > code when you see line numbers or backtraces. Google your error messages to > see if people have seen them before. If you are not familiar with how to > find error and system logs from PHP, please check the documentation on > php.net, the documentation for your operating system, or contact your system > administrator for information. > > -- brion > > > ------------------------------ > > Message: 3 > Date: Wed, 19 Oct 2011 11:11:41 -0700 > From: "Eric Armstrong" <eric(a)longjump.com> > Subject: Re: [Mediawiki-l] Upgrading to 1.17 > To: "'Brion Vibber'" <brion(a)pobox.com>, "'MediaWiki announcements and > site admin list'" <mediawiki-l(a)lists.wikimedia.org> > Message-ID: <038401cc8e8a$8dc96980$a95c3c80$@com> > Content-Type: text/plain; charset="UTF-8" > > Really good advice, Brion. Much appreciated. > > (And yes, we are for sure doing the upgrade in a sandbox!) > > :__) > > > > From: brion.vibber(a)gmail.com [mailto:brion.vibber@gmail.com] On Behalf Of Brion Vibber > Sent: Wednesday, October 19, 2011 10:31 AM > To: eric(a)longjump.com; MediaWiki announcements and site admin list > Subject: Re: [Mediawiki-l] Upgrading to 1.17 > > > > On Tue, Oct 18, 2011 at 6:56 PM, Eric Armstrong <eric(a)longjump.com> wrote: > > The download page for 1.17 has the (somewhat scary) comment: > > > > If your MediaWiki installation is heavily modified, it may be difficult to > incorporate the latest official changes/updates. (So here's version 1.6.5. > It's good for maybe a year.) > > > > I accept the need to do whatever integration is necessary-especially since > the one-year clock has been ticking for a while now--but I need to know: > > a) What constitutes "heavy" modification? > --We have a installed a number of plugins, have defined some variables, > have created several customized skins. Is that heavy or light? > > > It's not clear from the above whether you've modified MediaWiki at all, or if you've just dropped in extensions and skins with no modification whatsoever. > > If you changed files that were distributed with MediaWiki, then you've modified it and it's up to you to figure out how to perform those modifications on the new version. > > Extensions, skins etc can still be problematic, for instance if they make assumptions about internal interfaces which have changed. Skins are particularly fragile, as it's a poor interface to begin with and has never been very stable. > > You're also more likely to see errors related to extensions exacerbated at upgrade time; for instance if you also upgrade PHP you may encounter new problems related to changes in PHP's handling of references in function parameters. You may also find that updates in core that clean up old incorrect use of references cause extensions that have not been similarly cleaned up to require modification. > > > > b) What, in general, should be the migration process? > I'm guessing there are other kinds of modifications that could be done. > So ideally the upgrade notes would include a taxonomy of cases: > - If you've done "X", you'll need to do "Y". > > > > 1) Make a testing/staging copy of your site -- if you are not already doing this you are in trouble :) > > 2) Upgrade the testing/staging copy following standard procedures in the instructions (pull in updated code, run the updater script) > > 3) Test that everything works. > > If anything doesn't work as expected, debug and fix it. Follow normal debugging procedures that all software developers and system administrators are familiar with, such as testing small changes, turning individual pieces on and off to localize the source of a problem, etc. Make use of error messages produced directly in output and in system logs. Check the source code when you see line numbers or backtraces. Google your error messages to see if people have seen them before. If you are not familiar with how to find error and system logs from PHP, please check the documentation on php.net, the documentation for your operating system, or contact your system administrator for information. > > -- brion > > > > ------------------------------ > > Message: 4 > Date: Wed, 19 Oct 2011 12:14:00 -0700 > From: Brion Vibber <brion(a)pobox.com> > Subject: Re: [Mediawiki-l] MW seems to get confused when IP address of > client machine changes while user is logged in > To: MediaWiki announcements and site admin list > <mediawiki-l(a)lists.wikimedia.org> > Message-ID: > <CAFnWYTkXDbsi9fE29Mv0sDzO2SXNz8qur1WZDBapwGRnOw6riA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Oct 18, 2011 at 11:36 AM, Dan Nessett <dnessett(a)yahoo.com> wrote: > >> From what I have read, I thought this would fire up the session garbage >> collector on each access and timeout sessions after 60 seconds. It >> appears the latter is true, since if I log in (not setting "remember >> me"), edit a page, wait 60 seconds and try once again to edit the page, >> the latter is disallowed and the resulting response shows me logged off. >> >> However, when I look at the sessions directory, the session created by my >> login is still there. Maybe I don't understand what the garbage collector >> does, but I assumed it would destroy the session record if its lifetime >> exceeded maxlifetime. >> >> I know this is a PHP question, not a MW question, but I was hoping >> someone might fill me in. By the way, I am running PHP 5.3.4. >> > > Off the top of my head I'd guess this: > > * around login time, a session is started: > ** ID is generated: 123456789abcdef > ** session cookie is sent to browser > ** /path/to/sessions/123456789abcdef file is stored with the fresh data > * after a while, some other request comes in > ** session GC runs, removing the file /path/to/sessions/123456789abcdef > * your first browser reconnects, providing a session ID key in its cookie > ** server sees no session with that id, so establishes a new one > ** /path/to/sessions/123456789abcdef file is stored with the fresh data > > Possibly the request to trigger GC was also your own second request. > > -- brion > > > ------------------------------ > > Message: 5 > Date: Wed, 19 Oct 2011 21:09:33 -0700 > From: Norman <analogalley(a)gmail.com> > Subject: [Mediawiki-l] Problem with user page, talk page, other pages, > not displaying > To: mediawiki-l(a)lists.wikimedia.org > Message-ID: > <CAPdC62qFYJUaJ0Hn+qoDaEQBhdGcz3ZZE_B8CY0Tzd1eH9_PuA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Dear Mediawiki support folks; > > Hello. Please, I need help. I installed and have mediawiki up and running. > Problem is that the admin (or user) and My Talk links at the top of > the page result in an error message via both IE and FF. So I guess > that means there is a problem accessing or creating my pages. This > happens whether I am logged in as admin or as another reader/user that > I created. I also notice that a few links on the sidebar have the same > issue; namely community portal and current events (those links were > installed in the default installation). > > On IE, I get a "page cannot be displayed error" > > On FF, I get the following error: "Corrupted Content Error The page > you are trying to view cannot be shown because an error in the data > transmission was detected. The page you are trying to view cannot be > shown because an error in the data transmission was detected.Please > contact the website owners to inform them of this problem." > > Can someone help or shed light on this? I really would like to get > this operating right and am at a loss, struggling big time. :-( > > If you would like to see this issue in action, the URL is > www.analogalley.com/wiki > > Thank you in advance, > N. Tang. > > > > ------------------------------ > > Message: 6 > Date: Thu, 20 Oct 2011 11:26:31 +0000 > From: Daniel Barrett <danb(a)VistaPrint.com> > Subject: Re: [Mediawiki-l] Problem with user page, talk page, other > pages, not displaying > To: "analogalley(a)gmail.com" <analogalley(a)gmail.com>, MediaWiki > announcements and site admin list <mediawiki-l(a)lists.wikimedia.org> > Message-ID: > <68CF225601ADF74BA1F8A2511535F85D0A7CC18D(a)WNDMAIL02.vistaprint.net> > Content-Type: text/plain; charset="us-ascii" > > When I visit Talk:Foo, your webserver is rewriting this to TalkFoo without the colon (:). On Windows, colon is a special character for file paths. So either your webserver configuration is intentionally stripping out colons (say, by a rewrite rule), or your webserver cannot handle colons and is having errors (check your webserver logs for error messages). > > DanB > > > > > ------------------------------ > > Message: 7 > Date: Thu, 20 Oct 2011 08:55:50 -0400 > From: "Steve VanSlyck" <s.vanslyck(a)spamcop.net> > Subject: Re: [Mediawiki-l] Problem with user page, talk page, other > pages, not displaying > To: "MediaWiki announcements and site admin list" > <mediawiki-l(a)lists.wikimedia.org> > Message-ID: <20111020.125550.984.1@LEGAL> > Content-Type: text/plain > > **Who's** webserver? > > ----- Original Message ----- > From: Daniel Barrett <danb(a)VistaPrint.com> > To: "analogalley(a)gmail.com" <analogalley(a)gmail.com>, MediaWiki announcements and site admin list <mediawiki-l(a)lists.wikimedia.org> > Date: Thu, 20 Oct 2011 11:26:31 +0000 > Subject: Re: [Mediawiki-l] Problem with user page, talk page, other pages, not displaying > >> When I visit Talk:Foo, your webserver is rewriting this to TalkFoo without the colon (:). On Windows, colon is a special character for file paths. So either your webserver configuration is intentionally stripping out colons (say, by a rewrite rule), or your webserver cannot handle colons and is having errors (check your webserver logs for error messages). >> >> DanB >> >> >> _______________________________________________ >> MediaWiki-l mailing list >> MediaWiki-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l >> > > > > ------------------------------ > > Message: 8 > Date: Thu, 20 Oct 2011 13:11:58 +0000 > From: Daniel Barrett <danb(a)VistaPrint.com> > Subject: Re: [Mediawiki-l] Problem with user page, talk page, other > pages, not displaying > To: MediaWiki announcements and site admin list > <mediawiki-l(a)lists.wikimedia.org> > Message-ID: > <68CF225601ADF74BA1F8A2511535F85D0A7CC1CC(a)WNDMAIL02.vistaprint.net> > Content-Type: text/plain; charset="us-ascii" > > Steve VanSlyck >>**Who's** webserver? > > The webserver running MediaWiki, in this case, www.analogalley.com. > > DanB > > > > ------------------------------ > > _______________________________________________ > MediaWiki-l mailing list > MediaWiki-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > > > End of MediaWiki-l Digest, Vol 97, Issue 9 > ****************************************** >

4 3

Adjust article content without modifying page_touched
by Zach H. 23 Oct '11

23 Oct '11

So we are currently using the MediaWiki software to run a Knowledge base system and have a policy that says we will review ALL articles that have not been touched in 365 days to ensure they are still relevant. Coming up with the SQL code to find these was very easy, one feature I was asked to implement was 'is it possible to add a "outdated" tag to a article' so I added the {{outdated}} tag to the wiki, now the hard part is, how do I programmatically update the most current revision without adjusting the page_touched date? is it even possible? I know I can do this via SQL but that is VERY kludgy and I can see all sorts of issues this could cause so I wanted to ask the pro's. Thanks for any assistance in advance. Zach H.

5 5

Error when upgrading to 1.17.0 via SVN and running update script
by Morten Blaabjerg 21 Oct '11

21 Oct '11

I get the following error when I attempt to run the update script from the command line after switching via SVN to MediaWiki 1.17.0. Parse error: syntax error, unexpected T_SL, expecting ')' in > /home/public_html/.../public/languages/messages/MessagesDa.php on line 50 > The server runs php5 and either php update.php and php5 update.php yields the same result. Any ideas? Best wishes, Morten Blaabjerg

2 3

Problem with user page, talk page, other pages, not displaying
by Norman 20 Oct '11

20 Oct '11

Dear Mediawiki support folks; Hello. Please, I need help. I installed and have mediawiki up and running. Problem is that the admin (or user) and My Talk links at the top of the page result in an error message via both IE and FF. So I guess that means there is a problem accessing or creating my pages. This happens whether I am logged in as admin or as another reader/user that I created. I also notice that a few links on the sidebar have the same issue; namely community portal and current events (those links were installed in the default installation). On IE, I get a "page cannot be displayed error" On FF, I get the following error: "Corrupted Content Error The page you are trying to view cannot be shown because an error in the data transmission was detected. The page you are trying to view cannot be shown because an error in the data transmission was detected.Please contact the website owners to inform them of this problem." Can someone help or shed light on this? I really would like to get this operating right and am at a loss, struggling big time. :-( If you would like to see this issue in action, the URL is www.analogalley.com/wiki Thank you in advance, N. Tang.

3 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l October 2011