Need to require form entry to view individual ProNews post
Permalink
Hi, I'm a developer using concrete5 and I'm intermediate to advanced in both html and css but have only a beginner's understanding of php. I have a specific problem I need solved regarding a form submission. The site is located athttp://www.eclinicalsol.com for reference, and I have a test server I'm editing on athttp://www.nomad-sites.com to make new edits.
I'm using the ProNews add-on and need to make it so that when someone clicks on a WhitePaper entry athttp://www.eclinicalsol.com/insights/white-papers/... they are sent to a form which directs to that specific whitepaper entry upon completion. I currently have it set up so that it goes back to another whitepaper list which the user can then click through to the specific whitepaper. The problem is that the client is rightfully worried about losing people on clicks.
An additional problem is that once there are multiple whitepapers it will be redundant if the same user has to fill out a form every time they want to view another whitepaper entry.
ProNews correctly said that this was outside of the scope of support (had to try) but I did get some tips from them, which can be viewed in a previous forum topic I started awhile ago athttp://www.concrete5.org/index.php?cID=575731&editmode=... .
If you feel that you can help me with this I am willing to pay for up to 2 hours of your time. Please let me know if you're interested and what your hourly rate is. Thanks ahead of time
I'm using the ProNews add-on and need to make it so that when someone clicks on a WhitePaper entry athttp://www.eclinicalsol.com/insights/white-papers/... they are sent to a form which directs to that specific whitepaper entry upon completion. I currently have it set up so that it goes back to another whitepaper list which the user can then click through to the specific whitepaper. The problem is that the client is rightfully worried about losing people on clicks.
An additional problem is that once there are multiple whitepapers it will be redundant if the same user has to fill out a form every time they want to view another whitepaper entry.
ProNews correctly said that this was outside of the scope of support (had to try) but I did get some tips from them, which can be viewed in a previous forum topic I started awhile ago athttp://www.concrete5.org/index.php?cID=575731&editmode=... .
If you feel that you can help me with this I am willing to pay for up to 2 hours of your time. Please let me know if you're interested and what your hourly rate is. Thanks ahead of time
The client doesn't want the user to have to create a user account to fill out the form and view the content. Do you know if there is a way to automatically login someone if they are viewing the site without them having to create a user account?
Some time ago I wrote the code to create temporal users. Every time a guest visited a given page Concrete5 logged it in automatically. It was transparent for the user. When the user wanted to check out, Concrete5 reassigned its temporal user to a real user. Temporal users were deleted by the built-in aging system
Would this process work and be acceptable by the client?
1) 1st time user clicks a link to an article.
2) The article landing page checks for a cookie to see if the user has ever filled out the form.
3) If not, it send them back to the form.
4) Form sets a cookie and sends them back to the desired article page.
If that sounds right, I'll give it some thought.
1) 1st time user clicks a link to an article.
2) The article landing page checks for a cookie to see if the user has ever filled out the form.
3) If not, it send them back to the form.
4) Form sets a cookie and sends them back to the desired article page.
If that sounds right, I'll give it some thought.
This is what I'm trying to do so long as there isn't a long delay when verifying the cookie and redirecting to the form page. The way ProNews suggested to do this was actually to have a single_page with the form which would verify the cookie and the user through to the article/news post. I'm not sure if that is more, or less, complicated than what you suggested.
Private message me if you're interested in helping out with this. I'm also generally looking for a contact with more expertise in Concrete5 than I currently have for special client requests such as this if you're keen.
Private message me if you're interested in helping out with this. I'm also generally looking for a contact with more expertise in Concrete5 than I currently have for special client requests such as this if you're keen.
I'm going to try to build 2 blocks tonight. One that sets a cookie on a page and another one that checks for a cookie. I'll see how that goes. This seems like such a simple, desirable feature that I'm sure others would appreciate a solution.
That's great. Thanks so much. I was looking for an add-on that at least creates cookies, let alone one that detects them, with no luck. I'm sure other C5 developers could use a solution for this. Even so, I'm unclear how to modify the ProNews add-on to redirect once it detects the cookie.
This is where I wish we could do nestable blocks. We could have a "show if cookie exists" block.
Best,
James SHANNON
Sent from my phone
> On 9 janv. 2014, at 15:30, concrete5 Community <discussions@concretecms.com> wrote:
Best,
James SHANNON
Sent from my phone
> On 9 janv. 2014, at 15:30, concrete5 Community <discussions@concretecms.com> wrote:
Ah, the Holy Grail of concrete5.
You could quickly implement 'show block if cookie' with my Universal Content Puller and Magic Data addons.
UCP has an option to only show a stack (or other pulled content) if a Magic Data expression returns true.
The only part of the equation missing is a Magic Data symbol to check the cookie - about 10 minutes to code that up in php.
(I do have a series of request info symbols on my roadmap, just not got round to it yet)
Having said that, for a one off solution you could hack the cookie checking code into a custom block view template in the same time.
All depends if its a one off or a generic solution that is desired.
UCP has an option to only show a stack (or other pulled content) if a Magic Data expression returns true.
The only part of the equation missing is a Magic Data symbol to check the cookie - about 10 minutes to code that up in php.
(I do have a series of request info symbols on my roadmap, just not got round to it yet)
Having said that, for a one off solution you could hack the cookie checking code into a custom block view template in the same time.
All depends if its a one off or a generic solution that is desired.
I just don't think I have the expertise to do what you're describing at this point. I've made custom block views with limited php knowledge, but I'm just not there yet.
It'd really just be a one off for this one circumstance on the site. I just don't really know where to start with cookies and creating a custom block that will perform this action. Is anyone able to help me with this or can anyone point me to some documentation that I might be able to learn how to do this?
I guess the important question is what to do if the user shows up on a different browser or clears their cache, or the cookie just disappears (after months or years).
In Mhawke's proposal, the previous form entry is gone (as far as the user is concerned), and they'd have to complete a new one. In the other proposal, the user would have to look in their email or do a password reset request and figure out how to login.
I recommend the former option.
The latter is what my membership addon does (creates the account, logs them in automatically), and it's a bit of a pain in the ass for both the developer (data validation is harder, what to do if the email address already exists), but I think this makes sense for memberships, but not necessarily for what your client is trying to do.
In Mhawke's proposal, the previous form entry is gone (as far as the user is concerned), and they'd have to complete a new one. In the other proposal, the user would have to look in their email or do a password reset request and figure out how to login.
I recommend the former option.
The latter is what my membership addon does (creates the account, logs them in automatically), and it's a bit of a pain in the ass for both the developer (data validation is harder, what to do if the email address already exists), but I think this makes sense for memberships, but not necessarily for what your client is trying to do.
This is a casual/formal discussion. 'Casual' has the consequences inherent in cookies and 'Formal' has the consequences inherent in registration systems.
I think most users are aware of the cookie issue and would expect the site to ask them to fill out the form again if they tried to access it from another computer. I see no problem spelling this out on the form such as: "This form uses browser cookies to give you temporary access to the news articles on this specific computer... etc, etc"
The bigger question is: What does the client want to do with the form information? If they want to build an external contact list in Excel then the casual method is fine but if they want to eventually use this information within the walls on concrete5 add-ons, they better get those pseudo-members into the database, even if it's only their first name, last name and email address at first.
As anyone who builds databases can tell you, you have to know what reports are going to be generated from the data before you can even begin to develop a strategy for collecting the data.
I think most users are aware of the cookie issue and would expect the site to ask them to fill out the form again if they tried to access it from another computer. I see no problem spelling this out on the form such as: "This form uses browser cookies to give you temporary access to the news articles on this specific computer... etc, etc"
The bigger question is: What does the client want to do with the form information? If they want to build an external contact list in Excel then the casual method is fine but if they want to eventually use this information within the walls on concrete5 add-ons, they better get those pseudo-members into the database, even if it's only their first name, last name and email address at first.
As anyone who builds databases can tell you, you have to know what reports are going to be generated from the data before you can even begin to develop a strategy for collecting the data.
Yes precisely. It is meant to be more of a "casual" interaction rather than actually creating a user account and all that. If it were the more "formal" login approach I'd know what to do, but I have very little experience with cookies so I'm at a loss.
If it's casual then the less info collected the better. Everyone knows that when a site asks for your email address then they are going to get spammed so this brings up a bunch of other requirements (both legal and ethical) regarding opt-out procedures. Is the client up to that?
There are several forms on the site and the client is actually a marketing company that handles several sites email campaigns, social media, etc. so I'm assuming they understand what's entailed. They've also run this all through their lawyers and yada yada so I figure they've covered their bases.
block. You could add any data you wanted to collect in the user
registration, then once they are logged in permissions could be set so
they view your white papers.
On 1/8/14, 6:43 AM, concrete5 Community wrote: