The current mw is running on mysql, and the upgrade should too, no desire to run an sqlite anything
-------- Original Message --------
From: Platonides <Platonides(a)gmail.com>
Sent: Tue, 26/06/2012 07:19 PM
To: mediawiki-l(a)lists.wikimedia.org
CC:
Subject: Re: [MediaWiki-l] problems upgrading from 13.2 to 19.1
On 27/06/12 00:42, Dave Hunsberger wrote:
> * Edited /htdocs/mw119/localSettings.php to point to /mw119
> folder and new db ('mediawiki_1_19')
Note it should be LocalSettings.php (capital L). If it can't
> Errors when running [URL]/mw119/mw-config/:
>
> * Blank page with error message "Warning: Cannot load module
> 'pdo_sqlite' because required module 'pdo' is not loaded in Unknown on
> line 0"
>
> MediaWiki 1.19.1 Updater
> PHP Fatal error: Call to undefined function mysql_error() in
> /[PATH]/mw119/includes/db/DatabaseMysql.php on line 305
> Fatal error: Call to undefined function mysql_error() in
> /[PATH]/mw119/includes/db/DatabaseMysql.php on line 305
So, are you trying to use a sqlite database or a mysql one?
Seems you have a problem with php.ini configuration there.
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hello everyone,
I was careless enough to run a MediaWiki installation allowing people to
sign up without a moderator's approval. Hence a few hundred of them did
sign up and started to use the site to swap images.
How can I delete their accounts in the most expeditious way?
Thanks.
Boris.
Dear all,
Starting October 1, 2012, translatewiki.net will drop support for all
MediaWiki extensions it currently supports that still remain in the
Subversion repository svn.wikimedia.org.
Many, if not all of the extensions that by that time have not been
migrated to git/Gerrit, are clearly not that well maintained and we want
to prevent our translators from spending their time on it. At the moment,
a maximum of 273 extensions are affected.
In case this message makes you wonder what git and Gerrit is all about,
and how you can revive your precious extension, please see the following
links:
* https://www.mediawiki.org/wiki/Git/Tutorial
* https://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue
Cheers!
Siebrand
I tried to carefully follow the directions, but when I upload I get the
"broken picture" symbol. There doesn't seem to be any error messages
anywhere. What did I miss?
--
D. E. (Steve) Stevenson
(Almost emeritus) Associate Professor
Director, Institute for Modeling and Simulation Applications.
Clemson University
steve at clemson dot edu
Anyone who has ever looked into the glazed eyes of a soldier dying on the
battlefield will think hard before starting a war. -Otto von Bismarck,
statesman (1815-1898)
Hi,
at PuppetConf (puppetconf.org) multiple talks pointed out how the
PuppetForge (http://forge.puppetlabs.com/),
a repository of puppet modules meanwhile has over 500 modules.
so i searched for mediawiki and there are at least 3 mediawiki modules:
http://forge.puppetlabs.com/modules?q=mediawiki&commit=Go
Module carlasouza/mediawiki
"Puppet Module to create many wikis (on the same machine) using only
one mediawiki installation."
Module martasd/mediawiki
"...deploys and manages multiple MediaWiki instances using a single
MediaWiki installation. .."
Module rcoleman/mediawiki
"..fork of the martasd/mediawiki module. All good changes are being
pushed upstream. "
Also, martasd/mediawiki has been "module of the week"
http://puppetlabs.com/blog/module-of-the-week-martasd-mediawiki/
Thought these might be helpful for Labs Mediawiki deployment.
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
Hi,
I have a GoDaddy hosted linux server where MediaWiki was installed.
Whenever we go to our website however, we receive a 404 error message:
The requested URL /wiki/index.php was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an
ErrorDocument to handle the request.
I'm confused as to what the problem could be. When I FTP into the server
and go into the wiki folder, the index.php file is present. All the
necessary components (php, MySQL, etc) are all installed. I have looked at
the localsettings.php file and everything appears to be correct.
My interpretation is that for some reason, upon initializing the script
cannot locate the index.php file. I have been parsing through various php
files but nothing looks out of place to me (although I could be wrong as I
am new to this).
Any help would be tremendously appreciated,
-Andrew
On 09/28/2012 09:22 AM, Antoine Musso wrote:
>> I'm talking about Composer (http://getcomposer.org/).
> My past experiment is on the wiki at:
> https://www.mediawiki.org/wiki/Composer
Awesome!
I do agree with David Gerard's assessment, though. We need to make sure
that whatever we use is going to work with package management tools that
Debian and Redhat and the like already use.
For Debian, there is dh-make-perl and dh-make-php that will turn CPAN
libraries, PECL and PEAR libraries into debian packages automatically.
They don't *always* work, but they're a good start.
Ultimately, dh-make-php should probably support Composer as well. If
Composer can work with MediaWiki extensions, then all the better.
> And again, adding support for Composer would just need:
> - write basic code to include the generated autoload file
> - add some composer.json files in extension roots
>
> We could start with a subset of extensions.
A great place to start would be the SMW Bundle:
http://www.mediawiki.org/wiki/Semantic_Bundle
When I was building the tarball, I made an attempt to create a MW
tarball with this bundle and it exposed some problems with the installer.
Mark.
--
http://hexmode.com/
Necessitous men are not, truly speaking, free men.
-- Vernon v Bethell (1762), quoted by FDR's Second Bill of Rights
On 09/26/2012 01:54 PM, Krinkle wrote:
> We're going towards a flexible modular system, which
> means components have dependencies and build on each other - as opposed to just
> "being there".
This sounds great, but I do see an important missing piece of
infrastructure.
First, I am absolutely in favor of a loosely-coupled, modular system
instead of just building a larger and larger core.
The problem, though, is that there is no way to install, use, or update
extensions apart from doing it by hand. Requiring the installation of
multiple modules by hand isn't going to lead to a thriving, modular
ecosystem. We need a dependency manager.
Thankfully, I think there is already a dependency manager that we can
build on.
I'm talking about Composer (http://getcomposer.org/).
Of course, MediaWiki isn't aware of this dependency manager and so
MediaWiki's extensions aren't either. I've only looked at it briefly,
but it appears that adding support wouldn't be difficult at all -- it
would just mean adding a file to the git repository.
What do you think?
Mark.
Hi All,
I have tried this upgrade twice now, carefully reviewing each step as
described here: http://www.mediawiki.org/wiki/Manual:Upgrading and
both times, I get stuck at what appears to be the exact same place.
I have enabled $wgShowExceptionDetails = true; in LocalSettings.php
but nothing is displayed in the web browser. The only message I get
is in the apache logs and the fatal message is:
PHP Fatal error: Call to undefined method ACTION::getActionName() in
/var/www/wiki/includes/Wiki.php on line 317
I have some php experience but get lost quick in this code. There are
methods/functions/tools that I've never used before so I'm having
difficulty following it.
I've done everything it told me to on the upgrade page.
Download new
Remove old
Move new to web root
Copied old LocalSettings.php to new
Turned on wgShowExceptionDetails
Updated extensions
etc.
However, I get a blank web page when I browse to index.php and the
error log shows the error pasted above. If this helps, here's where
"getActionName" is found in the code base:
../includes/Action.php: public final static function getActionName(
IContextSource $context ) {
../includes/OutputPage.php: $bodyAttrs['class'] .= ' action-' .
Sanitizer::escapeClass( Action::getActionName( $this->getContext() )
);
../includes/OutputPage.php: 'wgAction' => Action::getActionName(
$this->getContext() ),
../includes/Wiki.php: $action = Action::getActionName( $this->context );
Any ideas?
Thanks in advance,
Pete
On Fri, Sep 28, 2012 at 1:11 AM, Daniel Friesen
<daniel(a)nadir-seen-fire.com> wrote:
>> - Extensions should probably have some sort of manifest file. What
>> format should it be in and what information should it contain?
>
> I think Chad (^demon) was the the one focusing on this area. We should ask
> him what his plans were.
>
I had some rough ideas, but they never got fleshed out. In my ideal
world, I was thinking something like an abstract Extension class
that each extension would implement. It would have methods for
returning things $wgExtensionCredits does now, as well as being
able to say "I depend on Foo" extension. Then we'd have some kind
of ExtensionRegistry, so enabling an extension would be something
like ExtensionRegistry::register( new MyExt );
But yeah, I never really got further than that.
-Chad