 Archives
|
There are also other places where to askCommunication: IRCCommunication#Chat, mailing listsMailing lists, Q&A etc.
| Language: | English • español |
|---|
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.
Hello, My wiki is not on the internet, rather I am editing it locally. It worked perfectly. I moved my wiki from one computer to another. Now when I open it, it says the following message- "Sorry! This site is experiencing technical difficulties.
Try waiting a few minutes and reloading.
(Cannot access the database)"
I am using XXAMP (on both computers), and both computers are windows. Can someone help me? Thanks, Kianlolcat99.
Edit: This is Mediawiki 1.26
In LocalSettings.php you have the database credentials, which MediaWiki is using to connect to the database. On the new server these credentials obviously are different from the old one.
Make sure that database name, MySQL username, password and host are correct!
Hi, when I try to upload any file, mediawiki show an error like this:
Warning: set_time_limit() has been disabled for security reasons in /home/xxxx/public_html/wiki/includes/GlobalFunctions.php on line 3407 Exception encountered, of type "LocalFileLockError"
I don't change anything.... it appears just for all the files that I try ti upload with all the users.
Thanks.
G.
This message means that in the PHP configuration, executing function set_time_limit() has been disallowed. The right solution for this problem is to allow this function again.
A workaround would be to set $wgTransactionalTimeLimit to a smaller value: If you set $wgTransactionalTimeLimit to something smaller than the max_execution_time of PHP, then the error also will no longer appear. Note however that this will limit the time, which POST requests can be running before they get aborted. It might be that you actually do not want to set this value too low. See $wgTransactionalTimeLimit for more details!
After my upgrade from 1.23.11 to 1.27.1 my recent changes are empty. Anybody with a hint what to do?
I tried rebuilding the recent changes table via maintenance/rebuildall.php but still no changes
Rebuilding recentchanges table:
Rebuilding $wgRCMaxAge=7776000 seconds (90 days) Clearing recentchanges table for time range... Loading from page and revision tables... Inserting from page and revision tables... Updating links and size differences... Loading from user, page, and logging tables... Flagging bot account edits... Flagging auto-patrolled edits... Removing duplicate revision and logging entries... Deleting feed timestamps. Done.
I also receive an error when running rebuildall:
... 1100 1200 Es ist ein Datenbankabfragefehler aufgetreten. Abfrage: INSERT IGNORE INTO `page_props` (pp_page,pp_propname,pp_value,pp_sortkey) VALUES ('1287','notoc',,NULL),('1287','noeditsection',,NULL) Funktion: LinksUpdate::incrTableUpdate Fehler: 1054 Unknown column 'pp_sortkey' in 'field list' (localhost)
Your database of MediaWiki 1.27 should have the column pp_sortkey in the page_props table. Have you forgotten to run update.php after doing the upgrade? This should have added the missing column...
Merry Christmas to you anyways!
Merry Christmas! I ran php maintenance/update.php via console. But you're right, the column was missing... After running update.php again the column ist there.
But I still have the problem with missing recent updates, although rebuildall.php was run.
In your first post you wrote that the recent changes would be empty. The rebuildall.php script should have added entries to the database table recentchanges.
Is that table still empty now? Or are there now rows in it, but new rows are not getting added?
Note also that Recent Changes have a limit of entries to display by date, so if there has been no edit since more than 3 days you need to adjust the filters to display them
Hello! I am admin on the following wiki: https://yourosongcontest.miraheze.org/wiki/Main_Page
https://yourosongcontest.miraheze.org/wiki/Special:Version
and it won't let me log in, i get the following message:
There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.
What do I do? :)
Kimmy
Possibly, this issue: Topic:T75cloz7981b8i92
As miraheze Wikis are maintained by their team, you will probably have to contact them: https://meta.miraheze.org/wiki/Help_center.
I allow anons to upload images to website and it works correctly. The recent changes lists the uploads as expected. But special:log doesn't list anons uploads, only registered ones. I checked if they are logged in the database table - and they are, so I guess the software is simply filtering anon uploads. How can this be changed? I have the old v. 1.15.1.
You first should update the wiki to a supported version. These currently are 1.23, 1.27 and 1.28. 1.23 and 1.27 have long term support with 1.27 being supported two years longer than 1.23.
I think there might be a way to change what Special:Log is displaying using a hook. I have checked the available hooks, but at least on a quick glance I could not find one, which would be run inside that special page so that you could change the SQL query from there...
Regarding the upgrade, I am afraid an upgrade will cause more damage than good. I have a custom CSS design (which will probably break), custom JS (which will probably not work properly) and Extension:AWC's Forum (which is now obsolete, which means I might loose all the data stored in the forum). I am not a programmer and the site is free so I can't afford to spend any money on such an upgrade, unfortunately.
I was actually thinking of a fix to the PHP file which displays the log, but I don't know what that might be and couldn't find anyone with the same problem (obviously, anon uploads isn't popular).
In MediaWiki 1.27 sessions are no longer stored using the default php session storage, but on the object cache. If you've changed $wgMainCacheType, you may need to tune $wgSessionCacheType, in case the caching you've chosen is not persisting data across requests. Setting $wgSessionCacheType = CACHE_DB; would be a sensible value.
Hello,
after an upgrade from 1.26.3 to 1.27 nearly all works fine including special pages and creating or editing pages. But when I try to login (and as an Administrator I must login for some tasks), I get the following message "There seems to be a problem with your login session; this action has been canceled ... ". The same happens, when I want to create an account. There are no extensions for account control/rights management installed.
What can or have I to do.
Many thanks .
Try creating a directory: tmp, in the MediaWiki installation directory and include the following line in your LocalSettings.php, at the end:
session_save_path("tmp");
I didi it. I've set the appropriate permissions to that folder. I reloaded the main page and tried to login. Same error. The "tmp" folder remains empty.
Creating a tmp folder on the mediawiki installation for storing sessions is a high security risk, since that folder is probably accessible from the web and anyone could potentially see the active sessions on the server. If sessions were working before the upgrade, the session save path shouldn't be the problem.
Try to set up a debug log file and repeat the action of logging in, and see if there's something in the log that can give more information about what's going one (in case you want to post the log output here, remove any private information like the login credentials, as the manual describes)
Yeah, sorry about the high risk solution, but I was having the same problems and had the tmp folder temporarily (for about a couple of minutes) set-up which apparently fixed any session lost issues. Another mistake I was making was jumping from HTTP to HTTPS and vice versa (maybe that's your problem too).
Again, apologies for the high risk solution.
I agree with Ciencia. It seems to be a problem with the new session handling in 1.27. In 1.26.x I've never lost my sessions. It seems so, that my sessionID changes every time when I send a request to the server (I don't switch between http and https). But I don't have a reason and not a solution. So I post the error.log here.
Start request POST /wiki/index.php?title=Spezial:Anmelden&returnto=Hauptseite
HTTP HEADERS:
HOST: MyServer.de
USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
ACCEPT-LANGUAGE: de,en-US;q=0.7,en;q=0.3
ACCEPT-ENCODING: gzip, deflate
DNT: 1
REFERER: http://MyServer.de/wiki/index.php?title=Spezial:Anmelden&returnto=Hauptseite
COOKIE: __utma=160677477.911326897.1398857347.1467369865.1467636887.185; __utmz=160677477.1422875023.52.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); my_wikiUserName=MyUserName; __utmc=160677477; MyGitWikiSession=ge9bns6c6h48et2s4rrjs3v45h9psflf; my_wikilanguage=en; uls-previous-language-autonym=English; mw_installer_session=sh49d0t4af333d2jrb39n8ni37; IPBWikiSession=nifd5814p6ns4l022hnlllm4v0; ipb_wikiUserID=1; ipb_wikiUserName=MyUserName; ipb_wikiToken=f3eb3f4043d61703fec60a996fb7d0b0
CONNECTION: keep-alive
PRAGMA: no-cache
CACHE-CONTROL: no-cache
CONTENT-TYPE: application/x-www-form-urlencoded
CONTENT-LENGTH: 185
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[session] Session "ge9bns6c6h48et2s4rrjs3v45h9psflf" requested without UserID cookie
[session] SessionBackend "ge9bns6c6h48et2s4rrjs3v45h9psflf" is unsaved, marking dirty in constructor
MWCryptRand::realGenerate: Generating cryptographic random bytes for MediaWiki\Session\SessionManager->generateSessionId/MWCryptRand::generateHex/MWCryptRand->realGenerateHex/MWCryptRand::generate/MWCryptRand->realGenerate
MWCryptRand::realGenerate: openssl_random_pseudo_bytes generated 20 bytes of strong randomness.
MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer.
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" metadata dirty due to ID reset (formerly "ge9bns6c6h48et2s4rrjs3v45h9psflf")
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" save: dataDirty=1 metaDirty=1 forcePersist=0
[cookie] setcookie: "MyGitWikiSession", "n94eau9g0hoeo1397jtdsf281grae587", "0", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiUserID", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiToken", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "forceHTTPS", "", "1436186784", "/", "", "", "1"
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" save: dataDirty=1 metaDirty=1 forcePersist=0
[cookie] already set setcookie: "MyGitWikiSession", "n94eau9g0hoeo1397jtdsf281grae587", "0", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiUserID", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiToken", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "forceHTTPS", "", "1436186784", "/", "", "", "1"
[cookie] already set setcookie: "MyGitWikiSession", "n94eau9g0hoeo1397jtdsf281grae587", "0", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiUserID", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "my_wikiToken", "", "1436186784", "/", "", "", "1"
[cookie] already deleted setcookie: "forceHTTPS", "", "1436186784", "/", "", "", "1"
IP: 192.124.243.164
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" Taking over PHP session
Fully initialised
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache->getParser
Parser: using preprocessor: Preprocessor_DOM
Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions->__construct
QuickTemplate::__construct was called with no Config instance passed to it
MWCryptRand::realGenerate: Generating cryptographic random bytes for PasswordFactory::generateRandomPasswordString/MWCryptRand::generateHex/MWCryptRand->realGenerateHex/MWCryptRand::generate/MWCryptRand->realGenerate
MWCryptRand::realGenerate: openssl_random_pseudo_bytes generated 7 bytes of strong randomness.
MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer.
MWCryptRand::realGenerate: Generating cryptographic random bytes for MediaWiki\Session\Session->getToken/MWCryptRand::generateHex/MWCryptRand->realGenerateHex/MWCryptRand::generate/MWCryptRand->realGenerate
MWCryptRand::realGenerate: openssl_random_pseudo_bytes generated 16 bytes of strong randomness.
MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer.
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" data dirty due to dirty(): LoginSignupSpecialPage->getFakeTemplate/SpecialUserLogin->getToken/MediaWiki\Session\Session->getToken/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty
[session] SessionBackend "n94eau9g0hoeo1397jtdsf281grae587" save: dataDirty=1 metaDirty=0 forcePersist=0
User::getBlockedStatus: checking...
[connect] Connected to database 0 at localhost
MediaWiki::preOutputCommit: all transactions committed
MediaWiki::preOutputCommit: pre-send deferred updates completed
OutputPage::sendCacheControl: private caching; **
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
Request ended normally
[session] Saving all sessions on shutdown
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[connect] Connected to database 0 at localhost
[connect] Connected to database 0 at localhost
[MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[connect] Connected to database 0 at localhost
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[connect] Connected to database 0 at localhost
[connect] Connected to database 0 at localhost
[caches] cluster: APCBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[MessageCache] MessageCache::load: Loading de... local cache is empty, got from global cache
[connect] Connected to database 0 at localhost
I got the same problem as 192.124.243.164, but I only started to experience this problem in Mediawiki 1.27 after I updated to PHP 7.
It's strange to see like two different cookie prefixes:
Do you have a clue about where does both come from? Do you have 2 wikis on the same domain/subdomain? If in doubt, try clearing cookies or navigate using private browsing to be sure there aren't leftover cookies from older installations.
Anyway, I've mentioned this thread on task T138072 that seemed related, although that one seems to happen on WMF wikis.
Well I don't know about user 192.124.243.164, but for me it seems that PHP 7 is causing the issue because I have uninstalled PHP 7 and installed PHP 5 back and enabled it and now everything seems to be working again. Does anyone know why would PHP 7 cause such problems and how could I fix it so I can use it again?
On task T138072 some devs request if someone can post HTTP headers of the request and response of the first access to the login form and when logging in.
To get HTTP request and response headers, open the developer tools of the browser (hit F12). There should be a network tab, click on it. It's a good idea to start a private browser session before loading the page, so you don't have cookies of previous sessions.
Go to the login page, the network tab should list each request to the server: select the first item, which should be the login URL. At the right there should be some other panels with information about the selected URL, click on the "headers" panel. In Firefox, click the "unmodified headers" (or similar) button to display them in a format you can copy and paste. In chrome, click the "view source" link in request and response headers.
Do the same for when you submit the user & password (user and password are sent in a POST request, so they won't appear in HTTP headers, but check for them anyway just in case)
You can paste them on https://phabricator.wikimedia.org/paste/edit/form/14/ and if you're concerned about possible privacy issues, you can change visibility to "subscribers" and add manually trusted devs like Anomie to the subscribers list.
Another cause may be an extension, you can try disabling all extensions and see if the problem is still happening.
Okay, so I was wrong about it only not working in PHP 7, I still have the problem with PHP 5 as well. I am not able to use my accounts even if I go into private browsing. I even tried out an other pc on an entirely different network and it doesn't work there either.
I have created a paste form on phabricator based on your instructions Ciencia. Is this how am I supposed to do it: https://phabricator.wikimedia.org/P3340 Is there any more I need to do?
The wiki I work at switched to 1.27 and is now experiencing login problems as well, but also we can't even edit anything. Not sure if that's related but it probably is sinice it started happening at the same time.
Thanks for the headers, Tribly! Hopefully this is enough to diagnose the problem.
Hi, I'm 192.124.243.164 (registered now to the Support_desk).
I had not much time today but investigated a little what happens with cookies and session data. The old 1.26 Wiki sets a cookie, when navigating to the login page and two more after login. Because there is not set a session.save_path in the php.ini the session data are saved in the systems temp-dir (/var/lib/php5 on my machine). Works fine. After deleting all cookis and all session data I tried out the new wiki, which runs on the same machine, installed in a separate directory with a separate database and different session name.
The new 1.27 wiki also sets a cookie when navigating to the login page but this cookie changes its value after every new request. I couldn't find session data anywhere on the machine. So I think, that the new wiki (or its session engine) is unable to save the session data and that's the reason. Does anybody know, where the 1.27 engine tries to save the session data or how to configure it? Setting a session.save_path has no effect (and yes, I've restarted apache and the path was readable and writable for apache and php).
Many Thanks
In 1.27 it saves session data to the cache specified with $wgSessionCacheType.
Alright, so I tried to switch back to the 1.26 version of mediawiki(I made a backup folder before updating to 1.27, so I only had to rename that folder to html to switch back, and rename the 1.27 folder to something else.) and when I tried to login I got the following error Wiki uses cookies to log in users. You have cookies disabled. Please enable them and try again.. I tried to login with other accounts as well and tried other browsers as well but every time I got the same error. So I googled the error and got this post: https://www.mediawiki.org/wiki/Topic:Rg3w5u0e70fs8l4e
The solution to the post was:
The session cookie are not working when session.referer_check = On is set in php.ini. Maybe there sould be iniset in php.ini or at least a check for this setting
So I go into my php.ini file and searched for session.referer_check and find that there was no value set for session.referer_check and it was like this: session.referer_check =
So I set session.referer_check to Off: session.referer_check = Off
Then I restarted apache with sudo service apache2 restart and after that I was able to login again with every account. I switched back to 1.27 and it seems to be working there as well.
Also wanted to try out my wiki with this method with PHP7 but it was not working. Seting the session.referer_check to Off in the PHP7's php.ini had no effect. So I set back pnp.ini to it's default state(session.referer_check =) then I looked through my php extensions and I notified that apcu was missing for PHP7. I installed it and now it seems to be working with PHP7 without even the need to modify the php.ini. I also tried to login in private browsing and it worked. My fellow staff members have also tried to login and it's working for them.
For PHP5 I have the following extensions installed:
apcu.ini curl.ini gd.ini imagick.ini intl.ini json.ini mcrypt.ini mysql.ini mysqli.ini opcache.ini pdo.ini pdo_mysql.ini readline.ini xcache.ini
And For PHP7 I have the following extensions installed:
apcu.ini apcu_bc.ini calendar.ini ctype.ini dom.ini exif.ini fileinfo.ini ftp.ini gettext.ini iconv.ini json.ini mbstring.ini mysqli.ini mysqlnd.ini opcache.ini pdo.ini pdo_mysql.ini phar.ini posix.ini readline.ini shmop.ini simplexml.ini sockets.ini sysvmsg.ini sysvsem.ini sysvshm.ini tokenizer.ini wddx.ini xml.ini xmlreader.ini xmlwriter.ini xsl.ini
Hello again,
regarding Anomies tip I've learned, that MW 1.27 stores the sessions always in object cache (so in Memory?) and $wgSessionCacheType has the same possible values as $wgMainCacheType. Hmmm. I have installed APCu. My $wgSessionCacheType was not set but $wgMainCacheType = CACHE_ACCEL (using $wgSessionCacheType instead of or in combination with $wgMainCacheType has no effect). When I set $wgMainCacheType to any other of the possible values, Problems have gone (login works). So far so good. I use now CACHE_ANYTHING until I understand a little bit more about the underlying mechanisms.
I'm a little bit confused about some things.
Whe I use $wgMainCacheType = NONE; isn't it so, that no object caching is used and if so, where are the session data stored? Loggin works.
I've read, that APC (APCu) does not work with PHP5 because PHP5 uses OPcache which is bundled with PHP 5.5 and later (I have PHP 5.5.9 installed). Nevertheless, I have installed APCu and I didn't have any problems with MW 1.26 and prior.
Regarding Triblys experience with session.referer_check I can only say, that this variable in my php.ini has not a value and that seems to be ok because I don't want to make a pattern check to the referrer string.
Hope the tip with $wgMainCacheType helps anybody.
Regards Mosi.
Yes, setting $wgMainCacheType = NONE; seems to be the solution here. I wonder why it hasn't been set up this way in DefaultSettings.php
Sorry for the confusion, I meant $wgSessionCacheType which the documentation doesn't make clear where sessions would be stored depending on the value of $wgMainCacheType. As the manual page is now, it seems like $wgMainCacheType = NONE would make $wgSessionCacheType = NONE as well
Thank you all for your effort. You helped me really. I've upgraded the second Wiki (which is the "real" wiki, the other is for testing e.g. if upgrades make problems). Same problem, same solution. I'm in vacation the next days but I've a lot of suggestions for expanding my knowledge about configuring and maintainig a wiki.
I have found that setting the wiki to "read-only" mode ($wgReadOnly) makes the problem significantly worse. I set "$wgMainCacheType = CACHE_DB;" as suggested, and am crossing my fingers that it gets fixed before it causes any serious problems.
After changing $wgMainCacheType to CACHE_ANYTHING, CACHE_NONE, CACHE_DB and CACHE_ACCEL, there was no change in the symptoms. Still having the same error.
I had the same issue after updating my server to Ubuntu 16.04.1, PHP to 7.x and MediaWiki to 1.27.1 and could no longer log in. I then changed my $wgMainCacheType from CACHE_ACCEL to CACHE_DB, saved my changed LocalSettings.php, reset Apache2 and can now successfully log in again.
I'm using MediaWiki 1.27.1 with PHP 7.0.8 and I have to set $wgMainCacheType to CACHE_NONE; or I will get logged out as soon as I visit another page on my wiki :/ I'd love to use OPcache though, so what can I do? Thanks and cheers!
Just make sure $wgSessionCacheType is set to a cache that is persistent and (if you have more than one server) shared, then you can set $wgMainCacheType to whatever you want.
Thank you, Anomie! It's weird, somehow the following combination kinda works now:
$wgMainCacheType = CACHE_ACCEL; $wgParserCacheType = CACHE_ACCEL; $wgMessageCacheType = CACHE_ACCEL; $wgSessionCacheType = CACHE_DB;
However, I have to log in twice: when I log in, it shows that I'm logged in but when I go to another article or just click edit, I'm suddenly logged out. I have to log in again and this time it is persistent and I can edit articles. As soon as I log out, everything starts all over again.
Do I have to change $wgAuthenticationTokenVersion? Right now it's set to $wgAuthenticationTokenVersion = "1"; And I'm also using CentralAuth:
$wgCentralAuthCookies = true; $wgCentralAuthCookieDomain = '.domain.com';
Thanks and cheers!
Sorry, I don't know what happened but everything works perfectly now. Thanks and cheers!
@Anomie Should've never this https://github.com/wikimedia/mediawiki/blob/d175b391ae2a77e3183b2608bb4422782af092a1/includes/Setup.php#L701 be updated to use the DB?
Had the same problem after an upgrade. Adding
$wgSessionCacheType = CACHE_DB;
in LocalSettings.php as described above helped - thank you very much!
setting
$wgSessionCacheType = CACHE_DB;
worked for 1.28, saved my day, thanks!
Had same problem: Hint with creating tmp-folder and adding session_save_path("tmp"); at the end in localsettings.php helped. thank you!
^In which case you should also be aware of the security risk mentioned in the second comment after the "session_save_path("tmp")" one.
For my case, adding the "tmp" line (for whatever reason) also resolved the issue. Additionally, I soon removed this line which (again for whatever reason) didn't bring back the "loss of session data" issue.
Recently upgraded to 1.27 and moved to a new hosted solution. I can login in but the Password reset page hangs for 60 seconds and then throws the following error:
******************************************************
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@escriptionwiki.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
******************************************************
I do see in the error logs that the page is coming back as missing.
[Thu Dec 22 15:31:37 2016] [error] [client 199.4.160.10] File does not exist: /home/escripti/public_html/500.shtml, referer: http://www.escriptionwiki.com/wiki/index.php?title=Special:PasswordReset [Thu Dec 22 15:28:29 2016] [error] [client 199.4.160.10] PHP Warning: file_put_contents(/home/YOUR_USER/public_html/cache/resources/js/b/b3/b5191e7679eef1d0052e2d838fe9a59a32d27198.cache): failed to open stream: No such file or directory in /home/escripti/public_html/wiki/includes/cache/FileCacheBase.php on line 171, referer: http://www.escriptionwiki.com/wiki/index.php?title=Special:UserLogin&returnto=Special%3AVersion
Any help on fixing this would appreciated.
A friend noticed that Apache was running as a 32-bit process. The ImageMagick I had installed was 64-bit, so couldn't access it.
We installed MediaWiki here at work (and it's awesome). Images and image uploading work fine, but we can't get image thumbnailing to work. I've installed ImageMagick 7 on the host machine (Windows) and I think I've made all of the correct changes to LocalSettings.php, but whenever we try thumbnailing, Apache crashes. No messages are logged in the error log until it restarts. I know ImageMagick 7 uses magick instead of convert, so I have that change.
Here are the pertinent entries from the PHP file:
I don't actually have a "Tmp" directory defined, but I couldn't find a setting that sets that.
Any idea of what I can check?
When I last installed IM under Windows, it also had a convert.exe coming with it. I don't know for certain, but it might be that both, magick.exe and convert.exe just are identical.
Note that your value for $wgTmpDirectory is invalid! It has to be a valid path!
What the line $wgSVGConverterPath = ; does is not clear to me. Defining a variable with an equal sign, but then putting nothing at all behind it looks close to a syntax error. I would just leave this line away.
Sorry about the $wgSVGConverterPath confusion. I guess it got wikified out. What it's supposed to look like is:
Thanks for the suggestion. I'll try changing $wgTmpDirectory to a path.
Okay, I changed $wgTmpDirectory to a valid path, but it still doesn't work. Thanks for pointing it out, though!
magick.exe is the wrong executable. There should be a convert.exe file.
"Convert" was deprecated for ImageMagick 7. The new name of the conversion executable is Magick.exe. There is no convert.exe.
Actually, in the latest version, there are no less than nine (9) executables, which all have the same size: magick.exe is one of them, but there also are identify, composite, compare and convert.exe.
The difference between magick.exe and convert.exe is 2 bytes out of around 16MB.
I installed ImageMagick-7.0.3-Q16 and I see six executables and one of them is the uninstaller:
I was confused that I didn't see convert anywhere, but somewhere I saw that it was changed to magick and convert was gone. It was actually about another user trying to get ImageMagick to work with MediaWiki. I see that the latest version of ImageMagick is now 7.0.4.0. I'll uninstall 7.0.3 and install the new version and see what I get.
Okay, installed 7.0.4.0 and saw in the install Wizard that you can choose to "Install legacy utilities (e.g. convert)". Selecting that gives me 14 executables, one of which is, indeed, convert. Apache still crashes when I try to display a thumbnail, however. And nothing is recorded in the error log except for the fact that it crashed and is restarting. I'm sure that just one of my settings is wrong, though. Here are my pertinent settings now:
# Image Converter $wgSVGConverter = 'ImageMagick'; # Image converter path $wgSVGConverterPath = ''; ## To enable image uploads, make sure the 'images' directory ## is writable, then set this to true: $wgEnableUploads = true; $wgUseImageMagick = true; $wgUseImageResize = true; $wgTmpDirectory = 'D:/xampp/imagetemp'; $wgImageMagickConvertCommand = 'C:/Program Files/ImageMagick-7.0.4-Q16/convert.exe'; # Path to jpegtran utility $wgJpegTran = 'D:/xampp/common/bin/'; # Path to tidy utility binary $wgTidyBin = 'D:/xampp/common/bin/';
D:/xampp/common/bin/ doesn't exist, but I don't know if that is related or not. I don't know what the jpegtran utility or tidy utility are. D:/xampp/imagetemp does exist, and I set it was Read-only. I changed it so it was writable, but it keeps getting set back to Read-only.
If jpegTran and Tidy are not installed in your system, you can just remove the two lines from your configuration. ImageMagick can also work without them.
It is important that the temp directory actually is working. Does it work, if you remove the line on $wgTmpDirectory so that you just leave $wgTmpDirectory unchanged? MediaWiki should find the right path automatically - at least in theory.
$wgImageMagickConvertCommand should be ok as you have it.
If the above changs alone are not yet solving the problem, then I would set up debugging like so:
$wgDebugLogFile = "D:/xampp/mediawiki-debug.log";
Thanks for your reply! I'll give those suggestions a shot when I get some time.
SOLVED. A friend noticed that Apache was running as a 32-bit process. The ImageMagick I had installed was 64-bit, so couldn't access it. I installed the 32-bit version of ImageMagick and PRESTO! Thanks for all your help! Turning on the logging was the first step in finding the solution. :)
I'd like to change the logo in the sidebar on my wiki - http://fnlst.com/pVQR/4L1lU4Db How do I do that? Does that fall into the skin category or do I need to change a template? Google has not aided me in this, I appreciate any assistance! Thanks!
In setting up mediawiki to authenticate with openldap i seem to be having an issue and was hoping someone could identify it via the config and logs below
mediawiki version is 1.26.3
ldap extension is version for 1.26.3
php-ldap is php-ldap-5.4.16-42.el7.x86_64
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering validDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 User is using a valid domain (ldap).
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Setting domain as: ldap
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getCanonicalName
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Username is: Freasb
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Munged username: Freasb
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getCanonicalName
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Username is: Freasb
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Munged username: Freasb
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering authenticate for username Freasb
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering Connect
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Using SSL
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Using non-standard port: 636
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Using servers: ldaps://ip.of.ldap.server:636
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 PHP's LDAP connect method returned true (note, this does not imply it connected to the server).
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getSearchString
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getUserDN
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Doing an anonymous bind
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Failed to bind as 2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Failed to bind
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 userdn is:
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 User DN is blank
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering strict.
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Returning true in strict().
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering allowPasswordChange
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering getDomain
2016-12-22 15:02:33 ip.of.ldap.server wikidatabase: 2.1.0 Entering modifyUITemplate
#LDAP
require_once 'extensions/LdapAuthentication/LdapAuthentication.php';
#require_once 'extensions/LdapAuthentication/LdapAuthenticationPlugin.php';
require_once 'includes/AuthPlugin.php';
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array('ldap');
$wgLDAPServerNames = array('ldap' => 'ip.of.lap.server');
$wgLDAPUseLocal = false;
$wgLDAPDebug = 3;
$wgDebugLogGroups['ldap'] = '/tmp/debug.log';
$wgLDAPEncryptionType = array('ldap' => 'ssl');
$wgLDAPSearchAttributes = array('ldap' => 'uid');
$wgLDAPBaseDNs = array('ldap' => 'dc=ldap');
$wgLDAPPreferences = array('ldap' => array('email' => 'mail', 'realname' => 'uid'));
$wgLDAPLowerCaseUsername = array('ldap' => true);
$wgLDAPGroupUseFullDN = array('ldap'=>false);
#$wgLDAPGroupObjectclass = array('ldap' => 'posixgroup');
#$wgLDAPGroupAttribute = array('ldap' => 'memberUid');
#$wgLDAPGroupNameAttribute = array('ldap' => 'cn');
$wgLDAPPort = array('ldap' => '636');
$wgDebugToolbar=true;
thanks
