November 2014 - MediaWiki-l - lists.wikimedia.org

MediaWiki-l November 2014

mediawiki-l@lists.wikimedia.org

57 participants
58 discussions

Lis tes messages avant qu'ils ne soient effaces!

by Badoo

Lis ton message de Nganguem Victor avant qu'il ne soit efface! Pour lire ton message, suis simplement ce lien: http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6 D'autres personnes sont aussi presentes: Oded (Tel Aviv, Israel) Priya (Udaipur, Inde) RajaYogi BK (Udaipur, Inde) Karuna (Udaipur, Inde) Chika Reginald Onyia (Pnompen', Cambodge) ...Qui d'autre? http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6 Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur. Tu as recu cet email suite a un message envoye par Nganguem Victor de notre systeme. S'il s'agit d'une erreur, ignore simplement cet email. La requete sera alors effacee du systeme. Amuse-toi bien ! L'equipe Badoo Courrier automatique de Badoo suite a l'envoi d'un message a ton attention sur Badoo. Les reponses ne sont ni stockees, ni traitees. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir: http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…

5?months

Wikibase on third-party wikis

by Till Kraemer

Hi, I'm trying to use Wikibase on my pool wiki and language wikis. In my pool wiki, I can create properties and items, but I can't add site links to them. ID: "Q1", site id: "cswiki", site link: "article name" gives me the error "The specified article could not be found on the corresponding site." even though that article exists on cswiki. I also can't access data from the language wikis. If I use {{#property:P1}} in an article on cswiki, nothing shows up. I downloaded Wikidata-refs-heads-master.tar.gz and extracted it to the extension folder of my pool wiki and language wikis. My LocalSettings.php of the pool wiki looks like this: # Wikibase $wgEnableWikibaseRepo = true; $wgEnableWikibaseClient = false; $wmgUseWikibaseRepo = true; $wmgUseWikibaseClient = false; require_once __DIR__ . "/extensions/Wikidata/Wikidata.php"; require_once __DIR__ . "/extensions/Wikidata/extensions/Wikibase/repo/ExampleSettings.php"; # SiteMatrix Extension require_once "$IP/extensions/SiteMatrix/SiteMatrix.php"; $wgLocalDatabases = array( 'cswiki', 'dewiki', 'enwiki', 'eswiki', 'frwiki', 'huwiki', 'hywiki', 'itwiki', 'nlwiki', 'plwiki', 'poolwiki', 'ptwiki', 'ruwiki', 'srwiki', 'svwiki' ); My LocalSettings.php of the language wikis (cs for example) look like this: # Wikibase Extension $wgEnableWikibaseRepo = false; $wgEnableWikibaseClient = true; $wmgUseWikibaseRepo = false; $wmgUseWikibaseClient = true; require_once __DIR__ . "/extensions/Wikidata/Wikidata.php"; # Settings $wgWBSettings['repoUrl'] = ' http://pool.mypedia.com '; $wgWBSettings['repoScriptPath'] = '/w'; $wgWBSettings['repoArticlePath'] = '/wiki/$1'; $wgWBSettings['siteGlobalID'] = 'cswiki'; $wgWBSettings['repoDatabase'] = 'poolwiki'; $wgWBSettings['changesDatabase'] = 'poolwiki'; # Optional $wgWBSettings['siteGroup'] = 'mypedia'; $wgWBSettings['sort'] = 'code'; //optional $wgWBSettings['sortPrepend'] = array( 'cs' ); In populateSitesTable.php, I changed " https://meta.wikimedia.org/w/api.php " to " http://pool.mypedia.com/w/api.php " and "$validGroups = array( 'wikipedia', 'wikivoyage', 'wikiquote', 'wiktionary','wikibooks', 'wikisource', 'wikiversity', 'wikinews' );" to "$validGroups = array( 'mypedia' );" Do I need to change "$wikiId = $this->getOption( 'wiki' );" too, since it says "wiki" is expanded to "wikipedia"? Table "sites" in the poolwiki database looks like this: site_id | site_global_key | site_type | site_group | site_source | site_language | site_protocol | site_domain | site_data | site_forward | site_config 1 | cswiki | mediawiki | mypedia | local | cs | http:// | com.mypedia.cs. | a:1:{s:5:"paths";a:2:{s:9:"file_path";s:5:"/w/$1";s:9:"page_path";s:8:"/wiki/$1";}} | 0 | a:0:{} [...] 15 | poolwiki | mediawiki | pool | local | en | http:// | com.mypedia.pool. | a:1:{s:5:"paths";a:2:{s:9:"file_path";s:5:"/w/$1";s:9:"page_path";s:8:"/wiki/$1";}} | 0 | a:0:{} I changed site_group "wikipedia" to "mypedia" and added data for site_protocol and site_domain by hand. I noticed that the script path is "/w/$1" here, while $wgScriptPath in LocalSettings.php is actually "/w", could that cause any problems? And should I change site_group of the pool to mypedia like I did with the language wikis or isn't that necessary? Wikibase DataModel 0.8, Wikibase Repository 0.5 alpha, WikibaseLib 0.5 alpha and Wikidata show up in Special:Version of the pool wiki. Wikibase Client 0.5 alpha, Wikibase DataModel 0.8, WikibaseLib 0.5 alpha and Wikidata show up in Special:Version of the language wikis. Any help would be really appreciated! Thanks and cheers, Till

7?years, 8?months

File descriptions aren't fetched

by Till Kraemer

Hi, I'm running multiple language wikis and one pool wiki. The problem is that no file descriptions are fetched in the language wikis although $wgFetchCommonsDescriptions is set to true. LocalSettings.php of the language wikis: $wgUseSharedUploads = true; $wgSharedUploadPath = ' http://pool.example.com/w/images '; $wgSharedUploadDirectory = '/path/to/pool/w/images/'; $wgHashedSharedUploadDirectory = true; $wgFetchCommonsDescriptions = true; $wgSharedUploadDBname = 'poolwiki'; # DB-Name of PoolWiki #$wgSharedUploadDBprefix = 'wiki_'; # Table name prefix for PoolWiki $wgRepositoryBaseUrl = " http://pool.example.com/wiki/Image :"; ForeignAPIRepo used to work fine before, but since I switched from Apache to Nginx, no images show up anymore in the language wikis. This is how my LocalSettings.php used to look like: $wgForeignFileRepos[] = array( 'class' => 'ForeignAPIRepo', 'name' => 'pool', 'apibase' => ' http://pool.example.com/w/api.php ', 'fetchDescription' => true, // Optional 'descriptionCacheExpiry' => 43200, // 12 hours, optional (values are seconds) 'apiThumbCacheExpiry' => 0, // required for local thumb caching ); I also tried to set 'name' => 'poolwiki', (name of the pool database) but that doesn't work either. I also re-started Memcached and I even deleted a file description page from the CloudFlare cache, but still no file description can be seen :/ My software: MediaWiki: 1.22.0 PHP: 5.3.27 (fpm-fcgi) MySQL: 5.1.70-log Any help would be uber-cool. Thanks and cheers, Till

7?years, 8?months

Re: [MediaWiki-l] [Wikitech-l] Requiring PHP >= 5.3.3 for MediaWiki core

by James Forrester

On 24 October 2014 08:41, Chad <innocentkiller(a)gmail.com> wrote: > On Fri, Oct 24, 2014 at 8:12 AM, James Forrester <jforrester(a)wikimedia.org > > > wrote: > > > On 23 October 2014 18:39, Legoktm <legoktm.wikipedia(a)gmail.com> wrote: > > > > > Hi, > > > > > > As part of the librarization project[1], we are planning on taking the > > > CSSJanus library that is currently in includes/lib/ and bringing it in > > > with composer. However, it requires PHP >=5.3.3 in its > composer.json[2]. > > > Krinkle has stated[3] that is due to the fact that it has only been > > > tested on 5.3.3 and higher, and it's also what travis-ci provides. > > > > > > After doing some research[4], it appears that we would be dropping > > > support for Ubuntu 10.04LTS, which has security support until April > > > 2015. MediaWiki 1.25.0 is expected to be released in May 2015. > > > > > > Does anyone have any objections to dropping 5.3.2 support? I've > uploaded > > > [5] that actually increments the required version number. > > > > > > > ?I understood that the vague plan was to switch over to 5.4.x > requirement, > > and that we'd only waited because Wikimedia wasn't ready yet. Has this > > changed? I know a number of people have talked about wanting to use PHP > > traits. > > > > > Yes, but that's longer term. > ?How much longer? 1.25 is May 2015; Wikimedia's ZAP -> HAT migration is nominally to be finished within a month…? > This minor bump still in the 5.3.x branch I think we can do immediately. > ?Sure, if announcing a 1.25 dependency change and then changing the change later won't disrupt people too much. (Copying the main MediaWiki-l list for those who don't follow wikitech-l) ?J.? -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

