I'm building out a test server and already have a production server
running. I'm considering replicating the production content over to
test using rsync.
I understand I'll need to handle the database contents differently. I
also know that I'll need to maintain a slightly different mediawiki
configuration on test than I have in production.
Is this an advisable approach? If so, what are the particular files I
should exclude during the sync process? Are there any gotchas I should
be watching out for?
Thanks in advance for your time and suggestions.
I just tarred up and copied over my entire site to a new server. I've
dumped and recovered the database and untarred everything on the new box
and everything is working fine - except most of my images are missing.
Both boxes are urning unix.
I've checked the mediawiki_install_root/images directory for permissions
or access problems but all seems fine. On a lot of the pages the logo
is missing. I would have to say at quick glance any uploaded and linked
images are gone too. The LocalSettings.php on both servers are identical.
When I relocated my wiki I nested its install root within another file
system so it isn't located exactly where it was first installed. My
thought was this wouldn't be the problem unless pointers to the image
files locations were being stored in the database. On a lark I ran a
program called rebuildImages.php --dry-run. Its output indicated there
wasn't much to be done (0 of 2 rows). So I didn't run it without the
So I'm at a loss. Is there a document that explains MediaWiki's
processing of image files or maybe that describes in detail how
Mediawiki operates? If anybody could help me find a solution it would
be greatly appreciated.
I've started the code review of the r56150:HEAD range. Eventually I
will branch the trunk and create both a new wmf-deployment and a 1.16
There are 3500 revisions and 3 months of development effort to review.
It's going to take me a long time despite the fact that my examination
of many components will be very brief.
If you want to help, here is what you can do:
* Fix things that are marked in CodeReview as "fixme". Please do this
even if you are not the original author.
* Focus on quality in your regular development work. Test your changes
before you commit them. Finish what you started.
* Review code and write comments.
Because some people use "resolved" to indicate that some small part of
the revision was fixed, despite glaring issues in the remainder, I
treat all "resolved" statuses as needing review. If a partial review
has been done, I'd prefer to see a new -> fixme -> new sequence,
instead of new -> fixme -> resolved.
Unlike last time I did this, I am respecting some of the OK status
flags set by other people. But please do not set any revisions as OK
unless you are really sure they are OK in every way. I'd rather see
people working on setting fixme statuses and leaving the OKs for me.
The exception is the review work that I'm deferring. Any sort of OK is
better than deferred.
Please do not mark your own changes as "ok" or "resolved". Please
review my changes, because I don't like to be hypocritical on this
point and will be setting them to "deferred" if nobody else is
interested in looking at them.
I think the usability initiative team is large enough and experienced
enough that they should be able to review their own changes. I'll be
doing some whole-file reviews but I'd like to avoid reviewing the
-- Tim Starling