I've gone ahead and released 1.2.0 on account of a major bug in
1.2.0rc4 that could delete an existing wiki instead of upgrading it
when using the web installer. At some point later a 1.2.1 should clean
up some other minor installation issues and bugs.
Download link:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.2.0.tar.gz?
download
See release notes for changes since 1.1.0:
https://sourceforge.net/project/shownotes.php?release_id=226003
Changes from 1.2.0rc4:
Web install:
* Serious upgrade bug fixed; an attempt to install over an existing
database should now either upgrade gracefully or immediately fail,
instead of wiping out your entire database (BUT BACKUP FIRST!)
* Configuration tosses in output compression if available
* Detects more image-related options (but uploads are still disabled by
default)
Localizations:
* Spanish localization has had most hard-coded "Wikipedia"s removed
* French localization has been changed to UTF-8
Maintenance scripts:
* rebuildrecentchanges.php works again
* importPhase2.php for importing from very old format (pre-May 2002)
wiki
-- brion vibber (brion @ pobox.com)
I suppose it's my own fault for trusting what was explicitly labeled as
an "experimental" web interface installer, but I'm going to pass this
information on so that other people are aware as well.
I've had an existing wiki that I wanted to upgrade to 1.2.0rc4, and I
tried using the web interface. I didn't realize that the installer
would WIPE MY ENTIRE DATABASE and start over with a blank slate! I
think you guys should either (a) put a much more obvious warning
against using the installer for existing wikis (I haven't found one
yet), or else (b) tell the installer to do nothing as a safeguard if it
detects an existing database using the name of the database it was told
to set up.
Thanks,
Dan Carlson
*praying that his host has a backup of the database*
I am doing an English wiki, but I need to customize the language.php file to change the license(I want it to be public domain) and other small details.
Is there an easy way to update this file? If I just make the changes without reinstalling the mediawiki software, I only get a blank home page. If I reinstall everything then it works. Isn't there an easier way for the changes that must be made to this file?
Thanks,
Luke
Sorry I haven't responded earlier, it seems the mailing list has
decided to send me only administrative messages and not actual messages
to the list! Garrrr...
mikeFitzhugh wrote on March 14:
> I'm having some trouble with the web installer. Everything seems to
> go
> well during the installation. But, when I visit what should be the
> front of my new wiki using this URL:
>
> http://www.objectif.org/wiki/index.php
>
> ... I get redirected to this URL:
>
> http://www.objectif.org/wiki/index.php/Wiki/index.php
>
> where I get the message "No input file specified"
It looks like there's something wrong with the web server, it's not
passing requests to the script correctly. As a workaround, try putting
this in LocalSettings.php:
$wgArticlePath = "$wgScript?title=$1";
Uglier, but perhaps safer.
-- brion vibber (brion @ pobox.com)
Hi,
I recently installed MediaWiki 1.1.0, and on the Main Page the magic word
__NOEDITSECTION__ appears at the bottom. I couldn't find any obvious errors
in Language.php or OutputPage.php that would cause this. Has this happened
to anyone else?
Paul
Daniel Milne wrote on March 15:
> I'm trying to figure out the upgrade procedure. I'm currently running
> mediawiki-1.2.0rc3 and would like to upgrade to rc4.
> My setup is such that $wgScriptPath is set to /wiki, and /wiki is a sym
> link to mediawiki-1.2.0rc3.
>
> I've copied LocalSettings.php and AdminSettings.php to the rc4
> directory. Trying to run the update.php from either the web browser or
> command line results in:
>
> php update.php
> Can't use command-line utils with in-place install yet, sorry.
>
> What's the correct way to do this update?
For the moment, the way to do an update with an in-place install is:
* decompress the new version in a fresh directory (or over the existing
directory, and move the old LocalSettings.php out of the way for now)
* run the setup, giving it the same info as before (same database etc)
The in-place install will make any necessary changes to the database
structure if it recognizes there's already a database there.
I realize this isn't 100% ideal... it should be refined in upcoming
point releases.
-- brion vibber (brion @ pobox.com)
Kevin Heneveld wrote on March 17:
> First, on the Main_Page we have the "Selected Anniversaries" and "Did
> You Know" blocks. At the bottom of each is the "More..." link.
> However, the link is getting incorrectly displayed and is instead
> diplaying as:
>
> http://www.wikipedia.org/wiki/Selected_anniversaries/March"
> class='external' title="">More
> selected anniversaries...
That sounds odd... Have a look at [[MediaWiki:March 17 selected
anniversaries]] or equivalent; does the link work in there, or is it
just on the main page?
Also, exactly which version of MediaWiki are you using?
> Also, we are having problems when clicking links to pages that include
> apostrophies (ie "Boyle's Law"). We get "Bad Title" errors.
Check your PHP configuration; weird things can happen with apostrophes
if "magic_quotes_gpc" is on. (This is a misguided "feature" of PHP to
"help" developers by semi-randomly putting slashes in front of
characters _just in case_ you want to blindly insert data into SQL and
_never ever_ do anything else with input.) We try to work around it but
may miss some spots.
If you can disable this option in php.ini and restart the web server,
hopefully that'll clear it up.
Docs: http://us4.php.net/manual/en/ref.info.php#ini.magic-quotes-gpc
> I've modified the source code for texvc to create transparent
> backgrounds on the TeX math equations. This works, but the
> antialiasing occasionally leaves undesireable (grey) artifacts along
> the edges. Does anyone have a better hack for texvc that will allow
> better transparency or alpha-transparent .PNGs?
If anyone does, we'd love to have it too...
> Finally, I know there is no image dump on the downloads page yet, but
> is there a place I can perhaps "curl" or "rsync" the images from? If
> not, when might there be an image dump?
Sorry, an official image dump has been held up by the rampant practice
of uploading copyrighted images without permission or a clear
demarcation of what is really considerable as "fair use" vs what's just
plunked in without thought.
You should be able to spider the /upload directory with curl or wget if
you really need to.
-- brion @ pobox.com)
Brief background:
We are running a local wikipedia (read-only copy) to provide our k12 students with faster access
to research as we have only 2 T1's to share amoungst 20,000+ users. Having a local copy speeds
research while simultaniously reduces external internet traffic. It also allows a modicum of
control over certain topics and their related images (when we get them) which may not be
appropriate for our younger users (ie, clitoris, etc.).
We are running into several issues that I haven't been able to find answers to online.
First, on the Main_Page we have the "Selected Anniversaries" and "Did You Know" blocks. At the
bottom of each is the "More..." link. However, the link is getting incorrectly displayed and is
instead diplaying as:
http://www.wikipedia.org/wiki/Selected_anniversaries/March" class='external' title="">More
selected anniversaries...
With the "http://www.wikipedia.org/wiki/Selected_anniversaries/March" acually being the active
link. This doesn't happen on other wikipedia sites I've looked at so we must be doing something
wrong. I'm not sure where to look for the answer because the entire block (in the case of
anniversaries) is genereated with the
{{msg:{{CURRENTMONTHNAME}}_{{CURRENTDAY}}_selected_anniversaries}} command on the main page so it
appears we have no formatting control.
What am I missing?
Also, we are having problems when clicking links to pages that include apostrophies (ie "Boyle's
Law"). We get "Bad Title" errors. I've reduced the problem by adding a mod_rewrite rule to remove
the apostrophies and change the link to "Boyles_Law" which works in some cases, but not in others.
I know this isn't the right way to handle it and am assuming that the apostrophy character is
probably getting encoded as something else in the MySQL index, but haven't figured out what or why
yet.
Again, any ideas.
Also, we've skinned wikipedia to fit seamlessly with our internally developed "Web-Based
Integrated Learning Environment" which can in turn be skinned in a variety of ways and has a
light-blue background color by default. I've modified the source code for texvc to create
transparent backgrounds on the TeX math equations. This works, but the antialiasing occasionally
leaves undesireable (grey) artifacts along the edges. Does anyone have a better hack for texvc
that will allow better transparency or alpha-transparent .PNGs?
Finally, I know there is no image dump on the downloads page yet, but is there a place I can
perhaps "curl" or "rsync" the images from? If not, when might there be an image dump?
Thank you, and forgive me if these are "stupid newby" questions.
_____________________________________
Kevin Heneveld - System Administrator
Fairbanks School District
(907) 452-2000 X375
Hi
I am trying to configure a mediawiki to run closed for non-approved
accounts. The version I'm running is phase 3 1.2.0rc3 on redhat 8
I have changed the following in the LocalSettings.php file:
# Invitation-only closed shop type of system
$wgWhitelistEdit = true;
$wgWhitelistRead = true;
$wgWhitelistAccount = array ( "user" => 0, "sysop" => 1, "developer" =>
1 );
But only edits are disallowed for users not logged in. Its possible for
anonymous users to read all pages.
Is this a bug, or am I missing some important information?
Thank you for your help
/Thomas