9?years, 1?month

Missing tests/ directory in 1.23.1-5

by Daniel Renfro

While looking into upgrading my 1.22.5 installation to 1.23.5, I noticed that the tests/ directory was missing. Looking in git it is there for the REL1_23, but seems to have vanished in the tarballs for releases? Am I missing something? or are these releases incomplete? Sincerely confused, -Daniel (Us+er:AlephNull)

9?years, 3?months

[BREAKING CHANGE] Upcoming jQuery upgrade: Removing jQuery Migrate

by Krinkle

Hey all, TL;DR: * We did not make the breaking change last week for Wikimedia; it is postponed. * MediaWiki 1.24.0 will ship with jQuery Migrate switched off. * Wikimedia & non-Wikimedia wikis can enable jQuery Migrate if needed. * When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis. As we said last month, we are upgrading MediaWiki's jQuery to version 1.11.x [1], which removes some long-deprecated functions. These were done in phase one [2] and two [3] as of last week. However, we have held off with phase 3 (removing the jQuery Migrate plugin) for a while to give migration a little more time. The amount of migration work necessary has been much less than I anticipated. Very few scripts have actually needed changing, probably because these features have been deprecated for quite a while now. Some of newer developers may never have even known of these APIs. Having said that, it does take a while for a message like this to spread out to some members of our large community. While those wiki scripts and gadgets which have active maintainers have been looked into, and (where needed) updated accordingly, a large number of gadgets and scripts in the cluster of Wikimedia wikis have not yet had a chance to get a grip on this, let alone extensions and wikis outside of Wikimedia. While I don't want to set another deadline, I think it makes sense to ship the jQuery Migrate plugin for one release (with MediaWiki 1.24), and then remove it in MediaWiki 1.25. This will give all wikis' communities and extension authors a few more months until the MediaWiki 1.24 branch point (in Autumn 2014) before they will need to make adjustments to work with MediaWiki master. MediaWiki 1.24.0 stable will disable support for legacy jQuery by default. If you find you have scripts, gadgets or extensions still using legacy jQuery APIs, you can enable them with a simple line in LocalSettings.php: $wgIncludejQueryMigrate = true; And of course when you find you need to do this, please make an effort to ensure the maintainers of those items still using these legacy features are aware of this so they may patch the code accordingly (using the upgrade guide[4] and my earlier announcement [5]). When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis. ? Krinkle [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44740 [2] https://gerrit.wikimedia.org/r/#/c/131494/ [3] https://gerrit.wikimedia.org/r/#/c/133477/ [4] http://jquery.com/upgrade-guide/1.9/ [5] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg75735.html On 7 May 2014, at 18:29, Krinkle <krinklemail(a)gmail.com> wrote: > Hey all, > > TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This > major release removes deprecated functionality. Please migrate away from this > deprecated functionality as soon as possible. > > It's been a long time coming but we're now finally upgrading the jQuery package > that ships with MediaWiki. > > We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple > of years ago due to lack of time and concern about disruption. Because of this, > many developers have needed to work around bugs that were already fixed in later > versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been > the first release in jQuery history that needed an upgrade guide[1][2]. It's a > major release that cleans up deprecated and dubious functionality. > > Migration of existing code in extensions, gadgets, and user & site scripts > should be trivial (swapping one method for another, maybe with a slight change > to the parameters passed). This is all documented in the upgrade guide[1][2]. > The upgrade guide may look scary (as it lists many of your favourite methods), > but they are mostly just addressing edge cases. > > == Call to action == > > This is a call for you, to: > > 1) Get familiar with http://jquery.com/upgrade-guide/1.9/ . > > 2) Start migrating your code. > > jQuery v1.9 is about removing deprecated functionality. The new functionality is > already present in jQuery 1.8 or, in some cases, earlier. > > 3) Look out for deprecation warnings. > > Once instrumentation has begun, using "?debug=true" will log jQuery deprecation > warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also > find deprecation notices from mediawiki.js, for more about those see the mail > from last October [8]. > > == Plan == > > 1) Instrumentation and logging > > The first phase is to instrument jQuery to work out all the areas which will > need work. I have started work on loading jQuery Migrate alongside the current > version of jQuery. I expect that to land in master this week [6], and roll out on > Wikimedia wikis the week after. This will enable you to detect usage of most > deprecated functionality through your browser console. Don't forget the upgrade > guide[1], as Migrate cannot detect everything. > > 2) Upgrade and Migrate > > After this, the actual upgrade will take place, whilst Migrate stays. This > should not break anything since Migrate covers almost all functionality that > will be removed. The instrumentation and logging will remain during this phase; > the only effective change at this point is whatever jQuery didn't think was > worth covering in Migrate or were just one of many bug fixes. > > 3) Finalise upgrade > > Finally, we will remove the migration plugin (both the Migrate compatibility > layer and its instrumentation). This will bring us to a clean version of latest > jQuery v1.x without compatibility hacks. > > > A rough timeline: > > * 12 May 2014 (1.24wmf4 [9]): Phase 1 ? Instrumentation and logging starts. This > will run for 4 weeks (until June 9). > > * 19 May 2014 (1.24wmf5): Phase 2 ? "Upgrade and Migrate". This will run for 3 > weeks (upto June 9). The instrumentation continues during this period. > > * 1 June 2014 (1.24wmf7) Finalise upgrade. > > > == FAQ == > > Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11? > > A: Those are regular updates that only fix bugs and/or introduce non-breaking > enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any > hassle. We'll be fast-forwarding straight from v1.8 to v1.11. > > > Q: What about the jQuery Migrate plugin? > > A: jQuery developed a plugin that adds back some of the removed features (not > all, consult the upgrade guide[2] for details). It also logs usage of these to > the console. > > > Q: When will the upgrade happen? > > A: In the next few weeks, once we are happy that the impact is reasonably low. > An update will be sent to wikitech-l just before this is done as a final reminder. > This will be well before the MediaWiki 1.24 branch point for extension authors > looking to maintain compatibility. > > > Q: When are we moving to jQuery v2.x? > > A: We are not currently planing to do this. Despite the name, jQuery v2.x > doesn't contain any new features compared to jQuery v1 [3]. The main difference > is in the reduced support for different browsers and environments; most > noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which > MediaWiki is still supporting for now, and is outside the scope of this work. > Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new > features. For example, jQuery released v1.11 and v2.1 together[4][5]. > > -- Krinkle > > [1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate- > final-released/ > [2] http://jquery.com/upgrade-guide/1.9/ > [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/ > [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/ > [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/ > [6] https://gerrit.wikimedia.org/r/131494 > [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md > [8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html > [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap >

