Mark Orie

The selection can be done in SQL using cases. It works for me like this:

[Code moderated as per the Forum Rules. Please use the pastebin]

The last WHERE statement excludes two testing accounts.

It happend in the 0.83 release. the latetst version in the trunk (which i upgraded to afterwards) is fine.

The users involved found no problem with it and took the email as a token of involvedness on my account, so no harm done whatsoever

Happy Newyear!

(although they can delete their profiles later)

I checked. They can not (only I can, as administrator). Relieved, cause al the metadata about the petition would disappear if the user would be removed as user.

Hi John,

tested everything and almost all of it works now. 1 issue I do not know how to handle yet:

• When I tested, I did not get a password e-mail. Maybe because I disabled “users can register” in WP to force people to only register by signing the petition. You mentioned that the welcome message might contain the password, but how do I achieve that? Is {password} possible, which would be replaced by a newly generated user password?

furthermore, there are some interesting points. Not problems, but points of attention

• In “user profile” view, only profiles that have all fields filed are shown. fields may be empty, but is not all the fields are mentioned in the usermeta, the user will not show. This is important to know for all those who update their petition to include a new field, since it means they have to at least edit-save all of the exsisting users. Maybe a user could show as soon as action=sign, with e-mail as a key. missing fields could than be set to blank
• It seems label is used to define how to display the field but also to define the fieldname in wp_usermeta. I did expect the latter to be named as the field is, i.e. {field label=showname save=usermeta} would result in displaying “Showname” and saving the input as “field” in wp_usermeta.
• previous remark also means that, at the moment, a field which is set to save=usermeta but has no label set, will not be saved. Took me a while to fugure that one out, so maybe it should be mentioned in documentation
• Simple CRM does not know how to handle checkboxes. I posted a suggestion to its developer to include them

Having used the new configuration, your anonimity solution seems a specific case of coupling any checkbox to hide a field if checked. I could imagine a display format as mentioned before, like this:

[ecampaign class=show]
{name hide=checkbox1}{function }{organisation}
[/ecampaign]

which would introduce an if-loop on displaying the name, based on the value of checkbox1. Don’t know if that poses serious coding chalenges or not.

For my site, I maintain 2 views (manually, now):

• a list of subscribers: name, function, organisation
• a count of subscribers per organisation: organisation, count

I ask subscribers for name, email, function and organisation. I use the 2 checkboxes for “do not show my name” and “do not show my function”.

on subscriptions:
John Smith; john@smith.com; operator; Hellothere inc; 0;0
Mike Turner; mike@turner.org; chairman, BraveWorld GmbH; 1;1
Jake Jameson; Jake@jameson.net; CEO; Hellothere Inc

I should get on the subscribers page
John Smith; operator; Hellothere inc
[hidden]; [hidden]; BraveWorld GmbH
[hidden]; CEO; Hellothere Inc

On the organisation page
Hellothere Inc; 2
BraveWorld GmbH; 1

see it in action on http://www.zorgwaarde.org/?page_id=81 and http://www.zorgwaarde.org/?page_id=88 (I have made a distiction on the organisation page at the moment, but it is not important

I imagined something like

[ecampaign class=show]
{name}{function}{organisation}
[/ecampaign]

to do the trick, where {function} could be replaced with something like {usermeta field=function} if necessary.

I guess the anonymity marker would have to be stored with the other parameters. For my specific needs I would want to control which fields a subscriber could set to anonymous (because I always need to always show organisation for strategic purposes, the subscribers sympathise but their organisations are the ones are the ones that participate actively), but that may be nitpicking and as long as they are counted in the totals would not even be a real issue come to think of it.

The generic thing I mentioned (something that puts…) is probably just my lack of coding knowledge. I sounded simple to have something that would take something like

[tableshow]
{wp_ecampaign_log select=state;sign show=name;address;checkbox1}
[/tableshow]

to display the requested data on a page in a table. It would not serve all of my needs (no anonimity; data is going to be spread across multiple tables; I didn’t take into account the way the usermeta data is stored), but I looked for it as a starting point.

Hope this is specific enough

John,
Thanks for the reply.

Custom fields:
You are right, I would want to save fields in seperate columns. I could immagine something along the lines of the labels of the checkboxes: two or three colums named “custom1” etc, specifically named by an atribute in the form where the field is added. This would be universal and at the same time offer flexibility (I assume it is the specificness of the fields that bothers you, not adding another colum to the table. It means you could even use the fields differently depending on what petition you are showing (since the atributes coul be set differently on a customised form without affecting the db colums in any way)

Displaying data
The display function would be great. I immagine a call on page that uses the fields in the same way the forms do (default on admin pages and possible customisation on page). If the suggestion for custom fields above makes sense, this would sort them out again (atributing the right field names to the right custom fields. something like:

[ecampaign class=display postID=11]
{name};{custom1 "function"};{custom2 "organisation"}
[/ecampaign]'

Or, ideal to my situation but probably a lot more complex:

[ecampaign class=display postID=11]
{name anonymous=cb1};{custom1 “function” anonymous=cb2};{custom2 “organisation”}
[/ecampaign]’

I have searched for a generic display plugin (somethig that puts an user interface on echo-ing any wpdb data to a html table on a page). I have found none and it seems to be a common problem for many people who are not proficient in PHP: It is so simple to do specifically (if you know PHP) nobody finds any chalenge in building it generically.

sign up
I want to do exactly that. I realised after my initial post it would mean a check to see if the email is unique, but I would suggest that anyway after having multiple petition signups with one email adress (probably due to reloading a browser). You might even think of a welcomming email using the eCampaign fields in the same way a campaign is generated in the admin field, but I have no idea wheter that is easily achieved reusing code or a whole new chalenge

CRM or WP
I have indeed considered a CRM, but was strongly advised against it. The main reason is that, ultimately, the site is just pages and articles grouped around this one petition. That added to my non-existing PHP skills would make Drupal overly complex (or so I was told). Apart from some very specific point mentioned above and the generic problem of creating html tables on pages using data from the db, I am actually very happy with WordPress!

Thanks for your response so far, I hope I have been an inspiration to eCampaign rather than just being a demanding user. Warn me if I ask to much…