Page MenuHomePhabricator

Implement input form support on strategy.wikimedia.org
Closed, DeclinedPublic

Description

Please install FormMailer and SimpleForms to the strategy.wikimedia.org wiki to support the major roll-out of the call for participation phase of strategic priority. We are setting up an OTRS queue to manage the form mail.


Version: unspecified
Severity: critical
URL: http://strategy.wikimedia.org

Details

Reference
bz20292

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 10:53 PM
bzimport set Reference to bz20292.

Moving priority to highest per meeting with Eugene Kim and Erik Moeller. Show stopper for a major deployement.

By the way - the workflow is: User gets an email. Goes to a page. Enters their information and checks which task forces they're willing to be on. A free text field for CV. Then hits send, which sends it to an OTRS queue.

If there are better extensions, do that instead.

Neither of these extensions appear to be in our subversion repository, so they'll need to be reviewed and committed.

http://www.mediawiki.org/wiki/Extension:FormMailer
http://www.mediawiki.org/wiki/Extension:Simple_Forms

Assigning to myself for initial review...

http://www.organicdesign.co.nz/Extension:FormMailer.php

$wgExtensionFunctions[] = 'wfSetupFormMailer';

This appears to be the actual form processing function, with several *huge* problems:

  • there's no check that the form was POSTed, so you can be spammed by an <img>
  • there's no particular location to which the form needs to be posted
  • there's no protection against cross-site requests, much less form submissions

This needs to be redone using a clear entry point such as a Special page, with a check for POSTing. Preferably include an edittoken check to protect against cross-site form submissions.

$_SERVER['REMOTE_ADDR']

This will always show one of our proxies. Needs to use wfGetIP()

foreach ($wgRequest->getValues() as $k => $v) if (!in_array($k, $wgFormMailerDontSend)) {

Looks it really should just stick to things with the form prefix and not touch anything else... all sorts of misc vars might turn up in your form that don't belong in there.

$wgSiteNotice .= "<div class='usermessage'>".($err ? $err : $message)."</div>";

This is utterly broken. :) The sitenotice is definitely the wrong place to put success/error output.

More generally, it lacks any way to specify multiple different forms, as well as not using the localization framework for its UI messages.

Simple Forms is listed as obsolete and unmaintained; definitely not installing that. :)

Aran, what's the replacement that you would recommend?

I'm not wedded to those extensions; but need similar functionality... forms with multiple input types (picklist, check box, text enter), and mailing to OTRS.

http://www.mediawiki.org/wiki/Extension:Form may be a contender. It interacts using MediaWiki pages and wiki templates and has a number of options for various input types (checkbox, radio, select, etc.).

It's written to support posting new wiki pages, but may be adaptable to outputting to e-mail instead.

Sorry we don't really have a replacement for SimpleForms, we've just been using Raw html restricted to the Form NS

updated Bug summary;

We will need some form of form input that generates mail. Would Extension:Form be an option?

Before we really dive into form bureaucracy:

  1. Is this targeted at the general public or at the editing community?
  2. If this is general public, why not just use a wiki page supported by the Javascript form like this one:

http://pl.wikipedia.org/w/index.php?title=MediaWiki:Wikibugs.js

People could create short profiles, willing to describe what they really feel to write about themselves,
not full CVs that would need to be protected.

I don't understand why can't use a simpler, less bureaucratic concept?

The form is targeted at all users, not just editors. Most of these people will not want their email addresses published to a wiki page. In addition, there will be potentially thousands of responses - edit conflicts abound. Some of them may want to include information about work history that particularly qualifies them for a task force; they may wish for that information to not be public.