Move most form elements to results page

[graphiclunarkid]

To encourage people to interact, and so that they can see the results for their URL before deciding whether to sign up for email alerts, we want to move all but the URL submission box from the front page to the thankyou page.

The URL box should be repeated and pre-populated on the thankyou page.

Current:

Desired:

[graphiclunarkid]

Please don't take my GIMP hatchet-job as being indicative of style or layout! I was just trying to show which elements should appear on which screen.

There should be a pre-populated URL field on the thankyou.html page but I forgot to add it.

For goodness sake don't give me any graphic design jobs to do :wink:

[graphiclunarkid]

We should also remove the suggestion that we're going to email a one-off copy of the results to the submitter if they give us their email address. We discussed this and decided it doesn't add much value now that we have near-instant display of results on the thankyou page. This will become even if we implement #25.

The email options we want are:

• Consent to be contacted if ORG thinks this report is particularly juicy
• Subscribe to regular reports about this URL
• Join ORG's mailing list

[webal]

I've moved the forms about, I've not had a chance to check them but I think it should be ok.

I've uploaded to staging (and updated repo) - wasn't sure which to use.

I commented out the HTML code in staging for the form as I didn't want to accidentally delete something as the form stuff doesn't quite match the repo so just delete this once you're happy with the form.

[graphiclunarkid]

Thanks @webal!

This could maybe do with a bit of testing by @mkillock if he gets chance. We also need to fix up the layout of the thankyou page to cope with its increased information load - but this can wait until we're working on new.blocked if you like. I see no reason to start duplicating effort at this stage!

I believe once @jimkillock has done a second migration to the live server we'll only need to change things on new.blocked. Both the staging server and the repo will be dormant. My guess is we'll copy the running version of the live site back to staging and the repo at some future point.

[mkillock]

I've made a minor change to the Formit call on the home page because we don't need to do email validation there because there is no email field. The commented out HTML code can go, I reckon - this is now in Chunks/campaign sites/blocking/blocked_home_page_content

[mkillock]

Minor comment - we appear to have lost the table headers in the results

[mkillock]

Do we want to re-submit the url on the thank-you page? I guess 'yes' because we then create a copy of the form data in the API db -right?

[mkillock]

OK! I have got the form working on the thanks page. However, because we put a check on that page to redirect to the home page if it was visited without first submitting a url, when then second form with extra details was filled in correctly, it was redirecting to the home page because FormIt clears the form data and this passes the check we have in place to check for non-prior-submission of URL from home page. Therefore.... I've had to add a 2nd redirect page which now needs content! Page ID 7482

[mkillock]

Also I added in a hidden field that pre-populates the previously submitted URL from the home page, so there is a URL to submit to the API from the form.

[graphiclunarkid]

@pamcowburn can help with content for page ID 7482.

I have made some changes to the layout and content of the thankyou page (ID 7451), including:

• Rearrange form elements on the page.
• Remove references to emailing a one-off copy of results to the user.
• Include permalink to results for this URL.
• Minor content edits.

I'm sure Pam will want to look more closely at the content of this page in due course but I don't think we should include that in this issue.

@webal - can you figure out how to restore the column headings?

[graphiclunarkid]

@mkillock Yes, as a minimum we want to resubmit the URL, for the reason you state.

In future we could have the API return a request ID from the front page so that we can ALTER that request from the thankyou page if the user provides further details. The advantage would be that we would avoid overwriting the "last blocked" value for filtered sites by submitting a second check immediately after the first (in many cases).

[graphiclunarkid]

Hmm. Refreshing the thankyou page now redirects to the homepage instead of refreshing the results...

[graphiclunarkid]

I've deleted the commented-out form elements from the blocked_home_page_content chunk.

[mkillock]

As for the refreshing of the thankyou page taking to homepage, not sure what we can do about that. The form works like this:

1. Home page form, url saved in cookie, redirects to thankyou page
2. thankyou uses formitretriever which gets url from cookie, if present. If no url from that mechanism, AND no url from $_GET then redirect to home page

So if someone refreshes the thankyou page, the cookie will have been deleted by formitretriever and the $_GET variable was never set from the homepage.

The only way around this that I can see is somehow redirecting to the thanks page from the homepage by having a redirect url such as:

new.blocked.org.uk/thankyou?url=http://www.example.com

[graphiclunarkid]

I guess since the permalinks will be pretty visible anyway it wouldn't do any harm to GET them explicitly from the homepage. Would there be some juggling of the request order to do? I'm wondering exactly when in the sequence of events we can reference the URL value and boost it into the redirect parameter...

[mkillock]

OK, I'll have a go at changing the thankyou page to use the GET variable. Are we still wanting the thankyou page and results page to be the same thing?

[mkillock]

Oh, I see your point. Not sure it will work, let me investigate when I have time later. I'm not sure whether the url can be passed to a redirect url that changes after the form is submitted! Doesn't sound plausible

[mkillock]

Curiosity got better of me - you are right @graphiclunarkid - we can't pass a GET variable from a submitted form to the redirect page, or at least FormIt doesn't seem to give us that option. So that seems to leave us with:

1. Leaving the refresh of thankyou page redirecting to homepage, because we want visits to that page without submitting the form to go to home page
2. Letting people reload the page, but leave out the redirect to homepage
3. Kludge in a page reload that includes the ?url=xxx.yyy in the URL. This would mean the thankyou page redirects to itself if FormItRetriever has set the url placeholder, otherwise leaving it alone

How does that sound? Not sure if any of this fits in with your other plans for these forms, to be honest?

[mkillock]

Actually - on my system (Firefox) I can reload the thankyou page without it redirecting to homepage after a homepage submission. Why is that? Has one or both of us got unusual cookie settings?

[graphiclunarkid]

I'm using Chromium. It could have been a weird cookie thing, since I can now refresh the thankyou page and have it reload the results, rather than redirecting back to the home page. I guess we can close this therefore. If it reappears we can open a bug instead.