Fatal error: Call to undefined function tt()

Yes, it looks like though i18ncontent module depends on i18nstrings this may be enabled before the other one is loaded.

I've added some code to force loading of i18nstrings for this and other modules (profile, taxonomy...), this should fix the issue.

I started getting this error for a bunch of different (taxonomy related) modules after updating from the 2010-Apr-08 6.x-1.x-dev to the 2010-Apr-12 one. Reverting to the older version resolved the issue.

I wasn't sure if I should report it here or in #226139: "Fatal error: Call to undefined function tt()" on enabling modules. or if I should start a new issue. Hope I'm not causing a mess in the issue queue.

In todays DRUPAL-6--1 (6.x-1.4) Jose writes
"- Deleted obsolete functions tt() and to(). Replaced by i18nstrings() and i18nstrings_update()"

In my opinion this is very bad design, since many many other modules rely on this function.
All modules must update.

Doing such a major api change is at least reason enough for a big release update, not a minor one.
I'd recomment readding tt() for 6.x-1.x-dev again and continuing with significant changes in DRUPAL-6--2. Else this will break a lot.

I agree with you Miro. Furthermore, as with any such change (I mean the kind that affect a lot of people and change a well-known feature drastically) I think that it is a good practice to gracefully fall back to previous behavior.

If there is need to kindly 'force' module developers/maintainers to adopt the new feature, perhaps a warning at the site's status report would be the best way to go. This way, individual bug reports would be made to each module's issue queue by site admins and the feature would slowly make its way to new releases.

Marking this critical since it affects that many dependent modules.

People, this effects A LOT of modules. Can we please have an official answer from the maintainers?

Module developers and users start shouting around since they try latest dev leading to this fatal error in many different cases.

Some modules already start with issues like "upgrade from deprecated tt to i18nstrings".

This will result in a huge mess of module version incompatibility issue and a huge period of partial i18n module support where everything will fail here and there.

This is very bad publicity for drupal related multilanguage development.

indeed guys, have you gone nuts just removing it ? :s

Here comes the rain...

Hierarchical Select: #768948: Replace obsolete functions tt() & to() with i18nstrings() & i18nstrings_update()
Content Taxonomy: #780976: Replace obsolete functions tt() & to() with i18nstrings() & i18nstrings_update() - WSOD(!)

Attaching latest dev that still works with tt()...

... file got auto-renamed to .tar_.gz, but you know what to do ;)

more modules that have the issue...

http://drupal.org/project/issues?text=fatal+tt%28%29&projects=&status=Op...

I don't know what you guys are smoking. Changing function in the middle of stable release lifetime ? WTF ?

Maybe we can find some kind of "best practice" to move forward with the change from tt() to i18nstringds() for maintainers of modules that are affected by this issue?

...or maybe, i18nstrings module could provide both functions until... i18n is branched? ...or, maybe even provide both functions for Drupal 6 branch?

The following could be added to i18nstrings.module.

/**
 * Translate or update user defined string - DEPRECATED.
 *
 * @todo Remove tt() for Drupal 7.
 * @see i18nstrings()
 */
function tt($name, $string, $langcode = NULL) {
  return i18nstrings($name, $string, $langcode);
}

PS: If Jose cannot attend this issue, and people agree on adding tt() back as above, then I may commit this to CVS (reference) because it seems critical enough to not wait too much.

So, how about this?

looks perfect to me, markus. please apply.
A second reviewer please set RTBC asap.

this is no brainer

Committed to CVS. Hopefully available with the soon to be rebuilt dev snapshot.

This also fixes this issue : #770360: Obsolete deleted fucntions are still used by other modules

While tt() is the most popular usage of the i18n api there was also to() and ts().

At least to() was named in the remove commit from Jose while we also know e.g. ts() that was used by some modules.

Is there some overview from previous and future API and its usage to complete this task?

to() was replaced by i18nstrings_update()

...don't know about ts() though.

ts became i18nstrings_ts

