[ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

maniqui · 2008-04-15 13:57:39

Hi Bloke,

interesting ideas. I will be working in something similar soon, so your approach will be really helpful, if it works.
Have you read this one? http://www.benbruce.com/postmanual/default-list-when-subscribing

About the PHP warnings, it’s a known issue, and the “fix” is to set the site to Live mode, as you did.

Let’s wait for Ben, he always have some good ideas to share.

Bloke · 2008-04-15 14:28:14

maniqui wrote:

Have you read this one? http://www.benbruce.com/postmanual/default-list-when-subscribing

Aha! Yes, I have but I didn’t figure out I could use it, d’oh! Thanks for the tip :-)

So I can confirm that using name="zemSubscriberLists" works for the ‘automatic’ (secret) case. Begs the question what zemDoSubscribe is for; the docs mention it quite a bit so it must be important somewhere!

The result with the checkbox, however, is a double-edged sword: if I also change my checkbox to name="zemSubscriberLists" then it does indeed add the person to a list. Unfortunately, the list is called “Yes” because that’s what the checkbox result is. I can’t see an option in zem_contact_checkbox that would allow me to specify the name of the list to associate the checkbox with, but perhaps I’m missing something.

The second problem with this approach is that it seems to then “forget” the secret subscriber list name. Perhaps Postmaster can only subscribe one list at a time? Or maybe the aggregator is the key, but I haven’t got my head round it yet.

I briefly wondered if I could maybe insert the course code into a tag attribute as well as the ‘newsletter’ text (like the multiple list example in the link you gave me). But then, if the checkbox is not checked, they would not be subscribed to either list :-(

The only way I can think of doing it is using a secret option list and adding a jQuery “toggler” function on the checkbox such that when it is checked, “newsletter” is added to the secret tag and when it is unchecked it is removed. Not sure if that would work. As you say, I’ll wait to see if Ben has any pearls of wisdom.

Thanks for the pointers so far, at least I’m getting somewhere now…

jdykast · 2008-04-15 14:35:58

I ran into the same PHP problems but with a bit of work I was able to squash those bugs. The first thing I did was to replace $page_url = page_url(); with $page_url = $_SERVER['REQUEST_URI']; where ever it’s found. That takes care of the “Missing argument 1 for page_url()” error.

Adding $search_results = 0; before the line while ($a = nextRow($gesh)) { cleans up another error (which one I don’t remember).

I also swapped this line:

echo '<p>' . bab_pm_preferences($column) . '</p><input type="text" name="' . $bab_prefix . $bab_input_name . '" value="' . $row[$column] . '" class="bab_pm_input">';

for these lines:

$colVal = '<p>' . bab_pm_preferences($column) . '</p><input type="text" name="' . $bab_prefix . $bab_input_name . '"';
$colVal .= isset($row[$column]) ? ' value="' . $row[$column] . '"' : ' value=""';
$colVal .= ' class="bab_pm_input">';
echo $colVal;

I think those fixes cleared up all the PHP errors Postmaster was causing on my server. It’s been a while since I made those changes so my memory may be a bit off but I think the information is accurate. I hope that helps and if there is any problems with the code I’d love the feedback so I can make the appropriate fixes.

Bloke · 2008-04-15 15:15:02

Thanks jdykast. I just made those changes and the errors have gone. Nice one!

I had to do one extra thing (#2 in the list here) and I made a couple of small adjustments to your original methods for no real reason other than I prefer the shorter syntax; yours would work just as well. For the record, here’s what I did:

1) Replaced: page_url() with page_url(array()) wherever it occurred in both Postmaster Library and the plugin.

2) Added $page_url = page_url(array()); as the first line to the bab_pm_lists() function

3) Added $search_results = 0; exactly like you did, before the first while ($a = nextRow($gesh)) { in the bab_pm_subscribers() function

4) In the bab_pm_makeform() function, replaced:

echo '<p>' . bab_pm_preferences($column) . '</p><input type="text" name="' . $bab_prefix . $bab_input_name . '" value="' . $row[$column] . '" class="bab_pm_input">';

With:

echo '<p>' . bab_pm_preferences($column) . '</p><input type="text" name="' . $bab_prefix . $bab_input_name . '" value="' . ((isset($row[$column])) ? $row[$column] : '') . '" class="bab_pm_input">';

Everything seems to have cleared up now, though I’ve not tested it extensively. Thanks for the help; much appreciated.

