[TYPO3-ttnews] Current localization issues - tx_news vs. tt_news

[Thomas Skierlo]

Hello everybody,

on my live servers I'm still running TYPO3 4.5.4, with a very limited 
set of major extensions, like TV, DAM, realUrl, tt_news 3.01. Most of my 
projects are multilingual. To get tt_news 3.01 working in a multilingual 
environment I had to apply many patches – and finally all worked as 
expected.

During the last 4 weeks I tried to update TYPO3 to a more recent version 
on my development system. I knew about tx_news, but I first tried to 
keep tt_news. Before I started the update to tt_news 3.1.0 I checked the 
issue tracker. It seemed that tt_news 3.1.0 includes all the patches I 
manually applied for 3.01 earlier. After the installation and with the 
caching framework enabled, everything seemed to be ok except the single 
news page browser (previous/next article), which had lost the ability to 
localize and sorts non-default records after the default language 
sequence (I remember that I once applied a patch for 3.01 for this 
reason – but I didn't document it). So probably one of the patches for 
3.01 didn't make it into 3.1.0.

While I was still looking for a solution tt_news 3.2.0 came up. 
According to the release notes only a modification for improved TYPO3 
4.7 compatibility. I installed it anyhow, to always use the latest 
version. Next thing I noticed was a fatal exception. FE and BE died 
instantly because of a „cache not accessible“ problem. This problem 
could be solved by disabling the caching framework (which was enabled 
since tt_news 3.01 without problems). For sure disabling it could not be 
a long term solution.

Ok, I thought. Time for a change. tt_news is dead and tx_news is on it's 
way. I can understand that a developer must concentrate on the future 
release, at least, if both, the old one as well as the new one, need a 
lot of attention. I would do the same, if time and development power are 
limited.

So I installed tx_news 1.3.2 and started my first dive into 
fluid/extbase. The combination looked very familiar, similar to the MVC 
concept of Zend Framework – and I liked that. My first aim was a list 
view and a detail view and after a day or two my test news records 
looked very similar to the ones from my live server with the patched 
tt_news 3.01. On my dev system I use both, tt_news 3.1.0 and tx_news, 
both share the same news storage folder and pages, so I can see 
differences in a second. Everything seems to be fine for the default 
language – but not for any additional language.

DAM assets are not localized, and overwriting in the flexforms didn't 
cure the problem. Same for Images included via the RTE. I tried all 
combinations of


1) Entering everything into the RTE form: Default language seems to be 
ok, but all assets are missing in the localized versions. After playing 
around I found an alternative variant. Default and localized text 
version, but assets from DAM only in default language (captions, 
alt-text, titles).

2) Using only the teaser field and a DAM image for the list view, plus 
additional content elements: Same problem as under 1) for the referenced 
image, but the content elements seemed to be ok (I tried Text/w.Image, 
and all DAM functionality was available – at least for the default 
language). I found no way to translate this record later. Nothing 
happened in the BE after clicking the localization buttons.

Like tt_news, tx_news defines it's own „content element“, as part of the 
Model. For me the question is, why? Wouldn't it be possible to really 
use default content elements (tt_content) within tx_news, getting rid of 
all the MVC/Extbase/DAM/RTE issues and discussions? Reducing the model 
to the pure management of a teaser, special, news related data (archive 
settings, top-news) and keeping track of tt_content records, which form 
the body of the detail view. It would result in a lightweight news 
system with all the power of the core technology. I don't know if 
Extbase offers a feature like „give me a record of tt_content in the old 
fashioned way and allow me to manipulate/edit it without changing its 
structure“? If not, it might still be possible to place all standard 
content news elements on a not-in-menu page and link them to the proper 
news record. All localisations could be handled inside the page module, 
where DAM includes without any problems until the day being.

Probably the reason for the current behaviour is either Extbase, which 
might not be ready for production, or DAM 1.x, which was never designed 
for MVC or Fluid. Couldn't all these problems be avoided by 
concentrating on the use of standard content elements instead of own ones?

What would be the right approach to my problem, especially if waiting 
for Extbase 2.x or DAM 2.x is not an option? I can either carry on using 
my patched tt_news 3.01 with a version freeze of TYPO3 4.5 or move on to 
a later TYPO3 version and say goodbye to multilingual projects with the 
need of news. Seems like a decision between plague and cholera.


Is there any best practice in the current situation?

Greetings from Holland,

Thomas Skierlo