Plug-in: zem_contact_reborn

phiw13 · 2006-03-22 05:05:24

Apologies if this has been discussed before – 15 pages makes it a long thread…

I am running into a few (language) problems with this for a Japanese site.

1/ subject of the email message – appends the name of the site automatically. But this comes through as garbled when the name of the site is in Japanese. (that particular field is a huge problem with php and mailing forms for Japanese anyway).
I solved this by editing, in zem_contact_reborn this line:
'subject' => zem_contact_gTxt('email_subject', $sitename),
I deleted the $sitename, and use a full English subject in the txp:zem_contact tag. Not a huge problems at all.

Question – does the code of the plugin rely on this ($sitename) at any level for validation or security, spam or whatever ?

2/ labels for form elements – If I want a label containing Japanese text (i.e ‘Name’ in Japanese), this won’t work at all, for many reason, as the plugin uses that label to append classes, to give an ID, for validation, etc. Not a big problem by itself.
I solved this by inserting the Japanese text string before the appropriate tag in my txp-form. On output I then get this:
XXX < label for="name" > < Name > < /label > etc
where XXX is some text in Japanese – gives a bilingual label, a bonus maybe, and with a bit of CSS magic, it appears quite nice. However, the XXX Japanese text is not wrapped into the label.

Question: would it be possible to start the opening of the < label for="" > before the XXX in my example (mostly an accessibility thing) ?

3/ More problematic, I think. Localisation.
In the zem_contact_lang file, I edited some strings to use Japanese text (‘thank you, your message has been send’, the error messages,…). OK, this works, when using the (contact)form, the correct messages are outputted, with no errors. BUT
But when I save the zem_contact_lang file then reopen it, those translated strings have been converted to ??????.
This means that I have to re-edit all translated strings whenever I need to make some changes.

Apparently, those strings are saved correctly in the db (I guess), and Txp can use them for the visitor, but TXP, or the plugin, can not retrieve those strings for editing. More likely the plugin, as I don’t have problems editing any other textarea in Textpattern.

And finally,
4/ Thanks a lot of this plugin! It works very well for the user (mail recieved correctly, error validation works).

1beb · 2006-03-22 06:09:35

@Stuart: No, I do not have that option set I am using the basic < zem_contact to=“email” / >

marios · 2006-03-22 18:35:31

phiw13 wrote:
3/ More problematic, I think. Localisation.
In the zem_contact_lang file, I edited some strings to use Japanese text (‘thank you, your message has been send’, the error messages,…). OK, this works, when using the (contact)form, the correct messages are outputted, with no errors. BUT
But when I save the zem_contact_lang file then reopen it, those translated strings have been converted to ??????.
This means that I have to re-edit all translated strings whenever I need to make some changes.
Apparently, those strings are saved correctly in the db (I guess), and Txp can use them for the visitor, but TXP, or the plugin, can not retrieve those strings for editing. More likely the plugin, as I don’t have problems editing any other textarea in Textpattern.

That’s a good question, since the language conversion does not work from within the edit window,
and if I wanted to make a localized version for greek(Non ASCII) of the language plugin, what is the right go for this?
The other (backends) language strings get fetched through XML-RPC, when you installl them.
(This was mentioned to work the same way for plugins in future versions of tXP AFAIK)
When I need to localize the lang plugin now as is, I suppose I have to make a new lang plugin,
but what are the best steps to follow for localization in general ?

Last edited by marios (2006-03-22 18:37:36)

mrdale · 2006-03-22 22:45:24

Is “show_error” fixed yet?

thebombsite · 2006-03-22 23:24:02

@mrdale – It’s fixed in version .18 which you can test here.

Logoleptic · 2006-03-23 07:21:49

I’m having a small problem with pap_contact_cleaner. Every time I activate it extra margin gets added to the bottom of my form, pushing any text that follows the form down the page by about ~~1em~~ 2em or so. Any idea why this is happening and how to fix it?

Last edited by Logoleptic (2006-03-23 07:22:53)

wet · 2006-03-23 07:41:41

Thats because pap_contact_cleaner inserts a <div> past the form. Though tranquillo styles it with visibility: hidden; it somehow has a notable height at least in IE6.

I’ve previously tried various combinations of text-indent: -9999px;, height: 1px;, display: none; and the like for the enclosing div as well as for the embedded input tags but I haven’t managed to find a style which will definitely shrink this element into invisibilty on IE (It works with Firefox, but that’s no news).

If you’d like to have your own fun with that and succeeded with any markup which works in browsers and browser imitations as well, please report here.

Logoleptic · 2006-03-23 08:14:59

Ah, there’s the problem. Setting the CSS visibility property to hidden will hide the content of the element, but retain it’s size and subsequent effect on other page elements according to the box model. It needs to be changed to display:none instead.

