TYPO3 Core

I figured out that the content of the "empty" fields when editing the FCE is there. But only in hidden fields. Could it be, that this is a TYPO3 4.2 UI issue? Seems that some js is not working correctly in TV FCE's ...

Ok. It has nothing to do with Sections. It is clearly the RTE. I have completely replaced all RTE-fields with normal textfields an everything works fine again.

damn i am not that into developing for TYPO3. Atm i can only reduce the error sources to the rte itself or the way templavoila implements it. Possible the core?

Seems to me like this issue is for the advanced T3'ler ... ^^

I made one more test. I placed 3 RTE fields in one FCE. Everything works fine. But if i make a section and than place an RTE field inside the whole FCE form will break as desrcibed.

I have exactly the same problem with TYPO3 4.2 and TV 1.3.4

I have created an FCE with sections and a textfield and an RTE field inside that.

I get a pop up to relogin when trying to save the FCE and the text from the textfield is not been saved. Only the RTE content is being saved.

Did you find any fix for that?

Sorry ... i still have the problem. Seems like this issue has somtehing to do with TV itself, the RTE ext or the Core. So solving this is way to big for me.

But i found a "workaround" ... Cause it is just a JS Bug and the data is just not shown right but delivered right you can still use the FCE forms just by klicking "abort" when the message with the relogin appears.

This way it is possible to create and edit FCE's even with this bug. The only problem is, that you don't see what you are editing. I didn't try to "test this workaround" with more complex FCE's which e.g. have images inside or a link field.

Same problem here. (TYPO3 4.2, TV 1.3.6)

In addition to what's already reported, the header field (from tt_content) doesn't get populated in my case.

Disabling the RTE fixes these problems immediatly, but unfortunately that is nothing I can offer an editor as a workaround. ;-)

I can confirm what Oliver mentioned, too. And upgrading to version 1.3.6 doesn't solved it, too.

I confirm this bug too.

I have the same problem

Hi,

I've just noticed the same problem. The problem is that the JavaScript code for an RTE is inserted on the page but not the HTML the JS is refering to. Seems like TCEforms generates templates for items that may be inserted into the sections. That's why it also calls a function to generate a RTE element. The HTML for the RTE is not rendered, but the JS Code is saved internally and inserted later. That's why the initEditor function fails. This JS error also causes the backend to think your login has timed out.

Unfortunately this is not easy to fix, but I found a quick fix to get around the login timeout problem. See the patch for htmlarea.js I've attached ( fce_with_section_and_rte.patch ).

It checks if the node for the RTE exists before it is initialized to avoid the resulting JS errors. Like this you get rid of the timeout alert when saving. But if you create a new item in a section, you won't get an RTE for the text field, but if you just save you will get the RTEs as the page reloads. It seems like the RTE handling for sections in FCEs is not yet completely implemented in TCEforms. If I've the time I'll have a look at how this is handled by IRRE and try to supply a better patch.

I forgot to mention, you might want to delete the cache files in typo3temp/rtehtmlarea/ and clear your caches.

I can confirm the bug too. I have a complex FCE with possibility to create several RTE's only one or two of them works, and Erwins descriptions seems resonable. Can someone confirm that this is a bug for TemplaVoila or should the bug be handled by RTE guys? Seems like it has been alive for some time.

I've allready posted it in the rte section, too.

See here http://bugs.typo3.org/view.php?id=8570

Till now there's no response either. Shall we switch to louder drums? =) Does someone has the louder onces? =/ Actually i've no idea what to do more.

Perhaps Erwin is able to handle this one!? =/ Seems like he has the deeper understanding of this bug.

Louder drums could be a post on the templavoila mailinglist, I'm not personally enrolled there though.

I don't have any experience with the sourcecode so I hope that this can be fixed by a competent person before I have to invite editors on my current project, otherwise I will look into the bug later.

I guess the most appreciated louder drum you have available is to sponsor the bug.

We we "solved" it by switching (temporarily?) to TinyRTE. Quite obviously not a perfect solution.
[UPDATE] We THOUGHT we found a workaround with tinyrte. however:
the good thing: no login popup appears and it's possible to edit already existing textfields.
the bad thing: when creating a new element, the rte is disabled

research results: it's hard to make rte's and scriptaculous work together.
Anyway, something like this issue was on the TO DO list of the IRRE project:

http://wiki.typo3.org/index.php/Jp:Inline_Relational_Record_Editing
"OK bugfixing RTE problems for cascaded inline fields over more levels (positioning, width, height) "
But it doesn't really sound like the problems described here (that page has been edited eleven months ago ... ).

