We have our wiki set up so that the sidebar isn't shown until after a user logs in. This is our way of securing our wiki from unauthorized users as the permissions way doesn't work. Unfortunately they can still search via the search bar so was trying to find a way to simply hide the search bar for our Main page, is this possible?
Project:Support desk
About this board
 Archives
|
There are also other places where to ask: IRC, mailing lists, Q&A etc.
Before you post
- Make sure you have read our fundamental introduction.
- Please carefully check our FAQ and Errors and Symptoms pages.
- Project:Current issues is where you should discuss issues about the mediawiki.org website itself.
- If your question is about a specific function, please read the relevant technical manual, end-user help or extension page and consider asking on its talk page.
- Test wiki editing at the Project:Sandbox.
Post a new question
- 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
- 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.
- To start a new thread, click "Start a new topic".
Previous page history was archived for backup purposes at Project:Support desk/LQT Archive 1 on 2015-07-30.
| Language: | English • español |
|---|
Hi, I am working on my own personal Wikimedia site. It's just for me right now to document my past work (only I can edit), and I have allowed a lot of different file types to be uploaded. But Wikimedia doesn't seem to want to allow html or htm to be allowed.
I know I am editing localsettings.php section correctly:
$wgFileExtensions = array_merge(
$wgFileExtensions, array(
'zip', 'xls', 'xlsx', 'doc','docx', 'mdb', 'accdb', 'ppt', 'pptx', 'csv', 'txt', 'html', 'pdf'
)
);
If I take out or add in other extensions, changes are immediately reflected in allowed extensions on my Upload file page. But html or htm simply won't show as allowed extensions, and give an error that they are not allowed if I try to upload.
I realize I can simply upload the html pages to my site, outside of Wikimedia. But I am creating an archive of projects and as such, I want to take advantage of all the nice file tracking and commenting features of Wikimedia.
Google doesn't seem to help. The Wikimedia page on file types doesn't say they're not allowed.
I believe I have Wikimedia 1.27.1 (install files dated Aug. 23, 2016). I used my SiteGround hosts' installer.
Can anyone help?
See $wgFileBlacklist. As that page suggests, if you want to allow HTML files, you'll have to do something like the following:
$wgFileExtensions[] = 'html';
$wgFileBlacklist = array_diff( $wgFileBlacklist, array ('html') );
Also see $wgMimeTypeBlacklist for text/html.
Thank you very much, it's been very helpful and enlightening...
Even after all that (and it was needed), I still get the Upload Warning:
This file contains HTML or script code that may be erroneously interpreted by a web browser.
And it won't let me upload even if I checkmark Ignore Any Warnings.
There isn't really any reason to think there's a problem with the html. It is over 6 years old, came from a game wiki I knew well then (above the board), and modern Chrome displays it fine; my AV and malwarebytes does not have any problem.
Any idea on what to do next?
Followup:
I looked into temporarily deactivating all safeguards. (At this point in time, I am the only person with write access to my wiki.) There seems to be a history of SVG files causing this error as seen here, where they also talk about using detectScript in SpecialUploads.php, and just adding an IF phrase to jump out of the security check if it's SVG.
Of course, anything like this has to be used with extreme caution. But there's an exception to every rule, too.
Still, my SpecialUpload.php does not have any detectScript function. Apparently SVGs can load scripts. Plus the article is from 2009, so maybe that issue is obsolete anyway.
It is also possible that there are actually numerous triggers in my html files that Wikimedia Upload won't like. Not that my html is particularly suspicious (I know it isn't), but because Wikimedia is very cautious. In short, it may be a wild goose chase to try to find every specific problem. I may need a general way around the problem.
Some might say, why not change the extension and trick Wikimedia? No, I would rather just post the htmls outside Wikimedia than force readers to play a game of "download and rename extension in order to view it". And I still like Wikimedia's tracking capabilities. Finally, the warning itself is really about the contents of the file, not its extension.
Anyway. Does anyone have insights now? I can temporarily over-ride warnings... I have exactly 10 old htmls I want to upload, and that's it. This is for a very specific old project I am trying to document on my wiki.
Thanks if you can help!
Due to this bug https://phabricator.wikimedia.org/T124196 we were unable to store job table in mysql. So we use Redis instead. We set the "Job Queue" as instruction here: https://github.com/wikimedia/mediawiki-extensions-CirrusSearch
$redisPassword = '<password goes here>'; $wgJobTypeConf['default'] = array( 'class' => 'JobQueueRedis', 'order' => 'fifo', 'redisServer' => 'localhost', 'checkDelay' => true, 'redisConfig' => array( 'password' => $redisPassword, ), ); $wgJobQueueAggregator = array( 'class' => 'JobQueueAggregatorRedis', 'redisServer' => 'localhost', 'redisConfig' => array( 'password' => $redisPassword, ), );
We successfully store job queue in redis and runjob without problem. However, it seems that redis would not delete finished job after it been ran. Once the ram get filled up we get error message like these: "Redis server error: Could not insert 1 EchoNotificationDeleteJob Job(s)."
We got limited 1GB ram for redis. Redis is using volatile-lru maxmemory_policy
Hi,
I have been trying to figure this out for the past week and can't come across a solution!
Basically- I uploaded a few files last week and everything was working well. Then, halfway through an upload, the screen went blank. I had one file that just wouldn't upload (even though it had the correct extensions etc).
Anyway, after this point, every time I go into 'special pages' and click on list files or anything that requires a directory of the uploaded files, I get a blank page. It half loads then seems to give up and just ends up blank.
I've tried to do the error thing in local settings.php; increase memory in php.ini and various other things and I can't seem to work out where the problem is.
I'm running on MAMP on my Mac.
Help!
When output stops like that, I've found a good way to figure out what the error is is to add
error_reporting( -1 ); ini_set( 'display_errors', 1 );
to your LocalSettings.php.
If you add those two lines, do you see any error messages?
See also the documentation on blank pages.
Hi,
Thanks, have tried all of it and it doesn't appear to be showing anything...
I've added the error reporting to the local settings and nothing has come up.. and I've increased the memory size.
Is there anything else I can try?
Thanks,
S
hello, I have the same problem with the blank file-list page. I'm running the wiki on an extern server. How can I fix it - all the "error-reporting" in the local settings.php didn't help.
I would be very very glad for any help!!
The error reporting thing is not to fix the issue, but to know the cause of it being broken (which currently nobody knows) so it can be fixed.
If you post a detailed error message, it would help us diagnose the problem. Otherwise, we can't do anything since we can't reproduce the error in our environment.
I have the same problem - a blank page when trying to upload an image file. My Wiki is 2 yrs old and this problem has never occurred before. Also, after trying to upload a 3MB .jpeg I am unable to view Special:ListFiles. Adding the error-reporting lines to LocalSettings.php didn't produce an error message on the blank page. However, my error log file contains the following:
PHP Fatal error: Allowed memory size of 52428800 bytes exhausted (tried to allocate 9216 bytes) in /home/xxxxx/public_html/wiki/includes/media/Bitmap.php on line 566
I'm using MediaWiki 1.23.5, PHP 5.3.24
Any advice would be gratefully received.
Your memory limit currently is set to 50MB. However, this obviously is not enough; try setting the PHP setting memory_limit to something higher, e.g. to 128MB and try again!
I took a guess (!) at how to do this and added
$wgMemoryLimit = "128M";
to LocalSettings.php and it has worked. Thank you very much!
Is the problem likely to recur if we keep uploading images? I'm just wondering if I will need to increase the limit again at some point in the future.
I don't think this will reoccur any time soon: The memory limit is per request, so if you don't do anything with many images in the same website call, then there should be no problem. Maybe you have to raise this again some time in the future, when 128MB has become "small". Anyway, I guess that's not any time soon.
Perfecto. Again, many thanks.
For days i had the same problem after upgrading from 1.23 --> 1.28.
Strangly the MemoryLimit variable was not part of the lLocalSetting file
After manualy adding this gives me the fileslist option back and even uploading a 500 kb image works now
I have just setup mediawiki 1.28 for the first time and I’m having issues with trailing slash
I am using centos/httpd setup, with virtual host and multiple services
The mediawiki is under:
<Directory /var/www/mediawiki> AllowOverride All </Directory> alias /mediawiki /var/www/mediawiki/
which has the following output for the URL:
AddressURL: https://<domain>/mediawiki
ResolvedURL: https://<domain>/mediawiki/index.php/Main_Page
There are no issues with the site itself or the other sites/services on the same Apache
Only when trying to link to a template from a template
Using the mediawiki’s Main Page as an example
I have the Main Page that links to Template:Main page .. which works fine … as far as I can tell
Under the Template:Main page I have the code (exactly the same as mediawiki’s page)
… <div id="mainpage_pagetitle">'''{{Main page/include|welcome|{{{1|}}}|3=[[MediaWiki|<span id="mainpage_mwtitle">MediaWiki.org</span>]]}}'''</div> …
For this example, this should call the Template:Main page/welcome … (no trailing slash), however on the “read” page for Template:Main page, gives me a red link for this and show the trailing “/”
{{#if:
|
I can correctly search and bring up the page,
https://<domain>/mediawiki/index.php/Template:Main_page/welcome
I am not sure how to fix this, as I don’t necessarily have a trail slash Apache issue
thanks
i notice that a section of code response was missing in the post:
{{#if:
| {{#ifexist: Template:Main page/welcome/
| Template:Main page/welcome/
| Welcome to MediaWiki.org
}}
Is the problem solved?
Not at this time, issue still persists
The mediawiki program seems to be broken for the synology device. When I try to access the page I get
Exception encountered, of type "InvalidArgumentException"
or
"Notice: Object of class Closure could not be converted to int in /volume1/web/MediaWiki/includes/libs/objectcache/WANObjectCache.php on line 801 Exception encountered, of type "InvalidArgumentException""
which has a little more information, but not enough for me to get it working again.
Which MediaWiki version is this about? To get a stacktrace for the exception, see Manual:How to debug
So I was looking to create a user page and noticed a modern editor. I'm talking about the thing that shows up when I click here - what extension is it? Is it VisualEditor, WikiEditor, or something else? What's the difference between VisualEditor and WikiEditor? Thanks.
See https://www.mediawiki.org/wiki/Extension:WikiEditor and https://www.mediawiki.org/wiki/Extension:VisualEditor for a start :)
Hello!
I have a wiki that has very long page names (generated by a script), which makes linking between them unpractical and harder than it should be. I'd like to know if there's a way to somehow shorten the names — by using some kind of wildcards, aliases, or maybe by their PageID? Or what other alternative solutions to my problem might exist?
Thank you in advance!
Hi All,
I have upgrade mediawiki from 1.12.0 to 1.27.1. I have also installed Visual Editor in new wiki. But later I have noticed that external URL links are not opening.
Previously "|_new" is added to make the URL open in new tab but now that is being taken by wiki as "%7C" and URL is not opening.
Could any on suggest what can be done?e
First, was your previous version really 1.12? That's amazing. I'm glad you upgraded.
You should look at Manual:$wgExternalLinkTarget and see if that addresses your use case.
Thanks for your reply..
But that extension is to open all the links in new window. we need specific links to open in new window which have "|_new" as suffix to the link.
As I recall, the "|_new" syntax was not in MW by default but was something that could be added. Have you checked to see if how the syntax was implemented in your old wiki?
I have gone through Linker.php file in old wiki and new wiki. I noticed there is much difference between those two files.
Is it the culprit I'm checking for??
I'm not sure what you're looking for. Check extensions first since I could be wrong and it may be there.
If that doesn't turn up anything, then what I would do is use git to check out MediaWiki on the REL1_12 branch and then copy your old wiki's includes directory over your checked out code's includes directory. There will be some differences that aren't related to your changes since there were four releases of 1.12 besides your installed copy, but one of the changes should be what you're looking for.
If all else fails, just use "grep -R _new ." in your old wiki installation.
what is the alternative getExternalLinkAttributes function in new mediawiki? I guess it is unable to parse the given link in new miediawiki
Environment:
OS: Ubuntu 14.04.4 LTS
MediaWiki: 1.26.2
wiki url: http://intranet.hit.local/wiki-hitit/
parsoid listener port: 8142
After a good day of trying to set up VirtualEditor, the above error is still with us.
I think I followed the instructions in
- https://www.mediawiki.org/wiki/Extension:VisualEditor
- https://www.mediawiki.org/wiki/Parsoid/Setup
though, I'm still uncertain about the url/uri.
/var/www/html/wiki-hitit/LocalSettings.php has the following entries for VisualEditor:
### VisualEditor
require_once( "$IP/extensions/VisualEditor/VisualEditor.php" );
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgSessionsInObjectCache = true;
$wgVirtualRestConfig['modules']['parsoid'] = array(
'url' => 'http://localhost:8142/wiki-hitit/',
'prefix' => 'wiki-hitit'
);
/etc/mediawiki/parsoid/localsettings.js has the following entries:
'use strict';
exports.setup = function(parsoidConfig) {
parsoidConfig.setMwApi({ prefix: 'wiki-hitit', uri: 'http://localhost/wiki-hitit/api.php' });
parsoidConfig.useSelser = true;
};
/var/www/html/wiki-hitit/extensions/parsoid/localsettings.js has these:
'use strict';
exports.setup = function(parsoidConfig) {
parsoidConfig.setMwApi({
prefix: 'wiki-hitit', // optional
uri: 'http://localhost/wiki-hitit/api.php' });
parsoidConfig.useSelser = true;
};
The api.php is accessible:
$ curl 'http://localhost/wiki-hitit/api.php' | head
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
<!DOCTYPE html>
<html lang="en" dir="ltr" class="client-nojs">
<head>
<meta charset="UTF-8" />
<title>MediaWiki API help - Hitit</title>
The wiki pages now have both an 'edit' and an 'edit source' tab. But when you press the 'edit' tab, you get a pop-up with this error message:
"Error loading data from server: 404: parsoidserver-http: HTTP 404. Would you like to retry?"
I've found several articles about this issue, but none that helped.
Is the url/uri definition correct? (All examples I found used simple urls.)
Are there any log files I can check? I tried the parsoid and apache2 logs, but there's nothing there.
Any other suggestions?
Kind regards,
Herta
There's a 404 error somewhere, try to find in apache error logs the URL being requested, that should give you a hint what configuration is wrong. Maybe you need to omit the "prefix" configuration part
Thanks for your reply.
There's nothing in the apache error log. The access log has this entry:
10.32.14.57 - - [29/Feb/2016:09:59:13 +0100] "GET /wiki-hitit/api.php?action=visualeditor&format=json&paction=parse&page=Main_Page&uselang=en HTTP/1.1" 200 511 "http://intranet.hit.local/wiki-hitit/index.php/Main_Page?veaction=edit" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0"
10.32.14.57 - - [29/Feb/2016:09:59:13 +0100] "GET /wiki-hitit/load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Ccore%2Cdata%2CdesktopArticleTarget%2Cicons%2Clanguage%2Cmediawiki%2Cmwalienextension%2Cmwcore%2Cmwformatting%2Cmwgallery%2Cmwimage%2Cmwlink%2Cmwmeta%2Cmwreference%2Cmwtransclusion%7Cext.visualEditor.core.desktop%7Cext.visualEditor.mwimage.core%7Cext.visualEditor.mwreference.core%7Cext.visualEditor.mwtransclusion.core%7Cjquery.autoEllipsis%2CbyteLimit%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.action.history.diff%7Cmediawiki.api.options%7Cmediawiki.language.names%2CspecialCharacters%7Cmediawiki.page.gallery.styles%7Cmediawiki.skinning.content.parsoid%7Cmediawiki.widgets.CategorySelector%2Cstyles%7Cmoment%2Coojs%2Coojs-ui%2Cpapaparse%2Crangefix%2Cunicodejs%7Coojs-ui.styles%7Coojs-ui.styles.icons%2Cicons-editing-advanced%2Cicons-editing-core%2Cicons-editing-list%2Cicons-editing-styling%2Cindicators%2Ctextures&skin=monobook&version=10061a186059 HTTP/1.1" 200 2196466 "http://intranet.hit.local/wiki-hitit/index.php/Main_Page?veaction=edit" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0"
P.S. I removed the prefix from the three config files and restarted parsoid and apache2, but the error remains.
I think the URI in your LocalSettings.php file should be
'url' => 'http://localhost:8142'
.
So without the
/wiki-hiti/
part. Let us know if that works :)
After much trial and error, that is indeed what fixed it.
Thanks, Swennet.
@Hvdeynde, how you solve this issue? Pleace post your config files
Hello all,
After spending a LOT of time to let VisualEditor extension be able to work on my Wiki (I tried every possibilities for both parsoid setting file and LocalSettings file), I finally found a simple conf that actually works for me. So, that's what I am sharing below.
For your information :
-running on Debian,
-mediawiki 1.26.2,
-wiki's name si WikiName,
-it's located in /var/www/WikiName,
-IP adress of my wiki is IP_adress (like 123.123.123.123).
In /etc/mediawiki/parsoid/setting.js, what has changed from the original file is following below:
parsoidConfig.setMwApi({ prefix: 'IP_adress', uri: 'http://IP_adress/WikiName/api.php' );
In LocalSettings.php:
$wgVirtualRestConfig[‘modules’][‘parsoid’] = array(
‘url’ => ‘http://IP_adress:8142’
);
Everything else is useless for me (like domain for instance). I think that 'Localhost' is not working on recent wiki (my visual editor was not working since I updated my wiki), that's why I think you should try to put some IP adress of yours to make it work insteasd of localhost.
I hope it will help a few of you!
@+
KrazyMax
Sorry for the bad layout, looked much better before it was actually posted!
KrazyMax
Hello,
it dosnt work to me.
MediaWiki 1.28.0
i become 404
LocalConfig.php:
wfLoadExtension( 'VisualEditor' );
// Enable by default for everybody $wgDefaultUserOptions['visualeditor-enable'] = 1;
// Optional: Set VisualEditor as the default for anonymous users // otherwise they will have to switch to VE // $wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";
// Don't allow users to disable it $wgHiddenPrefs[] = 'visualeditor-enable';
// OPTIONAL: Enable VisualEditor's experimental code features
$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;
$wgVirtualRestConfig['modules']['parsoid'] = array(
// URL to the Parsoid instance
// Use port 8142 if you use the Debian package
'url' => 'http://XXX.XXX.XXX.XXX:8142',
// Parsoid "domain", see below (optional)
//'domain' => 'XXX',
// Parsoid "prefix", see below (optional)
//'prefix' => 'XXX'
);
localsettings.js:
parsoidConfig.setInterwiki( { prefix: 'XXX.XXX.XXX.XXX', uri: 'http://XXX.XXX.XXX.XXX/mediawiki/api.php' } );
From previous messages I see the config is parsoidConfig.setMwApi, not parsoidConfig.setInterwiki. Can you check that's correct?
Thanks. But ist the same 404 -.-
parsoidConfig.setMwApi({ prefix: 'XXX.XXX.XXX.XXX', uri: 'http://XXX.XXX.XXX.XXX/mediawiki/api.php'});
does opening http://XXX.XXX.XXX.XXX/mediawiki/api.php load the api help page when opening the URL from the server?
yes
Other ideas?
