upgrade 1.20.2 to 1.22.7

List overview All Threads
Download

newer

older

MediaWiki 1.23.0 released

Mediawiki 1.22 and Sgvizler...

Rob Lingelbach

1 Jun 2014 1 Jun '14

7:14 p.m.

Platform is CentOS. MW version 1.20.2 PHP 5.4.29 (apache2handler) MySQL 5.5.37 I want to upgrade (long overdue) to MW 1.22.7 . Backed up the files and DB. did "php update.php" returns no errors. I didn't upgrade the extensions because I have lots of them, and have found this the hardest part of upgrades. (I guess I was hoping they would work). Reloaded existing (old) LocalSettings.php All the above done from command line. Result: blank wiki. My thinking (funny how writing this out causes a better thought process) is that my old extensions are causing the problem(s). I think I should try to delete extensions from LocalSettings.php and see how that improves the situation. I believe however I have extensions that possibly have not been updated and I'll be missing some extension functions I was relying on. Yet I'll be happy to have the ability to add new ones (a bit of work for sure). My main objective is to get Semantic Wiki folded into the mix. Any comments quite welcome, and thank you for any help in advance. (PS. I'm able to revert to old setup due to careful backups of files. update.php update for 1.22.7 doesn't seem to harm the reversion to 1.20.2). Also, so much work has been done on 1.20.2 that I'm loathe to lose the extensions that were part of that work, if they're out of date with 1.22.7 . -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

Show replies by date

John

1 Jun 1 Jun

7:19 p.m.

I would have waited for 1.23. But your first step is either upgrading the extensions or removing them. Most broken extensions cause havoc trying to debug. Once you remove all your extensions you can add them back one by one until your wiki breaks. At that point you know where the problem is. On Sun, Jun 1, 2014 at 3:14 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

...

Rob Lingelbach

7:34 p.m.

On Jun 1, 2014, at 2:19 PM, John <phoenixoverride(a)gmail.com> wrote:

...

In removing them just now, I lost count at 50 or 60. thanks for the advice. -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

Rob Lingelbach

8:22 p.m.

On Jun 1, 2014, at 2:34 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

...

On Jun 1, 2014, at 2:19 PM, John <phoenixoverride(a)gmail.com> wrote:

In removing them just now, I lost count at 50 or 60. thanks for the advice.

I may be out of sync with myself here. In trying to simplify things, I’ve done the following (after the appropriate backing up steps, db dump, etc.): Loaded the files in my wiki directory from mw-1.22.7 . First, because I was having the same problems with a blank wiki *even after commenting out all extensions from LocalSettings.php* I decided to start fresh and have only the files from mw-1.22.7 in /var/www/wiki. I then checked LocalSettings.php for structural naming (wiki root etc) and all looked ok. I ran ‘php maintenance/update.php’. No errors returned. Yet still a blank wiki. Is it possible that I’ve outsmarted myself and the MySQL db from my legacy wiki is now out of sync with the wiki files (which I removed after backing up)? I can reconvene the wiki as it was before; all the files exist as backups. My suspicion is that at some point my LocalSettings.php ran afoul of a MW update, even with extensions today commented out, and if I try to debug it, I might get to the heart of the matter. I must admit I’m not sure what process to use (logfiles) to follow for debugging. -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

John

8:26 p.m.

is your wiki public? On Sun, Jun 1, 2014 at 4:22 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

...

On Jun 1, 2014, at 2:34 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

On Jun 1, 2014, at 2:19 PM, John <phoenixoverride(a)gmail.com> wrote: > I would have waited for 1.23. But your first step is either upgrading

the

> extensions or removing them. Most broken extensions cause havoc trying

> debug. Once you remove all your extensions you can add them back one by

one

until your wiki breaks. At that point you know where the problem is.

In removing them just now, I lost count at 50 or 60. thanks for the

advice. I may be out of sync with myself here. In trying to simplify things, I’ve done the following (after the appropriate backing up steps, db dump, etc.): Loaded the files in my wiki directory from mw-1.22.7 . First, because I was having the same problems with a blank wiki *even after commenting out all extensions from LocalSettings.php* I decided to start fresh and have only the files from mw-1.22.7 in /var/www/wiki. I then checked LocalSettings.php for structural naming (wiki root etc) and all looked ok. I ran ‘php maintenance/update.php’. No errors returned. Yet still a blank wiki. Is it possible that I’ve outsmarted myself and the MySQL db from my legacy wiki is now out of sync with the wiki files (which I removed after backing up)? I can reconvene the wiki as it was before; all the files exist as backups. My suspicion is that at some point my LocalSettings.php ran afoul of a MW update, even with extensions today commented out, and if I try to debug it, I might get to the heart of the matter. I must admit I’m not sure what process to use (logfiles) to follow for debugging. -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Rob Lingelbach