Whow! That was fast Miro :) Thanx!

Anyone of you know who makes use of to() or ts() ??? Is it really necessary to provide the old function names in these cases?

I'm afraid to touch these 2 functions, and I would wait to see the POV of Jose. AFAICT, tt() was affecting a lot of modules, but... to() and ts() ????

In #20 I reported a duplicate issue.
After deletion of tt() I found bug in Faceted_Search : #770354: Incompatible with last i18n module DEV release
Unfortunately there is still no response.
So it could be long and hard to find all modules using it. Worst to ask them resolve it.

subscribing

Yes, agree there was some bad design here, but that was the 'tt' api. It had performance, namespace and security issues (See the latest 2 security updates).

So that function is to be marked obsolete and to be gone on this or next releases. If we want to keep it for one more release, ok.

Unfortunately there's not an easy way to see which modules are using it, not since we have different tags for development branches of contrib modules. So the only way I could think of enforcing all modules using it, I don't know how many, to update was to mark it obsoleted for one release and remove it on the next.

Unfortunately we are not handling compatibiliy of module versions with Drupal 6. But we need to update all modules to the new API instead of allowing them to keep using the old one for ever.

Whether this needs to take one month or one year I don't know. So if someone has a better idea to 'enforce' other modules using the new API, please...

I agree you must take "rock heart" decision if you want all modules to migrate rapidly.

In such a case, is there way to search in all last version files in CSV if they contain tt() function ?

Here's an idea for an implementation plan to get rid of tt():

- Create a last 6.x-1.x release with explicit documentation (release notes) that states function tt() is deprecated and soon to be removed.
- Create a new branch 6.x-2.x where tt() is removed.
- Document the differences between 6.x-1.x and 6.x-2.x in the i18n project page, so it is visible to everyone.
- Branch 6.x-1.x remains alive for... 3/6 months? and then marked as non-supported.
- All future development is moved to the 6.x-2.x branch.

Re: "In such a case, is there way to search in all last version files in CSV if they contain tt() function ?"

AFAICT, checking out the contrib repository for D6 related branches of all projects, then doing a grep.

I agree with Markus on the logic that this should be handled. The new 2.x branch + setting 1.x to non-supported after some time seems to be the best practice. I think that this will 'kindly' force people requesting new features to move on.

Searching through the repository using grep is a solution ('server-side' if I may call it that) that will involve maintainers to do most of the work. But I have another recommendation (don't know if it is programmatically doable though)...

I am using the Schema module. One of its functions is:

Schema comparison: the module compares the live database structure with the schema structure declared by all enabled modules, reporting on any missing or incorrect tables.

...this adds a field in the site's status report like so (also see attached screenshot to see what I mean.):

Database schema Inconsistent
The Schema comparison report shows:

* 48 modules with matching tables
* 2 extra tables
* 1 module with mis-matching tables

The database schema comparison report provides more details.

So, I think you are getting where I'm going at. Implementing this sort of report that would search & report use of use of tt(), ts() and to() functions within modules. This way normal users and site visitors would not get any WSOD or 'Fatal error' messages, but site admins (or users that have access to the site status page in general) would be notified. Then they could either contribute patches or report bugs to respective module issue queues. A link to more details would provide a 'module -> file -> line number' list in order to help them do that.

What do you people think?

PS: I've made a 'mock-up' below (based on the one that the Schema module has) of how I think the report in the site's status page should look :)

Use of obsolete tt(), ts() and to() functions detected:
For more information please see the related issue in i18n module queue on Drupal.org:
http://drupal.org/node/358839

* 15 modules make use of these obsolete functions.
* tt() function is called 57 times by 13 modules
* ts() function is called 11 times by 3 modules
* to() function is called 3 times by 1 module

The obsolete functions report provides more details.

