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 success
On Jun 2, 2014, at 9:52 PM, Tom 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 w
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
On Jun 2, 2014, at 6:59 PM, Tom Hutchison 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 f
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. Sear
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
On Jun 2, 2014, at 4:00 PM, John 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
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
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
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 wrote:
>
> On Jun 2, 2014, at 2:35 AM, Gordon Joly > wrote:
>
> > On 02/06/14 01:33, John wrote:
> >> I don't have the docs in front of me, but you s
On Jun 2, 2014, at 2:35 AM, Gordon Joly 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.
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
__
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
___
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 wrote:
> I have a brand new install of 1.22.7 done and ready. (ready for what I ask
> myself).
>
> I have
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
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 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 a
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@lists.wikimedia.or
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 wrote:
> meant to say, the URL below is the path to the existing broken 1.22.7
> install
> as it exists no
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 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
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 wrote:
> If the existing broken wiki is public I could
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 wrote:
> I can reconstruct it on 1.20. and make it public again if it helps.
>
> On Jun 1, 2014, at 3:26 PM,
It was until I started upgrading it. Now it’s down.
On Jun 1, 2014, at 3:26 PM, John wrote:
> is your wiki public?
>
--
Rob Lingelbach http://rob.colorist.org
http://colorist.org r...@colorist.org
___
MediaWiki-l mailing list
MediaWiki-l@lists
I can reconstruct it on 1.20. and make it public again if it helps.
On Jun 1, 2014, at 3:26 PM, John wrote:
> is your wiki public?
\
___
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
is your wiki public?
On Sun, Jun 1, 2014 at 4:22 PM, Rob Lingelbach wrote:
>
> On Jun 1, 2014, at 2:34 PM, Rob Lingelbach wrote:
>
> >
> > On Jun 1, 2014, at 2:19 PM, John wrote:
> >
> >> I would have waited for 1.23. But your first step is either upgrading
> the
> >> extensions or removing th
On Jun 1, 2014, at 2:34 PM, Rob Lingelbach wrote:
>
> On Jun 1, 2014, at 2:19 PM, John 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 to
>> debug. Once you remove all your extensio
On Jun 1, 2014, at 2:19 PM, John 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 to
> debug. Once you remove all your extensions you can add them back one by one
> until your wiki breaks.
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 Su
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
28 matches
Mail list logo