8:27 p.m.

It was until I started upgrading it. Now it’s down. On Jun 1, 2014, at 3:26 PM, John <phoenixoverride(a)gmail.com> wrote:

...

is your wiki public?

-- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

Rob Lingelbach

8:28 p.m.

I can reconstruct it on 1.20. and make it public again if it helps. On Jun 1, 2014, at 3:26 PM, John <phoenixoverride(a)gmail.com> wrote:

...

is your wiki public?

John

8:32 p.m.

If the existing broken wiki is public I could take a look, it might be an issue with rewrite rules, Oh and have you rebooted your webserver? On Sun, Jun 1, 2014 at 4:28 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

...

I can reconstruct it on 1.20. and make it public again if it helps. On Jun 1, 2014, at 3:26 PM, John <phoenixoverride(a)gmail.com> wrote:

is your wiki public?

\ _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Rob Lingelbach

8:38 p.m.

I’ll leave the broken 1.22.7 in place for now. I’ll restart apache now. colorist.org/wiki is the path to the formerly working installation (1.20.2) if you like I can put 1.20.2 back online after this On Jun 1, 2014, at 3:32 PM, John <phoenixoverride(a)gmail.com> wrote:

...

I can reconstruct it on 1.20. and make it public again if it helps. On Jun 1, 2014, at 3:26 PM, John <phoenixoverride(a)gmail.com> wrote:

is your wiki public?

\ _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

_______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

-- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

Rob Lingelbach

8:41 p.m.

meant to say, the URL below is the path to the existing broken 1.22.7 install as it exists now. On Jun 1, 2014, at 3:38 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

...

I can reconstruct it on 1.20. and make it public again if it helps. On Jun 1, 2014, at 3:26 PM, John <phoenixoverride(a)gmail.com> wrote:

is your wiki public?

\ _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

_______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

-- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

-- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

John

8:42 p.m.

OK, looks like its not a rewrite issue. See https://www.mediawiki.org/wiki/Manual:How_to_debug on how to find out what is causing the problem On Sun, Jun 1, 2014 at 4:41 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

...

meant to say, the URL below is the path to the existing broken 1.22.7 install as it exists now. On Jun 1, 2014, at 3:38 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

I’ll leave the broken 1.22.7 in place for now. I’ll restart apache now. colorist.org/wiki is the path to the formerly working installation

(1.20.2)

if you like I can put 1.20.2 back online after this On Jun 1, 2014, at 3:32 PM, John <phoenixoverride(a)gmail.com> wrote: > If the existing broken wiki is public I could take a look, it might be

> issue with rewrite rules, Oh and have you rebooted your webserver? > > On Sun, Jun 1, 2014 at 4:28 PM, Rob Lingelbach <rob(a)colorist.org>

wrote:

I can reconstruct it on 1.20. and make it public again if it helps. On Jun 1, 2014, at 3:26 PM, John <phoenixoverride(a)gmail.com> wrote: > is your wiki public? \ _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

_______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Gordon Joly

9:08 p.m.

On 01/06/14 20:14, Rob Lingelbach wrote:

...

Reloaded existing (old) LocalSettings.php

Did you do a brand new install on 1.22.7 and then compare that LocalSetting.php with the old one? Gordo

Rob Lingelbach

9:31 p.m.

I thought about that. But what about the MySQL db, how would the old one (1.20.2) compete with the new one? On Jun 1, 2014, at 4:08 PM, Gordon Joly <gordon.joly(a)pobox.com> wrote:

...

On 01/06/14 20:14, Rob Lingelbach wrote:

Reloaded existing (old) LocalSettings.php

Did you do a brand new install on 1.22.7 and then compare that LocalSetting.php with the old one? Gordo _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

-- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

Rob Lingelbach

2 Jun 2 Jun

12:27 a.m.