Last edited by Bloke (2008-04-15 15:16:58)

jdykast · 2008-04-15 15:25:36

I like the way you were able to make TXP’s page_url() function work. I wasn’t able to figure out what I needed to add to make happy. I even looked at its code but was still too dense to figure it out. Thanks for noting the fixed item in number 2—I missed that as I was looking through the changes I made.

maniqui · 2008-04-15 15:55:00

Bloke wrote:

The only way I can think of doing it is using a secret option list and adding a jQuery “toggler” function on the checkbox such that when it is checked, “newsletter” is added to the secret tag and when it is unchecked it is removed. Not sure if that would work. As you say, I’ll wait to see if Ben has any pearls of wisdom.

The problem with this approach is that if you take a look at the source code on the page where the form is placed, there isn’t any secret/hidden input tag with the values for the list.
Just for curiosity, how does this works? I mean, if the values aren’t there (in the rendered form), how does ZCR/PM knows where to subscribe the visitor?
I suppose those “zem_contact_nonce” or “zem_contact_form_id” weird values refer to a temporary form temporary saved somewhere in the database and that is how the magic works.

I’m feeling more ignorant each time I want to discover how things (programming) works.

Bloke · 2008-04-15 16:13:19

maniqui wrote:

The problem with this approach is that if you take a look at the source code on the page where the form is placed, there isn’t any secret/hidden input tag with the values for the list.

Pants, you’re exactly right… I’d forgotten they truly are secret! :-D Hmmm, back to the drawing board… or I could perhaps hard-code a standard HTML input type="hidden" element in, since I don’t really need it to be secret?

how does ZCR/PM knows where to subscribe the visitor? I suppose those “zem_contact_nonce” or “zem_contact_form_id” weird values refer to a temporary form…

I believe you are right; the nonce or id must either link back to the database to retrieve the temporarily stored values (stored until the form expires after 10 mins I guess), or those values will be an encoded version of the hidden values that are read back when the form is submitted. I’m not sure which it is, I’ve not looked at the code for years.

I’m feeling more ignorant each time I want to discover how things (programming) works.

Hehehe, when it comes to ZCR/PM, you’re not the only one. It’s all clever stuff and I don’t get half of it!

Last edited by Bloke (2008-04-15 16:15:22)

maniqui · 2008-04-15 16:23:29

Pants, you’re exactly right… I’d forgotten they truly are secret! :-D Hmmm, back to the drawing board… or I could perhaps hard-code a standard HTML input type=“hidden” element in, since I don’t really need it to be secret?

You will have to test if that approach works (Ben? are you there?) because if you read my comment here I asked Ben to change the documentation. If I’m not wrong, in previous versions of PM, an input type="hidden" was used for the task. Then Ben discovered how to do some magic (¿sanitize?) with ZCR and so, he changed the way to do the task.

Gocom · 2008-04-15 16:24:23

maniqui wrote:

I suppose those “zem_contact_nonce” or “zem_contact_form_id” weird values refer to a temporary form temporary saved somewhere in the database and that is how the magic works.

Hehe, we don’t need any seeable HTML elements or values to move data :) Also, using (X)HTML to send data is insecure, therefor basic transfers must be serialized, cleaned and keep hidden. Same like putting secret auth code to hidden input (<input type="hidden" />) – it isn’t secure as you can modify the HTML the way you want, like bot can. But if we make it with “real” programmin way, then it’s much more secure, like we can do it with PHP.

Nonce is TXP build-in function. It prevents posting the form from somewhere else than from the correct place, your site, as it’s generated secret value that is stored in the db for some time. If it differs from the HTML form’s value, meaning those values differ, secret not nonce etc, then the form can not be send. Preview and that nonce is the key of TXP. With out it we would die. Really, die. It’s like bird with out wings in world of comments.

PS. To make sure: Don’t never store anything important in cookies nor hidden fields. Never.

Bloke · 2008-04-15 16:45:20

maniqui wrote:

You will have to test if that approach works

I’ll give it a go sometime, thanks for the heads up.

Since the data in this case is not that critical (assuming Postmaster accepts traditional hidden elements) it might work because I don’t really care if a bot tries to subscribe using a bogus hidden value. If the List doesn’t exist I won’t send stuff to it and can harvest out any (hopefully only a few) fake submissions later.