...btw before people rush to say that this is too much noise for a problem that will eventually resolve itself (by having modules' maintainers slowly adopt the new API functions), please consider that some modules out there have a really 'slow' development circle and their maintainers might take longer than expected to respond.

Also, there are a lot of module developing tutorials & books out there that will guide young module developers to use tt(). If some kind of check & warn process is implemented in the site's status report, it would help people realize that these functions have been deprecated (and spare them the frustration of doing things wrong and possibly making them quit in the long run).

I think that the tt() function should remain in i18n, but only as a check that will log use of it and then gracefully 'pass' its arguments to i18nstrings(). Same goes for ts() and to().

What is the problem with keeping tt() in D6 and changing it in D7 ?

...or that too :P

Many thanks about the stats of tt, to and ts

There are many modules that lack continuous maintenance of the repository. For a long time. We're sometimes waiting for months to get response.

I see we're provoking a situation where i18n changes a widely used api that will lead to partial module incompatibility for months.
Even if they apply the new version to the CVS some maintainers also delay creation of a next release. We can't enforce them to do so. Sometimes they're simply unavailable short term.
Note that Drupal 6 itself is still broken regarding different aspects (some of us would address to be over-critical) but they're not getting fixed, also/especially due to the risk of breaking something...

I'd expect a typical project will remain in the situation to need applying many patches for a long time.
Note that many people aren't aware of patch/diff/cvs and i18n is a common end user case.

Remaining on the deprecated API with some sort of warning for super admins (like update status does) seems to be the right direction to me.

Having this change finally enforced for d7 would be my favorite suggestion since all modules need to take action to support it. So if they do right that they're ready to take the effort to switch to the new API.

Jose, will we still be able to meet the security aspects of D6 that way?

Well, it's a nice surprise so many modules using i18n api :-)

So ok, let's keep 'tt' for now, at least for translating (not for updating strings) so the modules won't break.

I'll start by properly documenting the issue, and then posting issues for that modules.

If someone can post individual modules using tt, or a full list here, that would be great.

1. I've created this handbook page, for reference: http://drupal.org/node/789286

2. About marking the function as deprecated so it throws a PHP notice I think the better solution would be this one, maybe printing a link to the handbook page. (From http://stackoverflow.com/questions/194121/how-to-deprecate-a-function-in...)

function my_deprecated_function() {
    trigger_error("Deprecated function called.", E_USER_NOTICE);
    // do stuff.
}

Glad to be back on track again. And Thank you Jose for your support.

We'll fire a lot of errors (regarding drupal db error handler) then. Note that no regular callback trace will be added - so we need to backtrace for caller ourself. Really want to integrate that hard work? The message "deprecated call" alone seems to be useless to me.

I definitely need to catch up with my coding skills and be able to help more (I kinda feel useless always proposing things and not being able to actually implement them).

@Jose: thanks for creating the handbook page in such a short time! A fine first step in preventing further issues with people getting used to these to-be-deprecated functions (we'd have to either 'force' them or convince them to switch later on).

Now, all we need to do is to ensure that they gracefully fallback and not cause any WSOD or errors. I believe that we should keep related code around at least till D6 is not supported anymore (in other words when D8 is out I guess). In the meantime perhaps a 6.x-2.x version will be available by that time and then, it will be only excess code that only bloats things + we'll have the excuse of warning people ahead for changes to come ;)

If anyone more drupal+API-savvy out there spare some minutes to answer this question that's been itching me: Can we hook (hope I am using the term correctly here) to tt and the rest of these functions during execution time? I mean so that they can keep doing their job as normal but also handle the warning in the status report I've proposed in #32.

While I am at it... Coder checks other modules code for consistency with Drupal coding standards. Perhaps then an extra step would be to have it detect use of these functions and warn people to correct them. I am not sure about that, but also add some notes on the issue here: http://drupal.org/coding-standards

Once again Jose and Miro, thanx for giving this the appropriate attention.

So we are keeping tt() at least until D7.

We'll be doing a new maintenance release this week.

Luckely, cause too much stuff would break otherwise! Also think about older unsupported modules.