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)
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.
--
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
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
> ******************************************
>
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.
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
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.
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?
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".
etc.
The answers to those questions will help to tell me how much time an upgrade
is likely to take.
tia!
eric
~~~~~~~~~~~~~~~~~~~~
Eric Armstrong
Developer Advocate/Evangelist
www.longjump.com <http://www.longjump.com/>
lj.platformatyourservice.com/wiki
LongJump provides a cloud-computing platform that makes it
easier to develop & deploy database-driven apps. Build from scratch
or starting from a rich suite of customizable "application templates".
The platform and its collaboration capabilitites can be either self-hosted
or shared. It comes with a complete suite of Java and REST APIs,
integrated testing, and an Eclipse plugin.
~~~~~~~~~~~~~~~~~~~~
Eric Armstrong
Developer Advocate/Evangelist
<http://www.longjump.com/> www.longjump.comlj.platformatyourservice.com/wiki
LongJump provides a cloud-computing platform that makes it
easier to develop & deploy database-driven apps. Build from scratch
or starting from a rich suite of customizable "application templates".
The platform and its collaboration capabilitites can be either self-hosted
or shared. It comes with a complete suite of Java and REST APIs,
integrated testing, and an Eclipse plugin.
I've installed the mediawiki and ran through the config process, but when I go to http://localhost:8080/mediawiki/index.php, (which is where I installed everything) I get a MediaWiki internal error. I am using PostgreSQL 9.1 on Windows 7, using an apache 2.2.20 server and php v. 5.3.8. The page suggests to run the update.php in the maintenance folder, which produces errors also, but closes before I can read them.
Below is what the index.php shows:
MediaWiki internal error.
Original exception: exception 'DBQueryError' with message 'A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: http://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: SELECT value,exptime FROM objectcache WHERE keyname = 'my_wiki:messages:en' LIMIT 1
Function: SqlBagOStuff::get
Error: 1 ERROR: relation "objectcache" does not exist
LINE 1: ...ECT /* SqlBagOStuff::get */ value,exptime FROM objectcach...
^
' in C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\db\Database.php:781
Stack trace:
#0 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\db\Database.php(751): DatabaseBase->reportQueryError('ERROR: relatio...', 1, 'SELECT value,e...', 'SqlBagOStuff::g...', false)
#1 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\db\Database.php(1050): DatabaseBase->query('SELECT value,e...', 'SqlBagOStuff::g...')
#2 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\db\Database.php(1134): DatabaseBase->select('objectcache', Array, Array, 'SqlBagOStuff::g...', Array, Array)
#3 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\BagOStuff.php(267): DatabaseBase->selectRow('objectcache', Array, Array, 'SqlBagOStuff::g...')
#4 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\MessageCache.php(252): SqlBagOStuff->get('my_wiki:message...')
#5 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\MessageCache.php(606): MessageCache->load('en')
#6 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\MessageCache.php(545): MessageCache->getMsgFromNamespace('Mainpage', 'en')
#7 [internal function]: MessageCache->get('mainpage', true, true)
#8 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\StubObject.php(58): call_user_func_array(Array, Array)
#9 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\StubObject.php(76): StubObject->_call('get', Array)
#10 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\GlobalFunctions.php(781): StubObject->__call('get', Array)
#11 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\GlobalFunctions.php(781): StubObject->get('mainpage', true, true)
#12 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\GlobalFunctions.php(744): wfMsgGetKey('mainpage', true, true, true)
#13 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\GlobalFunctions.php(688): wfMsgReal('mainpage', Array, true, true)
#14 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\Title.php(318): wfMsgForContent('mainpage')
#15 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\includes\Wiki.php(122): Title::newMainPage()
#16 C:\Program Files (x86)\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\mediawiki\index.php(60): MediaWiki->checkInitialQueries(NULL, 'view')
#17 {main}
How do I get this configured correctly. When I query the objectchache table in the database, I get 2 records, but none have the keyname = 'my_wiki:messages:en'
Any help would be greatly appreciated.
Thanks.