Extension:DonationInterface/Refactor 2015

Defining Refactor

 * A refactor 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 finish

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

Areas for focus

 * UI/Forms
 * CSS
 * JS
 * Remove php form cruft
 * 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.
 * Remove all control logic from the page-related classes, and add to the gateway classes
 * Donationdata class - whenever anyone interacts with the payments cluster, this is called to look at all the data and mush it together into 1 cohesive set of data
 * Adapter class
 * 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
 * Remove heavy lifting from class constructors? <--helps with unit testing A LOT
 * Move XML and NVP building into helper classes, but we need a way to override some of that behavior from adapters.
 * 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.
 * Remaining ContributionTracking mess
 * 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
 * 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

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.