Bug #18690

Creating and editing of fields, forms, etc. in FCE's is impossible if there is a section inside

Added by Dennis Geldmacher about 14 years ago. Updated almost 12 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2008-04-24
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.2
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

It is impossible to change the data in the whole FCE if there is just one SC inside. And even more the data is not shown in this fields if you try to edit the FCE. Just the first content of a rte field an the references to images are shown.

If you try to save or save/close the FCE you get an js alert which says that you have to login once more. A popup opens but says that you are logged in. So saving is impossible, too.

The picture shows a part of a normaly fully filled FCE.

I get this js error every time i try to edit a FCE which consists of SC's:
document.getElementById("pleasewait" + editorNumber) has no properties
setRTEsizeByJS(2)

(issue imported from #M8232)


Files

tv.jpg (313 KB) tv.jpg Administrator Admin, 2008-04-24 14:13
fce_with_section_and_rte.patch (820 Bytes) fce_with_section_and_rte.patch Administrator Admin, 2008-06-09 18:22
steps.xml (2.73 KB) steps.xml Administrator Admin, 2008-08-06 16:04
8232.diff (22.8 KB) 8232.diff Administrator Admin, 2008-08-08 16:35
8232_v2.diff (26.4 KB) 8232_v2.diff Administrator Admin, 2008-08-11 18:06
8232_v3.diff (26.4 KB) 8232_v3.diff Administrator Admin, 2008-08-11 19:08
8232_v4.diff (26.6 KB) 8232_v4.diff Administrator Admin, 2008-08-11 19:44
8232_wizard_and_display.patch (3.84 KB) 8232_wizard_and_display.patch Administrator Admin, 2008-08-19 01:50

Related issues

Related to TYPO3 Core - Bug #18036: Corrupted flexform dataClosed2008-01-21

Actions
Related to TYPO3 Core - Bug #19624: RTEhtmlarea does not work with IRRE after new child records were createdClosedOliver Hader2008-11-21

Actions
Related to TYPO3 Core - Bug #19477: RTE does not work in IRRE subelementsClosedStanislas Rolland2008-10-17

Actions
Related to TYPO3 Core - Bug #18697: Creating and editing of fields, forms, etc. in TV FCE's is impossible if there is a section insideClosedChristian Kuhn2008-04-25

Actions
Has duplicate TYPO3 Core - Bug #18881: JS Script of RTE produces error if a section is part of the formClosedDmitry Dulepov2008-05-31

Actions
Has duplicate TYPO3 Core - Bug #18967: RTE not loading with TemplaVoila FCEsClosedDmitry Dulepov2008-06-16

Actions
Has duplicate TYPO3 Core - Bug #19519: Save form with more then one RTE on a Flexible CE opens an popup with "Your login has probably expired"ClosedStanislas Rolland2008-10-28

Actions
Has duplicate TYPO3 Core - Bug #19865: RTE doesn't load when using more than 1 section in TVClosedStanislas Rolland2009-01-20

Actions
#1

Updated by Dennis Geldmacher about 14 years ago

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 ...

#2

Updated by Dennis Geldmacher about 14 years ago

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 ... ^^

#3

Updated by Dennis Geldmacher about 14 years ago

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.

#4

Updated by Hercules Karvasonis about 14 years ago

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?

#5

Updated by Dennis Geldmacher about 14 years ago

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.

#6

Updated by Oliver Berg about 14 years ago

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. ;-)

#7

Updated by Dennis Geldmacher about 14 years ago

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

#8

Updated by Xavier Perseguers about 14 years ago

I confirm this bug too.

#9

Updated by LinTong about 14 years ago

I have the same problem

#10

Updated by Erwin Eggenberger about 14 years ago

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.

#11

Updated by Erwin Eggenberger about 14 years ago

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

#12

Updated by Søren Andersen about 14 years ago

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.

#13

Updated by Dennis Geldmacher about 14 years ago

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.

#14

Updated by Søren Andersen about 14 years ago

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.

#15

Updated by Jack Skaba almost 14 years ago

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

#16

Updated by Jack Skaba almost 14 years ago

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.

#17

Updated by Michael Cannon almost 14 years ago

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

#18

Updated by Dmitry Dulepov almost 14 years ago

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.

#19

Updated by Søren Andersen almost 14 years ago

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

#20

Updated by Dennis Geldmacher almost 14 years ago

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. =)

#21

Updated by Stanislas Rolland almost 14 years ago

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.

#22

Updated by Michael Cannon almost 14 years ago

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.

#23

Updated by Dmitry Dulepov almost 14 years ago

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.

#24

Updated by Michael Cannon almost 14 years ago

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.

#25

Updated by Stanislas Rolland almost 14 years ago

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.

#26

Updated by Michael Cannon almost 14 years ago

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

#27

Updated by Dmitry Dulepov almost 14 years ago

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;
        }
        ';
    }

I already modified it a little to enable support for deletion of section elements. Without there will be a big alert saying that one or more RTEs cannot be contacted.

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;
        }

Notice that editornumber is always 1 but textareaid is different! Can you search for editor number by textareaid instead of using editornumber? I guess this is how tinymce works.

#28

Updated by Michael Cannon almost 14 years ago

Dimitry, Stanislas:

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

#29

Updated by Dennis Geldmacher almost 14 years ago

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.

#30

Updated by Michael Cannon almost 14 years ago

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.

#31

Updated by Dmitry Dulepov almost 14 years ago

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.

#32

Updated by Dennis Geldmacher almost 14 years ago

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 ^^

#33

Updated by Dmitry Dulepov almost 14 years ago

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

#34

Updated by Dmitry Dulepov almost 14 years ago

The patch is attached...

#35

Updated by Dmitry Dulepov almost 14 years ago

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.

#36

Updated by Michael Cannon almost 14 years ago

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

#37

Updated by Michael Cannon almost 14 years ago

Patch works on live. Thank you Dmitry. Do email at for arranging payment.

#38

Updated by Søren Andersen almost 14 years ago

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€.

#39

Updated by Stanislas Rolland almost 14 years ago

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.

#40

Updated by Dmitry Dulepov almost 14 years ago

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 :)

#41

Updated by Dennis Geldmacher almost 14 years ago

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

Is it going into 4.2.2?

#42

Updated by Dmitry Dulepov almost 14 years ago

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

#43

Updated by Søren Andersen almost 14 years ago

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.

#44

Updated by Stanislas Rolland almost 14 years ago

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.

#45

Updated by Dmitry Dulepov almost 14 years ago

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.

#46

Updated by Dmitry Dulepov almost 14 years ago

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

#47

Updated by Stanislas Rolland almost 14 years ago

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.

#48

Updated by Dmitry Dulepov almost 14 years ago

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

#49

Updated by Stanislas Rolland almost 14 years ago

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

fails in FE.

#50

Updated by Dmitry Dulepov almost 14 years ago

Here is the fix for $().

Thanks for testing!

#51

Updated by Stanislas Rolland almost 14 years ago

Dmitry, here is a corrected patch tested in FE.

#52

Updated by Dmitry Dulepov almost 14 years ago

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

#53

Updated by Dmitry Dulepov almost 14 years ago

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.

#54

Updated by Stanislas Rolland almost 14 years ago

Wrong patch was committed. RTE now broken in FE.

#55

Updated by Dmitry Dulepov almost 14 years ago

I recommitted patch v4

#56

Updated by Stanislas Rolland almost 14 years ago

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.

#57

Updated by Stanislas Rolland almost 14 years ago

Committed follow-up patch to trunk revision 4002.

Also available in: Atom PDF