@MBeat33, @krobinson, @MSuijkerbuijk_WMF: we need to decide on a domain name for the donor self-service wiki. This would hold both the email preferences form and the recurring upgrade form.

donors.wikimedia.org ? or is that too similar to donate.wikimedia.org?
fundraising.wikimedia.org?

Something else?

Great question, @Ejegg

other suggestions
mypreferences.wikimedia.org
myprofile.wikimedia.org
donorpreference.wikimedia.org
donorsettings.wikimedia.org
donor-options.wikimedia.org

Hi @Ejegg
I need to understand a bit more the domain structure you are suggesting. Will one main domain then have 1/ a sub domain for the Email preference center and 2/ a sub domain for recurring self-service wiki? Is that self-service wiki only recurring or also one-time? Or how are you thinking of this.
This clarification is important as the names for each in my view should be different.
Adding @DBu-WMF

In T335793#8825647, @MSuijkerbuijk_WMF wrote:

Hi @Ejegg
I need to understand a bit more the domain structure you are suggesting. Will one main domain then have 1/ a sub domain for the Email preference center and 2/ a sub domain for recurring self-service wiki? Is that self-service wiki only recurring or also one-time? Or how are you thinking of this.
This clarification is important as the names for each in my view should be different.
Adding @DBu-WMF

Hi @MSuijkerbuijk_WMF,

There will just be one domain for the email preference center and the page for the recurring upgrades. Each form will have a different page on that one domain. We would use the same domain name for any other self-service pages we add later.

Hi @Ejegg and @AKanji-WMF
We need to discuss this first, as the Email preference center and the Recurring self-service/upgrade have very different goals.
I don't want the Email Pref center to be always visible, at least not for now, for Recurring campaigns like the upgrade or other.
So, could you give an example of the subdomain structure you'd suggest to avoid this? We can then decide on the best public facing name.

Hi @MSuijkerbuijk_WMF! I asked @Jgreen and @Dwisehaupt about the domain names yesterday, and it turns out they don't have a problem with multiple names pointing to the same machine.

So for the recurring self-service the links might look like

(when the donor clicks "yes" in the email)
https://sustainers.wikimedia.org/Special:RecurringUpgrade/upgrade?contact_id=12345678&checksum=3cedf4c9ef68f1713c4345cdf072337d_1683644380_168

(when the donor clicks "no" in the email)
https://sustainers.wikimedia.org/Special:RecurringUpgrade/decline?contact_id=12345678&checksum=3cedf4c9ef68f1713c4345cdf072337d_1683644380_168

while for the email preferences form it could be

https://donorprefs.wikimedia.org/Special:EmailPreferences/emailPreferences&contact_id=2241615&checksum=3cedf4c9ef68f1713c4345cdf072337d_1683644380_168

Note that the email preferences form currently allows for a donor to change their email address, country, and preferred language on file in Civi as well as opting in or out from all communications (besides receipts)

Whether the two forms live on the same domain name or not, they would not be visible from each other. The links in the header of the form will all lead to sections of https://wikimediafoundation.org/ . If a donor goes to the bare domain name we would probably redirect them to donatewiki, same as if a donor goes straight to https://payments.wikimedia.org without the rest of the URL parameters needed to make a donation. The only way a donor will see the form is by following a link from an email or from donor services with matching contact_id and (unexpired) checksum.

Hi @Ejegg
For the Recurring donor self serve portal, I've checked with the team and here's the suggestion: donorpreferences.wikimedia.org
Note that this is not the Email pref subdomain, that should be briefed by the Email team (e.g. emailpreferences.wikimedia.org)
Thanks

OK, great to hear it @MSuijkerbuijk_WMF . @Jgreen and @Dwisehaupt could you please start adding the donorpreferences.wikimedia.org domain to the prefswiki box?

Change 919423 had a related patch set uploaded (by Dwisehaupt; author: Dwisehaupt):

[operations/dns@master] Add donorpreferences, delete dash CNAMEs

https://gerrit.wikimedia.org/r/919423

Change 919423 merged by Jgreen:

[operations/dns@master] Add donorpreferences, delete dash CNAMEs

https://gerrit.wikimedia.org/r/919423

I would remove "email" and "donors" from the subdomain because those words
may create privacy concerns and potentially cyber attacks. I would
recommend "preference.wikimedia.org" or "recurring.wikimedia.org" or "
sustainer.wikimedia.org"

Thanks @DBu-WMF - we want to land on something that is somewhat specific to fundraising (e.g. preferences.wikimedia.org could be for editor preferences). I defer to the online fundraising team - how about something like supporters@wikimedia.org? @MSuijkerbuijk_WMF please let us know if you have other preferences

Hi @AKanji-WMF we agreed with Elliott that we can have 2 different ones (one for the Email Pref center and one for the Recurring self-serve/upgrade). For the recurring one I've suggested donorpreferences.wikimedia.org. Is that fine with fr-tech? Do you think that'll have security issues? If yes, the alternative might be recurring.wikimedia.org.

OK. I have updated the LE certificate config and all the apache and nginx configs. The new setup is in place on https://donorpreferences.wikimedia.org

It still has ssl certificate client authentication on it until we verify the look, feel, and functionality are as expected. That is a quick config change to disable when we are ready. I still need to verify what valid URLs will be to satisfy the redirect point for the task.

Configured and working using the /index.php?title=Special:EmailPreferences path. If we wish to shift to /Special:EmailPreferences we'll need to update the location pattern in nginx. General redirects are working otherwise.

@Ejegg I know you were doing testing on this. Is there anything else needed from ops for this config?

Looks good for now! When the email / recurring team wants to send the upgrade emails we can check if the longer URLs are OK, but I think that's still not too soon.