I have a brand new install of 1.22.7 done and ready. (ready for what I ask myself). I have years of development (data mostly) in the old Mediawiki, which I have backed up in various ways. I wouldn’t be averse to folding that data in manually to a new structure based on the clean 1.22.7 install, but don’t know quite what the best way to do that would be. I don’t mind creating a new structure for the whole thing, moving things around, etc. The db is MySQL, the OS is CentOS. My first thought was to create a parallel wiki and start moving things over from old to new and so deciding how to change them. When I created the new (1.22.7) wiki I chose a new name for it. Not sure if that allows for separate tables; the name/pwd for the tables remained the same for the old and new. On Jun 1, 2014, at 4:08 PM, Gordon Joly <gordon.joly(a)pobox.com> wrote:

...

On 01/06/14 20:14, Rob Lingelbach wrote:

Reloaded existing (old) LocalSettings.php

-- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

John

12:33 a.m.

I don't have the docs in front of me, but you should be able to just use the importdump.php and point it to the backup and import all of the old data On Sunday, June 1, 2014, Rob Lingelbach <rob(a)colorist.org> wrote:

...

On 01/06/14 20:14, Rob Lingelbach wrote:

Reloaded existing (old) LocalSettings.php

Did you do a brand new install on 1.22.7 and then compare that LocalSetting.php with the old one? Gordo _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org <javascript:;> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

-- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org <javascript:;> _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org <javascript:;> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Gordon Joly

7:35 a.m.

On 02/06/14 01:33, John wrote:

...

I don't have the docs in front of me, but you should be able to just use the importdump.php and point it to the backup and import all of the old data

Good idea! Will need some cleanup, but a good plan. :-) Gordo

Rob Lingelbach

4:37 p.m.

On Jun 2, 2014, at 2:35 AM, Gordon Joly <gordon.joly(a)pobox.com> wrote:

...

On 02/06/14 01:33, John wrote:

I don't have the docs in front of me, but you should be able to just use the importdump.php and point it to the backup and import all of the old data

Good idea! Will need some cleanup, but a good plan.

It worked after a fashion. The downside is that none of the photos made it, but the basic structure is there, minus a lot of customization. When I’ve watched my backups trundle down the directories, I’ve noticed the photos seem to be stored in (inscrutable directories) yet by their original names. If I have to, will I be able to go through manually grabbing and re-inserting them? -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

John

5 p.m.

You should be able to just copy/paste the old image directory and be good since all the data is in backup On Monday, June 2, 2014, Rob Lingelbach <rob(a)colorist.org> wrote:

...

On Jun 2, 2014, at 2:35 AM, Gordon Joly <gordon.joly(a)pobox.com <javascript:;>> wrote:

On 02/06/14 01:33, John wrote: > I don't have the docs in front of me, but you should be able to just use > the importdump.php and point it to the backup and import all of the old

data

Good idea! Will need some cleanup, but a good plan.

Rob Lingelbach

8:49 p.m.

I copied over all the old images, which were in the 1.20.2/images directory, to the 1.22.7/images directory, preserving hierarchy, etc. They aren’t appearing, and I suspect it’s because of the path change that happened with the version change. Here are is my apache httpd.conf showing the alias setup: # # (old) Alias /wiki /var/www/html/colorist/wiki3/mediawiki-1.20.5/index.php/Main_Page # # (new) Alias /wiki /var/www/html/colorist/wiki3/mediawiki-1.22.7/index.php/Main_Page So you can see perhaps On Jun 2, 2014, at 12:00 PM, John <phoenixoverride(a)gmail.com> wrote:

...

You should be able to just copy/paste the old image directory and be good since all the data is in backup On Monday, June 2, 2014, Rob Lingelbach <rob(a)colorist.org> wrote:

On Jun 2, 2014, at 2:35 AM, Gordon Joly <gordon.joly(a)pobox.com <javascript:;>> wrote:

On 02/06/14 01:33, John wrote: > I don't have the docs in front of me, but you should be able to just use > the importdump.php and point it to the backup and import all of the old

data

Good idea! Will need some cleanup, but a good plan.

_______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

-- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

John

9 p.m.

....Grumble, Grumble. If you review my previous suggestion, Which I know works because Ive done it myself several times. Is to move the old directory to a .old or archived location and unpack the new mediawiki in the same place and use the same setup you should have almost no issues. If you start re-naming the db, moving paths and what not your just adding more variables to make it more complex. At this point You may have caused too much damage to be properly upgraded. On Mon, Jun 2, 2014 at 4:49 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

