(REF) civicrm/mailing/unsubscribe - Add page-controller in front of form-controller
authorTim Otten <totten@civicrm.org>
Wed, 10 Jan 2024 21:54:41 +0000 (13:54 -0800)
committerTim Otten <totten@civicrm.org>
Fri, 12 Jan 2024 21:46:37 +0000 (13:46 -0800)
commit944096c3dc82d1436e0c4dd98fae34a005195982
tree7b910de1cb8cb7016b8e739a7fe8172543e2dfba
parente3f073761411ac9411acb50c188d48a2e838a2b1
(REF) civicrm/mailing/unsubscribe - Add page-controller in front of form-controller

Before: `civicrm/mailing/unsubscribe` points directly to `CRM_Mailing_Form_Unsubscribe`

After: `civicrm/mailing/unsubscribe` points to `CRM_Mailing_Page_Unsubscribe`, which MAY delegate
to `CRM_Mailing_Form_Unsubscribe`

Comments:

* This is a step toward supporting one-click subscribe.
    * The problem is that one-click unsubscribe MUST receive a POST on the same URL
      as a user-visible form.
    * In Quickform (esp `CRM_Mailing_Form_Unsubscribe`), every POST MUST give a `qfKey`.
    * We need a place to process the one-click POST *without* requiring `qfKey`.
* There is a pre-existing class `CRM_Mailing_Page_Unsubscribe`. This was dead code.
  The patch co-opts/re-uses the class for its own purpose.
    * The old `Page` class was not referenced anywhere (by routes or other classes).
    * What appears to have happened: this screen was originally a `Page`; then it was
      renamed/converted to a `Form`; then shortly after, the original `Page` was re-imported
      verbatim by a gsoc student. Their commit doesn't appear to make substantive use of
      the `Page`. This smells like mistake in handling branches/merges/rebases.
CRM/Mailing/Page/Unsubscribe.php
CRM/Mailing/xml/Menu/Mailing.xml