MediaWiki - Move a site
I am working on a project that involves "MediaWiki"; I am an experienced web developer, I have never used MediaWiki before.
The first thing I want to do is move a copy of the site to another location for several reasons; mostly just to make revisions on a test basis without disturbing the "live" site until we are ready to apply the new version.
Can someone point me in a direction on how to do this?
Thanks
The first thing I want to do is move a copy of the site to another location for several reasons; mostly just to make revisions on a test basis without disturbing the "live" site until we are ready to apply the new version.
Can someone point me in a direction on how to do this?
Thanks
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
In your root FTP folder are a bunch of folders that come as a standard, one of them is skins. This is the folder in which you store custom designs to create a look and feel for the wiki. This includes custom navigation bars, header images, backgrounds etc.
The skins folder will contain subfolders and it is good practice, if you have a custom skinning setup, to name a subfolder accordingly. So if you worked on a Star Wars Wiki, a custom folder is likely to be named 'starwarswiki'.
If you installed a fresh MW today, you get 4 skin folders: CologneBlue, Modern, MonoBook and Vector. There is also a Readme file that tells you about how to use them. Depending on the age of your install you will see similar folders.
Namespaces are a handy way of creating different skins for certain areas. When you create custom name spaces you can control the look & feel of a named section, so that al cascading con tent in that section looks the same, in our Star Wars example you may want to theme each episode with a different header image or background, custom namespaces allow you to do that. You would find a folder called namespaces or similar in your active skin folder. Here is more about Namespaces.
If you cannot find any unusually named skins or any subfolder referring to namespaces then is is likely the vanilla base install and you don't need to worry about it, but on quite a few sites I looked after they had different developers over the years and there is much left behind that may or may not be vital.
hth
capt.
The skins folder will contain subfolders and it is good practice, if you have a custom skinning setup, to name a subfolder accordingly. So if you worked on a Star Wars Wiki, a custom folder is likely to be named 'starwarswiki'.
If you installed a fresh MW today, you get 4 skin folders: CologneBlue, Modern, MonoBook and Vector. There is also a Readme file that tells you about how to use them. Depending on the age of your install you will see similar folders.
Namespaces are a handy way of creating different skins for certain areas. When you create custom name spaces you can control the look & feel of a named section, so that al cascading con tent in that section looks the same, in our Star Wars example you may want to theme each episode with a different header image or background, custom namespaces allow you to do that. You would find a folder called namespaces or similar in your active skin folder. Here is more about Namespaces.
If you cannot find any unusually named skins or any subfolder referring to namespaces then is is likely the vanilla base install and you don't need to worry about it, but on quite a few sites I looked after they had different developers over the years and there is much left behind that may or may not be vital.
hth
capt.
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trial
Easy.
a. Setup server B like server A: Apache + relevant modules, php, php extensions, httpd.conf and its brethen.
b. Setup a Mysql server. Can be on the same server, or not.
c. Copy the mediawiki folders from server A to server B
d. Dump database A, easy if you use phpmyadmin.
e. Import database A into mysql server B.
f. Update LocalSetting.php with the new database address, db name, user and password.
If properly done, this is enough. Otherwise follow the error trail :)
a. Setup server B like server A: Apache + relevant modules, php, php extensions, httpd.conf and its brethen.
b. Setup a Mysql server. Can be on the same server, or not.
c. Copy the mediawiki folders from server A to server B
d. Dump database A, easy if you use phpmyadmin.
e. Import database A into mysql server B.
f. Update LocalSetting.php with the new database address, db name, user and password.
If properly done, this is enough. Otherwise follow the error trail :)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Web Languages and Standards
From novice to tech pro — start learning today.
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
With the caveat that I have not done this myself (yet) I have worked on Mediawiki sites in the past and just installed a fresh out of the box one on my own website (to be published)
In principle there are 4 main aspects:
I would think that you backup everything flat, via FTP so any custom assets are backed up ready for re-upload. MySQL backups via DB export from original db and import into new target db. I cannot imagine it will be any more complex than that.
If the wiki has got self referring links with absolute URLs rather than relative it may get more complex as you have to find and replace old domain references with the new one...
MW has a detailed help source here
hth
capt.