Plus I’m covered with the nonce value, and also pap_contact_cleaner, and maybe a little trickery of my own if those aren’t enough.

As an interesting side note, it seems that I can subscribe to a List that doesn’t exist (e.g. I don’t have a list called “Yes” but the checkbox submitted that as the name of the list and the person was added to the Subscribers page with the ‘List’ column showing as “Yes”). Does anyone know if there’s a way to reject any submissions to lists that have not been already set up on the server? (sorry if this has been covered before)

jdykast · 2008-04-16 12:49:13

The function used to add a subscriber (bab_pm_zemcontact_submit) doesn’t do any checks to ensure the list actually exists. Without updating the code there is no way to prevent what you described. It should be pretty easy to ensure a list actually exists before allowing the subscription (maybe by using something like safe_count($listsTable, list=incomingList) > 0). (The variables in the code sample need to be changed, of course).

Bloke · 2008-04-18 12:38:25

OK, I got a bit further but it required ‘fixing’ the code a little. In the end I went with the Aggregator function. Since it is not possible to assign a value attribute to a ZCR checkbox (I don’t think), what I have done is add the Seminar Code as a <txp:zem_contact_secret /> and then added a manually-created checkbox like this within my ZCR form:

<input type="checkbox" id="newsletter" name="zemSubscriberAggregate[]"
     class="zemCheckbox" value="newsletter" />
<label for="newsletter" class="zemCheckbox">Subscribe to the newsletter</label>

Of course, this checkbox does not get sent to PM because it is not “known” as an official ZCR item.

I looked through the code and found the aggregator part. I was a trifle confused because it seems to create something called $field and then not use it anywhere. Perhaps it’s vital and I shouldn’t have killed it, but I removed it for now. It also, by default, empties out any other subscriber lists set by (in this case) the secret value. So I changed the function to append the values instead:

$field = gps(bab_pm_preferences('aggregate_field'));
if ($field) {
	foreach ($field as $item) {
		 $zemSubscriberLists .= (($zemSubscriberLists=='') ? '' : ' ') .$item;
	}
}

That works a treat (hope it doesn’t break anything else) and I think it’ll work with the ‘official’ ZCR checkboxes too, but I’m not sure.

So I can now ‘silently’ subscribe a user to one or more lists and also allow them the option of subscribing to any number of others via checkboxes. Hurrah!

Now comes some more fun: how do I allow them to unsubscribe from more than one list at once? As far as I can tell, each list has one and only one unsubscribe link. And it has to be unique, right?

See, when someone subscribes using my form, they are added to two lists, the thanks_form says they are added to both and if they want to unsubscribe, they can visit a standard link (site.com/unsubscribe). There is no e-mail sent out (I don’t think, I’m using fake e-mail addresses right now so I don’t clog up my inbox!)

On the unsubscribe page I would like to do one of two things:

list all available lists (both List code & description) with checkboxes next to each so they can tick the ones they want to be removed from
allow them to enter their e-mail address, submit that which will then fetch only their subscribed lists along with checkboxes that allow them to unsubscribe from one or more of them

The 2nd option is because I can see the day when we have quite a few seminars and it might get a little unwieldy to list them all; I’d rather only show the ones any particular person is currently subscribed to.

Now I don’t think the code is geared up for this way of working. I’ve tried bab_pm_data but I can’t find a way of specifying which list it refers to. I tried a cheat using sed_pcf to hold all the current lists in a custom field in the Unsubscribe article, then used sed_pcf_for_each_value to iterate over them and display a checkbox for each List, but there is no way of grabbing the List name and its description. Plus, when it’s submitted nothing happens.

If anyone has any clues about how I can a) hack it to do that, b) offer something similar using some devious technique(s) then please let me know. Thanks!

Textpattern CMS

Textpattern CMS support forum

#109 2008-04-15 13:57:39

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#110 2008-04-15 14:28:14

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#111 2008-04-15 14:35:58

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#112 2008-04-15 15:15:02

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#113 2008-04-15 15:25:36

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#114 2008-04-15 15:55:00

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#115 2008-04-15 16:13:19

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#116 2008-04-15 16:23:29

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#117 2008-04-15 16:24:23

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#118 2008-04-15 16:45:20

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#119 2008-04-16 12:49:13

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

#120 2008-04-18 12:38:25

Re: [ARCHIVED] Postmaster (0.4.4) -A simple newsletter manager

Board footer