Pre-fill the (first of two) subscriber forms

[talgalili]

tl;dr

If a developer bothers using the email url parameter, it's likely because they want the form to be pre-filled. Using the "placeholder" doesn't help the user, and just leads to a bad user experience! This small diff fixes the issue.

Details

When creating a subscriber form we want to allow users to be sent to it after they've pre-filled another form (say, an html form in a sidebar or a pop-up box).

A solution for doing it is to have the a form on some website (say, blog), with something like this (which should be in the docs, BTW. Might be worth adding): (notice the use of the id="email" attribute)

<form  style="width:202px; float:left;" action="https://my-blog.com/phplist/?p=subscribe&id=1" method="post" target="popupwindow" id="email">

<input type="text" style="width:110px"  onclick="if (this.value == 'Your e-mail here') this.value = '';" value='Your e-mail here' name="email"/>
<input type="hidden" value="my_blog" name="uri"/><input type="hidden" name="loc" value="en_US"/><input type="submit" value="Subscribe" />

</form>

When a user filles the form with "[email protected]", they are then sent to the subscriber page, before this current change, they would see the following form. Notice how the email seems to be pre-filled, but actually it is not:

The user would have to now type their email two more times (!), on top of the first time they already typed it.

The reason for this odd behavior is that the form fills the email attribute into the "placeholder" tag, which is a bad practice in general (see here: https://www.smashingmagazine.com/2018/06/placeholder-attribute/). The better solution is to use the 'value' attribute, to give the desired behavior: the user will now need to type their email only one more time.

Notice how now the email is black, and not greyed out:

Related Issue

A similar thing was previously requested here: https://discuss.phplist.org/t/link-to-subscription-page-with-email-or-userid/6808

[michield]

Interesting. But if the email is not provided on the GET, wouldn't we want to keep the placeholder function? In various places in that case it would be annoying to have to remove the example address.

[talgalili]

Hey @michield , Right now, if the email is not provided in GET, the placeholder will be empty (which is also the behavior after this diff). So there is no change in behavior for that case. You could potentially add a

placeholder = "[email protected]"

Or something like that. Feel free to revise the diff in that spirit (as long as value="%s", I think the placeholder could be some example email).

WDYT?

[michield]

Ok, sounds good. We can consider that a different change and this PR should be fine to approve.

Would you mind signing the CLA, so we can process it? Thanks

Thanks for a very clear explanation of the situation by the way, that's brilliant.

[talgalili]

Signed:

Thanks @michield :)

[michield]

Great, marking ready to merge

@bramley I think this is a good change. Any other considerations?

[bramley]

This change will affect the preferences page. Currently the email field shows an obfuscated email address as a placeholder. The user just needs to enter their email address. With this change the obfuscated email address is the value which then needs to be manually removed before entering the email address.

An earlier change went from using a value attribute to placeholder, see https://github.com/phpList/phplist3/pull/292 and the Mantis issue for an explanation why.

[talgalili]

Interesting @bramley . How do you think it should be addressed then? The current behavior is (IMHO) a bug for the subscriber page. It makes no sense that we'll send a subscriber to the page after they filled their email, only to have them re-fill it 2 more times. Maybe have different behavior for the subscriber page vs the other page? WDY?T

[michield]

I guess making it dependent on the existence of the email GET parameter would work?

if (!empty($_GET['email'] ))

that kind of thing.

[bramley]

I don't know the reason for there being an email GET parameter at all. Looking at the history it appears to once have been an option for the preferences page as an alternative to using a uid to identify the subscriber but was removed https://github.com/phpList/phplist3/issues/405

If you simply want to let someone subscribe from your own web site then the AJAX approach does that. https://www.phplist.org/manual/books/phplist-manual/page/creating-a-subscribe-page#bkmrk-add-an-ajax-subscrib

[talgalili]

@bramley , Thanks for the context and reference. The AJAX approach makes sense if I wanted to have the subscribe page be embedded in another website (which is one use-case).

But why force users to use AJAX in their web-page instead of also giving them a simple form (with action) solution? Especially given that it can relatively easily be supported via something like an email parameter? (given some extra if statement, as @michield proposed). Wouldn't that be simpler to implement for the user, and less prune to lead to mistakes/debugging? (at least that's what I think it would be for me)

[bramley]

It wasn't clear to me what exactly you are trying to achieve. If your proposal does what you need, then that's fine.

[talgalili]

@bramley - thanks. @michield - do you think we can accept this diff as is, or should we add the if statement you proposed? (if so, could you please help with the revision of this diff with the if you proposed?)

[michield]

I do think we want it changed before accepting the PR, otherwise it'll be a regression on the changes from #292 which is a bad UX for the preferences page.

You can simply push more commits to your branch and it will update your PR.

[michield]

Due to #901 Github closed this PR.