A possible solution (implemented in Rails...) was to enable / disable the editor (tinyMCE), an approach that is taken a bit further by http://inplacericheditor.box.re (based on tinyMCE).

BTW: using tinyrte the only workaround is to create an rte area and save it (even though it's empty). Afterwards the rte loads as expected. Drag and Drop however is now impossible.

I've added the TemplaVoila Flexible Content Element Data Structure for the problem we're encountering.

The problem is only with TYPO3 code for HTMLArea. It has nothing to do with scriptaculous or htmlarea javascript code. I managed to make working everything except saving RTE data. The problem is that rtehtmlarea code rely on the increasing counter in TCEforms. This does not work for sections. Content cannot be saved with rtehtmlarea but will work with other RTEs.

Where does that put os solution-wise? Is it not possible to get it working like it should?

Oh ... OK.

Does this mean, that the only chance is to switch to another RTE like Tiny? Or are there plans to get even rtehtmlarea work with it?

Good tosee you here btw. =)

I was able to reproduce this issue (or these issues).

The first issue is that JS code is inserted for twice the number of RTE-enabled fields that are actually present.

This issue eventulally leads to a JS error when initialization of a non-existent RTE area is invoked.

Sounds like some great progress here.

As a reminder, the 450 Euro bounty offer is for a working fix by Monday 10 AM Eastern. After that, it goes back to 300 Euro.

In short, make some good money fast here with a proven fix to test by Monday morning.

Thank you.

I have a patch to fix almost everything. The problem now is in the rtehtmlarea extension. It uses sequental numbers from TCEforms for editor instances. This works for normal CE elements but for sections these numbers are absent. Therefore every RTE is saved in the value of the first RTE. This is the only remaining problem. Otherwise my patch completely solves the issue.

Notice: it is truly the problem of rtehtmlarea. Other RTEs will work properly with my patch.

Can there a be a fix of rtehtmlarea then?

Some clients are used to rtehtmlarea and have them configured specifically. Changing out causes much grief to devs and clients.

Well, it would be easy to avoid the initial error. However, the error is just a symptom of a more difficult issue.

For each element of the structure that may be repeated, the flexform creates a model html section to be inserted in the form only when the add new button is pressed.

First issue: When the model html section is created for a RTE-enabled element, corresponding JS statements are also created, and inserted in the page. Thus, we initially get JS code that refers to non-existant html. This is the cause of the JS error.

Second issue: Each RTE area is uniquely identified, because it may have its own configuration. But when the add new button is pressed, the RTE area is always inserted with the same identifier that appears in the model html section. Moreover, the RTE is not initialized. Because the RTE is not initialized, the area appears as plain text. If the flexform script is modified to initialize the RTE, the identifier issue remains, causing the save issue.

Of course, if the new element contains multiple RTE-enabled elements, the problem gets even worse.

Thank you for the thorough explanation. How do you recommend proceeding to the best solution?

Stanislas, actually, identifier will be different, that is already fixed. The problem now is the function named setSaveRTE(). It code:

    function setSaveRTE($RTEcounter, $formName, $textareaId) {
        return '
        editornumber = '.$RTEcounter.';
        if (RTEarea[editornumber]) {
            document.'.$formName.'["'.$textareaId.'"].value = RTEarea[editornumber]["editor"].getHTML();
        }
        else if (!RTEarea[editornumber].deleted) {
            OK = 0;
        }
        ';
    }

Anyway... The function again uses $RTECounter, which is always the same number in case of sections. I fixed sections to add this postJS to every new section element but the problem is with the counter. Since it is always the same, all RTEs now save to the field of the same RTE. Imagine you added two elements to section like this in the form:

----------
Header: aaa
RTE: aaa
----------
Header: bbb
RTE: bbb
----------

After saving it becomes:

----------
Header: aaa
RTE: bbb
----------
Header: bbb
RTE: bbb
----------

And this happens only due to the second function! If we could fix it not to use the hardcoded number but HTML id, for example, that would completely solve the problem I think. But I do not have enough knowledge about RTE to fix it.

The submission code procuded by RTE currently looks like:

        editornumber = <b>1</b>;
        if (RTEarea[editornumber]) {
            document.editform["unuqie-id-<b>1</b>"].value = RTEarea[editornumber]["editor"].getHTML();
        }
        else if (!RTEarea[editornumber].deleted) {
            OK = 0;
        }

        editornumber = <b>1</b>;
        if (RTEarea[editornumber]) {
            document.editform["unuqie-id-</b>2</b>"].value = RTEarea[editornumber]["editor"].getHTML();
        }
        else if (!RTEarea[editornumber].deleted) {
            OK = 0;
        }

Dimitry, Stanislas:

