Extension:DonationInterface/zh

DonationInterface呈现付款表格，并提供recharinary机制，用于通过各种支付网关收集和跟踪付款.

概述
捐赠接口扩展所做的大部分工作都是与支付网关进行通信. 我们还提供了一个面向用户的表单层，用于接受捐赠.

配置
在LocalSettings.php中include以下内容：

接下来，定义要启用的网关.

例如，以下内容将打开所有当前网关和扩展 （TODO:文档默认值和更新. ）:

在此之后，TODO确保为您打算使用的每个网关定义帐户信息，例如：

重要信息:

DonationInterface以一种特殊的方式搜索全局.

网关使用的任何DonationInterface全局都可以被分配一个特定于该网关的值，或者是整个扩展的默认值（如果两者都存在，则细节将覆盖默认值）.

要为网关全局分配扩展范围的默认值，只需将全局变量名称中的网关前缀换成“wgDonationInterface”即可.

例如：要在默认情况下为整个DonationInterface扩展打开syslogging，而不仅仅是payflow pro网关，请更改以下内容：

到这:

Syslog现在将为所有网关启用，除非您使用特定于网关的全局变量关闭它们.



额外配置
要创建自定义捐赠筛选规则，请在LocalSettings.php文件中设置$wgCustomFiltersRefRules和$wgCustomFilter SrcRules全局变量.

这些数组应设置为关联数组，将正则表达式模式与风险评分数字配对，例如：



定义全局在LocalSettings.php
虽然还有更多的全局变量可供覆盖，但如果您希望DonationInterface实际工作，则可能需要在LocalSettings中定义以下内容.

全局变量定义在DonationInterface.php中.

TODO: update

实现


代码
一般来说，完成捐赠的过程是这样的：


 * 捐赠者被发送到一个已经绑定到特定支付网关的捐赠表格中. 此表单将由GatewayForm类派生的类的特定于网关的未列出特殊页面控制.
 * 扩展的GatewayForm类将实例化其网关适配器. 在构造时，网关适配器将收集、规范化并验证$wgRequest中的任何相关数据.  所有网关都使用相同的类DonationData来完成此任务.  这样做意味着所有数据都要经过相同的规范化和验证过程，无论是谁要求数据或数据来自哪里.
 * 然后，控制GatewayForm子类将使用网关适配器来确定用户在捐赠过程中的位置，如果合适（验证时没有错误，存在所有数据，对编辑令牌或会话没有陌生感，诸如此类），则使用同一网关适配器与远程支付服务器进行交互，以便在捐赠流程中采取下一步行动. 由于每个支付网关都有自己的一组规则（在某些情况下，完全不同的交易类型与任何其他网关中的任何其他交易类型都不直接相似），因此由适配器在内部对所有这些进行分类，并且只以在所有可能的适配器对象中或多或少通用的方式向控制对象公开功能.
 * 在让网关适配器与远程支付网关执行一个或多个交易之后，控制对象将使用网关来确定发生了什么，并向潜在的捐赠者显示适当的结果. 这可能是一个“谢谢”页面，一个显示在提交的表单上的错误，提示用户以有意义的方式重试，或者是一个更致命的错误页面.

GatewayAdapter class
(DonationInterface/gateway_common/gateway.adapter.php) - This is an abstract class that takes care of everything a general gateway needs to do. It it also supposed to yell at you rather loudly if you fail to define any of the particulars that a gateway needs, in order to be able to do anything worthwhile.

GatewayForm
(DonationInterface/gateway_common/GatewayForm.php) - A class that extends UnlistedSpecialPage. This will take care of all the not-gateway-specific functionality necessary to present a donation form to a user, and get the results. Of particular interest are the mechanisms for displaying the requested form (or not), handling some of the more universal aspects of form validation, and fetching data that could be used by the specified forms (as in, a list of countries and their codes for a country drop-down).

Classes that inherit from these will be specific to a particular payment gateway. As such, they will be located in a folder named something like DonationInterface/[name]_gateway/.

Most adapters will implement GatewayForm for two routes: the initial payment form, and a result switcher page.

The initial payment form is responsible for rendering a form with inputs for the mandatory data to be collected. Alternatively, some gateways such as GlobalCollect will render an iframed form hosted by the payment processor, and others such as PayPal and Amazon will transparently redirect to the processor unless the donation information (currency and amount) are invalid and must be corrected.

The result switcher is usually not responsible for confirming payment or performing further authorization, it simply routes the donor to either the Thank You or Failure pages, depending on approximate responses from the processor.

DonationData class
(DonationInterface/gateway_common/DonationData.php) - This class is intended to handle everything that we are likely to want to do with Donation Data. It should load the data in a consistent way from any appropriate source (including a test), saves relevant Contribution Tracking data, generates data we always need to generate (like order IDs), normalizes everything, and hands it back to the gateway. Classes inheriting from GatewayAdapter will instantiate a DonationData class on creation. The GatewayAdapter child classes should only ever use data that has come through the DonationData class. It also handles edit tokens.

DataValidator
All data is first normalized by DonationData, and is then validated. If data fails validation, all processing is halted and the donor is redirected back to the form where they can correct any errors. Messages are displayed to guide the user through the corrections. TODO: make messages human-readable, attach to fields rather than pop-up, etc.

The gateway adapter is consulted for some of these validations, for example a lower and upper threshold for valid donation amounts, and accepted currencies.

Defining A New Gateway Adapter
GatewayAdapter extends the GatewayType interface. TODO: Here is a quick guide to defining the functions in GatewayType.

测试
Unit tests can be found in the tests directory of the DonationInterface extension.

To run unit tests go to the mediawiki-core directory, then under tests/phpunit:

Composer
Whenever  changes, you must run   to refresh the contents of vendor/.

For WMF production, vendor is deployed on the "deployment" branch as a git submodule. You must  the package ".git" directories when committing new packages, otherwise they will be treated as misshapen, nested submodules and you don't want to go there.

路线图
Some things we want to do:

(✅) (✅) : (✅)
 * Decouple presentation layer from controllers and payments backend
 * Kill RapidHTML and use a mainline templating engine
 * Consolidate forms into a single universal form, with boolean params that control block visibility and available features
 * Decouple payment processing from the MediaWiki framework, so it can be used as a standalone library
 * Provide access to the payments library inside of Drupal, to enable refunds, cancellation, and status retrieval from CiviCRM