Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Plugin Request: improving zem_contact for money
Can you give me the coding you have used for this, and I’ll test it? Not being a crash hot PHP coder I dojn’t give any guarantees, but I will take some time to go through it …
In my page template is this: <code><txp:zem_contact form=“contact_form” /></code>.
Then in my form, “contact_form” is this:
<code><txp:zem_contact_email /><br />
<txp:zem_contact_select_mailto list=“Media Relations,Online Department” addresses=“jeff@test.org,jeff@blahbadyblah.com” /><br />
<txp:zem_contact_text label=“Subject” /><br />
<txp:zem_contact_textarea label=“Message” /><br />
<txp:zem_contact_submit label=“Send” /></code>
Refresh Dallas and other Refreshing Cities.
Offline
Re: Plugin Request: improving zem_contact for money
Even though I’m at work, I’ve had an epiphany! When I tested this, it was inside a page ie. not on a form. I’m guessing the problem is that when textpattern parses a form, it’s converting all the tags to simple XHTML output and loses all the ‘smart’s.
I have an idea of how to modify this to make it work (and actually improve some default handlig) but it will have to wait till I get home tonight.
Foreign language issues are beyond me – I just don’t have an understanding of how they are treated when the form is submitted. If anyone has some ideas, I’m happy to experiment…
Offline
Re: Plugin Request: improving zem_contact for money
Its not foreign language per se, its foreign characters. I have the zem_contact in a form. What is mystifying is one tag has a drop down list with a Norwegian character in it i.e “ø”. With that, the form submits correctly.
However, in every other location where I have a Norwegian character it fails, unless I use the HTML entity instead: <code>ø</code>
Having said that, sometimes the form fails with HTML entities. Its quite buggy. I use the latest posted version from an earlier post above.
Last edited by jstubbs (2005-12-13 11:11:53)
Offline
Re: Plugin Request: improving zem_contact for money
In the new version of this plugin, the output is like so:
Email: email address
Phone: 1234
How can I change this to:
Email:
email address
Phone:
1234
Thanks, I will take a look at the plugin but not sure if I want to play around and break something ;-)
Offline
Re: Plugin Request: improving zem_contact for money
jstubbs you can do this in your css: <code>label{display:block;}</code>
Refresh Dallas and other Refreshing Cities.
Offline
Re: Plugin Request: improving zem_contact for money
Hi tinyfly. I was referring to the email output after the form has been submitted. The original zem_contact was as I wanted, its only in the latest version it changed.
Offline
Re: Plugin Request: improving zem_contact for money
I’m just browsing the source code to the original at the moment as it does mostly what I want it to, except I don’t like the markup much.
Just one thing though – what’s this reference to ‘nonce’ that keep appearing in the source code?? In England a nonce is someone who generally is quite unpleasant to minors… anything that can be done about that? :/
Offline
Re: Plugin Request: improving zem_contact for money
It outputs a long random string of characters in a hidden input field. I believe it has something to do with form expiration. To keep people from submitting your form a million times.
Refresh Dallas and other Refreshing Cities.
Offline
Re: Plugin Request: improving zem_contact for money
jstubbs -
To add another line break in the email add another <code>\n</code> to the following line:
<pre>$msg .= “$k: “.htmlspecialchars($v).”\n\n”;</pre>
You need to add it here <code>”$k: \n”</code>.
Offline
Re: Plugin Request: improving zem_contact for money
I did that and it works. Thanks!
Offline
#59 2005-12-14 07:51:36
- boblet
- Member
- Registered: 2005-08-08
- Posts: 53
Re: Plugin Request: improving zem_contact for money
Hey fellow zem_contact
ers interested in i18n :-)
aslsw66 wrote:
I’m not really sure of what the issues with internationalisation are. In Australia we are just so far away!
I’m not sure that boblets approach of additional tags is the best way to go. Wouldn’t it be better to set something in the admin sitde?
There were two main i18n issues with the original zem_contact
; all plugin messages/errors were hard-coded into the plugin (making it useless for non-English sites), and apparently foreign characters in the email were also garbled. I made some ugly hacks and worked around both.
My approach was to specify English defaults in the plugin, and to include additional tags for each plugin message, allowing the English to be overridden for localisations. I agree this is fugly, but I have no idea how to add (language) variables to the prefs table and then pull them back into a plugin. There’s a thread that mentions txp_prefs
, but not in enough detail for me to work it out (ah – just found some more relevant forum posts 1, 2).
If someone can explain to me how to add plugin translations to txp_prefs
, or refer me to a plugin that does this, I’ll have a go at attempting it.
addendum: struth mate, what does being in Oz have to do with it? Don’tcha have big Greek and Chinese communities over there?? :P (originally from NZ here – you never know where life’ll take you, it’s a small world, etc etc ;)
jstubbs wrote:
Foreign language characters seem to put off the form
If you’re referring to text submitted by the user, I think this is solved by changing from htmlentities
to htmlspecialchars
mentioned by Finnish
jstubbs wrote:
in every other location where I have a Norwegian character it fails
This is possibly the preg_replace
on $name
(first paragraph) that I had to remove – it was turning kanji label for=""
values into question marks. You could check by doing a return $name;
straight after this line of code: $name = (empty($atts['name']) ? preg_replace('/\W/', '', $label) : $atts['name']);
. If you just get “?“s instead of characters try removing the preg_replace
. Keep in mind removing this means it’s up to you to avoid using HTML illegal characters (whitespace, ?). The relevant HTML spec seems to indicate it’s the same as id
, which is alphanumeric plus -_.:, case sensitive, and must start with a letter (automatically excluding utf-8 characters). Fwiw, my all-Japanese form works on modern browsers and validates on XHTML 1 strict and XHTML 1.1. Haven’t checked it on IE6 though [shivers].
aslsw66 wrote:
Foreign language issues are beyond me – I just don’t have an understanding of how they are treated when the form is submitted
afaik, TxP handles everything as UTF-8, including form content. It’s only when some nasty PHP5 call which doesn’t understand (htmlentities
, preg_replace
…) comes along that things fall apart. I think PHP5 is inherently UTF-8 unaware, and that this’ll be the big change when PHP6 comes along. Until then we just have to be careful not to use PHP that assumes ASCII input.
peace – boblet
Last edited by boblet (2005-12-14 07:55:00)
Offline
Re: Plugin Request: improving zem_contact for money
The error I had mentioned was due to a problem with my company blocking certain email from being transmitted. Not a problem with aslsw66’s modifications at all. Thanks for the help.
Refresh Dallas and other Refreshing Cities.
Offline