...

You should be able to just copy/paste the old image directory and be good since all the data is in backup On Monday, June 2, 2014, Rob Lingelbach <rob(a)colorist.org> wrote: > > On Jun 2, 2014, at 2:35 AM, Gordon Joly <gordon.joly(a)pobox.com > <javascript:;>> wrote: > >> On 02/06/14 01:33, John wrote: >>> I don't have the docs in front of me, but you should be able to just

use

>>> the importdump.php and point it to the backup and import all of the

old

> data >> >> >> Good idea! Will need some cleanup, but a good plan. > > It worked after a fashion. The downside is that none of the photos made > it, but the > basic structure is there, minus a lot of customization. > > When I’ve watched my backups trundle down the directories, I’ve noticed > the photos seem > to be stored in (inscrutable directories) yet by their original names.

I have to, will I be able to go through manually grabbing and re-inserting them? -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org <javascript:;> _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org <javascript:;> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

_______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Rob Lingelbach

10:14 p.m.

On Jun 2, 2014, at 4:00 PM, John <phoenixoverride(a)gmail.com> wrote:

...

John

10:23 p.m.

You should be able to mass upload missing images if you extract them from the /images subdirectories and use the importimages.php as for graphs if they are not in /images your probably missing the extension that created it. Just download and install it to the new wiki. On Monday, June 2, 2014, Rob Lingelbach <rob(a)colorist.org> wrote:

...

On Jun 2, 2014, at 4:00 PM, John <phoenixoverride(a)gmail.com <javascript:;>> wrote:

....Grumble, Grumble. If you review my previous suggestion, Which I know works because Ive done it myself several times. Is to move the old directory to a .old or

archived

location and unpack the new mediawiki in the same place and use the same setup you should have almost no issues. If you start re-naming the db, moving paths and what not your just adding more variables to make it more complex. At this point You may have caused too much damage to be properly upgraded.

I understand. Yet I am upgraded to 1.22.7, but without the wiki as it existed. I will have to rebuild it somewhat by hand; some things (text based mostly) came through fine but images and drawings and graphs didn’t. Thank you for the help John. Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org <javascript:;> _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org <javascript:;> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Tom Hutchison

11:59 p.m.

Did you account for /images or /skins and a whole lot of other things in your .htaccess file? Always a bad idea to put the install in the root. This is only the start of what you need to think of. Robots.txt, google verification file, /extensions which store files such as processed widgets. Search engines will have their way with your wiki. Indexing edit pages and revision pages unless you create special rules not just Disallow /w. It will also make it harder to upgrade which is a mute discussion at this point. Not saying root install isn't possible. Just a whole lot of things to consider. To start: Check the path for /images and a file. If your rewrite doesn't ignore the /images directory you'd 404 the call to it in a page. Simple test, call the hard url to an image. /images/1/a/example.png. If it takes you to the wiki and says create a page your rewrite is not excluding the directory and seeing it as a page. Tom You should be able to mass upload missing images if you extract them from the /images subdirectories and use the importimages.php as for graphs if they are not in /images your probably missing the extension that created it. Just download and install it to the new wiki. On Monday, June 2, 2014, Rob Lingelbach <rob(a)colorist.org> wrote:

...

On Jun 2, 2014, at 4:00 PM, John <phoenixoverride(a)gmail.com <javascript:;>> wrote:

....Grumble, Grumble. If you review my previous suggestion, Which I know works because Ive done it myself several times. Is to move the old directory to a .old or

archived

_______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Rob Lingelbach

3 Jun 3 Jun

1:18 a.m.

On Jun 2, 2014, at 6:59 PM, Tom Hutchison <tom(a)hutch4.us> wrote:

...

Did you account for /images or /skins and a whole lot of other things in your .htaccess file? Always a bad idea to put the install in the root.

You mean e.g. apache’s DocumentRoot or ServerRoot? I’ve been in the habit of having mediawiki files go into a subdirectory based on (for example) DocumentRoot/wiki/mediawiki-1.22.7. and then Alias it as DocumentRoot/wiki .

...

