Probably the easiest way would be to first create a mysqldump of the database while it's pristine:
mysqldump -u <username> -p <password|credentials file> mediawiki > media-wiki-pristine.sql
...then script a MySQL database drop:
mysql -u <username> -p <password|credentials file> -e "drop database mediawiki;"
...followed by a ...
My first suggestion would be to ensure you are fixing the right problem.
Track your memory usage over a reasonable time frame and see how high it goes (and if you can correlate this to something such as increased traffic).
If you already have some monitoring in place (e.g. Munin) you should be able to see memory trends
Otherwise, use sar (e.g. if you ...
Some great tips here. For me the thing that made the biggest difference (from 8 seconds to 0 on IIS 7) was enabling caching and changing $wgDBserver = "127.0.0.1"; (from localhost). For some reason localhost was being resolved via the network.
Here is the whole post by Jaded:
One of the biggest impacts, reducing the load from 15 seconds down to around 6 ...
Instead of memory caching especially if your site is small to medium size, so the total size of of all the hmtl pages isn't an issue - a simple solution is to just switch on the file cache instead.
I spent several hours today trying to switch on any of the mediawiki recommended memory caching solutions on my ...
Do you care at which layer in the stack the encryption happens?
Short of massively modifying the source code to decrypt all DB queries (and that's ignoring the key management aspect), the best bet might be to encrypt the partition that the database lives on.
What is the reasoning behind it? There may be a better way.
You could start by reducing Google and Bing requests... Have you set up a robots.txt? Exclude the ScriptPath from crawling, so that only the canonical page URLs are indexed, but not any URL with parameters to api.php or index.php. Also set a crawl-delay if needed.
Many MediaWiki sites are slowed down by search engines due to small configuration errors.
You need to change the collation of the database/tables, by selecting one that equates é with e that is most suitable for your needs, such as utf8_general_ci.
You should carefully select one based on your requirements, unfortunately there are a lot to choose from; http://dev.mysql.com/doc/refman//5.5/en/charset-unicode-sets.html
MySQL also offers some nice ...
I'd suggest looking into the official Mediawiki support channels. They probably have a forum, mailing list, etc.
I haven't used Mediawiki in quite a while, but my recollection is that if you delete pages through the web GUI, they just get marked as "deleted" in the database (and thus are not displayed), but the actual content still exists in the database. ...
It looks like you have the libraries installed in a non standard location.
If this is the case, it could be that php simply doesn't know where to look for the libraries it needs. Try setting the LD_LIBRARY_PATH environment variable to that path before launching php, if you're running it from command line. For example in bash:
Have you tried checking MediaWiki's process for moving a Wiki?
The short version is:
Back up the database
Back up the MediaWiki files
Re-create the database, user and permissions
Import the database backup
Import the MediaWiki files
Check the configuration file
The problem lies with the browser not the installation.
It appears that the Google Chrome browser has some sort of caching problem. I found that when I cleared the browser cache, the problem went away.
You must configure MediaWiki so that it will actually obey the X-Forwarded-For header. Without these settings, MediaWiki will ignore it.
(For historical reasons all of these configuration options refer to Squid...)
At a minimum, these lines must be in your LocalSettings.php:
$wgUseSquid = true;
$wgSquidServers = array('127.0.0.1'); # IP address of your ...
It turns out that the SQL Server driver only supports PHP 5.4 (there's also a preview for 5.5) and I was using PHP 5.6. Rolling back to PHP 5.4 and enabling the php_pdo_sqlsrv_54_nts.dll and php_sqlsrv_54_nts.dll extensions worked.
Take a look at your request headers.
Edit: These were not the cause of trouble and can be safely ignored. Varnish documentation stating:
Note By default, Varnish does not care about the Cache-Control request
header. If you want to let users update the cache via a force refresh
you need to do it ...
Yes, it will work fine. Be sure to keep them in separate paths and use separate databases for them, but otherwise you should see no trouble.
Whether there is any reason to do this or why you might want to do it on Windows is another question entirely, but there is no reason it shouldn't work.
First of all you have to Be sure That You use Apache Server'''. Mediawiki is slower if you have installed on Windows Server Or IIS. If it is on the Windows Server Move the Application Folders to Linux Server. Windows and Linux Server for Mediawiki Guide
Your media wiki URL starts from the path specified in your web server configuration, not your file path. In this case, the info is found in mediawiki.conf under /etc/apache2/conf.d directory.
On my own ubuntu server, it looks like I would have to uncomment out this alias in the file:
Alias /mediawiki /var/lib/mediawiki
Which allows me to access the URL ...
I'm having a very hard time parsing what exactly occurred here (wikimedia's infamous bureaucracy).. but what it looks like to me is that the release note made it in (diff), but the change to actually enable the feature was reverted.
The only clear notes on this seem to be in the commit notes for the revert, with nothing in the outstanding bug.
You're barking up the wrong tree. I have SSL enabled on my mediawiki install and uploads work fine with no additional modifications.
You should look elsewhere, like what extensions are allowed to be uploaded, for example.
You also say "I updated my write permissions to the /images/". I hope that this is just poorly worded. Your permissions to /images don'...
That's a very interesting expression they have there. Their main manual page for short URLs has this to say:
These guides are old and are almost entirely bad advice.
Anyway, let's see if we can simplify it a bit.
rewrite ^/wiki/([^\?]*) /mywiki/index.php?title=$1&$args last;
Note that you can't overlay the 'pretty' path (which you've put in the ...
According to the PHP manual, htmlspecialchars does take 4 parameters, 3 of which are optional.
This suggests that Quercus is an incomplete implementation of PHP.
A Warning in PHP usually indicates that it is going to keep going and do whatever it can. Presumably, in this case, it will behave as if it were set to true and hence it will double-encode any ...
If this is about spambots trying to edit, you could try some of the webserver-level antispam solutions: https://www.mediawiki.org/wiki/Manual:Combating_spam#Hardcore_measures
Or it could be that your antispam measures are bringing the site down, it's not uncommon; check that your solutions are performant, some cures are worse than the illness.
If you're not ...
This is caused by SELinux, rather than setting SELinux to only log and not enforce policy (permissive mode) you can modify the labels on the file system to allow the Apache to write the location while SELinux is enforcing:
Assuming /usr/local/mediawiki-1.20.5/images is the location you want to allow write access to:
semanage fcontext -a -t ...
It looks like it is done by manually adding an entry into MediaWiki's interwiki table (reference):
REPLACE INTO interwiki (iw_prefix, iw_url, iw_local) VALUES
The caveats of manually editing a database apply (backup table/database, double-check your query, etc...).