Since (I think) the current visibility setting is applied with an inline style, no ammount of changes to your linked stylesheet or in your document’s head will fix it. The update will have to be made in the plugin code itself, though that shouldn’t be much of a problem.

Logoleptic · 2006-03-23 08:18:24

Just tested my fix. Works like a charm. Can we get this into the next release?

phiw13 · 2006-03-23 08:28:56

wet wrote:

Thats because pap_contact_cleaner inserts a <div> past the form. Though tranquillo styles it with visibility: hidden; it somehow has a notable height at least in IE6.

display:none is one option, although I’ve had problems with that in IE 6 (still included in a submission, real weird — iExploder…)

visibility: hidden; height:1px; overflow:hidden; will work well.

thebombsite · 2006-03-23 14:45:50

My experience with display:none; suggests using both that and a negative margin fix at the same time. I think most browsers can do one or the other and many do both. You should also specify a height for IE6, usually 1px as shown above, otherwise it throws a wobbly. I also know that we had the option of putting the div itself inside the form as well so what thoughts on that? I’ll look at the display:none; and negative margin anyway. I don’t know how much of this thread you have read but version .18 which is currently being tested does not use the pap_contact_cleaner plug-in, indeed it doesn’t have the API either as we are looking to make the base code as secure as possible and remove it’s dependancy on add-ons so to some extent this is likely to be a temporary problem for you. Let me know if you prefer the div inside the form or not.

Last edited by thebombsite (2006-03-23 14:50:45)

mrdale · 2006-03-23 15:08:15

error dl instead of ul?

I have one form in a ul in my sidedar that get’s automatically collapsed. The error message in a ul royally screws this arrangement up. So I hacked my version to display errors in a dl instead of a ul. Perhaps this change would be useful to others… or not. Thoughts?

Just a thought untill .18 gets released, and we get to use show_error…

Last edited by mrdale (2006-03-23 15:09:49)

roelof · 2006-03-23 17:03:58

Hello,

If a only use the contact-form without the send option.
Im a safe for spam or do i have to use the pap_contact_cleaner.
If so, where can i find it.

Roelof

Logoleptic · 2006-03-23 17:28:33

thebombsite wrote:

My experience with display:none; suggests using both that and a negative margin fix at the same time. I think most browsers can do one or the other and many do both. You should also specify a height for IE6, usually 1px as shown above, otherwise it throws a wobbly.

Using display:none by itself seems to be working okay in IE6 for me, but I haven’t done backward-compatibility checks in earlier versions of IE yet. I’ll be installing the stand-alone versions of IE 5.01 and 5.5 this weekend, along with the latest beta of IE7. We’ll see how it goes.

You can get a look at the contact form in question here. From what I’ve seen on two computers running IE6, the spacing between the form and the heading below it seems correct.

I also know that we had the option of putting the div itself inside the form as well so what thoughts on that?

I’d considered that as another possible fix, but once I learned that visibility:hidden was being used I figured changing it to display:none was the fastest way to go. I don’t have time to test the in-form idea myself, but I’d be interested in hearing how someone else does with it.

thebombsite · 2006-03-24 00:31:08

@ roelof – you are advised to use the pap_contact_cleaner plug-in whatever setup you use with the current version. You can find it on page 1 of this thread with the main plug-ins.

Last edited by thebombsite (2006-03-24 00:32:00)

Textpattern CMS

Textpattern CMS support forum

#376 2006-03-22 05:05:24

Re: Plug-in: zem_contact_reborn

#377 2006-03-22 06:09:35

Re: Plug-in: zem_contact_reborn

#378 2006-03-22 18:35:31

Re: Plug-in: zem_contact_reborn

#379 2006-03-22 22:45:24

Re: Plug-in: zem_contact_reborn

#380 2006-03-22 23:24:02

Re: Plug-in: zem_contact_reborn

#381 2006-03-23 07:21:49

Re: Plug-in: zem_contact_reborn

#382 2006-03-23 07:41:41

Re: Plug-in: zem_contact_reborn

#383 2006-03-23 08:14:59

Re: Plug-in: zem_contact_reborn

#384 2006-03-23 08:18:24

Re: Plug-in: zem_contact_reborn

#385 2006-03-23 08:28:56

Re: Plug-in: zem_contact_reborn

#386 2006-03-23 14:45:50

Re: Plug-in: zem_contact_reborn

#387 2006-03-23 15:08:15

Re: Plug-in: zem_contact_reborn

#388 2006-03-23 17:03:58

Re: Plug-in: zem_contact_reborn

#389 2006-03-23 17:28:33

Re: Plug-in: zem_contact_reborn

#390 2006-03-24 00:31:08

Re: Plug-in: zem_contact_reborn

Board footer