Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
[wiki] Draft: Expanded zem_contact use/modification docs
Subject:
Expanding documentation for the zem_contact plugin (latest is version 0.6).
Background:
If you’ve used zem_contact even once, you know how valuable it can be. However, zem_contact hasn’t changed in a while, so it’s necessary for new users of the plugin to squash a few bugs (or make a few modifications) before putting it to trouble-free use (or for using it in particular ways). Many if not all of these bugs are mentioned around the boards, but a new user has to spend a rediculous amount of time to find them. My observation is they generally just make another quick, redundant post and someone more knowing points them to the thread already in existence. Why do we do this over and over? (That’s rhetorical, I know some of you actually like doing that kind of thing.)
Another common discussion is how to make zem_contact validate. The ability to do this seems to vary from person to person, so it might be nice to lay it out straight for everyone. Start your validation quest with message #9 of this thread.
Other questions often center around customizing zem_contact (e.g., subject output, using mail lists, etc.), and it might be nice to properly capture and document what those various customizations are so new users can follow them as desired.
EDIT: And this is probably a joke that zem has on all of us, but who knows?
Approach:
First step would be to get input from everyone about the specific things that need addressed in some expanded documentation (“expanded” suggesting beyond what zem provides in the plugin). Based on the above, the notions are already:
- identifying and fixing known bugs,
- validation modifications,
- useful customizations,
- and perhaps some notes about hotshot styling
Those could be broken down further (or added to).
Next, or at the same time, we pinpoint all the replies in threads around the forum that talk about any of the notions listed above. We make those replies known as followups to this thread, organizing them accordingly as they are brought to light.
After a period of time, allowing the stew to get hot and tender, someone begins the process of outlining the nuggets being collected. This enables us to clearly see what we have and what still needs covered. This could be done here or in the wiki (though the wiki might make more sense).
Anyway, that’s the general idea. I’ll make a couple replies so you see one possible way to follow up.
Side: I’ve noticed more and more people moving away from zem_contact and other contact type forms for a simple contact page of nothing more than a phone number, address, and email link (surely encrypted). Is that because it’s just easier to do? No bugs to f*ck with? Easy validation? Low maintenance? (Sounding better to me all the time.)
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
The Form Option Bug
Problem:
Plugin documentation indicates you can choose to use the tags directly in a page template, or call them from a custom form. The former works no problem. The latter, often the popular choice, is buggy. Rather than seeing the form output, use see the name of the form itself as output, which seems to be pulled from the <code>form</code> attribute.
E.g., If this is used in a template to call the custom form…<code><txp:zem_contact mailto=“dest@example.com” form=“mycontactform” /></code>, then you only see “mycontactform” as output on the contact page, not the contact form itself.
Solution: (kudos to wilshire, from here)
On line 16 which reads:
<pre>$Form = fetch(“Form”,“txp_form”,“name”,$form);</pre>
it should be:
<pre>$form = fetch(“Form”,“txp_form”,“name”,$form);</pre>
Note the lowercase “f” in <code>$form</code>.
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
The above reply is pulled from this thread (and there’s actually one more bug pinpointed in that thread and indicated in the next reply). Some may feel that duplicating it here is being redundant. Maybe. But there’s a big organizational difference to consider; I’ve pulled both the problem and the solution together in one message (no scrolling a thread to find the two pieces). Also, I’ve given the bug a name which makes it easier to talk (i.e., write) about it. Most importantly, it is now roped under this documentation thread that hopes to get all such issues for zem_contact into one easy to follow place where the “nuggets” can be more easily used to draft a full article later.
EDIT: Actually, now that I look at it as combined above, it’s almost easy to think that no further documentation is needed with respect to the bug; it’s spelled-out nicely — problem and solution — in one place. Customization aspects, well, that’s a different story; a nice write-up is probably better.
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
The Select List bug
Problem
When adding a select control to the zem_contact, e.g., <code><txp:zem_contact_select label=“Topic” list=“Item 1,Item 2,Item 3,Other” required=“1” /></code>, and then trying to send a test message by selecting a list item, you’ll end up getting an error notice in duplicate fashion like this…
- Required field Topic is missing
- Required field Topic is missing
Solution (kudos to lee, from here)
Find: (line 189 or there abouts)
<pre>$v = (ps($name) ? ps(name) : $selected);</pre>
Replace it with…
<pre>$v = (ps($name) ? ps($name) : $selected);</pre>
Note the missing <code>$</code> in front of “name”.
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
The Thank You Rerouting Modification
(Routing from one Article to another in same Section)
Problem
zem_contact provides for some thank you notice handling, but there are seeming problems with it (need links here). A reroute to a thank you page is one way to handle thank you notices nicely by redirecting users to a different article altogether. However, a redirect requires a modification to the plugin code.
Solution (kudos to wilshire, from here)
Find the block that starts on line 61:
<pre>if ($r) {
$_POST = array();
$out .= $thanks;
$f = parse($form);
}</pre>
Change to…
<pre>if ($r) {
$_POST = array();
header(“Location: /thankyou”);
}</pre>
Then change the <code>Location:</code> path to where your “thank you” page is. Make sure the path reflects your current URL scheme (messy, section/title, etc.)
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
The Thank You Rerouting Modification
(Routing from one Section to another)
Destry, thanks for starting this very helpful thread. I’ve made a modification to wilshire’s “Thank You Rerouting”. I added an attribute to the main zem_contact tag that, when set, reroutes the form submitter to a new page. If this attribute is not set no action is taken. Setting this attribute will override any value give to <code>thanksform</code>.
Here is the attribute: <code>newlocation</code>. It is used like any other attribute of zem_contact. For example:
<code><txp:zem_contact mailto=“my@address.com” newlocation=“thanks” /></code>
This will reroute the person using the form to the section “thanks.”
To achieve this I added the following lines:
<pre>
if (isset($atts[‘newlocation’])){
$newlocation = “Location: “.$atts[‘newlocation’];
}
</pre>
And changed the following:
<pre>
if ($r) {
$_POST = array();
$out .= $thanks;
$f = parse($form);
}
</pre>
To…
<pre>
if ($r) {
$_POST = array();
if ($newlocation) {
header($newlocation);
} else {
$out .= $thanks;
$f = parse($form);
}
}
</pre>
I recognize that I’m an amatuer hack here so any improvements to this method are warmly appreciated.
Last edited by jdykast (2005-11-19 00:26:55)
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
Slick! Thanks, jdykast. I use the first mod in combination with a little conditional tag magic (big ups to Sencer! and which I still need to write-up for the tag pages, I know) to achieve a nice two-article swap using one section/page combo, in this case my “Contact” section/page. I like this way because it eliminates having to create an extra section just for the thank you notice, but at the same time is a step better than the plugin’s thank you handling by allowing me to separate messages into two articles.
In any case, your approach could be very useful to others, thanks for adding it. I’ve added a header to your post so it’s easier for people to distinguish the two mods with a quick glance.
P.S. The conditional tags are not necessary to make the mod work; I simply use the tags so that my Contact link in the primary navigation will appear as just <code>…/section</code> for the default article (which is given a status of “sticky”), and not as <code>…/section/article</code>.
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
The Changeset 512 Modification
Problem:
This is a modification that is perhaps only necessary if you used one of the Rerouting mods above and have upgraded from PHP4 to PHP5. Without this Changeset 512 modification, you will be shown a 200 OK page with a message reading…
OK
The document has moved here.
Solution: (kudos to Sencer, from here)
Go into plugin code and find…
<pre>if ($r) {
$_POST = array();
header(“Location: /thankyou”);
}
</pre>
and replace with…
<pre>if ($r) {
$_POST = array();
header(“HTTP/1.x 301 Moved Permanently”);
header(“Status: 301”);
header(“Location: /thankyou”.$url);
header(“Connection: close”);
}
</pre>
Replace <code>/thankyou</code> with the appropriate path to your thank you article.
Note: You’ll note that Sencer indicated various mod options, but the one shown above is the combined version of those options and therefore perhaps the best one to use across most situations.
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
XHTML Strict Validation
The success of validating zem_contact seems to vary from situation to situation, though it is possible to do. The confusion might be that part of the contact form is plugin code and part of it is contained in a Textpattern Form. In any case, the discussion here, and ubernostrum’s notes replicated below (from here), should put you on the right track.
<txp:zem_contact mailto="myemail@mydomain" thanksform="contact_thanks">
<p><txp:zem_contact_text label="Your name" /></p>
<p><txp:zem_contact_email required="1" label="Your email address" /></p>
<p><txp:zem_contact_text label="Subject" /></p>
<p><txp:zem_contact_textarea label=" Your message" required="1" cols="70" rows="20" /></p>
<p><txp:zem_contact_submit label="Send" /></p>
</txp:zem_contact>The key is to edit the TxP form component of zem_contact by wrapping lines in the proper tags. Other enhancement such as putting the works in a <code><fieldset>…</fieldset></code> are also a good idea.
Note: The attributes and such shown in the example above are just for reference, not to be copied as shown. Modify as needed.
Obviously we could clarify this better. Other enhancements accomplished? Variations? Preferred methods?
How about different ways of making the form appear, presentational wise; anybody break out of the same old boring mold? (E.g., box/label alignment, styling, etc.)
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
Destry,
You are the man, man.
Thank you. I could have used this awhile ago, but I know it will prove extremely useful to others: well done.
One question I have, which may be innapropriate for this thread, and if so, feel free to edit or delete :)
Many folks have asked for a contact list that could be sent to multiple individuals email addresses.
Something to the effect of selecting from the drop down menu selects an email address specific to that individual.
For instance in the selects list, the formatting might look like this:
select=”,matthew smith;matthew@artiswork.org,John Rutgers; john@artiswork.org,…” etc.
or better yet, a select list determined by authors and their email addresses. (That would make me drool) :)
Just a thinking out loud, per your “other discussions center around…”.
I think Zem contact has the possibility of being a really extensive multi purpose form, and for that matter, already is, just maybe needs a few bells and whistles? If you have the ability to go into the future ask me to do it in two years when I will understand how to use PHP :) If not, a bunch of us could use your help.
Thanks,
Matthew
- I am Squared Eye and I
am launchinghave launched Pattern Tap
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
@ jdykast (or anyone who understand the jdykast’s mod)
To achieve this I added the following lines:
if (isset($atts['newlocation'])){
$newlocation = "Location: ".$atts['newlocation'];
}
where should we add this lines?
thanks!
Last edited by maniqui (2005-11-21 03:50:54)
Offline
Re: [wiki] Draft: Expanded zem_contact use/modification docs
The best way to do this wouldn’t to post an updated version of the plugin, more accessible, bug free (hoping), and easily translatable ? So that anyone can begin working with it cleanly ?
Offline