Is there a related RTE issue ticket that we can connect and discuss with RTE devs?

Yes ... there is one. http://bugs.typo3.org/view.php?id=8570

I've multi posted this issue in diffrent areas because i was not sure if it is a core, RTE or TV issue.

But perhaps it would be a goog idea to open a totaly new one because of the probably missleading title. I think with the gained information in this thread another title would be better to get attention of other devs.

I don't feel confident enough to create the new HTML issue. Could another do it and then post the link and relate this and the new issues?

I'd be happy to post some funds for sponsorship on that issue to combine with this issue.

Dennis, TV does not create, show or process forms. It is all done by TYPO3 core. So all sections and RTEs is TYPO3 core stuff.

• * *

General update: after fighting with lots of JS code I produced something monstrous that seems to work... I will make some more checks and post the patch for trying. Now it works ok in FF but I am not sure that my changes will work in MSIE6.

Dimitry, now i'm wiser. ;) But at the time of my first encounter with this issue i've just thought of 3 possibilities. I was'nt that far away. ^^

I will test your patch as soon as i notice it.

Seems that posting to the mailing list is much more effective than just here!? Days over days nobody who was able to handle this one. And now after one little hint to the mailinglist ... just as i expected the bugtracker to work. hehe ^^

Dennis, it is not just a hint in the mailing list, it is also amount of sponsoring that makes a difference :D

The patch is attached...

I forgot to say: the patch is not too clean. There is commented code and some things should be formatted better. But now we need to know if it works for everyone.

I confirm that patch works on clients dev system. I'll try on live now.

Patch works on live. Thank you Dmitry. Do email at michael@cannonbose.com for arranging payment.

I can confirm as well that the patch works.

Thank you to Michael Cannon for sponsoring the bug, the 30€ I could offer wasn't really much leverage for such a complex bug, so thank you!

Dmitry, thank you for the patch, I have used the "Donate" button on typo3bloke.net to send you the 30€.

@Dmitry Dulepov: The patch looks good to me from initial reading and testing. However, please do not use prototype.js constructs in rtehtmlarea code, because the RTE may be used in the frontend with some other incompatible framework loaded on the same page and would then fail.

Søren, thanks! :)

Michael, mail sent! :)

Total it took nearly 11 hours to fix it. This a personal record for me for a single bug :)

Works like a charm! Well spent 11 hours of life juice. ;)

Is it going into 4.2.2?

Stanislas, "do use" or "do not use"?

A brief comment;

One of my clients suddenly experienced the following error message "Warning Editor url is not set".

She reported that it worked fine earlier, but seemingly after the patch the error occured. I have asked for more details and possibly a screenshot.

Her site is running on 4.2.1 without templavoila.

Maybe you know how this could happen, either way, I will report back. On google I found this issue with htmlarea, where a clearing of the persons cookies helped.

UPDATE: I can reproduce it know, and it seems to be a consequence of this patch. It happens when you click the button "Edit in Rich Text Editor", I didn't discover it, because I normally use the pencil to edit things.

@Dmitry Dulepov: Sorry, I meant do NOT use prototype.js.

You also need to apply your logic to the frontend version of the RTE: see rtehtmlarea/pi2/class.tx_rtehtmlarea_pi2.php which extends tx_rtehtmlarea_base for the frontend.

Søren, don't know :( I made lots of tests and did not see such problem. Am not sure because 4.1, RTE can be different there.

Stanislas, ok, will take care in the end of next week. I hope you can review it in the core list when I post it.

Stanislas, are you sure pi2 needs changes? There is no such problem in FE, so we could keep the old [simple] code in pi2.

Yes, Dmitry, I am quite sure. I cannot test it right now because of the use of proptotype.js in your current patch. But if you test with any extension that uses the RTE in the frontend, I expect that it will fail.

You need to apply the same logic to the teaxtarea id, save js, etc.

Here is a new patch. Can you test it? I do not have any test ext with RTE in FE.

$("pleasewait' . $textAreaId . '").id = "pleasewait" + editornumber;

fails in FE.

Here is the fix for $().

Thanks for testing!

Dmitry, here is a corrected patch tested in FE.

Stanislas, thanks! :) I'll post it to core list now!

Btw, the patch is in the core list. So if any monitoring guys want to see it in the next TYPO3 version, vote for it in the core list! I need one more +1 there.

Wrong patch was committed. RTE now broken in FE.

I recommitted patch v4

There is still an issue. The RTE wizard for full page view produces a JS error.

The attached patch will fix the RTE wizard issue. It will also fix the fact that the contents of the textarea is not initially hidden while the RTE is being loaded and initialized.

Committed follow-up patch to trunk revision 4002.