This is only the start of what you need to think of. Robots.txt, google verification file, /extensions which store files such as processed widgets. Search engines will have their way with your wiki. Indexing edit pages and revision pages unless you create special rules not just Disallow /w. It will also make it harder to upgrade which is a mute discussion at this point. Not saying root install isn't possible. Just a whole lot of things to consider. To start: Check the path for /images and a file. If your rewrite doesn't ignore the /images directory you'd 404 the call to it in a page. Simple test, call the hard url to an image. /images/1/a/example.png. If it takes you to the wiki and says create a page your rewrite is not excluding the directory and seeing it as a page.

thank you for the advice, I’ll look at that this evening. -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

Tom

2:52 a.m.

docs root or public_html as the case may be for others. /wiki with a /wiki alias? /a or /b or whatever and rewrite as /wiki or /public or whatever you want to rewrite it too. Updates are easier /w with your new install in /wnew. Update extensions, copy over images directory, and any other files including localsettings. Rename /w to /wold and /wnew to /w. Now run update.php. Test wiki. White screen, turn on error reporting. Set at top of localsettings. Fatal in ....w/extensions/.... On line ... Comment out extension. Try to access wiki again. Another white screen, repeat. Comment out the next extension in localsettings etc. White screens can be avoided if you make sure all extensions are up to date to work with the mw version you are updating too. Sometimes there might not be an exact it works with version but the extensions talk page is a great place to look for a fix... Mod this file line xxx to this or comment out these lines. Tom Sent from my iPhone

...

On Jun 2, 2014, at 9:18 PM, Rob Lingelbach <rob(a)colorist.org> wrote:

On Jun 2, 2014, at 6:59 PM, Tom Hutchison <tom(a)hutch4.us> wrote: Did you account for /images or /skins and a whole lot of other things in your .htaccess file? Always a bad idea to put the install in the root.

thank you for the advice, I’ll look at that this evening. -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Rob Lingelbach

3:36 a.m.

On Jun 2, 2014, at 9:52 PM, Tom <tom(a)hutch4.us> wrote:

...

docs root or public_html as the case may be for others. /wiki with a /wiki alias?

Typo. Should have been docroot/wiki/mediawiki-version#. maybe good reasons not to do it that way.

...

/a or /b or whatever and rewrite as /wiki or /public or whatever you want to rewrite it too. Updates are easier /w with your new install in /wnew. Update extensions, copy over images directory, and any other files including localsettings. Rename /w to /wold and /wnew to /w. Now run update.php. Test wiki. White screen, turn on error reporting. Set at top of localsettings. Fatal in ....w/extensions/.... On line ... Comment out extension. Try to access wiki again. Another white screen, repeat. Comment out the next extension in localsettings etc.

sounds good.

...

White screens can be avoided if you make sure all extensions are up to date to work with the mw version you are updating too. Sometimes there might not be an exact it works with version but the extensions talk page is a great place to look for a fix... Mod this file line xxx to this or comment out these lines.

I had, before getting lazy and not updating MW for quite a while, noticed that many of my favorite extensions weren’t getting updated. So I wasn’t sure what would be my MW update policy, except perhaps just to drop all non-current extensions and start fresh. which is what i’ve effectively done, though without enough thought given to images, for one thing. Thank you again. -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

Rob Lingelbach

5 Jun 5 Jun

3:02 a.m.

new 1.22.7 functioning ok except that uploaded images won’t show. They upload ok, just don’t show on the wiki pages. For example, the default flower with “set wgLogo to the URL path to your own logo image” displays fine in its original form… other image uploads, after seeming to upload successfully, don’t display when I include links to them in pages in wiki syntax, or when I use a URL such as is suggested in the “default flower” text. Possibly a db error? When I updated to 1.22.7, I changed the db name to “my_wiki” (from 1.20.2’s “wikidb”) for reasons of keeping these versions separate. yet phpMyAdmin shows my_wiki with the image uploads I expect; they just don’t load into mw 1.22.7. -- Rob Lingelbach http://rob.colorist.org http://colorist.org rob(a)colorist.org

Gordon Joly

2 Jun 2 Jun

7:34 a.m.

On 02/06/14 01:27, Rob Lingelbach wrote:

...

I wouldn’t be averse to folding that data in manually to a new structure based on the clean 1.22.7 install, but don’t know quite what the best way to do that would be.

Do a mysqldump of the old, and then restore in the new? Gordo

3627

days inactive

3631

days old

mediawiki-l@lists.wikimedia.org

Manage subscription

27 comments

5 participants

tags (0)

participants (5)

Gordon Joly
John
Rob Lingelbach
Tom
Tom Hutchison