Background: our company is looking for a self-hosted event registration system with a double opt-in email registration. Unfortunately, it seems this kind of software does simply not exist. Thats why I am giving phplist a try. We are primarily targeting the subscribe pages feature of phplist, to set up multiple “registration” forms.
Currently I am stuck at the problem, that I can not create a subscribe page for a private list in phplist. It is not an option to make every list public, as we do not want the list to be seen on the public front page.
So my primary question is: Is it possible to
a) create a subscribe page for a private list? or…
b) hide the public front page which lists every public list…?
Are there any plugins or options I might not have seen so far, which might help realizing this?
For b, rather than give or use a link to your public front page, use the link(s) from that page, to the individual lists. For example, look at your pfp and right click over one of the links, that should give you the option to save link or copy link, then use that as the link to your list.
If a link is not visible on your pfp, then using the link as I describe above, change the list id to that of your hidden subscribe page using the ID shown against your list in the admin area.
Thanks for your reply, Dragonrider. If I understand you correctly, you are telling me to set the list to public, attach it to a subscribe page (which cannot be hidden), then just distribute the direct link to the subscribe page, and don’t tell our customers about the public front page.
Unfortunately, “not telling” anyone about the public front page is not a very safe approach. Even if I distribute the subscription page “mydomain.de/p=subscribe&id=2” everyone might be so clever to just try “mydomain.de/” which results to show up every kind of public list/page…
All subscribe pages are public, so your idea of having a subscribe page for a private list is not really any different to that for a public list. Someone can guess the url and try to subscribe.
Without knowing more about what you are trying to do it is difficult to see how phplist can meet your requirements. Have you looked at CiviCRM, which has an Event module?
@dunanc You are correct, the id’s are not randomly generated, so guessing the url is always an option to access the list. So, it looks like phplist can not meet my requirements.
Your Google-fu is much stronger than mine, it’s the first time I read about CiviCRM. I will definitely take a look at it, as it seems to fit into my requirements at the first glance. Thanks a lot for pointing me to it
More is to the point if someone was trying to guess a url and failed, becuase there was no subscribe page, they would see the main page, which would have the list on.
Why is it that you want the page to be “private?” - Does this not just limit sign ups to your event?
@anna: Sometimes we need to invite only a very specific group of people, e.g. specific experts. In this case we send out invitation links (to the registration form page) to just this group.
Have you considered using .htaccess to require a password for your subscribe page and send the password with the invitation email? This way only those invited will be able to get through to subscribe.
This page over at About Tech gives a simple how-do password protect a single page.
.htaccess might be an option, although I am not an rewrite rule expert. Until now, I even did not know that it is possible to password protect specific sites based only on their GET url parameters. (e.g. &id=5)
Unfortunately I would not consider this a very user friendly solution. It’s hard enough to get people to sign up to your boring events. I am afraid adding another hurdle (username & password) might be a bad idea. Also, there are specific cases, when we publish event registration Links to flyers and other print material - a password would not be very attractive in this scenario.
btw: Our current (expiring) solution is using randomly generated 6 digit IDs for every event form (e.g. http://domain.com/638201), which fits our needs in terms of “security”, but I understand the password approach for a “real” security layer.
I do not want to waste your time anymore. For me it is quite clear that phplist does not fit in our use case for event registration. If you guys do not have anymore curious questions about our use case, feel free to close this thread. Thanks again everyone for participating in this discussion
I am afraid adding another hurdle (username & password) might be a bad idea. Also, there are specific cases, when we publish event registration Links to flyers and other print material - a password would not be very attractive in this scenario.