Thanks! Here's an updated landing page that looks better (still a work in progress).

These look great! Do all the captions need to be localized?

Thanks @Ejegg, I'll pass that positive feedback along to Eric and Randy :)

Got a couple new versions that have gotten valuable feedback from Caitlin and Peter, so I'm ready to call them legit semifinal:

1. Semifinal with hover effect, no click
2. Seminfinal with lightbox gallery on image click

An important note about #2 (lightbox gallery) : it uses a plugin to achieve the lightbox effect. As far as licensing, I'll quote @Pcoombe :

The lightbox plugin appears to be available under the GPL (https://github.com/sachinchoolur/lightGallery/blob/master/LICENSE.md) which should be okay, although fr-tech might have security concerns about bringing in 3rd-party code.

If you do have concerns, we'd be ok going w/ the hover effect, no click variant.

Elliott and company, could you tell us what you think re: the lightbox plugin, and we can pick one to use as our base for implementation?

@spatton - the lightbox plugin should be fine.

With all those captions, are you planning to pay to have them translated, or wait till the translations come in from translatewiki.net before sending out mailings in different languages?

Re translations, yes, we will be getting them, starting with Italian but moving on to Swedish and likely Dutch in April and May. I don't know what the merits are of using translate wiki vs doing them as one-offs. Can you help us decide what would be the best an ongoing workflow?

Ooh, there are translated captions and descriptions under a bunch of the pictures on commons - looks like some of the payoff from the structured data project! I'll play around with some queries to pull those into the translation files. If I can get that working, it would be great to do the translations right on commons with the pictures.

Change 498287 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] WIP: fancy variant for opt-in page

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

Change 501406 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/vagrant@master] Queue settings for FundraisingEmailUnsubscribe

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

Change 501406 merged by jenkins-bot:
[mediawiki/vagrant@master] Queue settings for FundraisingEmailUnsubscribe

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

Change 498287 merged by jenkins-bot:
[mediawiki/extensions/FundraisingEmailUnsubscribe@master] Fancy variant for opt-in page

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

This is ready to deploy as soon as we get MediaWiki 1.31 back on payments-wiki

OK, this is deployed. An example of the new form:

https://payments.wikimedia.org/index.php/Special:FundraiserSubscribe?e=eeggleston@wikimedia.org&p=optin&v=wle_001

We just need to decide where to put the variant name when it comes in on the backend. A new column in the communications table? Or a whole new table for opt_in metadata, which would have this plus attempted amount?

Awesome @Ejegg! So motivating to have a live link.

• Re: where to put the variant name, and whether we should create a new table for opt_in metadata (including attempted amount) - I hope @CCogdill_WMF or @Pcoombe have smart answers for that!

• It looks to me like I can't properly load the page if I don't include e=something (the email parameter) in the URL. Is that true? Can we set it up to load with or without that URL email parameter?

• Ah snap, the TY page :) Didn't think of that. Can we point people to any URL? Might be simplest to maintain some page on meta wiki or elsewhere.

Thanks so much, @Ejegg, this looks great! My notes are below--each of Sam's items are included so you don't have to hop back and forth:

• Where to put variant name: I like the new table idea, since we want to record extra stuff anyway in some opt-in cases.
• e=foo@foo.com required: The first test I want to run on this page is email vs no email pre-populated. Plus, I think the page needs to work without the email in order for this to meet legal requirements.
• Thank You page: where can we point it--any URL?
• Not finding new record: We tried opting in a new record with the email ewilfong+20190409@trilogyinteractive.com and I am not finding a record for that email in Civi. Is there a latency period?
• No status update for existing record: We tried opting in an existing record that was previously unsubscribed (ccogdill@wikimedia.org) and the unsubscribe status did not change.
• Landing page hits recorded?: On donate wiki, we use landing page impressions as an approximation for email "clicks" (so we don't have to use IBM's clicktracking system). We pull the stats from pgehers.donatewiki_counts. Is it possible for payments to do the same thing?

Thank you again! I'm really excited to get a first test out.

Just a couple initial answers:

• emails with no existing record are tricky - Civi doesn't seem to let us create a contact with no first name or last name.
• the queue consumer runs once every hour, which might explain why I don't see ccogdill in the the logs yet
• the opt-in queue consumer strictly just updates the opt-in custom field, without touching any of the other communication preferences. This means it's possible to be in the quantum superposition of opted in and opted out at the same time! I guess we should update it to clear out any opt_out, do_not_solicit, and do_not_email fields?

