I've tried installing mediawiki 1.4.7 multiple times already with
different settings; can anyone advise me on getting this working (or is
Mediawiki 1.5 coming soon without these issues?
(Q) Is it possible that php 5.0.4's default is to use the new 4.1 mysql
passwords?
... in which case forcing mysql to use the old passwords is a problem?
Context:
OS: Fedora Core 4 x68_64
mysql -V: mysql Ver 14.7 Distrib 4.1.11, for redhat-linux-gnu (x86_64)
yum info php: Installed Packages: Name: php; Arch; x86_64; Version: 5.0.4;
Release: 10.3
TurckMMcache installed & detected by mediawiki/config/config/index.php
webform and
memcached 1.1.12 running
On first try, using memcached, the configuration seemed to be successful,
told me to go to
http://localhost/wiki/index.php
which states only:
: Sorry! The wiki is experiencing some technical difficulties, and cannot
contact the database server.
I don't understand since I can log into mysql by
mysql -u wikiuser -p
---- An attempted dead end: ----
Moving the file LocalSettings.php and re-attempting the config webform
with any choice of caching gives six copies of :
Warning: array_key_exists() [function.array-key-exists]: The second
argument should be either an array or an object in
/var/www/html/mediawiki-1.4.7/includes/User.php on line 716
and other complaints which I assume have to do with attempting to create
already created databases and/or users.
--------------------------------
Reinstallation experiments showed that provided the wikiuser and wikidb
were dropped first,
the configuration program was successfully able to login and create wikidb
and authorize the wikiuser.
so I deleted the wiki directory, in mysql deleted wikiuser and wikidb, and
reinstalled without caching.
Result: a blank wiki/index.php: <html><body></body></html>.
(Q) is this consistent with the same issue?
I was advised to see the release-notes on mysql 4.1 which directed me to
http://dev.mysql.com/doc/mysql/en/old-client.html
and so I've used mysql command
SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd');
on all three wikiuser accounts.
I checked that /etc/my.cnf seems to be set to use old mysql passwds:
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
and so it turns out that OLD_PASSWORD('foo') = PASSWORD('foo') anyway!
Refreshed /wiki/index.php: got blank
page:<html><body></body></html>.
Restarted mysql, Refresh /wiki/index.php: got blank
page:<html><body></body></html>.
Any advice? Is there more I need to do to convince 4.1 to play nicely?
Hi all,
I have some existing mediawiki sites running 1.4.7 that I'd like to add
E-mail watchlist notification to. The EnotifWiki site makes reference to
a patch file that can be applied to an existing wiki install, but on
SourceForge I'm only seeing tarballs I can download that include all of
mediawiki with the extension already installed.
Where can I download the enotif patch for v1.4.x?
Thank you,
Scott
--
Scott Garman
sgarman at iname dot com
Can someone point me to a link to instructions on how to add one more
tab to each page?
Essentially, I want to duplicate what the Talk tab does, but in a
custom namespace. Of course, I really want to add three tabs, but if I
can add one, I can add three. ;-)
What am looking to do is create an additional tab with a link of the
form
http://myservername/index.php?title=My_New_Name_Space:Same_Title_As_The_Sou…
Thank you!
David Gerisch, Systems Development Specialist
A.C.S. / Tulare County Information Technology
degerisch(a)co.tulare.ca.us
(559) 737-4045 ext 300
I am setting up a new wiki. I would like to use most and maybe all of
the help that is available from meta.wikimedia.org. Is there an easy
way to mirror all of this content to my installation or should I start
a long copy and paste session?
Thanks,
Paul
Hi There,
On Prints of pages I get the text "From [name wiki]-Wiki". right under the title of the page. Can I eliminate that?
Thanks.
Best regards,
Marcel
---------------------------------
Yahoo! Messenger NEW - crystal clear PC to PCcalling worldwide with voicemail
I have a MediaWiki setup at old.domain.com
I want to move it to new.newdomain.com
All other details should stay the same(including database info)
Both domain.com and newdomain.com are both hosted by the same company
Can I just move all files from one subdomain to another? Is there any other
changes I need to make?
Thanks!
After using the shortened URLs for a day on my company's intranet wiki,
I've gotten nothing but good comments. Nobody seems to be having any
problems, and it's quite a bit nicer to link people.
I understand what you guys are saying and completely agree with it. In a
public environment, on a shared server, or getting loads of traffic,
this wouldn't be a very good idea. But as an intranet wiki for a small
company, I have to say, it seems to work just fine (being as I don't
need a robots.txt, lack of favicon.ico is bad but excusable, using the
default skin, etc). It might be technically wrong, but in practice seems
to be nice.
> -----Original Message-----
> From: mediawiki-l-bounces(a)Wikimedia.org [mailto:mediawiki-l-
> bounces(a)Wikimedia.org] On Behalf Of Jamie Bliss
> Sent: Wednesday, July 20, 2005 4:04 PM
> To: MediaWiki announcements and site admin list
> Subject: Re: [Mediawiki-l] Get rid of index.php in URL
>
> On 7/20/05, Brion Vibber <brion(a)pobox.com> wrote:
> > Zain Memon wrote:
> > > Thanks, the QSA fixed the problem nicely.
> > >
> > > As for your recommendations... I have an entire subdomain
dedicated to
> > > nothing but the wiki, and its set up as a VirtualHost in Apache.
I'm
> > > just fine with having the entire subdomain be dedicated to nothing
but
> > > the wiki.
> >
> > robots.txt
> > favicon.ico
> > skins/ subdirectory
> > etc
> >
> > This includes both files used by the wiki and general stuff that
applies
> > all over the web.
>
> Brion is entirely correct in recomending this. It is generally a bad
> idea to have a directory containing both virtual files (rewritten to
> something else) and real ones. I have had problems with this, even in
> a subdirectory.
>
> You can use RewriteCond to skip it, like this:
> RewriteCond %{REQUEST_FILENAME} !-f [OR]
> RewriteCond %{REQUEST_FILENAME} -d
> But then Apache gives 403 Forbidden if the article name contains a
> colon (at least for me).
>
> Using a /w & /wiki is easy to install, deal with, and maintain. I
> would strongly discourage using anything else. (Although I have set it
> up under /astro73/csx rewritten to /astro73/csxml without issues, see
> <http://endeavour.zapto.org/astro73/csxml/Main_Page>.)
>
> -- Jamie
> -------------------------------------------------------------------
> http://endeavour.zapto.org/astro73/
> Thank you to JosephM for inviting me to Gmail!
> Have lots of invites. Gmail now has 2GB.
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Thanks, the QSA fixed the problem nicely.
As for your recommendations... I have an entire subdomain dedicated to
nothing but the wiki, and its set up as a VirtualHost in Apache. I'm
just fine with having the entire subdomain be dedicated to nothing but
the wiki. It just looks a lot nicer to have
http://wiki.subdomain.com/Main_Page than having a subdirectory or
index.php in there. Is that alright or am I committing blasphemy?
Thanks.
> -----Original Message-----
> From: mediawiki-l-bounces(a)Wikimedia.org [mailto:mediawiki-l-
> bounces(a)Wikimedia.org] On Behalf Of Brion Vibber
> Sent: Wednesday, July 20, 2005 12:59 AM
> To: MediaWiki announcements and site admin list
> Subject: Re: [Mediawiki-l] Get rid of index.php in URL
>
> Zain Memon wrote:
> > Thanks, that was exactly what I was looking for. However, I'm having
> > one problem. I used the Kludge method from the page
> > http://meta.wikimedia.org/wiki/Using_a_very_short_URL
>
> That's a bad idea -- I strongly recommend against doing this as it
fills
> your entire URL namespace with the wiki. This will break legitimate
> files unless you add exceptions, and make it impossible to have wiki
> pages with titles conflicting with those exceptions. It may cause
> strange errors for use with actual files that you forgot to except.
>
> The URL space for the wiki pages should *always* appear as a
> 'subdirectory', not the root URL, for compatibility and safety.
>
> > and it seems to
> > be working okay, except for one thing: Searches don't work.
>
> Your rewrite rules must include [QSA] for the query string to be
passed
> through.
>
> -- brion vibber (brion @ pobox.com)
> From: Brian <reflection(a)gmail.com>
>
> There is an additional problem with client-side spell chekers. If
> you use
> spellbound on an article that has html or css in it, it will
> attempt to
> check all of the attributes which becomes very annoying...
The speller built into MacOS X seems to be smarter than that. Example
at:
http://www.bytesmiths.com/stuff/SpellExample.gif
But this is pretty far off-topic, and some defensive people probably
view it as flame bait. It is not intended as such. I'll be quiet now.
:::: You can't have your SUV and eat it, too!
:::: (It takes TEN calories of fossil-fuel energy to produce EACH
calorie of food.)
:::: Jan Steinman <http://www.Bytesmiths.com/Van>
Hi this wiki is giving me too many random errors to sort out and since its
still early in its life and has a manageable small number of pages im
going to copy the content from the edit pages and start again. So what i'd
like to know is suggestions of what server/php/mysql versions or packages
containing all three work well with mediaWIKI on windows. Has anyone had a
beautiful error/stress free install? What version on mediawiki are you
using etc?
Any suggestions much appreciated.
Regards
Caspar
===============================================================
National Australia Group Europe Limited (Company Number 02108635, Registered Office 88 Wood Street, London EC2V 7QQ) (NAGE) is a subsidiary of National Australia Bank Limited (an Australian registered company). The following UK companies are authorised and regulated by the Financial Services Authority: Clydesdale Bank PLC (trading as Clydesdale Bank and Yorkshire Bank), MLC Savings Limited, MLC Trust Management Company Limited, Clydesdale Bank Insurance Brokers Limited, Yorkshire Bank Financial Services Limited, National Australia Insurance Services Limited and Custom Fleet Limited.
The views and opinions expressed in this email may not reflect the views and opinions of any member of the group of which NAGE forms part. The information contained in this message is confidential and may also be privileged. It is intended only for the addressee named above. The unauthorised use, disclosure, copying or alteration of this message is strictly prohibited. If you are not the addressee (or responsible for delivery of the message to the addressee), please notify the originator immediately by return message and destroy the original message. This message and any attachments have been scanned for viruses prior to leaving the NAGE network. However, NAGE does not guarantee the security of this message and will not be responsible for any damages arising as a result of any virus being passed on or arising from any alteration of this message by a third party. NAGE may monitor emails sent to and from the NAGE network.