9?years, 6?months

MediaWiki Language Extension Bundle 2014.11 release

by Kartik Mistry

Hello all, I would like to announce the release of MediaWiki Language Extension Bundle 2014.11. This bundle is compatible with MediaWiki 1.23.7 and MediaWiki 1.24.0 releases. It should also work with 1.22.14 but we no longer test against it. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.11.tar… * sha256sum: 39b397a05561f743962cfb499f59a58219338607ea13ebfcc7a8806105e7dedc Quick links: * Installation instructions are at: https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n * Report bugs to: https://phabricator.wikimedia.org/ * Talk with us at: #mediawiki-i18n @ Freenode Release notes for each extension are below. -- Kartik Mistry == Babel, CleanChanges and LocalisationUpdate == * Only localisation updates. == CLDR == * Fixed some time displays if CLDR had only partial localisation of time units. == Translate == * Translate WebAPI documentation is now localized. Only works in MediaWiki 1.24 and newer. * Fixed a bug which prevented bootstrapping of shared TTMServer database with the ElasticSearch backend. * If you are using the '''Solr backend '''for the translation memory or the translation search, please let us know. If there are no users for the Solr backend, we will deprecate and later remove it in favor of the better maintained ElasticSearch backend. == UniversalLanguageSelector == * ULS WebAPI documentation is now localized. Only works in MediaWiki 1.24 and newer. * T67516: Removed font-size for ULS language selection panel buttons, which caused tiny font sizes on the Monobook skin. * Small compatibility fix when both ULS and VisualEditor are in use. * About 20 new languages are now supported in the language selector and a couple language names were changes. * A JavaScript error no longer happens on pages without any headings. * Added support for WOFF2 webfont format. Note that there are no WOFF2 webfonts in the font repository yet due to pending issues in WOFF2 font generation. Thanks! -- Kartik Mistry/??????? ???????? | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com

