Plug-in: zem_contact_reborn

marios · 2006-03-22 00:50:06

I received a 500 internal Server error on the latest version for this just using the default form and using an e-mail from one of my imap acc/ts.
Server is textdrive.

regards, marios

tinyfly · 2006-03-22 03:12:46

Textdrive email has been off and on today depending on what server you are on. See if your regular email is working and then try your form again.

marios · 2006-03-22 03:41:13

It doesn’t say much on the helpdesk page,
I had seen this before, but then again didn’t want to change everything to http, just for temporary reasons.
(my Server is Nelson).
EDIT.:Works now
I’ll give it a try tomorrow.

regards

Last edited by marios (2006-03-22 19:23:26)

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?

Textpattern CMS

Textpattern CMS support forum

#373 2006-03-22 00:50:06

Re: Plug-in: zem_contact_reborn

#374 2006-03-22 03:12:46

Re: Plug-in: zem_contact_reborn

#375 2006-03-22 03:41:13

Re: Plug-in: zem_contact_reborn

#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

Board footer