Thread

I’ve come across an interesting issue with ExpressionEngine 2.3.1 and non-English (specifically, Korean) text, and I wonder whether anyone else can confirm the issue for me.

I’m running a fresh localhost install of EE2.3.1 on MAMP Pro 2.0.1. The PHP version is 5.3.6, because of a tip in this forum that pasting into text fields will kick an error. All extensions are off.

Required fields accept English text fine, but if I enter double-byte character-set text (again, this is Korean), the entry is rejected with the error message that the field is required—i.e., as if I had left the field blank.

If I kick PHP back down to 5.2.17, this issue does not manifest itself. With PHP version 5.3.6, EE resumes rejecting entry of DBCS text.

Is anyone else encountering this issue? Maybe Nicolas Bottari, who uses Japanese?

Hi, Brendon.

Can you possibly post an example text we can test with?

A bit of example text would be 홍길동—which is a Korean name equivalent to “Joe Blow”. I’m trying to build an employee directory, and the name is a critical part of this.

I’m trying to enter it directly into a Text Input field (Title field, to be exact, although with Title Master or MX Title Control 2.5 I’d probably put it in a custom Text Input field). I’m not sure if you’d have the same result cutting-and-pasting. I’ve heard there is a cut-and-paste issue with Text Input fields on PHP 5.3.x—forget who reported that, though. Maybe it was a tip on the #eecms hashtag on Twitter.

You can directly enter this text by enabling the Korean Input Method (2-Set Korean) on your Mac (you do use a Mac, right, Sue?), switching to Korean text, and typing the phrase “ghdrlfehd”. When you submit on PHP 5.3.6, EE 2.3.1 should kick an error that the field is required. Yet you’ve entered text, so it’s certainly frustrating. Submit the same text on PHP 5.2.17, no problem.

I’d be really curious to know if you can duplicate this error. If it’s a real bug, it would be a pain for people to try to figure out. But maybe I just got a bad install.

Hi Brendon,

I wonder if this happens on a normal PHP form (no EE involved)? Just to eliminate the possibility that the problem is in general with PHP 5.3.x
I also quickly tested on EE 2.3.0 and PHP 5.3.1 in an entry title, and had no problem typing in Japanese.

In EE, this happens when you type in Hangul in the entry title field or required custom fields, is that correct?

I would maybe check some basic stuff first:
- Database and Table is in Unicode
- The final “enter” is pressed when typing. In Japanese, text is displayed in Japanese but is underlined and in an “untyped” state until you hit “Enter” to confirm input and the right kanji combination. Maybe this is similar in Korean?
- The url_title is filled out correctly with half-width alphanumerical characters. Japanese text does not fill the url_title out (unless you use my “Japanese kana typing” extension 😉).

UPDATE: I just tried with Hangul (2-Set), and indeed see an issue:
Upon typing an entry title, text is underlined as in Japanese. However, when hitting “Enter”, this doesn’t only confirm the typed text, but also submits the form. Since the url_title isn’t populated with alphanumerical characters, I get an error saying “Unable to create valid URL Title for your entry”. Manually entering something in the url_title, then clicking “Submit” saves the entry.

Looks like something to do with the Hangul IME’s interpretation when pressing Enter. I could be wrong, though 😉

Korean’s a little different from Japanese in that our language’s hangul writing system is an actual alphabet while Japanese katakana and hiragana are syllabaries. Koreans, in fact, love to go on about the superiority of the hangul writing system as one of history’s greatest achievements; as a linguist it is definitely an interesting development which contrasts favorably with the well-established use of syllabaries in many other Asian countries. But that’s a tangent.

The bottom line is that except when entering Chinese characters, the Korean input method does not require Enter to be pressed to complete a syllable.

But you’ve raised an interesting issue: No hangul autocomplete url_title. Maybe the lack of the URL title is causing the error. I’m going to use English in the Title field, allow the url_title to be autocompleted (or manually enter the url_title), and see if hangul text will be accepted in the other, custom Text Input fields.

What’s strange is that the EE error message isn’t identifying the url_title as being the problem. And, of course, the other strange element is that PHP 5.2.17 works just fine, while only PHP 5.3.6 is a problem.

UPDATE: I’ve confirmed that the problem does not arise from inability to autocomplete the url_title. I’ve manually entered a Roman-lettered url_title, and Roman-lettered Title field, with Korean entered into two Text Input custom fields. On MAMP’s PHP 5.2.17, the Korean entries are accepted. On PHP 5.3.6, ExpressionEngine throws the error that the fields are required—i.e., as if no text had been entered in those fields at all.

Database and table are Unicode. It’s a fresh EE 2.3.1 install (no legacy database), and Kyara tells me all the tables are UTF-8 Unicode.

I haven’t tested this with plain PHP forms yet, but it sure does look like an EE problem to me. I don’t ordinarily have trouble entering Korean text anywhere, and since the problem manifests itself only on EE with a specific PHP version, that points to a coding problem.

I want to test on Windows, in order to exclude the Mac OS X Korean input method, but my VMWare Fusion install recognizes localhost as being in the Windows VM. So complicated!

Brendon Carr,

I’m gonna run this up to the dev team for their input.

Cheers,

Korean’s a little different from Japanese in that our language’s hangul writing system is an actual alphabet

lol 우리말...

Sue & Dan, I’m curious to receive your feedback.

It looks like it’s a bug in MAMP’s iconv - see here.  It’s fixed in MAMP 2.0.2. (or try it under your current MAMP and php 5.2).

That do the trick?  Really not something that can be addressed on the EE end of things.

Just double checking that the incov bug makes sense in light of what you’re seeing, Brandon.

Robin,

Thanks for your followup, and for tracking down the iconv issue in MAMP. I was on MAMP 2.0.1, so the tip to move to MAMP 2.0.2+ was very helpful. If it ain’t broke, don’t fix it, but if it is broke… On 2.0.5 there’s no issue anymore.

Glad you are up and running again Brendon. Feel free as always to start a new thread if you have any more questions.