Tag Info

Hot answers tagged

12

Unless there's going to be a lot of content switching tiers, I'd recommend separate wikis, as MW was never built for solid access control. Read http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions first and decide whether it's worth the effort. There's a lot of warnings and exploits that can circumvent the protection methods. If you ...


9

One obvious point, or so it seems to me, is if you want something that's very tightly locked down then are you sure you actually want a Wiki. Isn't a large part of the ethos of a wiki that it's as open as possible? Once you've moved far enough away from the original purpose then doesn't it sooner or later become a better idea to try a different tool that has ...


6

Why don't you double check the size of the POST request. For example, you can use netcat to listen on 8080. netcat -l -p 8080 Then, redirect your browser to use a proxy on port 8080 just before submitting the form. You should get something like this: POST http://example.com/path/to/my/wiki/index.php HTTP/1.1 Host: example.com Proxy-Connection: ...


6

Use separate source code and separate databases. That way you can install extensions or custom themes in one of them without impacting others. If you really know that you will never ever have custom extensions/themes in one but not in the other wikis, then 3. seems to be a better choice than 2, but keep in mind the upload folder (there is a setting in ...


6

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 ...


5

Mediawiki upgrades are a doddle anyway, so I run 2 totally separate instances, including a copy of the plugins directory and a copy (not a symlink) of the LocalSettings.php file. I found years ago that trying to save a few minutes on running 2 upgrades would cost me days of getting it set up right, so I just don't bother anymore :) 2 DBs, 2 code instances. ...


5

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 ...


4

Hey, We use company-wide wiki. This is how we do it: We use LDAP for storage for username and kerberos for authentication. MediaWiki has extension for using LDAP. We locked down that IP address such that our offices in Canada and US has access to wiki, done on our firewall. Even though the wiki is on external IP address, the firewall only allows access ...


4

A MediaWiki installation is nothing more than a directory tree and associated database. You can run as many parallel installations as you like. Any part of the file base that needs to be shared can be done so using symlinks. It only gets tricky if you want to share parts of the database and because that tends to be a one way road to disaster you would be ...


4

You can use the template in any page. Note this excludes the search boxes. {{Special:AllPages}} There is more documentation about namespaces on the MediaWiki site.


4

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.


3

I see AdminSettings.php so this is almost certainly a MediaWiki installation. What you are going to want to do is emulate the old system that this was hosted on, most likely a LAMP setup (Linux, Apache, MySQL, PHP). Essentially, you are going to want to do the following steps (very much simplified): Build new LAMP server Copy data to public_html or ...


3

Unless that "copy" contains the database files in the mysql-data (.myd) then it probably does not have the data you are looking for. If you do have the .MYD file, then you have the actual MySQL database that the Wiki was run against and you should be able to attach that to another MySQL instance and query the data there.


3

I find the extensions BreadCrumbs, FCKeditor and InputBox quite useful.


3

You need to make it clear what is appropriate and what isn't appropriate for posting if you're going to use something like MediaWiki. That's about all of the security that you're going to get. If your business requirements mean that you need complex ACLs, you need to look at a solution designed for it. SharePoint, Traction, Alfresco and SocialText are all ...


3

MediaWiki runs under httpd, so either change httpd's port, or listen on another port as well and create a virtual host on this new port for running MediaWiki.


3

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. http://www.mediawiki.org/wiki/Manual:File_cache I spent several hours today trying to switch on any of the mediawiki recommended memory caching solutions on my ...


3

This should be as simple as just adding a second database to your MySQL (or chosen SQL system) and then resetting your config file to allow you to start the installation from scratch. cd /var/www/mediawiki cp LocalSettings.php LocalSettings.php.old nano LocalSettings.php Place in the new details and then kickstart your install.


3

check upload_max_filesize in /etc/php.ini


3

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. ...


3

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 Test


3

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.


3

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 ...


3

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.


3

Maybe /usr/share/webapps/mediawiki/images/lock_yBgMBwiR is symlink folder, check with ls -l.


2

Assume you are using to the standard search features and not an extension like sphinx have you tried running the rebuildall maintenance srcript (MediaWiki Manual) ? There is also a text index rebuild tool MediaWiki Manual


2

Did you try that address in your browser? The server is responding to pings, but there's seems to be something wrong with apache.


2

This isn't really useful for your particular application, and I'm not sure how scalable a solution it is, but DokuWiki stores all its data as text files in an open format. Should Bad Things happen like this, it becomes a godsend as the data is readable by human beings. It might be a good idea to suggest its use in the future to researchers at your ...


2

Depending on the answers you give to my questions above, Confluence is probably a good solution for you. It is a commercial wiki product but very polished and meets all your four requirements. It's also really user friendly.


2

We're using the SphinxSearch extension and it is much better than the default Mediawiki search. The extension installs directly in the Mediawiki server. SphinxSearch is only "supported" on Mediawiki 1.9+, but you may be able to shoe-horn it for testing purposes. Aside: I would recommend you look into upgrading your Mediawiki install as well as Apache, PHP ...



Only top voted, non community-wiki answers of a minimum length are eligible