This is on MediaWiki 1.16 (yea, I know), MariaDB 10.1.8, and MacOS X 10.6.8.
I had a database problem, and reinitialized and restored my database from a recent logical (SQL source) backup. There were no changes to any MediaWiki PHP files. The character set (UTF8) did not change.
Now, I get the infamous "[Sitename] has a problem… Can't contact the database server: Permission denied (localhost)."
The host/database/user/password info in LocalSettings.php has not changed. I can use those same credentials to access the database from various tools, such as mysql CLI client, phpMyAdmin, and Sequel Pro. And yet, MediaWiki is still unwilling to connect. I even tried tagging "?action=purge" onto the URL to rule out caching problems.
I used phpMyAdmin to re-set the login credentials to those in LocalSettings.php, thinking perhaps they hadn't been restored correctly. No luck there. The various other database clients can still get in using those same MediaWiki login credentials.
I've taken to grepping through the .php files, looking for where the login credentials are used, trying in vain to figure out why they no longer work, when they did just 24 hours ago!
I've also crawled through the MediaWiki online documentation, with no particular insight.
I'm leaning toward a MySQL User permissions problem, but I think I've ruled that out by getting in using the same credentials with other tools.
Any insight? Please show me something simple and stupid that I've been overlooking!
Over the past month I've submitted a few patches for Cargo and now I would
like to tackle race conditions as it relates to database updates.
I have a pretty good idea of how to implement it, but before I create a
whole new mechanism to handle this type of issue I was wondering how
MediaWiki itself does it. Are any classes, methods and tables that can (or
should) be leveraged?
>Jan, and many others, have made a lot of valid comments on this
discussion. So why have they all been summarily dismissed with such...
complete lack of consideration?
The folks at the foundation are not copying files and running update.php
every time they update Wikipedia. :) They also have a focus on
foundation-sponsored projects and improving things where their constituents
are. Not a lot of Wiki* editors need a better MediaWiki installer.
I don't believe it is much of a priority - for the foundation or a
significant percentage of third-party administrators. Those who are
dedicated figure it out, new people have to have a lot of patience - or
they are turned away. Which is really sad, IMHO.
To that end, what can we do about it? Might I suggest we put together an
IdeaLab proposal <https://meta.wikimedia.org/wiki/Grants:IdeaLab> and see
if we can pool our own resources (attention and time) to figuring out what
it would take to improve this part of MediaWiki? See if there's enough
interest, identify opportunities for support (dev skills and money) and
take care of this.
I also suggest we make an appropriate and courteous amount of productive
noise in Phabricator
experiences, feedback, and information to existing tasks related to the
installer. Add new ones for issues that have yet to be discovered.
> Okay, a few weeks ago my wiki stopped loading. The version I've got
> installed there is ancient, but it was working fine until one day it
> Parse error: syntax error, unexpected T_NAMESPACE, expecting T_STRING in
> on line 46
Your PHP was upgraded, and the old MediaWiki software will not work with it.
One of the reasons is that "namespace" is now a reserved word. The best
and easiest solution is to upgrade your wiki, but there are others:
Greg Sabino Mullane greg(a)endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
I have WP 1.25.1 from source.
I wanted to be able to post condensed meta on the right-side of my articles in an "Infobox", like Wikipedia does.
Found several "How-to" on exporting/importing templates from one source wiki to destination, like:
Followed the step, imported 20+ templates (checked "Include templates" on export page), and
now none of my templates are rendering!
Even completely standalone templates I wrote before (they worked before import) stopped working.
All with the same error, "Parser::braceSubstitution: template inclusion denied", ex:
>> Parser::braceSubstitution: template inclusion denied for Template:Documentation
Can anyone give me any pointers on what could be the cause?
I verified that:
- Lua interpreter (standalone) itself is working, I have a log of successful Lua module invocations
- I have extensions: ParserFunctions, Scribunto, InputBox and TemplateData installed
Could it be that I am missing some recursively required templates?
(I noticed existence of some not ordinary templates, like "Template:((", or "Template:!!", etc.)
If so, how could I identify which one(s)?
It seems "export" does not takes recursively all needed templates - it stops on first level of indirection.
I tried to manually list all templates needed for Infobox with their children recursively - the list
keeps growing with no end (have 270+ templates/modules in the list now).
If the Infobox "required templates" tree is so deep, is their a way to import all templates and modules from wiki at once?
(Are the not part of install from source tarball? May be I have them locally already, just need to load to DB?)
And finally, if this route is so complex, is there an easier way to create an Infobox on a new wiki?
Is creating them from scratch is any easier (perhaps it will be not as polished but close in functionality)?
Please point me to a guide/how-to for creating "Infobox-like" box on right-side of an article.
I hate to settle for "home brew" solution but I am ready to give up the dream of having wiki-consistent UI.
How does everyone else accomplishing this?
This message is intended for specified recipient(s) only. If received by any other party, please discard immediately.
This is just a guess, but I believe that MediaWiki uses the term "namespace" in a different way, when compared to PHP.
PHP introduced Namespaces at PHP 5.3+
Prior to that, the word "namespace" had no meaning in PHP. It may be worth checking to see if your hosting provider upgraded PHP recently.
No trouble using PHP 5.4 and MW 1.21, or PHP 5.5 and MW 1.26 (these are my only two installations)
I'm a big fan of keeping the software as up-to-date as possible. In the PHP world this means PHP 7+ but it also means breaking changes for some of the previously deprecated "features" from the dustbin of PHP. Docs here:
PHP 5 is still supported at PHP 5.5+ or PHP 5.6+
Two questions here:
1. Anyone know of an extension that adds a captcha (or similar) to the
registration page? I've found plenty that work on edits, but none to
prevent the initial spam account creation.
2. Anyone know how to require email upon registration? I know there's
the confirm-to-edit configuration I could use which would make this happen,
but I feel like I should be able to require email at registering while
still leaving edits open to anonymous users.
Thanks. Hope everyone is enjoying the holidays!