Extension:DonationInterface/Refactor 2015

Defining Refactor

 * Refactoring something should not change any features - there's no UI changes at all to the user, only to the back end
 * We should write complete tests that pass as is before writing the new pieces
 * Fixing bugs as a direct by-product of the refactor is OK, but not as a goal for the refactor
 * Documentation is a requirement to mark a refactored item as finished

UI/Forms

 * CSS
 * JS
 * Remove php form cruft
 * Handle the excessive amount of template file duplication without sacrificing flexibility
 * Replace template engine
 * Universal form (may not be possible)
 * At a minimum, reuse as many page elements between gateways as possible
 * Friendly error messages for situations we can tell the donors about (not a refactor concern. This is new work)

GatewayPage child classes

 * Remove all control logic from the page-related classes, and roll back in to the gateway classes

DonationData class

 * There is some evidence around a dream we had once, in the way we're currently trying (and failing) to handle order_id. This should be rolled in to the main strategy:
 * Each piece of data that DonationData keeps, should be an instance of a new data item class
 * The new class should keep track of all places that the data item can currently be pulled from ($_GET, $_POST, $_SESSION, passed to other class via constructor denoting some kind of batch mode, whatever else)
 * DonationData should keep general rules about what sources should win over other data sources, for individual data items
 * DonationData should try to call back to specific gateway adapter classes for rule overrides

Gateway adapter classes

 * Refactor Transaction Structure
 * Put transaction structure data nodes somewhere that they can easily be added/ignored
 * Transformations become first class entities, or at least easy (and clear) to compose.
 * Improve readability and reduce complexity
 * Examine child classes for things to move to parent, and vice versa
 * Kill PFP and all its stupid references, right in its face.
 * Separate declarative and code elements of adapters, see https://gerrit.wikimedia.org/r/#/c/65003/
 * Remove logging from adapter classes (with the stopwatch)
 * Clean up session handling
 * Refactor the way we store and handle payment method and submethod... but this might violate the REFACTOR ONLY rule
 * Polish antifraud rules
 * cruft removal
 * UNIT TESTS
 * Status buckets: The map of their status to our buckets
 * Move XML and NVP building into helper classes, but we need a way to override some of that behavior from adapters.

ContributionTracking

 * Not working on Donate wiki
 * Make it not a SPOF
 * UTM information handling
 * Later step: would be nice to record each event rather than rollup

Misc

 * Remove all heavy lifting from class constructors <--helps with unit testing A LOT
 * Vagrant role for working on payments.wikimedia.org. The remaining glue here is to modify the MultiWiki module to handle a second mediawiki-core source checkout, under another branch.
 * LocalSettings. Is a mess. See what we can do about that.
 * Admin UI.
 * Status page for all the stuff, lockouts.
 * Once the UI is decoupled
 * take UI out of the DI extension entirely.
 * Then, beef up the standaloneness of DI payments code.
 * Merge into SmashPig.
 * Make i18n strings sane.
 * Lots of unused stuff and copies.
 * Actually sort into interface, gateway, etc.
 * Unit tests!
 * Anything hard to test, should probably be refactored in the actual code

Approach

 * Commits should be as contained as possible so that we can roll them back individually as we go if there is a problem
 * Does it make sense to have a difference between the old and new so that we can toggle between them?
 * Pros
 * If a new goal is set by not-fr-tech, we can hopefully meet that quickly
 * Having a staging vs. dev environment
 * Cons
 * Can't build a house on 2 foundations
 * Toggling between the 2 is hard/tricky/fiddly
 * If we want to really use the new thing, we need other people to use the new thing, too.
 * Don't change queue message format or queues in the refactor

Goals
Near-term
 * Achieve maintainable and modern UI.
 * Make it easy for other WMF engineers and volunteers to help with code.

Long-term
 * Our payments stuff is used and maintained by other orgs.

Steps

 * SmashPig
 * Push DonationInterface payments code into SmashPig.
 * Push sundry audit and listener components into SmashPig.
 * SmashPig should use standard libraries like Composer autoload and Monolog.