Opened 11 years ago

Closed 11 years ago

#10696 closed Bug (duplicate)

Subsequent CKEdit boxes are not updated prior to submit

Reported by: Matt Owned by:
Priority: Normal Milestone:
Component: Core : Output Data Version:
Keywords: Cc:


I've encountered a problem with CKEditor (v4.2) as provided by v1.2.0 of TrSteel CKEditor Bundle for the Symfony 2 framework.

My application is using a mixture of JavaScript libraries, which include jQuery 1.10.2, Twitter Bootstrap 3.0.1 and plugins/extensions thereof.

In this instance, I have a doctrine entity with two attributes manifested that are manifested on the corresponding form type as two CKEditor boxes. The rendering and on-page functionality isn't a problem, and I have confirmed that ckeditor.js has attached an event handler to the encapsulating form's "submit" event. However, on submission, only one of the values is updated to the original textarea element and as such, only one value is submitted while the others remain blank (or whatever they happened to be when the page was was loaded).

Based on the solution to a similar historic issue (#9913) I implemented a rather hacky global workaround that invokes updateElement() on each object within CKEDITOR.instances on the submission of any form (with the appropriate defensive code in place for forms without CKEDITOR defined in the global JS scope).

I haven't been able to duplicate this on a "clean" Symfony 2.3.2 application with TrsteelCkeditorBundle installed and configured (but no jQuery/Twitter Bootstrap et al), which suggest that compatibility problems with other JS libraries may be responsible. Is this a known issue?

Change History (4)

comment:1 Changed 11 years ago by gifad

This is probably correlated to Save toolbar button saves only first instance, which is currently unhandled, but much easier to reproduce (happens with ckeditor samples) I thought it was a problem with the "Save" toolbar button, but it could actually be a timing (sync/async) problem in textareas updating ?

comment:2 Changed 11 years ago by Jakub Ś

Status: newpending
  1. Could you provide sample and reduced application showing this problem?
  2. Could you try version 4.1.3 to see if you still have this problem. If not then it is possible that this problem is caused by #10689.
  3. If not then this might be caused by some JS library. I know jQuery was causing some problems for editor (not other way around :))

comment:3 Changed 11 years ago by Matt

Apologies for the late reply; software releases wait for no man. :(

As requested I forced version v4.1.3 (and disabled my workaround) and this issue does not occur, so I'm inclined to agree with your assessment.

Although it'll take some doing, I'm happy to produce a reduced sample application this evening (GMT) if you still think it's necessary?

comment:4 Changed 11 years ago by Jakub Ś

Resolution: duplicate
Status: pendingclosed

If changing version to 4.1.3 in your application has solved the problem then I think we can assume that this is a duplicate of #10689.

I will close this issue for now but If you however think that this isn't the source of the problem or problem will still exist in version 4.2.1 (when #10689 will be fixed) please provide reduced sample and I will check this.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy