I have MW 1.24.1 installed on CentOs7 with nGinx and PHP-FPM 5.4.16. I am not using ImageMagick.
With that stated, I am having an issue where thumbs are not being created for files when they are used in articles with a specific width defined. Image uploads work fine, and a thumb gets made when a file is uploaded (I assume it's what is displayed on the File:) page. However, attempting to use the image with a new size ends up with a 404 due to the thumb not being there. I am not getting any PHP errors, there is nothing in my system log or my web server logs that would indicate a permission issue.
I enabled debugging on a page that attempted to use a resized image, and the log can be found at http://pastebin.com/yeif2YHw
I don't know enough PHP to understand what the TransformationalImageHandler is doing, but I have a strong feeling that
TransformationalImageHandler::doTransform: creating 150x200 thumbnail at mwstore://shared-backend/shared-thumb/6/67/BFZLogo.png/150px-BFZLogo.png using scaler gd
TransformationalImageHandler::doTransform: Transforming later per flags.
File::transform transformation deferred.
isn't a good thing. The specific page that I am using to test this on (and which generated the above debug output) is here.
I appreciate in advance any assistance you can give, and will provide whatever information I am able to if there's something that would help diagnose this issue.
In order to make sure images are generated on the fly, you need to setup a 404 handler.
"File::transform transformation deferred."
This means that it will be picked up later by the job queue, it is normal when the 404 handler is not in place. Then if you refresh the page, usually the scaling has been done and the image should show.
Shows that something deeper is going on. I suspect you have a configuration issue with paths, or with the permissions of the thumb directory. Because of that you are only able to see thumbnails that had already been generated at an earlier time, but no new ones.
What other processes would be involved in the generation of a thumbnail by the 404 handler if that is the case, and the one that is created during the process of uploading a new file? I would have assumed (and could very easily be wrong) that in both cases the resizing would be handled by the GD library within PHP. Permissions are sufficient for the php-fpm process to write to the thumbs dir at the time of upload, so I can't think what would have changed. Linux also isn't my forte, but I would expect to see a permission error shown in the system log of CentOs if not in the PHP log itself, and have found nothing in either.
I will look further into the 404 handler though, thank you for that lead. Any extra explanation you can provide in regards to my above comments would be appreciated.
Error creating thumbnail Error code: -1
Some images say Error creating thumbnail Error code: -1. Not display that error in all images, but some display that error or is too late to create thumbnail.
Version is like this:
MediaWiki : 1.24.2
PHP : 5.4.39 (apache)
MySQL : 5.0.45-log
ImageMagick : 6.9.1-1
If that happens with some images, it may be that they're large or complex enough which makes the thumbnail to fail. It may be that it requires more memory than the available memory of the server, or the allowed memory to use by PHP. See Manual:$wgMaxShellMemory and Manual:$wgMaxShellFileSize, and try using higher values.
The page Special:WhatLinksHere contains a list of links that link that page, each link has a link its article and a link to see the pages what links with page. E.g. in Special:WhatLinksHere/Project:Support_desk appears MediaWiki (← links))
But when I want to correct the links of a page (because is a disambiguation page) I have to open the articles and after press in Edit to put it in edit mode.
This is a support desk. Proposals should go to phabricator. See How to report a bug. I usually need edit links from everywhere, so I ended up creating a gadget that displays all sort of links (edit, history, whatlinkshere, logs, etc) whenever I hover an internal link
My wiki page (latest version) is suddenly white and the error log produces two errors:
[19-Apr-2015 22:58:58 America/Chicago] PHP Parse error: syntax error, unexpected '|' in /wiki/includes/debug/MWDebug.php on line 341 [19-Apr-2015 22:58:58 America/Chicago] PHP Fatal error: Class 'MWDebug' not found in /wiki/includes/GlobalFunctions.php on line 981
Prior to that the wiki has been running without a hitch the last error was over a month ago for the autodiscovery mechanism issue with skins (I resolved that)
I'm a total novice with PHP, so any insight would be greatly appreciated. The wiki is used for commercial purposes so it has put us at a stand-still.
What is the "latest version"? You should look at Special:Version for the version number.
Is this problem reproduceable?
I'm quite certain it is version 1.24.2, it was installed fresh a little over 2 months ago. I'm not sure what you mean by "Special:Version" The site is inaccessible. (Is there a file I can ftp to to find version?
I'm not sure what you mean by reproduceable either... If I try to access it, the error_log.php will show those errors above.
Thank you so much.
On April 8th you used version 1.24.1 (at least according to the Google cache).
The website currently only shows a blank page, meaning: Yes, the error most likely happens on each and every page hit.
Any idea how to resolve this? Maybe try updating? (not even sure that's possible if the site is inaccessible)
we are using: MediaWiki 1.10.1 PHP 5.2.17 MySQL 5.5.11
It is a non public Wiki, so access from outside is not possible.
When clickin on a image in a article I'll forward to the image site (standard). On this page I have a list of file links to see where the image is used. We have figured out the list is limited to 1000 entries. Unfortunately this is not enough for us. We need all links for statistics. How to configure this?
Best regards Giz
If you refer to "File usage": No setting that I'm aware of. The related code is nowadays in includes/page/ImagePage.php and under /includes/filerepo/file/* if you feel like hacking PHP.
General note: You are using an ancient and unsupported MediaWiki version that is full of security problems nowadays. Please run maintained software.
Then use the continue param in the result to generate the next api request, to collect all the urls referencing Example.jpg
I'm running mediawiki version 1.21.1 and I have to upgrade because my web host no longer support PHP 5.3 so the website doesn't work. When I go to /wiki/mw-config/. the first page lets me select the language but the second page has a light bulb in an orange box with a text box underneath and the progress list on the right but nothing else. I have tried highlighting text to see if it is invisible for some reason but it just isn't there, here's a screenshot. How can I fix this so that I can continue the upgrade? Because of PHP being updated the website does no display text on pages, I assume this is the same problem.
The website is ccfzatlas.com.
I have managed to get as far as the Upgrade existing installation screen, the orange box has a tick in it and it seems as though it was successful however there is no option to continue to the next page.
Note that in order to upgrade your wiki you need to download a new version first and put it on the server! Read Manual:Upgrade for instructions. Accessing /wiki/mw-config/ won't upgrade it to a new version. It's just to create the database, or make changes in the database in order to use a newer version of MediaWiki.
Hello, when I attempt to upload a file to my wiki, it gives the error 'Could not create directory "mwstore://local-backend/local-public/c/c4".'
I am running MediaWiki 1.24.2 with PHP 5.4.38 (cgi-fcgi) and SQLite 184.108.40.206 on a shared server. The images/ directory has 0755 permissions, but file uploads do not work with 0777 permissions either. The images/ directory is owned by the same user that owns and (to my knowledge) executes the scripts. The php.ini directive file_uploads is set to "On".
The wiki itself is located at wiki.liamscode.net.
Before, I had used (an outdated version of) MediaWiki installed using an automatic installation script and file uploads were working fine, and the permissions of the (sub)directories seem to be the same.
Edit: If I use the UploadWizard extension, it gives the error 'Internal error: Server failed to store temporary file.'. I am not sure if this information would help or not.
Edit 2: If I put a php file in wiki root directory that just creates a file in
images/ it runs fine (and the file is made). So it must be a problem with the MediaWiki files themselves, right?
Resolution: It turned out to be something to do with SQLite, when I tried using MySQL, it worked.
I'm in process of commissioning a new server with the latest stable releases of both MW,SMW and loads of extensions. Once running sweetly it will replace the current production server. It accessible here and is currently populated with a fairly recent backup of the production site to facilitate thorough debugging. The SSL cert will be reported as invalid because it is the production site cert and being used for Apache config/debug purposes only.
I have resolved multiple issues easily enough but not this one - yet: The search-box prompt and any type-in text appears below the actual box. Any pointers to fixing it would be much appreciated.
You have some sort of 'improved search' gadget or extension installed, that is not compatible with the latest search box styling changes and is breaking both the 'plain' and the 'improved search'.
A few pages on our media wiki have started providing the below error message, but we are not certain why or what is causing it, looks like a database error to me.
<parsererror style="display: block; white-space: pre; border: 2px solid #c77; padding: 0 1em 0 1em; margin: 1em; background-color: #fdd; color: black"> This page contains the following errors: error on line 1 at column 35: attributes construct error Below is a rendering of the page up to the first error. </parsererror>
It only appears on a few pages, and similar pages still works.
Zvik, Kim Apr 22, 8:44 AM: Hi Gliffy, We have a bunch of Gliffy diagrams in Media Wiki One has did=4395652 This image does display fine in MediaWiki When I attempt to edit it in MediaWiki so that I can export it and then import into Confluence 5, I get this error: Gliffy Online - Error! An error has occurred! You have used an out-of-date link to reach this page. If you accessing Gliffy through WordPress or the Gliffy API, the link that you used has expired. Please go back and refresh the page you came from, then follow the updated link. If you have further trouble, or you feel you have received this message in error, please contact email@example.com Thanks, Kim
Description: I've wrote a parser hook that checks if the guest has a valid SAML session - if so it logs the user in into the MediaWiki's user object. If I disable the check and let the guest login manually it works fine (so the signin function ect. is working as it should).
Problem: The cookies arent set, because the hook "CheckADFSPlugin" is ran BEFORE the 'signin' function is called. The hook is currently bound to: BeforePageDisplay since it needs to check the SAML session and user SESSION every page hit.
Momentarily, I use Mediawiki 1.24.1 with the Include extension (https://www.mediawiki.org/wiki/Extension:Include) to include some custon php pages I have made which queries a database with some extra info (servers, patches, etc...). But, with the update to MediaWiki 1.24.2, this extension does not work anymore.
I know this is a security risk, but I only use this wiki in a restricted environment (which can not access the Internet), and, my pages are located in a subfolder in my wiki (extrawikidocs). Also, I have some pages which can update the database (patch date,...).
Is there another (more secure) extension for adding extra php content?
Thank you in advance!
Hi, I'd like to know how i can become administrator if there are no administrators, stewards, bureaucrats?
- if there are no administrators, stewards, bureaucrats in the wiki?
How did this situation happen? Some mistake in the setup of the wiki, or is it an abandoned wiki that theoretically has admins, but practically they didn't visit the sites for ages? Do you have access to the server/database? If so, one way to make yourself an admin would be to edit the file LocalSettings.php. You could (warning: just for the five minutes or so this action would take) grant everyone the right to promote somebody as an admin by altering the LocalSettings.php, then go to the wiki, make yourself an admin, and go back to the LocalSettings.php and undo your changes.
It depends on the wiki. I'm not exactly familiar with how it's handled on Wikimedia since I've never witnessed a situation like that. On Wikia, they have "adoption requests" which allow for users to adopt a wiki and become administrator if the existing bureaucrats are gone. On independent wikis, generally there isn't much of a way to become an administrator. If the bureaucrats are all gone from the wiki, there's no real way for you to be given adminship unless you can somehow get a hold of a bureaucrat on the wiki. You can try contacting them on their talk page or using Special:EmailUser, as they may be notified about it and return to the wiki.
[RESOLVED] Could not create directory mwstore://local-backend/local-public/ when Uploading.
OS Version: CentOs 7 Database: MariaDB Php Version: 5.4.16
Path to installation Sym: /var/www/mediawiki Actual: /var/www/mediawiki-1.23.6
Error Displayed on the page when trying to upload: Could not create directory "mwstore://local-backend/local-public/9/9b". Error from error_log: [:error] [pid 19457] [client 10.107.1.89:58112] PHP Warning: failed to mkdir "/var/www/mediawiki-1.23.6/images/2/22" mode 0777 [Called from wfMkdirParents in /var/www/mediawiki-1.23.6/includes/GlobalFunctions.php at line 2625] in /var/www/mediawiki-1.23.6/includes/debug/Debug.php on line 303
This is an internal wiki so I can't post a link.
Issue: Can't upload file
I've been trying to fix this for a couple days now. I've googled the issue and everyone seems to say it's a permissions issue.
at this point I'm not sure it is (I know what I've done below is very very bad practice, but... it's come to the sledge hammer approach. I will fix this AFTER I can figure out what's breaking)
I've chown'ed the entire /var/www/mediawiki to apache:apache I've chmod -R 777 the entire /var/www/mediawiki folder (At this point there should be NO permission problems whatsoever)
and just to be sure I did the same using the actual path instead of the sym... not that that matters
I've confirmed that apache is running under user apache group apache
There's nothing left for me to open up in permissions... so how can it be a permission issue?
any help would be greatly appreciated.
The important line here is this one:
failed to mkdir "/var/www/mediawiki-1.23.6/images/2/22" mode 0777
If permissions are not the issue, maybe you have SELinux or APPArmor enabled, which is preventing the creation of files/folders?
I... am an idiot, and you are a wonderful person.
Hi, I've been trying to fix this issue also for few days. Here is the situation:
The mediawiki was working on another server, I move the database and the mediawiki folder to the new server which is running Centos 7. First I did
chown -R apache.apache mediawiki
The mediawiki folder and all files are using the following context
when uploading file I got:
Could not create directory "mwstore://local-backend/local-public/f/f3".
I read and tried a lot of different solution on the web but none are working.
LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks. This page, as the most active on mediawiki.org will be the last to be converted.
Please see details, and an emphatic request for feedback, at Topic:Sdoatsbslsafx6lw. Much thanks.
Currently, we are using MediaWiki 1.12 and wanted to upgrade it to the latest stable version i.e. MediaWiki 1.24. The associated PHP version is 5.1.6-39 and MYSQL version is 5.0.77-4. Please provide me the steps which needs to follow. The development environment is WINDOWs and our PROD is linux based. Kindly help me on this regards.
First, you should upgrade your webserver system. PHP 5.1.6 is really old and the support for it was stopped in MediaWiki 1.16 (which is stopped, too, and may contain security holes like your actual version), see Compatibility. The support for this php version was already stopped by php, too, see  (eol 8 years ago now: http://php.net/eol.php). After this, you can follow Manual:Upgrade to upgrade your installation, but read the complete document first before you start your work, there are important notices about how to upgrade from an old version of MediaWiki. And the most important thing: Backups, backups, backups :)
Can we do fresh installation of MediaWiki 1.24 on server and then move the existing contents from MediaWiki 1.12 to 1.24 by dumping the data from existing MYSQL to newer version.
What do you mean with dumping? Maybe i would be possible, but it would take more time and work to do it and i wouldn't do that :)
So if I understand your suggestion correctly, you are saying that 1- upgrade the existing PHP to the compatible version of PHP (used in MediaWiki 1.24). 2 - Then follow the manual upgrade to upgrade the existing MediaWiki version to never version.
question -by manual upgrade, would it upgrade the MYSQL too ? or we need to upgrade it 1st before upgrading the MediaWiki.
It is bit difficult from Mw 1.12 to Mw 1.23, recently we upgraded from Mw1.12 to Mw1.21 , faced lot of issues with skins,tables,and customized extensions,
1.Do you customized any predefined mediawiki tables?. 2.you developed your own skin? 3.list of extension also post here.
then i will assist you in this upgrade.
We did not customize any said features, so I hope it would be a smooth upgrade. Will let you know once I start upgrading it on my dev machine, but before that I wanted to upgrade the existing XAMPP. Very-very thank you for proving me assistance.
MediaWiki 1.23.6 PHP 5.4.16 (apache2handler) MariaDB 5.5.41-MariaDB
Wiki is hosted internally and not accessible from the WWW.
Can a text-based logo be used, and dressed up with CSS inside a div tag, or does MediaWiki require an image-based logo?
The file set in $wgLogo has to be an image, it will be used as a source for an img tag. But you can simply chnage the skin you're using and add a function to handle whatever you want :)
I think there might be an even easier solution: It is true that $wgLogo must point to an image file. But that must not be a JPG or a PNG file. I have not tested that, but it should also work with SVGs, where you can basically write your text into the image.
I thought about SVG, but not really sure that makes sense if it's not going to scale. Size is set by pixels in CSS. I still think text would be sharper, but as I think it through, maybe not.
I quickly made up this example SVG:
<svg height="135" width="135" style="background-color:green;"> <text x="68" y="45" fill="red" text-anchor="middle" style="font-size:20px;">My Company</text> <text x="68" y="75" fill="red" text-anchor="middle">Name</text> </svg>
Looks ugly, but proves the point: The text is perfectly sharp, it's centered and it can be edited easily.
Can you go into a little more detail on modifying the skin? I'm not sure how to create a function, and not sure what files would be appropriate to modify... I am using the stock Vector skin.
First: You should fork Vector and create your own skin on top of it, even, if you "just" want to change the logo :)
Here you find the needed lines. The link with the class "mw-wiki-logo" will get the logo as he background-logo property in css. You now could simply remove the css class and add an your text into the a-tags, or change the class to a custom one and design the logo like you want or you completly remove the link and write down your own stuff.
Last edit: 12:49, 23 March 2015
Is it possible to let the API make use of memcache?
I'd like to add a ~500 ms query on every article so memcache would come in handy.
The api already uses memcached if installed in appropriate places.
Sounds more like you want to use varnish/squid to cache full responses.
Does it? I see $wgMemc only used in ApiMain.php for makeHelpMsg().
Can I request that on phabricator?
Subfader: I'm not sure I understand.
Most of the API is (relatively) cheap sql queries with no clear way to do appropriate expiration. Thus memcached is not usually used, although I believe there is a couple places where the API calls into other parts of MW which use memcached.
If you want to make a somewhat repetitive api query, and don't care if the result is mildly out of date, set the maxage and smaxage parameters when making the api request, to how many seconds you want to cache. The maxage controls how long the user caches the api request, where smaxage (if you have varnish or squid installed) controls how long to cache for everyone [Assuming the request isn't something private, like retrieving a deleted page, or making an edit].
The first person to make that request will take the normal amount of time, however the response will be saved for up to 600 seconds, and anyone else who visits that exact url in the next 600 seconds will get the saved version, much faster, but potentially outdated.