In order to avoid a bad bug I've encountered (which breaks the wiki pages
of the "File" namespace for image files with big resolution), I need to
prevent users from uploading images with width and height over some wise
limit.
How can it be done?
--
Antonio
Hi, I am experiencing a problem running clamav on an OpenBSD machine. Apache comes chrooted by default (a configuration I want to keep) therefore when the apache user tries to scan a file it finds that no executable named clamscan or clamdscan is inside the chroot. Now I've tried to copy/synlink the executable(s) and the dependent files under the chroot and execute the scan however in my debug log file I always get:
UploadBase::detectVirus: running virus scan: /usr/local/bin/clamdscan --no-summary '/tmp/phpqkflgiwo' 2>&1
wfShellExec: /usr/local/bin/clamdscan --no-summary '/tmp/phpqkflgiwo' 2>&1
Possibly missing executable file: /usr/local/bin/clamdscan --no-summary '/tmp/phpqkflgiwo' 2>&1
UploadBase::detectVirus: failed to scan /tmp/phpqkflgiwo (code 127).
>From the look of it it can't see the executable to even try to scan. If the apache user (www) is running the scan and the same user is executing the scan then permissions of usr/local/bin/clamdscan is 555 (all the way through the path) then it seems it should at least be able to find the file. An odd but seemingly unrelated problem is that the temporary directory is set to /tmp (within the chroot) even though $wgTmpDirectory is set to /htdocs/wiki/images and in php settings they're set to /htdocs/temp. Trying to compile clamav with the --prefix and --exec-prefix options set inside the chroot doesn't result in the program being installed inside the chroot.
If I could just tell clamdscan to talk with the clamd socket that would be nice but it doesn't appear to be practical. It looks like installing clamav inside the chroot path should help but it isn't working as I had hoped. I made a test php script that executes the shell command that mediawiki does (from the wfShellExec function in GlobalFunctions.php) and directly put the desired command for a test file within the chroot and it still behaves the same way when invoked directly on the command line "php test.php". If someone has any suggestions on how to get these programs to work together I'd like to see them. Thanks in advance!
I downloaded the new 1.16 version of MediaWiki & installed it offline using EasyPHP for my MySQL backing. I was excited about the new layout in this version of MediaWiki, especially the change in the search bar location.
My installation of the new MediaWiki version was successful, except that the layout appears to be the same as the old 1.15 version. Notably the search bar is still in the left hand side navigation panel. The navigation panel as well is of the old style variety without any collapsible menus.
Is there something I am doing wrong ?
Thanks for the help.
Hello,
I am running the wonderful Usuability Initiative features on several
of my MediaWiki installs successfully, and really think they work
well. However, on one my instances of MW 1.16 we use for our school
district's Open Content curriculum I can't get the new toolbar to
work.
I think I am having an apparent conflict between the WikiEditor
toolbar, and Caycle's "WikEd" toolbar extension that has been running
on the site for four or so years, and can't seem to remove it
effectively. That older project code, and the required PARC Wiki
Dashboard tools are the only major differences between my sites that
I can see. I've tried removing the PARC tool, but nothing changed.
I have the Vector skin installed, and all modules are showing
up...everything looks great until I try to use the new WikiEditor
toolbar. An older version of this extension:
http://www.mediawiki.org/wiki/Extension:WikEd
When I or any of my users clicks "Edit" the script tries to call the
WikEd code, and all we get is my choice of:
1) A blank space where the toolbar should be...no toolbar at all
2) A nonfunctional WikEd toolbar. Nothing works on it. Click
the tool to make it disappear
(upper right) and get an error
3) Turn all Usability Initiative features off, and load the
standard original flavor toolbar
Try as I might to remove the WikEd one, I can't seem to keep it from
calling that code. I've escaped it, taken out every reference I can
find....and it keeps coming back. I removed the "Common.js" where it
was stored, cleared every kind of cache possible (I think)...from the
server itself to our machines' hardware level cache and browser
cache. Tried different browsers, but didn't help. No proxy in the
upstream path.
I can't find any instructions for removing the WikEd code on the
developer's home page:
http://en.wikipedia.org/wiki/User_talk:Cacycle/wikEd
Since it is an OLD version of that toolbar, I can't even find the
installation instructions to deconstruct what I did to get it set for
"site wide" use, rather than just user-specific. In reading them, the
instructions seem to have changed, and I can't figure out why the
code keeps coming back....
Here are my specifics, but they are identical to my other sites
running MW 1.16...except for the WikEd toolbar:
MediaWiki 1.16.0
PHP 5.2.14 (apache2handler)
MySQL 5.0.91-community-log
UsabilityInitiative (Version 0.1.1)
User Daily Contributions (Version 0.1.1)
Vector (Version 0.2.0)
WikiEditor (Version 0.2.0)
Further info:
http://wiki.bssd.org/index.php/Special:Version
A huge THANKS in advance if anyone has any clue how I can remove this
code, or fix the problem in some other way. I will post to Caycle's
page, but am hoping to get this fixed before school opens in the
morning, and teachers need to edit.
Regards,
JTC..in the Bering Sea
--
"No matter where you go, there you are."
Buckaroo Banzai & Confucius
Digital Contacts:
http://www.bssd.org
jconcilus(a)bssd.org
Skype VOIP: Johncn2
John Concilus, Director of Educational Technology
Bering Strait School District
225 Polar Bear Avenue
Unalakleet, AK 99684
907-624-4237 (Office)
907-624-3283 (Fax)
Hello guys,
whenever I insert some lines in an article using the new editor, he
breaks up my syntax and writes everything in one line. This does not
happen with the editor used in wikipedia. How could I avoid this
problem?
Thank you in advance.
robert
I have a MediaWiki install (v. 1.15.3) and I'd like to be able to use
an in-house single sign-on system that we have to authenticate users
and log them into the wiki. I've started down the path of using
AuthPlugin for this, but I'm stuck at one point.
Right now I've got it working such that when a user goes to the wiki
we check our SSO system to see if they are logged in and have the right
role (sounds like LDAP right? sadly, it's not). If so, we allow them
into the wiki. If not, we take them to our SSO sign-in page, they log
in, then get directed to the wiki. If they log in but don't have the
right role they are shown an error message. I want this to be the auth
flow, rather than using the MW login page, so that's all fine. The
problem is that I can't figure out how to get MW to auto-create
accounts for these users and log them in when they are sent back to the
wiki. They just end up back there as a logged-out anonymous user.
I've looked at the following resources but I still can't figure out
what I'm doing wrong:
http://www.mediawiki.org/wiki/AuthPluginhttp://svn.wikimedia.org/doc/classAuthPlugin.htmlhttp://wiki.case.edu/CaseWiki:External_Authentication
I guess I just don't know what functions I'm supposed to implement
myself to do account creation and login on the MW side, and I don't
know what the best practices are for calling those.
Thanks in advance for any insights you can give me :)
--
Owen B. Mehegan (owen(a)nerdnetworks.org)
"He is a dangerous mixture of sophistication and recklessness which
makes one anxious about his influence on other boys."
Tried to upgrade to the new version of the wikimedia software, but ran into
a problem again. Broke down and created an entirely new folder, plus
database then did a fresh install and everything went smoothly. However i'm
running into a problem now where I try to login to the newly created wiki
media page and I get an error message. It states that the action of loging
in was cancelled due to fear of session hijacking and I should go back to
the previous page, reload it, and try again. Done this multiple times
without any results nor have I been able to progress. What am I doing wrong
at the moment?