I'm pasting two of your items back in here to reply in-line:

• emails with no existing record are tricky - Civi doesn't seem to let us create a contact with no first name or last name.

This could be a sticking point. I think, even if we pre-populate the email field, a user is likely to change the pre-populated value and replace it with a new email address. I'd expect this to happen for at least 20% of users, though that's just a guess.

Would sending the contactID in the URL make any difference?

• the opt-in queue consumer strictly just updates the opt-in custom field, without touching any of the other communication preferences. This means it's possible to be in the quantum superposition of opted in and opted out at the same time! I guess we should update it to clear out any opt_out, do_not_solicit, and do_not_email fields?

Yes, that would be awesome! Though I always forget how do_not_solicit is used and if that's a field MGF uses for some custom preference.

Per T220647 my yubikey access is pending so I haven't been able to check again if the data is appearing differently in the back-end. Either way, I see the below as outstanding items or questions. Would it be good to get on a call to talk through these last details?

1. Need to be able to accept new email addresses: Some donors will want to give us a different email than the one we have on file. If we passed the contactID in the URL, would that help?
2. Page needs to work without pre-filled email address: Per legal requirements, this page has to function if someone hit upon it spontaneously, so it can't be dependent on that email in the URL.
3. Form should update existing communication preferences: Tested with CID 16134285, still opted out. This would be especially for donors who end up entering an email they have previously opted out.
4. Thank you page -- where can it point?: @Pcoombe can you advise on where this should go?
5. Landing page hits recorded?: On donate wiki, we use landing page impressions as an approximation for email "clicks" (so we don't have to use IBM's clicktracking system). We pull the stats from pgehers.donatewiki_counts. Is it possible for payments to do the same thing?

In T218240#5112242, @CCogdill_WMF wrote:

Thank you page -- where can it point?: @Pcoombe can you advise on where this should go?

My view is it should live on payments wiki as well, as part of the extension, so that there's a single place for translations and we're not bouncing users around domains needlessly. If that's not possible though, then we can make something on donatewiki.

Change 504213 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[wikimedia/fundraising/crm@master] Opting in reverses opt-out fields

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

The patch in Monday's gerritbot comment should address point 3.

Contact ID on the URL would definitely be useful to link a record with any new email address the donor adds. We'd want to include the contact_hash as well to make it harder for random ppl to change any contact's email address.

I agree with @Pcoombe that the thank you page should be part of the same extension and live on payments wiki as well.

