User facing application for the Wikimedia Deutschland fundraising
PHP JavaScript HTML CSS Shell Ruby
Latest commit bd28682 Feb 26, 2017 @JeroenDeDauw JeroenDeDauw committed on GitHub Merge pull request #834 from wmde/auto-set-company-salutation
automatically set salutation for companies
Failed to load latest commit information.
app map payment status to translatable messages Feb 8, 2017
build Use dummy mailer in Vagrant config Jan 19, 2017
cli Remove testing and debugging code Oct 25, 2016
contexts fix creating domain objects of company membership applications from d… Feb 23, 2017
deployment configure PHP version Jan 27, 2017
doc Add "Begin" actions to ValidationDispatchers Jan 16, 2017
res introducing konto_check library Jan 13, 2016
src Allow weird evil characeters in email domains Feb 12, 2017
tests fix creating domain objects of company membership applications from d… Feb 23, 2017
web apply donation confirmation page styles to membership confirmation page Feb 7, 2017
.gitignore Fixed composer installation Jan 16, 2017
.jscsrc Add optional logging to Redux store Mar 8, 2016
.jshintrc Disallow console.log in production code Mar 4, 2016
.scrutinizer.yml Ignore JS libs on ScurintizerCI Aug 5, 2016
.travis.yml Replaced constant visibility docs with PHP 7.1 feature Jan 19, 2017
COPYING.txt Add license file Aug 5, 2016 Updated test running docs Feb 12, 2017
Vagrantfile Add Vagrant app installation provisioning Jan 17, 2017
cli-config.php Remove ApplicationContext as discussed per email Oct 15, 2016
composer.json Switch to PHPUnit 6.x Feb 9, 2017
composer.lock Switch to PHPUnit 6.x Feb 9, 2017
console Move config validation to Cli namespace Aug 18, 2016
package.json Manually add polyfills for Redux May 31, 2016
phpcs.xml Use nullable parameters and return types Feb 6, 2017
phpmd.xml Decrease PHPMD failures May 29, 2016
phpunit.xml.dist Switch to PHPUnit 6.x Feb 9, 2017

Build Status Code Coverage Scrutinizer Code Quality

User facing application for the Wikimedia Deutschland fundraising.

The easiest way to get a working installation of the application is to use Vagrant. Just get a clone of our git repository and run vagrant up in it. Then vagrant ssh into it and go to /vagrant, where you will be able to run the full test suite. (Excluding a handful of payment provider system tests).

System dependencies

  • PHP >= 7
  • php7.0-intl
  • php7.0-curl
  • php7.0-sqlite3 (only needed for running the tests)
  • Node.js and npm (only needed in development for compiling the JavaScript and running the JavaScript tests)
  • kontocheck extension (only needed when you want to use or test direct debit)

Installation and configuration

Get a clone of our git repository and then run these commands in it:

composer install
npm install
npm run build-js

For the database connection you need to create the file app/config/ and enter your database connection data. If you're using MySQL, it's important to add the encoding to the driverOptions key.

"db": {
    "driver": "pdo_mysql",
    "user": "donations_user",
    "password": "s00pa_s33cr1t",
    "dbname": "all_donations",
    "host": "localhost",
    "charset": "utf8",
    "driverOptions": {
        "1002": "SET NAMES utf8"

For a fully working instance with all payment types and working templates you'll also need to fill out the following configuration data:

 - `cms-wiki-url`
 - `bank-data-file`
 - `cms-wiki-api-url`
 - `cms-wiki-user`
 - `cms-wiki-password`
 - `cms-wiki-title-prefix`
 - `operator-email`
 - `operator-displayname-organization`
 - `operator-displayname-suborganization`
 - `paypal`
 - `creditcard`

Running the application

For development

cd web
php -S 0:8000

The "add donation" form can then be found at http://localhost:8000/index.php

Running the tests

Full CI run

composer ci

For tests only

composer test ; npm run test

For style checks only

composer cs ; npm run cs


For tests only

composer test

For x (unit/integration/edgetoedge) tests only

vendor/bin/phpunit --testsuite=x

For one context only

vendor/bin/phpunit contexts/DonationContext/


For a full JS CI run

npm run ci

If JavaScript files where changed, you will first need to run

npm run build-js

If you are working on the JavaScript files and need automatic recompilation when a files changes, then run

npm run watch-js

If you want to debug problems in the Redux data flow, set the following variable in the shell environment:

export REDUX_LOG=on

Actions and their resulting state will be logged.


For an in-depth documentation how deployment on a server is done, see the deployment documentation.


When accessing the API via web/, profiling information will be generated and in app/cache/profiler. You can access the profiler UI via

Project structure

This codebase follows a modified version of The Clean Architecture, combined with a partial application of Domain Driven Design. The high level structure is represented by this diagram.

Production code layout

  • src/: framework agnostic code not belonging to any Bounded Context
    • Factories/: application factories used by the framework, including top level factory FFFactory
    • Presentation/: presentation code, including the Presenters/
    • Validation/: validation code
  • contexts/$ContextName/src/ framework agnostic code belonging to a specific Bounded Context
    • Domain/: domain model and domain services
    • UseCases/: one directory per use case
    • DataAccess/: implementations of services that binds to database, network, etc
    • Infrastructure/: implementations of services binding to cross cutting concerns, ie logging
  • web/: web accessible code
    • index.php: production entry point
  • app/: contains configuration and all framework (Silex) dependent code
    • bootstrap.php: framework application bootstrap (used by System tests)
    • routes.php: defines the routes and their handlers
    • RouteHandlers/: route handlers that get benefit from having their own class are placed here
    • config/: configuration files
      • config.dist.json: default configuration
      • config.test.json: configuration used by integration and system tests (gets merged into default config)
      • config.test.local.json: instance specific (gitignored) test config (gets merged into config.test.json)
      • instance specific (gitignored) production configuration (gets merged into default config)
    • js/lib: Javascript modules, will be compiled into one file for the frontend.
    • js/test: Unit tests for the JavaScript modules
  • var/: Ephemeral application data
    • log/: Log files (in debug mode, every request creates a log file)
    • cache/: Cache directory for Twig templates

Test code layout

The test directory structure (and namespace structure) mirrors the production code. Tests for code in src/ can be found in tests/. Tests for code in contexts/$ContextName/src/ can be found in contexts/$ContextName/tests/.

Tests are categorized by their type. To run only tests of a given type, you can use one of the testsuites defined in phpunit.xml.dist.

  • Unit/: small isolated tests (one class or a small number of related classes)
  • Integration/: tests combining several units
  • EdgeToEdge/: edge-to-edge tests (fake HTTP requests to the framework)
  • System/: tests involving outside systems (ie, beyond our PHP app and database)
  • Fixtures/: test doubles (stubs, spies and mocks)

If you need access to the application in your non-unit tests, for instance to interact with persistence, you should use TestEnvironment defined in tests/TestEnvironment.php.

Test type restrictions

Database (in memory) Top level factory Framework (Silex) Network & Disk
Unit No No No No
Integration If needed Discouraged No Read only
EdgeToEdge Yes Yes Yes Read only
System Yes Yes Yes Yes

Other directories

  • deployment/: Ansible scripts and configuration for deploying the application