9?years, 6?months

(no subject)

by Bryce Gerhardt

Bryce

9?years, 6?months

MediaWiki 1.24.0 released

by Markus Glaser

Hello everyone, I am happy to announce the availability of the first stable release of the new MediaWiki 1.24 release series. MediaWiki 1.24 is a large release that contains many new features and bug fixes. This is a summary of the major changes of interest to users. You can consult the RELEASE-NOTES-1.24 file for the full list of changes in this version. Our thanks to everyone who helped to improve MediaWiki by testing the release candidates and submitting bug reports. == What's new? == MediaWiki 1.24 includes all changes released in the smaller 1.24wmfX software deployments to Wikimedia sites. == Preferences made easier == MediaWiki is known to be extremely flexible and customisable, but few users use its full potential. In 1.24, we aim to make dozens obscure preferences easily discoverable and obvious to use. == New features == * Category pages can now be moved (bug 5451). * MergeHistory for all administrators by default (bug 66155). * Improvements have been made to the password storage system, allowing improved security against offline attacks should a wiki's database be compromised by attackers. Then, the default password storage algorithm was changed to PBKDF2. PBKDF2 and Bcrypt have built-in support in PHP. The new extensible password API makes it trivial to implement scrypt support if we wanted to. == Usability == * The move feature and other actions are now discoverable in Vector, thanks to a label for the dropdown where they're hidden by default (bug 44591). * Specify default language on a per-page basis * Redirect to Special:UserLogin when logging is in required to proceed, instead of showing an error message == Performance == In 2014, MediaWiki development has a new focus on frontend performance. * (bug 39035) Improved Vector skin performance by removing collapsibleNav, which used to collapse some sidebar elements by default. This removes -list id suffixes like p-lang-list: instead of using things like #p-lang-list, you can do #p-lang .body ul. If you would like CollapsibleNav back please use the CollapsibleVector extension. ==Upgrade notices for MediaWiki administrators== === Breaking changes === * Upgrade jQuery to version 1.11.x: [[mailarchive:wikitech-l/2014-June/076842.html]] * Support for register_globals (deprecated 5 years ago) was dropped, MediaWiki will no longer run with it enabled. * {{!}} is now a magic word that results in |, mainly for use in templates and other complex templates. If your wiki has another template at Template:!, you will need to change the name and update any usage of it. If your Template:! is just |, it can be safely deleted. === API changes === Starting with MediaWiki 1.24, we're cleaning up the API, and working towards an API 2.0. See the roadmap for more details. * Rarely used formats deprecated: dbg, dump, txt, wddx, yaml. These may be removed in a future release. * Token handling overhauled: the action=tokens module is now deprecated and replaced by action=query&meta=tokens. Most actions now just take a generic "csrf" token, and the token type is now properly documented in the auto-generated documentation. * And more! See the RELEASE-NOTES-1.24 file for a full list. === Directory changes === * The legacy '''skins/common/''' directory has been emptied and deleted as part of the skin system cleanup. Files that have been present in it have been moved elsewhere or deleted (if they were unused). If you loaded any of these files as part of your custom skin or on-wiki CSS/JS, you should make a copy of the old files in a non-MediaWiki directory. See the RELEASE-NOTES-1.24 file for the full list of moved/deleted files. === Browser support deprecated or removed === * Full support for Internet Explorer 6 and Internet Explorer 7 has been removed: it will browse MediaWiki without JavaScript. JavaScript fixes specific to it have also been removed. Additional IE6 and IE7 fixes that exist in MediaWiki:Common.js and similar can be safely removed. === Skins no longer loaded after upgrade? === MediaWiki 1.24 no longer uses the skin autodiscovery mechanism to load default skins, instead requiring that the skins be manually loaded in LocalSettings.php, much like extensions (see [[Manual:Skin configuration#Installing skins]]). This will require you to update LocalSettings.php after the upgrade - a prominently displayed warning message should guide you through the process, suggesting the exact configuration that you need to add. If you're upgrading via a tarball release, that is all you need to do. If you're upgrading via git or otherwise from source, note that the skins themselves have been each moved to a separate repository and will need to be installed separately (much like extensions, some basic ones are included in the tarball). === Composer === If you are using extensions managed by composer, make sure to backup your existing composer.json file as it will be overwritten on upgrade. Full release notes: https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.24.0/RELEASE-NOTES-1.… https://www.mediawiki.org/wiki/Release_notes/1.24 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0.tar.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0.tar.gz.sig Public keys: https://www.mediawiki.org/keys/keys.html Mark Hershberger and Markus Glaser (Wiki Release Team)

9?years, 6?months

problems upgrading to 1.24.0 from 1.19 installed by RPM on CentOS

by Alain Williams

I want to upgrade so that I can offer visual editor. CentOS 6.6, 64 bit, postgresql database, php 5.3.3 I followed the instructions and using a browser: * go to wiki//mw-config/index.php, language is OK so I click CONTINUE * next page I am prompted for the upgrade key that I copy/paste, CONTINUE * Environmental checks. Other than a warning about 'older version of the ICU project's library' all is OK, CONTINUE * Database settings, enter username/password, CONTINUE * Name page. I enter wiki name & admin details, select 'Im bored', CONTINUE * Install page, CONTINUE * I get database error: Error: 42P07 ERROR: relation "mwuser" already exists It appears to be trying to do a fresh install rather than an upgrade. But it asked for the upgrade key earlier ? As root at the command line I run & get: # php maintenance/update.php MediaWiki 1.24.0 Updater DB connection error: No database connection What am I doing that is wrong ? -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h>

9?years, 6?months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l November 2014