Great re: point 3! Thanks for plugging away. I have sql access again but am
having trouble figuring out how to read the civicrm_value_1_communication_4
table to actually check if the opt-ins are happening. Which of the ID
fields can I tie back to a contact record? I tried querying where id or
entity_id = 16134285 (my contactID I'm testing on) and I get an empty set
back.

The remaining outstanding questions are below. #2 is a high priority for
us, otherwise the page doesn't meet legal requirements.

1. *Need to be able to accept new email addresses:* Some donors will want to give us a different email than the one we have on file. Sounds like CID / contact_hash would help. Is there anything else we need to do?
2. *Page needs to work without pre-filled email address:* Per legal requirements, this page has to function if someone hit upon it spontaneously, so it can't be dependent on that email in the URL.
3. *Thank you page - next steps?:* Should we get another mockup over to y'all or is this something we can implement ourselves.
4. *Landing page hits recorded?:* On donate wiki, we use landing page impressions as an approximation for email "clicks" (so we don't have to use IBM's clicktracking system). We pull the stats from pgehers.donatewiki_counts. Is it possible for payments to do the same thing?

@Ejegg lots of little details here! Are you free to talk this afternoon or
tomorrow so we can get through these questions?

Talked with Elliott today, he said item #2 above is what is hanging this up. My over-simplified summary: the page was designed to require an email address so he needs to rewrite some of the code to make it work without one.

For TY page: it will be a template on payments wiki, like the main opt-in page. fr-creative can start working on design for this cc @spatton

Also from today, we know that the remind me later email addresses are getting into civi without any more info. @Eileenmcnaughton do you know how that's happening? I'm going to look for CIDs that are good examples of this and reply later.

In case it's useful, here are details about how remind-me-later gets into civi. From the banner, a background POST is made to a URL like this:

https://www.pages04.net/wikimedia/remind/Form?sp_source=B1718_123100_en6C_dsk_p1_lg_dsn_decal4

This is a silverpop endpoint. The value of sp_source is the name of the banner.

Example of form data POSTed to that URL:

Hope this helps!

Notes on technical stuff, mostly from IRC: https://etherpad.wikimedia.org/p/T218240

Thanks for those details, @AndyRussG and @DStrine.

@Ejegg, we've talked about TY page options and our preference would be an inline confirmation in the same container holding the email submission field. Here's a simple example:

Initial form appearance:

Thank you confirmation after successful email submission:

We'll provide the content for the TY block; can you let us know if you foresee any problems w/ this approach?

Sure, that should be fine.

The way we're building the form now, we would post back the whole thing and re-render even though that's the only changed bit. We can do that for starters then work on then work on de-duplicating the rest of the template.

Thanks @Ejegg, I've asked Trilogy to provide a coded version of the page w/ the Thank You block swapped in for the form element.

Hey @Ejegg, how is the work going on your end?

Here's a post-submission TY variant Trilogy created - simple but sufficient.

Change 508477 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Add fancy version of Thank You page for opt-in

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

Change 508477 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Add fancy version of Thank You page for opt-in

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

Change 504213 merged by Ejegg:
[wikimedia/fundraising/crm@master] Opting in reverses opt-out fields

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

@CCogdill_WMF In the case that we get an opt-in that comes in with the contact ID, but the user gives a different email than what we have in civi, should we replace the old email with the one the user entered, or just add the new email alongside the old one?
I can do either way. I'm just not sure what the intended behavior is.

I think we should go with whatever behavior the dedupe process uses--I think it makes the old email secondary and the new one primary? But I'm not sure.

New link: https://payments.wikimedia.org/index.php?title=Special:EmailPreferences/optin&variant=wle_001

Thanks @Ejegg! Still one optimization that should happen: it's currently possible to submit the form without a valid email address, or with no data in the email input field at all. That causes a redirect to an error page that doesn't include any link to return to the repermissioning page.

Could we add validation to the email field, so that no one gets that redirect?

Good catch, Sam! +1 to adding validation.

I tested with an active contact record (my own) and can confirm my opt-in
preferences were updates to "YES"! Woo!

Change 511604 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Basic email validation for opt-in

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

Change 511748 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Add retry link on opt-in error

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

Change 511604 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Basic email validation for opt-in

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

Change 511748 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Add retry link on opt-in error

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

OK @CCogdill_WMF and @spatton , those changes are deployed. There's now some basic client-side validation on submit, and the error page has a retry link. If you want to test the error page, use an almost-valid email address like "test@domain.1". That will get past the front-end validation but the back-end's stricter checking will cause an error. Note that the error page is still not styled for the variant.

Awesome @Ejegg!! Thank you!

I *think* we're ready to test this. @MBeat33 can you do a round of QA and
make sure this looks OK from a DS perspective?

Here's the link! https://payments.wikimedia.org/index.php?title=Special:EmailPreferences/optin&variant=wle_001

This looks great, everyone! I like the red frame around the field for incomplete entries, and the wee jig the Yes button does on mouse over.

@CCogdill_WMF the 'by' attributions for photos 1, 3-5, 8, 10-15 are blank, so we might see questions about that. I might also swap the word created for taken in the blue text box, but apart from those quibbles this looks very cool.

Please give me a heads up before testing and we can watch the Zendesk queue for any questions.

Good catch on the captions, @MBeat33 ! That's a bit mysterious, since the credits for all the pictures are in the source code. It looks like the Cyrillic ones are the ones that get dumped somewhere in the process of rendering the template. Trying to figure it out.

Change 511800 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Mustache flag to use spaces in helper args

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

Doh! Embarrassed I missed that and grateful for your keen eyes, @MBeat33.

@Ejegg <T218240+public+2de24ef6a42d4b7b@phabricator.wikimedia.org>, let us
know if there's anything we can do to help with the captions.

Change 511800 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Mustache flag to use spaces in helper args

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

@MBeat33, @CCogdill_WMF Turns out the problem was names with spaces, not cyrillic characters. I found the template setting that was blocking those and have just pushed a change to production that fixes it. Looking good now as far as I can tell.