Fundraising/Roadmap
We want to make our software easier to maintain and develop, and more accessible both to new developers on our team and to other organizations.
DonationInterface still uses jquery for a lot of form manipulation. It would be nice to move to something more modern like VueJS which is used in other new MediaWiki frontend features.
We want to move as much business logic as possible from DonationInterface to SmashPig. The obvious opportunities for this migration are when we rewrite a payment processor integration. The Amazon, Adyen, and Ingenico integrations all have moved a fair amount of business logic out of DonationInterface. The PayPal integration still manages all the business logic in DonationInterface code. We are planning to rewrite the PayPal integration in the first half of 2022. Once PayPal business logic is in SmashPig we can rewrite the PayPal pending transaction resolver and completely remove DonationInterface as a dependency of our CiviCRM install. That will then let us remove the WmfFramework shim from DonationInterface and simplify some code.
SmashPig has some homegrown features that are mostly handled by external libraries in modern applications. We should tear out the homegrown implementations and use a more modern approach to
- logging (replace with monolog)
- monitoring/failmail
- dependency injection (maybe Symfony containers)
We want to make configuration consistent and understandable across our codebases. DonationInterface and SmashPig each have a way to define defaults for configuration values that can be overridden on a per-processor basis. These two approaches should be harmonized. We should also make it easy to test the trickier parts of our configuration such as donation routing to ensure that we get the results we expect.
We need to move any CiviCRM custom code that interfaces with drupal 7 to instead interface with CiviCRM APIs. This will be an opportunity to clean up and modernize code while we are at it. In particular:
- Damaged message display needs batch delete / requeue and better search
- Audit parsers need better recurring handling, less wasteful log searching
- Large donation notifier and exchange rate updater should be totally generic & shared with other Civi users
Our current banner impressions stats collector and pageview counter is built on an inappropriate framework. We have a replacement (FRUEC) but need to switch over to using it and verify that the stats are still correct.