Project:Support desk

Jump to: navigation, search

About this board

vde   Welcome to's Support desk, where you can ask MediaWiki questions!

There are also other places where to askCommunication: IRCCommunication#Chat, mailing listsMailing lists, Q&A etc.

Before you post

Post a new question

  1. To help us answer your questions, please always indicate which versions you are using (reported by your wiki's Special:Version page):
    • MediaWiki
    • PHP
    • Database
  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 topic".
By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

Dedirect page need to login even in whitelist

Chan15tw (talkcontribs)

I set $wgGroupPermissions['*']['read'] to false and add page title to $wgWhitelistRead variable, there is a page on the whitelist page, everyone can see it, but I change the content to #REDIRECT to another page, then this page asked for login, so the redirect thing will not work, how to fix it

Seb35 (talkcontribs)

Add the target page in the whitelist? Does not it work?

Reply to "Dedirect page need to login even in whitelist"

Templates broken despite being direct import with no changes

2601:441:8000:6AA:B52C:864E:3E49:BE71 (talkcontribs)

So I'm starting an SS13 server, and for that I need a wiki. That is one of the broken templates. That is the template I exported and imported from.

It seems like the issue is that it isn't drawing on Template:! on my wiki, but I have no idea what the issue really is.

Mainframe98 (talkcontribs)

You're missing Extension:ParserFunctions, which is required for that template.

Azot944 (talkcontribs)

I transfer my wiki to Cloudflare service (with https).

Sometimes my wiki is showing mobile view where desktop view is expected.


Ciencia Al Poder (talkcontribs)

Looks good to me. Maybe cloudflare is caching the response, so if a mobile user first open a page, it caches the mobile view, and then a desktop user gets the cached mobile view instead.

Reply to "Mobile view instead of desktop view." (talkcontribs)

Give me an explanation of Wikki..What is it???

MarkAHershberger (talkcontribs)

A wiki (i/ˈwɪki/ WIK-ee) is a website that provides collaborative modification of its content and structure directly from the web browser. In a typical wiki, text is written using a simplified markup language (known as "wiki markup") and often edited with the help of a rich-text editor. A wiki is run using wiki software, otherwise known as a wiki engine. There are dozens of different wiki engines in use, both standalone and part of other software, such as bug tracking systems. Some wiki engines are open source, whereas others are proprietary. Some permit control over different functions (levels of access); for example, editing rights may permit changing, adding or removing material. Others may permit access without enforcing access control. Other rules may also be imposed to organize content. A wiki engine is a type of content management system, but it differs from most other such systems, including blog software, in that the content is created without any defined owner or leader, and wikis have little implicit structure, allowing structure to emerge according to the needs of the users.

Hansie (talkcontribs)

Dear Member,

Some time ago I got user registration problems most probably because of port problems of the hosting company :Topic:Szjv1s9juor2waas

Does a "MediaWiki-friendly" hosting company exists with which I don't have such problems?

Best Regards.


Malyacko (talkcontribs)

Hosting services

শাহাদাত সায়েম (talkcontribs)

In my site Extension:AbuseFilter is make an admin user . name : User:⧼abusefilter-blocker⧽ . Please tell me how Can I change it ? or tell me , is it right ?

Star Warden (talkcontribs)

As far as my knowledge goes, that extension creates an account on its own, gives it admin rights so it can automatically block users if certain filters are set to do that. So yes, that behaviour is normal. You can simply unadmin that account and the extension won't be able to block users if that's what you want.

To take the admin rights back, just go to Special:UserRights and enter the name of the account there and then uncheck the administrator checkbox and click save.

Summary by Seb35

Off-topic as for MediaWiki. (talkcontribs)

WikiMedia USA have UNLAWFULLY DEBITED MY VISA CARD!! Thanks a lot for all the hassle you are causing me. The Bank are investigating. I have also passed this incident on to our Australian Police Dept for further investigation.

Ciencia Al Poder (talkcontribs)

You should ask WikiMedia Foundation about this, not MediaWiki (talkcontribs)

I am not even sure that something called "WikiMedia USA" actually exists. At least I have never heard of that name. Maybe this even does not have anything to do with the Wikimedia Foundation? Should this be the case, I think that WMF also would be interested in this issue.

Summary by Seb35

(No reply after the question.) (talkcontribs)

Bom dia

Tenho MediaWiki rodando num Ubuntu, e instalei uma versão atualizada em outro servidor.

Fiz o backup do que está rodando e importei pro servidor novo.

Mas não exibe o conteúdo nas páginas, apesar de se eu for na opção editar está tudo redigido lá.

Seb35 (talkcontribs)

(Using Google Translate)

  1. Is it a public wiki?
  2. What PHP version? (I occasionnally saw this with old PHP versions)
Seb35 (talkcontribs)

(Usando Google Tradutor)

  1. É um wiki público?
  2. Que versão do PHP? (Eu occasionnally vi isso com versões antigas do PHP)

Error creating thumbnail: Unable to save thumbnail to destination

Star Warden (talkcontribs)

Hey. I keep getting this error button and I don't know how to fix it. It can be seen here:, here: and here:

I've tried setting a temp folder ($wgTmpDirectory = "$IP/images/temp";) and a debug file ($wgDebugLogFile = "/var/log/mediawiki/debug-{$wgDBname}.log";) as suggested and even made the temp folder writable by the server using chown, but that did not work.

The manual on how to debug specifies that this log can contain sensibile information, thus I won't post all of its contents and would like to know what could I share here from it that would help in solving this issue?

I mention the console is displaying some weird errors, but I cannot interpret them, sadly.

MarkAHershberger (talkcontribs)

Looking at your Special:NewFiles, it looks like you are able to upload images without problem, but those particular images cause a problem.

I can use thumb.php to create thumbnails of various sizes (see also).

thumb.php appears to work on images that show the problem.

Meanwhile, fails to produce thumb.php some thumbnails for the problematic images.

Maybe you can see what is produced in the debug log when one of the failing thumb.php links is called?

Star Warden (talkcontribs)

I found no recent instance of the cupcake thumb (at least the date isn't displayed when such calls are made, so it might be recent), thus I also included something more recent. The cupcake thumb is at the very top, the others are separated by a large space: Hope it helps!

MarkAHershberger (talkcontribs)

I'm at a loss. I don't really know how to help you without access to your machine. Sorry. Perhaps you can check the permissions on all the directories in your images folder to see if one or two has funky permissions.

Ciencia Al Poder (talkcontribs)

What if you set $wgShowExceptionDetails to true temporarily and open the problematic thumb.php URL?

Star Warden (talkcontribs)

That string was already set to true even before the problem occurred. But here's the strange thing. If you go and check my first two links (ruins and habitats), you'll see that the problem was solved on its own...

Here's a screenshot of the permissions that all folders seem to have: I selected all of them, and made sure they are all set to that. Do I need to change anything?

I forgot to mention that when renaming the file, the issue seems to disappear (of course, there's a reason I named them the way I did, in the first place, thus this isn't a good solution or the solution for that matter). And, in some cases, the issue is triggered only if I get over a certain pixel size while adding it to the article. Would manually moving the images (on the server) from one folder to another solve it? Is it even safe to do that?

MarkAHershberger (talkcontribs)

The permissions look fine if that user is the user that runs as the web server. You could also change the permissions on images to the numeric code 777 and recurse through the images directory.

You could move the images directory, but you would need to change a few configuration options like Manual:$wgUploadPath or Manual:$wgUploadPath. You might also need to use Manual:Img auth.php to stream images.

Star Warden (talkcontribs)

I am not sure if that user is the one that runs as the web server.. I was using the root account. How do I find out who it is?

Also, the second option you gave me is the same as the first one. I was asking if I could only move the images that cause trouble, not the whole directory. Seems kinda pointless to move the whole thing just for a few troublemakers.

MarkAHershberger (talkcontribs)
  • I don't recognize the tool you are using for ftp. But what does the full listing of the mediawiki directory show? Maybe that would have user names on it.
  • If you can physically remove the primary uploaded problematic file, then I think you could re-upload it. That might solve the problem.
Star Warden (talkcontribs)
  • I use FileZilla Client. I am not sure what you're referring to. Is this it: ?
  • By physically removing it, you mean to manually delete it from the server itself or from the wiki? Because if it's the latter, it doesn't work.
MarkAHershberger (talkcontribs)
  • That has the information I wanted. It looks like you're on a Debian server and the permissions are set correctly.
  • I meant from the server itself.
  • Could you use FileZilla to get the listing of the images/thumb/9/90 and images/thumb/9/90/The_Winds_of_November_Event_%2816.11.14%29.jpg directory?
Star Warden (talkcontribs)

I managed to get there and the folder has the image in 3 different sizes: 200px, 300px and 400px. Interestingly enough, this folder seems to have another owner than the typical one: I checked other problematic files, thinking the owner might be at fault, but they had the typical owner, so I guess the different owner theory can (for now, at least) be ruled out.

Should I delete the image from both its permanent place and the thumb folder?

MarkAHershberger (talkcontribs)

The root owner is definitely going to cause a problem. Delete that directory and its contents.

Star Warden (talkcontribs)

That solved the thumbnail problem, but only for that image.

Star Warden (talkcontribs)

Ehm, I was thinking of something. Sometimes, some special pages (usually uncategorised files) won't update, no matter what, regardless if I run updateSpecialPages.php (which runs daily on a cron job) no matter what. So I force it with refreshLinks.php which, in turn, creates a ton of jobs which are run by runJobs.php later on. From time to time, some jobs just get stuck, not allowing themselves to be run. I posted about it 2 months ago ( but got no response. So I looked into the database and found the stuck jobs in the job table. So I just manually deleted them (and have been doing that ever since). Could this be the problem behind it or is it unrelated? I remember this particular issue happened on the 1.26.2 installation, then a failed server upgrade brought the wiki down for a little while, we moved servers and that issue was fixed (this was last summer).

MarkAHershberger (talkcontribs)

It could be related.

You need to make sure that runJobs.php and refreshLinks.php are running as the www-data user and not the root user.

Star Warden (talkcontribs)

I am sorry, I am not good at this. How do I do that? I haven't used any other user besides my personal one and the root one.

MarkAHershberger (talkcontribs)

How do you normally get the jobs to run? How are they being run right now?

Star Warden (talkcontribs)

With cron. When I set it up, I opened putty, logged in on root, entered the command: crontab -e then I added this string: */120 * * * * cd (path to wiki) && php maintenance/runJobs.php and saved. But after using refreshLinks, I run it manually. It usually doubles the number of jobs, initially, then starts to decrease them.

MarkAHershberger (talkcontribs)

If the only cron jobs you have are those that are running for the wiki, then run this sequence of commands as root:

# crontab -l > cron.txt         # to save the current crontab
# crontab -r                    # to delete the current crontab for root
# crontab -u www-data cron.txt  # to give the crontab entries to the www-data user.

If you have other crontab entries, skip the second step (which removes all the entries for root) and edit cron.txt so that only wiki maintenance scripts are left in the file before running the third command.

In any case, the first command will back up all your root cron commands if there is a mistake made.

Star Warden (talkcontribs)

Before proceeding, I used grep CRON /var/log/syslog to see the other jobs. There are 3 other that are not in my current crontab (when using crontab -e), but they all are run by root. Two seem to be more server-related:

Is it safe to still do all the steps?

Also, I did the first step, but I got no confirmation of whether the procedure was successful or not? How do I check?

Star Warden (talkcontribs)

Ah, also, deleting images from the server then re-uploading them doesn't get rid of the error (because it uploads them to the same place in which they were before), BUT, I think it might just be related to root being the owner. So far, all images that I checked in images/thumb that had the issue, had root as the owner. It seems this issue occurs only with thumbnails.

MarkAHershberger (talkcontribs)

You can see if the first step worked by looking for cron.txt in the directory where you ran the file.

In fact, since you have other cron jobs running as root, skip the second step and just edit the cron.txt file to have the wiki-related jobs.

After that, erase those jobs from the root crontab using crontab -e and then run the third command to move the cronjobs to the www-data user.

Star Warden (talkcontribs)

I am not exactly sure what I am doing wrong. Technically, I run the command in the base directory (that is, I didn't change the folder after opening putty), but there is no such file there. Then I looked in /var/spool/cron/crontabs, which has the crontab that I can access through the crontab -e and crontab -l commands, but that's the only file in there (googling also lead me to the same location). There's also another crontab in /etc which lists all the cronjobs. But no sign of cron.txt in any of those three spots....

MarkAHershberger (talkcontribs)

If you run "crontab -u root -l > cron.txt" as root, it should create the cron.txt file for you.

Star Warden (talkcontribs)

I did that, still wasn't in any of those three locations, but I used find / -name and found it in /root. Inside it, there are the two jobs: runJobs.php and updateSpecialPages.php and the default "# Edit this file to introduce tasks to be run by cron". Is this the right file?

MarkAHershberger (talkcontribs)

That is it. It makes sense that it is in /root since that is the root user's home directory. Probably typing ls after running the command would have shown it.

Star Warden (talkcontribs)

Awesome. So let me get this straight before doing anything. I need to edit that file to have the wiki-related jobs going. It already has two jobs (updateSpecialPages and runJobs). This means I need to add the other three remaining jobs from /etc/crontab?

These are:
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

MarkAHershberger (talkcontribs)

Just the first one. And "root" should not be there. You should probably paste your cron.txt before running the command to load it.

Star Warden (talkcontribs)

Is this correct: What do I do with the last 3 cronjobs and with the other two crontabs (from /var/spool and /etc)?

EDIT: There was another job that I missed which was added as custom, apparently:

*/15 * * * *	root	cd /(path to wiki)/ && /usr/bin/php maintenance/rebuildFileCache.php >> /var/log/(log folder)/rebuildFileCache.log 2>&1
5 2 * * *     root    cd /(path to wiki)/ && /usr/bin/php maintenance/runJobs.php >> /var/log/(log folder)/runJobs.log 2>&1

It seems there is a second runJobs which is a tad bit different than the first runJobs. Doesn't really seem to be doing its job properly, though. Should I just remove it?

MarkAHershberger (talkcontribs)

First, do not run crontab -r. Use crontab -e to edit the root crontab files and remove only the wiki crontab entries. The rest should remain.

You should have a file, cron.txt, with the following based on the information you've given here:

*/15 * * * * www-data  cd (path to wiki) && php maintenance/rebuildFileCache.php   >> (log folder)/rebuildFileCache.log 2>&1
*/15 * * * * www-data  cd (path to wiki) && php maintenance/runJobs.php            >> (log folder)/runJobs.log 2>&1
0    0 * * * www-data  cd (path to wiki) && php maintenance/updateSpecialPages.php >> (log folder)/updateSpecialPages.log 2>&1

Move the cron.txt file to /etc/cron.d/wiki-cron-jobs.

This will allow Ubuntu's cron system to run them. Anytime you need to change them, you can safely edit that file.

I think this will get you where you need to be. Sorry for the confusion.

MarkAHershberger (talkcontribs)

And to reduce the repetition, you can use shell variables in that file, so you could do the following:

LOGDIR=/var/log/(log folder)
WIKIDIR=(path to wiki)

*/15 * * * * www-data  cd $WIKIDIR && php maintenance/rebuildFileCache.php   >> $LOGDIR/rebuildFileCache.log 2>&1
*/15 * * * * www-data  cd $WIKIDIR && php maintenance/runJobs.php            >> $LOGDIR/runJobs.log 2>&1
0    0 * * * www-data  cd $WIKIDIR && php maintenance/updateSpecialPages.php >> $LOGDIR/updateSpecialPages.log 2>&1
Star Warden (talkcontribs)

I did that and moved the .txt to where you suggested (I had to manually create the wiki-cron-jobs folder). Here's the entire paste:

Now, one question. What do I do with the remaining cronjobs that I wrote here ( They weren't in the crontab file that I could open with crontab -e while logged in on root. They are in the crontab that's found in /etc. This is its contents:

MarkAHershberger (talkcontribs)

I'm sorry, I should have been clearer. I wanted you to move cron.txt to a file called /etc/cron.d/wiki-cron-jobs. If you've created a directory, I'm not sure it will work.

Remove these lines from the file you found under /etc:

*/15 * * * *    root    cd /(wiki path) && /usr/bin/php maintenance/rebuildFileCache.php >> /var/log/wiki_logs/rebuildFileCache.log 2>&1
5 2 * * *     root    cd /(wiki path) && /usr/bin/php maintenance/runJobs.php >> /var/log/wiki_logs/runJobs.log 2>&1

The others should be left as-is.

Star Warden (talkcontribs)

Well, there was no such file there. Cron.txt currently rests in /etc/cron.d/wiki-cron-jobs folder. I used grep CRON /var/log/syslog to see the recent jobs, but not jobs from cron.txt seem to have been executed... what should I do?

MarkAHershberger (talkcontribs)

Run the following commands:

$ mv /etc/cron.d/wiki-cron-jobs/cron.txt /etc/cron.d/wiki-jobs
$ rmdir /etc/cron.d/wiki-cron-jobs

Both should run without problem and you should see cron jobs executing shortly after that.

Star Warden (talkcontribs)

Hey. Thanks! But there seems to be a problem... the jobs aren't run. Using grep CRON /var/log/syslog it does show me the runJobs.php has been executed, but the number does not go down, unless I manually run it. What might be the cause?

Star Warden (talkcontribs)

Actually, it seems none of the maintenance scripts are working, not only php runJobs.php.

MarkAHershberger (talkcontribs)

Could you run the following and tell me the output:

$ grep wiki-jobs /var/log/syslog
Star Warden (talkcontribs)

This is what I get:

MarkAHershberger (talkcontribs)

So, it is loading properly. I was worried that I had given you a bad one or that it had been corrupted some way. For example, I created a file with the wrong owner and got the following:

$ grep test /var/log/syslog
Mar 24 12:17:01 web cron[369]: (*system*test) WRONG FILE OWNER (/etc/cron.d/test)

I have set up a wiki with a file similar to what I asked you to set up now and when I look for www-data in my syslog, I see the following:

$ grep www-data /var/log/syslog
Mar 24 12:30:02 web CRON[25865]: (www-data) CMD ( cd $WIKIDIR && php maintenance/rebuildFileCache.php   >> $LOGDIR/rebuildFileCache.log 2>&1)
Mar 24 12:30:02 web CRON[25867]: (www-data) CMD ( cd $WIKIDIR && php maintenance/runJobs.php            >> $LOGDIR/runJobs.log 2>&1)

Do you see anything similar?

Star Warden (talkcontribs)

It seems I do:

Star Warden (talkcontribs)

If the command seems to be executed correctly, it means that wikidir and logdir are set correctly, right? I am not sure if it's safe to post them here (that's why I always censor them), but I wrote them something like:

LOGDIR=/var/log/foldername/ WIKIDIR=/mainfolder/foldername/

I didn't add /maintenance/ at the end of wikidir since the cronjob automatically switches to the maintenance folder due to php/maintenance. Plus, the command is basically the same to how I had it in the root crontab (minus adding information to the log, as well as having the name of the wiki path written instead of wikidir).

I take it that the above steps are correct?

MarkAHershberger (talkcontribs)

Yep, it looks like all the steps are correct. Check your log files to see what is being put in them.

Star Warden (talkcontribs)

From the outside, when looking at 'last modified' it seems that rebuildFileCache.log has been last modified on the 23rd while runJobs.log on the 18th. Those are the only two logs inside there.... The owner/group is root root. The first log is huge, I copied pasted the last pages (132 in word) and replaced the path to the wiki with 'wikidir':

As for runJobs =

MarkAHershberger (talkcontribs)

So, for rebuildFileCache, it looks like it is failing. As the message says, "Set $wgShowExceptionDetails = true; and $wgShowDBErrorBacktrace = true; at the bottom of LocalSettings.php to show detailed debugging information." so we can see what is going on.

runJobs looks fine.

MarkAHershberger (talkcontribs)

oh, and make both log files owned by www-data so that the cron jobs will be able to update them. You should also change the ownership on the log directory.

Star Warden (talkcontribs)

Both file logs and the folder itself are owned by www-data now. I am not sure how runJobs looks fine since I can see that the jobs aren't being run.

Maybe the wiki-jobs file itself has to be owned by www-data? Most of the folders on the server are owned by root.

Off-topic: most of the wiki folder is owned by www-data, but some folders are owned by root. Should I pass ownership to www-data?

And this is what rebuildcache log shows now:

MarkAHershberger (talkcontribs)

You still haven't set the variables to show exceptions.

Star Warden (talkcontribs)

I actually did. This is what the bottom of localsettings looks like:

Also, it's owned by root.

MarkAHershberger (talkcontribs)

interesting... it doesn't seem to have made a difference for your rebuildcachelog.

Star Warden (talkcontribs)

Maybe I should give those files different permissions? Their current permissions are -rw-r--r--

Also, what should I do to get the runJobs script running? Or all of the scripts, for that matter. None seems to be working.

MarkAHershberger (talkcontribs)

Here are the permissions on my file:

$ ls -l /etc/cron.d/test 
-rw-r--r-- 1 root root 442 Mar 24 12:15 /etc/cron.d/test

The content is what I gave above.

My log files show that the cron jobs are running.

$ zgrep maintenance /var/log/syslog.1 | tail -53 | head -3
Mar 26 00:00:01 web CRON[20974]: (www-data) CMD ( cd $WIKIDIR && php maintenance/rebuildFileCache.php   >> $LOGDIR/rebuildFileCache.log 2>&1)
Mar 26 00:00:01 web CRON[20977]: (www-data) CMD ( cd $WIKIDIR && php maintenance/runJobs.php            >> $LOGDIR/runJobs.log 2>&1)
Mar 26 00:00:01 web CRON[20979]: (www-data) CMD ( cd $WIKIDIR && php maintenance/updateSpecialPages.php >> $LOGDIR/updateSpecialPages.log 2>&1)

I'm not sure how I can help you in this forum.

Star Warden (talkcontribs)

So I fixed it. All I did was to replace wikidir and logdir with their respective folders. Strange fix.

Star Warden (talkcontribs)

Now, all that remains is the stuck jobs. Do I manually remove them from the database or what should I do? So far, that's the only solution I found to get rid of them.

Reply to "Error creating thumbnail: Unable to save thumbnail to destination"

SimpleSAML extension with Mediawiki 1.27.1

Ashni rai (talkcontribs)

I'm trying to migrate our mediawiki from 1.23.5 to 1.27.1. But the SimpleSAML extension is throwing a HTTP 500 error. I'm not able to rectify the error since am quite new to SimpleSAML. PFB configuration changes made in Localsettings.php. Is there any other config changes to be made other than the following.Thanks.

wfLoadExtension( 'PluggableAuth' ); 
$wgPluggableAuth_EnableAutoLogin = false;
$wgPluggableAuth_EnableLocalLogin = false; 
$wgPluggableAuth_Class = "SimpleSAMLphp"; 
wfLoadExtension( 'SimpleSAMLphp' ); 
$wgSimpleSAMLphp_InstallDir = 'C:\MediaWiki\mediawiki-1.27.1\extensions\SimpleSAMLphp';
$wgSimpleSAMLphp_AuthSourceId = 'default-sp';
$wgSimpleSAMLphp_RealNameAttribute = //cn;
$wgSimpleSAMLphp_EmailAttribute = //mail;
$wgSimpleSAMLphp_UsernameAttribute = //uid;
MarkAHershberger (talkcontribs)

I'm confused about the last three lines. Why are you putting slashes in front of cn, mail, and uid instead of surrounding them with quotes?

MarkAHershberger (talkcontribs)
  1. What is the error you're seeing?
  2. Could you replace the backslashes in $wgSimpleSAMLphp_InstallDir with forward slashes so that you have
$wgSimpleSAMLphp_InstallDir = 'C:/MediaWiki/mediawiki-1.27.1/extensions/SimpleSAMLphp';
Ashni rai (talkcontribs)

Hi Mark,

Actually we already have put the entire address of CN,Mail and UID in quotes like you mentioned followed by those with slashes as a comment. I think that's not the issue. Now i also tried with forward slashes as you said. It's still throwing me the same 'HTTP 500' error.

After setting wgShowExceptionDetails, it's showing the following backtrace:

Thanks & Regards


MarkAHershberger (talkcontribs)

There should be a message before the first line of the backtrace. What does it say?

Ashni rai (talkcontribs)

[f7e4f1c187b3bb5b5742b8c0] /mediawiki-1.27.1/index.php?title=PoP_Facilitation MWException from line 176 of C:\MediaWiki\mediawiki-1.27.1-downloaded\includes\Hooks.php: Invalid callback LocalisationUpdate::onRecacheFallback in hooks for LocalisationCacheRecacheFallback (talkcontribs)
$wgSimpleSAMLphp_RealNameAttribute = //cn;
$wgSimpleSAMLphp_EmailAttribute = //mail;
$wgSimpleSAMLphp_UsernameAttribute = //uid;

Because "//" starts a comment, these lines actually mean:

$wgSimpleSAMLphp_RealNameAttribute = $wgSimpleSAMLphp_EmailAttribute = $wgSimpleSAMLphp_UsernameAttribute =

Which is obviously a syntax error. They are probably meant to be strings.

Ashni rai (talkcontribs)


No i actually did have the entire '' in quotes not like the one mentioned above. I just removed them since i was posting in a forum. The error message is shared above. Kindly go through it and let me know what might be the issue.

Thanks & Regards,


Reply to "SimpleSAML extension with Mediawiki 1.27.1"