Symphony.

As observed by bauhouse, entry handle length has changed somewhere in the past. I did some tests on this matter. Here is the essence:

Truncation behaviour is defined in symphony/lib/toolkit/class.lang.php, and it changed long ago with Symphony 2.0.3. (However, I never noticed the change.)

Symphony 2.0.2 – 50 characters maximum handle length:

public static function createHandle($string, $max_length=50, $delim='-', $uriencode=false, $apply_transliteration=true, $additional_rule_set=NULL){

Symphony 2.0.3 and above – 255 characters maximum handle length:

public static function createHandle($string, $max_length=255, $delim='-', $uriencode=false, $apply_transliteration=true, $additional_rule_set=NULL){

I can not remember this change ever being officially announced. But for several reasons I do not think that it should be classified as a bug. (I’d rather see this as a feature change.)

• It makes sense (to me, at least).
• If it changed URLs in existing websites (thus breaking links from other websites to Symphony sites), this has occured long ago; any pain should be gone by now.

I also investigated how field handles are generated, because I ran into a small form validation problem yesterday which was caused by truncation:

Field handles are still limited to a length of 50 characters, although they use Lang::createHandle as well (which will truncate them to 255 characters). This happens due to the element_name MySQL field type being set to varchar(50). I am not sure if it is intended to have the “truncation functionality” in the database, but I hope that Alistair can comment on this.

I don’t recall specifically who introduced the change to $max_length, might have been me.

I am not sure if it is intended to have the “truncation functionality” in the database

Not really ideal. Although it is predictable, it does potentially introduce differences between the output of Lang::createHandle() and what is stored in the database. The 50 character length was a little arbitrary, and I don’t see any harm in changing the fields in the database to instead be VARCHAR(255). createHandle() should always be set to a maximum of 255 so no truncation ever takes place.

The handle creation process should, ideally, remain consistent across all future versions.

Perhaps prior to the next release we should agree upon some basic guidelines for handle creation and storage.

Alistair, so it might be a good idea to change the installer and to amend an update process for the element_name fields in the database to the Symphony updater. In this case there should be a warning during the update process, of course. If your XSLT already relies on field handles being truncated to 50 characters, certain things might break when you re-save the corresponding section (thus “removing” the 50 character limit).

It would be super-cool to get some hints where to search for potential problems. I could imagine throwing a list of “potentially truncated” field handles which are exactly 50 characters long.

So just in case the updater finds any 50-character-handles, it might throw a warning like this:

From Symphony 2.0.x, the 50 character limit to filed handles has been removed from the database. So field handles for new or updated sections may contain up to 255 characters now. The updater will perform the according changes to the Symphony database. We have found 2 field handles which are exactly 50 characters long, so they might have been truncated in the past:

• lorem-ipsum-dolor-sit-amet-consectetur-adipisicing
• sed-do-eiusmod-tempor-incididunt-ut-labore-et-dolo

These handles might change upon re-saving the correlated sections after the Symphony update. So if you edit the correlated sections, please check your XSLT for any issues.