Project:Support desk
 Archives |
- Check before posting
- Realtime help
- Mailing list
- Reports on unstable releases
Welcome to MediaWiki.org's Support desk, the central on-wiki place to ask MediaWiki questions!
The greater purpose of this page is to make our Manual and other available help so good that you do not have to come here to ask questions, or making them easier to find.
There are other ways for of communication as well (IRC, Mailing lists etc.). Read more here.
Before you post
- Please read through our technical manual and end-user help.
- Project:Current issues is where you should discuss issues about the mediawiki.org website itself.
- If your question is about an extension, consider posting your question at that extension's talk page instead.
- Project:Sandbox: Test wiki editing.
Post a new question
1. To help us answer your questions, please always indicate which versions you are using:
-
- MediaWiki (reported by your wiki's Special:Version page)
- PHP (likewise)
- Database (likewise, e.g. MySQL 4.1)
2. Please include the URL of your wiki unless you absolutely can't. It's often a lot easier for us to identify the source of the problem if we can look for ourselves.
3. To start a new thread, click "Start a new discussion".
Archiving topics
Topics are automatically archived when they have been inactive for three weeks. If a question you have asked is approaching this limit and still has not been answered, please 'bump' it to prevent it being archived. However do not 'bump' for other reasons.
- [History↑]
Contents
 First page |
 Previous page |
 Next page |
 Last page |
Have a problem with uploading files with installation for Windows Server 2008 . Files get uploaded (they do exist after upload in \\Server\mediawiki\images folders), but there are few problems with retrieving/using them. One of the problems is that when I try to get list of the files by using Special Pages – File list, the following message pops up: Server Error: 500 - Internal server error. There is a problem with the resource you are looking for, and it cannot be displayed.
The same message pops up when I try to do upload .png or .jpeg files (they are enabled in LocalSettings.php permitted file types). However, when I upload a .pdf file, the proper file:nameXYZ.pdf page is created (and links to it work OK from other content pages), but still it can’t be listed by using Special Pages – File list. The same applies to doc, docx, xls, xlsx, ppt, pptx, … (i.e. they are uploaded, page such as file:nameXYZ.doc is created and links to it work OK, but File list doesn't work – I get the above error message).
Everything else which is not related to files works OK. Any suggestion what can be wrong?
I installed: Mediawiki 1.19.2 /PHP5/MySQL5.0
GP
Hi,
Google WebMaster Tools needs the path of sitemap, but the domain name is already defined.
In other words, if the domain is www.domain-example.com, Google WMT wants only the string "sitemap.xml".
The problem is that with MW we have two domains: the real domain (www.domain-example.com/wk) and the wiki domain (www.domain-example.com/wiki).
If I send the sitemap for this last, Google looking for www.domain-example.com/wiki/sitemap.xml, but then MW search a page with this name and obviously it is not existing and so there is a 404 Error.
I've no way to send /wk/sitemap.xml because in Google WMT it is already defined the path "www.domain-example.com/wiki/".
I should set up Google WMT with the domain www.domain-example.com/wk/ but then the sitemap is wrong because its links are for the "wiki" path, not "wk". Furthermore I want to promote in Google the wiki, not the wk.
And, finally, I could not set up robot and sitemap into root of the domain because I have two independent CMSs in other folders.
How can I send correctly the sitemap?
Thanks in advance
Hello, When trying to import a page into my wiki via Special: Import, when I have the page ready to be uploaded, I hit the upload button and I am
prompted by this error message : Import Failed; No pages to import, when the page is clearly there. Does any one know of a way of fixing this, or
if I'm doing something wrong?,
Thanks
Hello,
I'm trying to download the Math extension and MediaWiki is returning the following error: Invalid response from remote subversion client. No other information is given. The download url is http://www.mediawiki.org/wiki/Special:ExtensionDistributor/Math.
Thanks, Mike
I am having the same issue.
I should add that I'm try to get the Cite extension for 1.15: http://www.mediawiki.org/wiki/Special:ExtensionDistributor?extdist_extension=Cite&extdist_version=branches%2FREL1_15&extdist_submit=Continue
I think it has something to do with switching to GIT. But instead of the Subversion place. However the implications seem to be that no one can download anything properly. Been trying with Cite, which I got from the info box, but doesn't seem to work properly yet
I've been having the same problem.
I just asked in the IRC channel and they know that it's broken, but don't have a plan, when it will be fixed again.
In the meantime, if you need an extension, you can clone the Git repository with the extension code in it.
that ain't so easy...
It's better than nothing, right?
As long as this problem is not fixed, you can update extensions using the command line (= Shell). On the Shell go to the folder "extensions/" in your installation:
cd wiki/extensions
Then get the files e.g. of the Collection extension with the following command on the command line:
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Collection.git
This will download you the folder "Collection" with the extension in it into the folder extensions/.
How can we get old versions of the extensions? I'm running 1.11 and get errors with the latest Renameuser.
Trying .. but still the same error Invalid response from remote subversion client.
Any new side available for easy downloads??
Khaled El Mansoury has just fixed the Extension Box on each page. Now you have a link to Git like this one: Git Change the extension name from "Collection" to what you need to get your extension. Attention: After extracting this archive, the folder you get will have some Git Commit name appended. You still have to remove this Commit name = rename the folder to "Collection" (or whatever extension you downloaded).
However, the download connector (which is only for SVN) still is broken.
my good friends, i am having the same problem. no extensions is working. the solution is to download git for windows if you have windows. click on the git bash type this git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git press enter, then type git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/TitleKey.git and press enter, then copy the folder TitleKey and paste on the extension folder of your wiki. then change the localsettings as per instructions. i am not an expert and have no idea what git is. the snapshot was good for me. now i just have to do things the hard way but at least i can keep moving. regards
Hi, Just to let you know. You no longer have to do that!
I have fixed the download, by simply implementing a link next to "Download Snapshot". The link text is Git, just click on it and it will automatically prompt for download a tar.gz archive which you can extract with tools like WinRAR, 7-zip, IZArc and pretty much any other ZIP/RAR archive program.
You will have to remove a code from the extracted folder, though. E.g. in your case when you download TitleKey, the resulting folder after extraction as of now is called "TitleKey-master-c5cf217", you should rename that to "TitleKey" before uploading it.
Though your method works it is quite tedious, a long process and unnecessary in comparison to a simple click on a download link.
Also when you clone the main software (i.e. core) through
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git, you download the current development version, i.e. an unstable in-progress future version being worked on by MediaWiki developers, instead of the current stable release, which you can download here: http://www.mediawiki.org/wiki/Download
My .htaccess:
RewriteEngine On
RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]
RewriteRule ^/?$ %{DOCUMENT_ROOT}/w/index.php [L]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^/?w/images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/w/thumb.php?f=$1&width=$2 [L,QSA,B]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^/?w/images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/w/thumb.php?f=$1&width=$2&archived=1 [L,QSA,B]
index.php rewrite rule works, but thumbnail doesn't.
If get thumb.php directly, it works:
thumb.php?f=test.jpg&width=180
So, the problem is in rewriting...
there is a web server error when I trying to get http://mysite.com/w/images/thumb/4/45/Chrysanthemum.jpg/180px-Chrysanthemum.jpg:
File does not exist: /home/gregk/public_html/mysite.com/w/images/thumb/4
Why the string is cutted?
I am using MediaWiki 1.19.1; PHP 5.3.10-1ubuntu3.2 (apache2handler) and PostgreSQL 9.1.5.
After a while using the wiki an error showed up in one of our categories. Every-time we enter this one category we get the following error:
MediaWiki internal error.
Original exception: exception 'DBQueryError' with message 'A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: SELECT COUNT(*) AS pages,COUNT( (CASE WHEN page_namespace=14 THEN 1 ELSE NULL END) ) AS subcats,COUNT( (CASE WHEN page_namespace=6 THEN 1 ELSE NULL END) ) AS files FROM "categorylinks","page" WHERE cl_to = 'Verfahrensanweisungen' AND (page_id = cl_from) LIMIT 1 LOCK IN SHARE MODE
Function: Category::refreshCounts
Error: 1 ERROR: syntax error at or near "LOCK"
LINE 1: ...nsanweisungen' AND (page_id = cl_from) LIMIT 1 LOCK IN SH...
^
' in /var/www/mediawiki/includes/db/Database.php:918
Stack trace:
#0 /var/www/mediawiki/includes/db/Database.php(885): DatabaseBase->reportQueryError('ERROR: syntax ...', 1, 'SELECT COUNT(*...', 'Category::refre...', false)
#1 /var/www/mediawiki/includes/db/Database.php(1358): DatabaseBase->query('SELECT COUNT(*...', 'Category::refre...')
#2 /var/www/mediawiki/includes/db/Database.php(1445): DatabaseBase->select(Array, Array, Array, 'Category::refre...', Array, Array)
#3 /var/www/mediawiki/includes/Category.php(289): DatabaseBase->selectRow(Array, Array, Array, 'Category::refre...', 'LOCK IN SHARE M...')
#4 /var/www/mediawiki/includes/CategoryViewer.php(670): Category->refreshCounts()
#5 /var/www/mediawiki/includes/CategoryViewer.php(379): CategoryViewer->getCountMessage(1, 2, 'article')
#6 /var/www/mediawiki/includes/CategoryViewer.php(90): CategoryViewer->getPagesSection()
#7 /var/www/mediawiki/includes/CategoryPage.php(97): CategoryViewer->getHTML()
#8 /var/www/mediawiki/includes/CategoryPage.php(63): CategoryPage->closeShowCategory()
#9 /var/www/mediawiki/includes/actions/ViewAction.php(40): CategoryPage->view()
#10 /var/www/mediawiki/includes/Wiki.php(484): ViewAction->show()
#11 /var/www/mediawiki/includes/Wiki.php(278): MediaWiki->performAction(Object(CategoryTreeCategoryPage))
#12 /var/www/mediawiki/includes/Wiki.php(593): MediaWiki->performRequest()
#13 /var/www/mediawiki/includes/Wiki.php(503): MediaWiki->main()
#14 /var/www/mediawiki/index.php(58): MediaWiki->run()
#15 {main}
Exception caught inside exception handler: exception 'DBUnexpectedError' with message 'SQL error: ERROR: current transaction is aborted, commands ignored until end of transaction block' in /var/www/mediawiki/includes/db/DatabasePostgres.php:313
Stack trace:
#0 /var/www/mediawiki/includes/WatchedItem.php(45): DatabasePostgres->numRows(false)
#1 /var/www/mediawiki/includes/User.php(2581): WatchedItem->isWatched()
#2 /var/www/mediawiki/includes/Title.php(1514): User->isWatched(Object(Title))
#3 /var/www/mediawiki/includes/SkinTemplate.php(971): Title->userIsWatching()
#4 /var/www/mediawiki/includes/SkinTemplate.php(455): SkinTemplate->buildContentNavigationUrls()
#5 /var/www/mediawiki/includes/OutputPage.php(1982): SkinTemplate->outputPage()
#6 /var/www/mediawiki/includes/Exception.php(182): OutputPage->output()
#7 /var/www/mediawiki/includes/Exception.php(209): MWException->reportHTML()
#8 /var/www/mediawiki/includes/Exception.php(490): MWException->report()
#9 /var/www/mediawiki/includes/Exception.php(569): MWExceptionHandler::report(Object(DBQueryError))
#10 /var/www/mediawiki/includes/Wiki.php(506): MWExceptionHandler::handle(Object(DBQueryError))
#11 /var/www/mediawiki/index.php(58): MediaWiki->run()
#12 {main}
I had a quick look in the code and the postgresql documentation: It seems that the postgresql doesn't support the "LOCK IN SHARE MODE" feature the way, MySQL does.
I can confirm that. Using current mediawiki 1.19.1 version and postgresql 8.3. Using a category with pages and files. In some categories it still works. Others are broken.
MediaWiki internal error.
Original exception: exception 'DBQueryError' with message 'A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: SELECT COUNT(*) AS pages,COUNT( (CASE WHEN page_namespace=14 THEN 1 ELSE NULL END) ) AS subcats,COUNT( (CASE WHEN page_namespace=6 THEN 1 ELSE NULL END) ) AS files FROM "categorylinks","page" WHERE cl_to = 'Java_EE' AND (page_id = cl_from) LIMIT 1 LOCK IN SHARE MODE
Function: Category::refreshCounts
Error: 1 FEHLER: Syntaxfehler bei »LOCK«
LINE 1: ...to = 'Java_EE' AND (page_id = cl_from) LIMIT 1 LOCK IN SH...
^
' in /var/www/mediawiki-1.19.1/includes/db/Database.php:918
Stack trace:
#0 /var/www/mediawiki-1.19.1/includes/db/Database.php(885): DatabaseBase->reportQueryError('FEHLER: Syntax...', 1, 'SELECT COUNT(*...', 'Category::refre...', false)
#1 /var/www/mediawiki-1.19.1/includes/db/Database.php(1358): DatabaseBase->query('SELECT COUNT(*...', 'Category::refre...')
#2 /var/www/mediawiki-1.19.1/includes/db/Database.php(1445): DatabaseBase->select(Array, Array, Array, 'Category::refre...', Array, Array)
#3 /var/www/mediawiki-1.19.1/includes/Category.php(289): DatabaseBase->selectRow(Array, Array, Array, 'Category::refre...', 'LOCK IN SHARE M...')
#4 /var/www/mediawiki-1.19.1/includes/CategoryViewer.php(670): Category->refreshCounts()
#5 /var/www/mediawiki-1.19.1/includes/CategoryViewer.php(401): CategoryViewer->getCountMessage(3, '5', 'file')
#6 /var/www/mediawiki-1.19.1/includes/CategoryViewer.php(91): CategoryViewer->getImageSection()
#7 /var/www/mediawiki-1.19.1/includes/CategoryPage.php(97): CategoryViewer->getHTML()
#8 /var/www/mediawiki-1.19.1/includes/CategoryPage.php(63): CategoryPage->closeShowCategory()
#9 /var/www/mediawiki-1.19.1/includes/actions/ViewAction.php(40): CategoryPage->view()
#10 /var/www/mediawiki-1.19.1/includes/Wiki.php(484): ViewAction->show()
#11 /var/www/mediawiki-1.19.1/includes/Wiki.php(278): MediaWiki->performAction(Object(CategoryPage))
#12 /var/www/mediawiki-1.19.1/includes/Wiki.php(593): MediaWiki->performRequest()
#13 /var/www/mediawiki-1.19.1/includes/Wiki.php(503): MediaWiki->main()
#14 /var/www/mediawiki-1.19.1/index.php(58): MediaWiki->run()
#15 {main}
Check out this bug: Bug 39635 - PostgreSQL LOCK IN SHARE MODE option is a syntax error. As the error message suggests "LOCK IN SHARE MODE" is not valid PostgreSQL syntax.
After clicking the bar "upload", page reloading without uploading file: http://factografia.com/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:Upload
I reinstalled LocalSettings.php and it's working!!! But InstantCommons not working. Is it free service or not?
It's free and may enabled with follow setting in LocalSettings.php: $wgUseInstantCommons = true;
I have enabled wgUseInstantCommons on the wiki I develop (http://practicalplants.org/wiki) but it doesn't appear to cache images, and appear to be requested from the commons each time they are displayed. If I load a page which pulls in images from a number of pages, it's clear from the long wait that they are being requested from the commons each time (eg. http://practicalplants.org/wiki/Search). Also, if I disable commons then none of the images previously loaded are available - I'm assuming that would not be the case if caching was working.
I have tried replacing $wgInstantCommons=true with the $wgForeignFileRepos[] value defined on http://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons#Details to no effect.
Is there something I can do to debug this? Are there folder permissions that need to be checked?
Thanks! Andru
Hi, i have the same issue on http://thwiki.org. I use the option "$wgUseInstantCommons = true;" since long time and the mediawiki cache the thumbnails in /image/thumb.
Since the update from 1.19.0 to 1.19.2 i can found in the folder /image/thumb only the thumbnails of local images.
Enabling "$wgHashedUploadDirectory" did not change this issue. To set the permissions on /images to 0777, but this has no effect, too.
Hello, After executing the importDump.php command in terminal, I get this error message: Warning: fopen(Test.xml): failed to open stream: No such file or directory in /Users/*/Sites/mediawiki/maintenance/importDump.php on line 240 Warning: feof() expects parameter 1 to be resource, boolean given in /Users/*/Sites/mediawiki/includes/Import.php on line 1499 Warning: fread() expects parameter 1 to be resource, boolean given in /Users/*/Sites/mediawiki/includes/Import.php on line 1506 Warning: feof() expects parameter 1 to be resource, boolean given in /Users/*/Sites/mediawiki/includes/Import.php on line 1499 Warning: XMLReader::read(): uploadsource://4f78e998b4b2e97b854b0642fd83a24d:1: parser error : Extra content at the end of the document in /Users/*/Sites/mediawiki/includes/Import.php on line 399 Warning: XMLReader::read(): in /Users/*/Sites/mediawiki/includes/Import.php on line 399 Warning: XMLReader::read(): ^ in /Users/*/Sites/mediawiki/includes/Import.php on line 399 Warning: XMLReader::read(): An Error Occured while reading in /Users/*/Sites/mediawiki/includes/Import.php on line 399 Set $wgShowExceptionDetails = true; in LocalSettings.php to show detailed debugging information., Does anyone know what I am doing wrong, or have to change?
I recently installed MediaWiki on my domain http://www.justadude.ca. Installation info is: MediaWiki 1.19.1, PHP 5.2.17 (cgi), MySQL 5.0.91-log via my webhost http://www.netfirms.com
My hope had been to edit it directly from my Blackberry. Unfortunately, the edit option doesn't appear on my Blackberry 9900 at the top. It's only available for subsections. My blackberry is OS 7.1 bundle 1310, v7.1.0.391 platform 5.1.0.319 on the Rogers Network.
I can work around this by adding "&action=edit" to the URL, but it's a bit annoying.
If anyone has any info on how I can enable the editing option at the top on my Blackberry, I would very much appreciate it!
Here is the link to a screenshot: http://www.justadude.ca/index.php?title=File:Blackberry-9900-no-edit.jpg
I guess that the edit tab in fact is there, but since the screen is so small, it has slid behind the tabs "page" and "discussion". If you could zoom the page a bit smaller, you should be able to see the button.
I'm working all the day to install EasyTimeLine in my WK 1.19.2.
I tried every type of advice existing in the talk of EasyTimeLine Installation page but I get always the same error:
- mod_fcgid: stderr: PHP Fatal error: Call to undefined method FSFileBackend::doQuickOperations() in /my-domain-path/public_html/wk/extensions/Timeline.php on line 167, referer: http://www.common.it/wk/index.php?title=Common_Wiki:Sandbox2&action=edit
I don't think that the problem is about the position of pl command or of the timeline.php, but in the method called.
I also noticed that in the requirements is provided "NConvert", but in any part of the instructions for installation this is mentioned, so I think it is not required for Linux.
Someone can help me to resolve this issue?
Thanks in advance.
Hello,
I would like to upload some technical documentation to my wiki and some files are slightly bigger than the default maximum size of 2 MB. I first changed the settings in php.ini /etc/php5/apache2/php.ini
Maximum size of POST data that PHP will accept.http://php.net/post-max-size
post_max_size = 160M
File Uploads ;
Whether to allow HTTP file uploads.http://php.net/file-uploads
file_uploads = On
Temporary directory for HTTP uploaded files (will use system default if notspecified).http://php.net/upload-tmp-dirupload_tmp_dir =
Maximum allowed size for uploaded files.http://php.net/upload-max-filesize
upload_max_filesize = 40M
Maximum number of files that can be uploaded via a single request
max_file_uploads = 20
I applied these changes also to /etc/php5/cli/php.ini
then I appended to the end of
/etc/mediawiki/LocalSettings.php (same as /var/lib/mediawiki/LocalSettings.php)
$wgUploadSizeWarning = 2147483648; $wgMaxUploadSize = 2147483648;
Restarting Apache or rebooting the computer has no effect. When I upload my 2.327 KB-file, mediawiki shows a warning in the preview, but the output looks fine. When I want to save the page, mediawiki refuses saving.
I use an Ubuntu 12.04 system with apache 2.2.22, mediawiki 1.15.5 and php 5.3.10.
How can I enable uploads >2MB?
Thanks, Martin
Hi Martin,
have you checked, if the PHP settings you made are actually taking effect? Check what phpinfo() tells you about the values of these variables.
Thanks, but that seems ok:
php phpinfo.php|grep upload
file_uploads => On => On
max_file_uploads => 20 => 20
upload_max_filesize => 40M => 40M
upload_tmp_dir => no value => no value
file_uploads => On => On
max_file_uploads => 20 => 20
upload_max_filesize => 40M => 40M
upload_tmp_dir => no value => no value
Do you have other ideas?
That is what you have in CLI mode. Did activating these settings also work properly for Apache in non CLI mode?
If that worked, I would search the MediaWiki source code for the exact error message, which you get. That way you should find the place in the source code, where this error happens. Then check, which conditions must have been true, before getting the error message. This should help you find the reason for the problem.
Thanks,
I never heard about Apache CLI/ non CLI mode and unfortunately, google does not help. I looked in /var/log/apache2/error.log, but there are no errors related to mediawiki listed. Is there a mediawiki error-log?
When you posted this shell command some posts above I thought you knew about Apache and that stuff, that's why I didn't explain it in detail. ;-)
When you run a script on the shell like you do with
$php phpinfo.php|grep upload
then the CLI configuration of your machine is used.
But when you run a script with your webbrowser, the configuration, which you have provided for that mode will be used. Checking this configuration is rather easy: Upload a file to your webspace with this content:
<?php phpinfo(); ?>
and view it with your webbrowser. You will then see the PHP settings which apply, when your website (read: MediaWiki) is called with a webbrowser. There the upload sizes must be correct/big enough.
I don't know of a MediaWiki error log. MediaWiki can write a debug log, but I don't know, if failed uploads would be logged there. But where you could still have a look is the PHP error log, which you should find in the folder php/logs.
Hello having problems loading up the pages on a site. Whatever page you go to comes up with the same error:
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "MediaWikiBagOStuff::_doinsert". MySQL returned error "1142: INSERT command denied to user 'uwikica_514419_2'@'linweb14.atlas.pipex.net' for table 'trueobjectcache' (cust-mysql-123-01)".
the versions are MediaWiki 1.15.2 php 5.2.16 mysql 5.1.52
I googled this error and found an entry that suggested the database was over the size allowed on the hosting. If this is the case, which tables can I delete from to give back enough space to be able to load up the site?
Im looking for a way to setup a quick link to open a message from inside mediawiki. Yes i know communicator is a horrid program, but I have no control over this. I want it to work basically like the email tag works. Any ideas would be greatly appreciated.
How does a link to a MS communicator message look like?
I think it should be possible to create such a link as interwiki link...
the link that was given to open a message via a link was <a href="sip:[email protected]">User</a> but i have been unable to figure out how to format this so mediawiki recognizes it as an actual link since its html format
I'm using an external authentication plugin for the wiki I develop (http://practicalplants.org/wiki). When page caching is turned on, the page will be cached with the user details of whoever viewed the page first, which is then displayed to both anonymous users and logged in users alike. Is there a way around this? Perhaps a way to enable caching of just the rendered article and not the entire skin? Not having caching enabled for anonymous users is causing quite a performance hit and painful delay in page rendering.
On a similar note, I've noticed an oddity which may or may not be a recognised bug, and which I'm having a hard time finding a pattern to. I have disabled anonymous editing, which sometimes leaves parser replace tags (eg UNIQ-long-hash-string), usually relating to Reference tags or templates, in the page for users who are not logged in. Users who are logged in (and thus have edit permissions) do not experience this problem. As I can't reproduce it reliably, I'm at a loss as to how to debug it. If you've come across anything like this before and have any tips on where to start digging, it'd be a great help.
Thanks in advance for any help you can offer Andru
The image thumbnail function on my entire wiki is broken... it can only show images at full size, or previously-created thumbnails. It can't seem to create any new thumbnails of any size.
Any thumbnail only has a grey box that looks like this:
| Error creating thumbnail: convert: Unrecognized option (-set). |
The only options related to ImageMagick in my LocalSettings.php file are:
- $wgUseImageMagick = true;
- $wgImageMagickConvertCommand ='C:\mowes\ImageMagick\convert.exe';
(Hiding the $wgImageMagickConvertCommand option changed the error to "Error creating thumbnail: The system cannot find the path specified.")
All other options (relating to SVGs, which never worked: see here) were removed to try and undo this glitch, but it didn't fix anything.
Please help. This problem has crippled my wiki since early August.
Resolved by upgrading to ImageMagick 6.8.0 (even though MoWeS won't recognize the new software, it seems to be working).
SVGs are still a little glitchy, but not generating crippling errors anymore.
I would like to update my MediaWiki 1.16 to the newest version in MoWeS Portable... but the Manual:Upgrading page is filled with confusing technobabble, and appears geared only toward upgrading MediaWiki on an actual online web server. I have no experience with running web servers or any command-line system (and neither does anyone I know), and I don't know how (or where) to execute any of the commands listed in that manual.
Can someone who understands this stuff walk me through the process with an introductory "for dummies" level of complexity? (I suppose a self-installer executable file for Windows XP would be asking too much...)
I currently have the newest software packaged by MoWeS:
- Apache2 (version 2.2.11)
- MySQL5 (version 5.5.8)
- PHP5 (version 5.3.5)
- ImageMagick (version 4.2.9)
- MediaWiki (version 1.16)
I'd like to update whatever can be updated, but especially MediaWiki.
Hi!
I have good news for you: With your software (Apache, PHP, MySQL) you do not have to do any additional updates. Updating only MediaWiki is enough.
Manual:Upgrading is mainly targeted at users with a Linux server; but you have Windows XP. So you have to adapt parts of the commands, which are presented there. E.g. you cannot just type "php update.php" on the Windows command prompt to run the script update.php with php.exe. Instead you would first have to change directory to the path in which you have update.php and call php.exe by typing the complete path to the exe.
In short to do the update you must do two things:
First replace the old MediaWiki files with the new ones and second update your database.
That means: Download the tar archive with the newest source code (version 1.19.2) and extract it on your PC. Check which files and folders you have there; these are the ones, which you have to replace in your MediaWiki installation. Move the old files and folders out of the way (maybe best do not delete them, but only move them to the dustbin, just in case something goes wrong) and put the new files and folders there.
Make sure your Apache server and MySQL are running. Now update the database. Two options: The easy one is to use your webbrowser. Visit the URL, which basically points to your wiki, but do not let it point to the MediaWiki mainscript index.php, but to mw-config/index.php. This is a web updater, which does the needed database updates, when you go it through. Second option would be to do the database updates by running the file maintenance/update.php on the Windows Command Prompt with PHP.
To run update.php via command prompt, if you have MediaWiki in C:\Mowes\MediaWiki, you would first cd to C:\Mowes\MediaWiki\maintenance. If you have php.exe in C:\Mowes\php\php.exe, you would then execute php.exe with C:\Mowes\php\php.exe update.php like so:
Microsoft Windows XP Copyright Microsoft Corp. 1985 - 2001 C:\Documents\Terminator> cd C:\Mowes\MediaWiki\maintenance C:\Mowes\MediaWiki\maintenance> C:\Mowes\php\php.exe update.php
Attempting to follow these instructions DELETED my entire database.
I've been able to partially restore it (drag & drop, overwriting the files), by using a zipped file that contained the entire contents of my Mowes directory... but it wasn't current, and I lost several weeks worth of very hard work.
Needless to say, I am PISSED at the above person.
Oh, and the "mw-config/index.php" does not exist, either.
I am sorry to hear that. However, please do not forget that you are responsible for what you do. Neither Manual:Upgrading nor my instructions, which are based on the very same page, tell you to delete your database. Additionally it was your decision not to create a backup (although Manual:Upgrading explicitly tells you to do so!); now don't blame others for your faults! And by the way: The folder "mw-config/index.php" does exist; if in your installation it doesn't, you again did something wrong.
You're certainly less than helpful.
And no, I didn't do anything wrong with the installation. It came from a MoWeS package. Again, it does not contain a "mw-config" folder. There is a "config" folder though.
If you didn't do anything wrong, why have you then deleted your database? Why have you not tried out in a test install first? Why have you not made a backup?
I have helped you and as a thank you you have nothing better to do than to claim I would be "less than helpful"? Are you off your fucking rocker?!?! I have given you exactly the help you asked for and that more than extensively; what do you want? Don't blame me for your incompetence. If you are unable to do what you are told, that is not my problem. If you know exactly that you do not know how to do things, why don't you try out in a test install first?
It is not my fault, when you don't test things first. It is not my fault, when you do not create a backup. It is not my fault, when you delete your database. There are so many ways that would have prevented you from loosing all your oh so precious data; but when you are just too stupid to pick only one of them, then also I can't help.
The Image administration manual says MediaWiki 1.17 and higher requires "ImageMagick 6.5.6-2" or higher. I only have 4.2.9, so how do I update that too?
The ImageMagick FTP server indicated in my version's readme doesn't seem to exist, so where do I get ImageMagick?
- Most importantly... is there an installer executable for Windows XP?
[1] Is that what you need?
I think so... but it's really quite weird. I tried installing it, but MoWeS sorta half recognizes it, and only under certain conditions. The webpage MoWeS opens when it starts the server makes a list of software running, and another for installed packages. It still insists the only installed package is version 4.2.9.
Here's where it gets weirder... The new ImageMagick installed to a folder called "ImageMagick-6.8.0-Q16", and MoWeS can't recognize this folder, and just doesn't see it. Renaming it to simply "ImageMagick" result in that MoWeS summary page displaying a message that version 6.8.0 is installed and works... yet the package listed is still only 4.2.9.
MoWeS seems pretty glitchy on the subject, so perhaps it's better to judge functionality by how it actually works in the wiki, and ignore what the MoWeS thing says. That took some guesswork and modifying my LocalSettings.php file a little. First, an explosion of errors regarding a bad path (despite correcting the paths) in thumbnail renders... but renaming the "ImageMagick" folder to "ImageMagick-6.8.0-Q16" again, and altering the path callouts in the LocalSettings.php file (to what it was looking for), cleaned up all the errors. For the first time ever, my wiki supports SVGs!
But it's still a bit buggy. Two of my test SVGs are strangely missing their colors... which I'll take to a more relevant thread for that topic.
Still don't know how to update the MediaWiki software though...
Can somebody please help me get my wiki to display SVG files? I'm having error after error, and I don't understand how SVG works yet.
- Be advised: this is a private wiki that is offline (similar to a wiki-on-a-stick), running on Windows XP through the MoWeS Portable II server package. The wiki version is MediaWiki 1.16.0.
I've successfully set my LocalSettings.php file to allow SVG uploads, and am using a few simple test images pulled straight from Wikipedia.
The Configuration settings and Image Administration Manuals here on MediaWiki have not been helpful at resolving the problem, and have only yielded more complicated errors that are not mentioned in those manuals.
My current LocalSettings.php configuration settings for SVG files reads as follows:
$wgAllowTitlesInSVG = true; $wgSVGConverter = 'ImageMagick'; $wgSVGConverterPath = "C:\mowes\ImageMagick"; $wgSVGConverters = array( 'ImageMagick' => '$path/convert -background white -thumbnail $widthx$height\! $input PNG:$output');
The current error is:
Error creating thumbnail: convert: no delegates configuration file found (delegates.mgk). convert: no delegate for this image format (SVG). convert: Missing an image file name.
- Addendum
- ALL image thumbnail rendering is also broken. The error is vague and unhelpful:
Error creating thumbnail: The system cannot find the path specified.
Undoing the changes made to LocalSettings.php failed to correct the problem.
Please help.
The error
Error creating thumbnail: convert: no delegates configuration file found (delegates.mgk). convert: no delegate for this image format (SVG). convert: Missing an image file name.
I think means that you have image magick set up incorrectly (As in the convert program itself, not MediaWiki). Basically convert is missing a file that tells it how to thumbnail various image formats. Try re-installing image magick.
Error creating thumbnail: The system cannot find the path specified.
Did you set $wgImageMagickConvertCommand to something appropriate?
How do I re-install ImageMagick on Windows? Version 4.2.9 came as part of the MoWeS package; and I don't know how to upgrade anything on a server.
I didn't even have $wgImageMagickConvertCommand set to anything... but when I added that line, the error for thumbnails changed to:
Error creating thumbnail: convert: Unrecognized option (-set).
And the error for SVGs stayed the same.
Hiding the $wgSVGConverterPath = "C:\mowes\ImageMagick"; line changed the SVG error to:
Error creating thumbnail: Invalid Parameter - white
> Error creating thumbnail: Invalid Parameter - white
After reading about passthru(), it seems there are some PATH issues. You can fix this bug by forcing the search path via $wgSVGConverterPath. For example, $wgSVGConverterPath = 'C:/Program Files/ImageMagick-6.4.5-Q16/' fixes it for me.
Setting $wgSVGConverterPath = "C:\mowes\ImageMagick"; changes the error from "Error creating thumbnail: Invalid Parameter - white" to:
Error creating thumbnail: convert: no delegates configuration file found (delegates.mgk).
convert: no delegate for this image format (SVG).
convert: Missing an image file name.
It does not fix the problem.
After a complicated (to put it mildly) upgrade to ImageMagick 6.8.0, the errors have all vanished...
...but there's one little bug remaining, that hopefully will be simpler to fix.
Among my test SVGs are a few generic images copied straight from the Wikimedia Commons. Two of them are rendering oddly... File:X_mark.svg and File:Yes_check.svg are both just a black outline with white interiors: no colors.
Any idea what's wrong?
First page |
Previous page |
Next page |
Last page |
