Home › Toolset Professional Support › [Resolved] In Loop Modals and TinyMCE Violations
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
- | 10:00 – 13:00 | 10:00 – 13:00 | 10:00 – 13:00 | 10:00 – 13:00 | 10:00 – 13:00 | - |
- | 14:00 – 18:00 | 14:00 – 18:00 | 14:00 – 18:00 | 14:00 – 18:00 | 14:00 – 18:00 | - |
Supporter timezone: Asia/Kolkata (GMT+05:30)
This topic contains 7 replies, has 2 voices.
Last updated by Minesh 6 months, 3 weeks ago.
Assisted by: Minesh.
Hello,
I'm trying to use creation and edit forms in modals, and all this works fine, but I've run into a cavitate.
If I use a WYSIWYG editor then the modals can create 50+ iterations per view load easily as they have to be in the loop to work correctly. and the WordPress TinyMCE version is very old and generates this error:
[Violation] Added non-passive event listener to a scroll-blocking <some> event. Consider marking event handler as 'passive' to make the page more responsive.
About 5 of these are generated per instance of the TinyMCE editor, and if there are 50+ instances, you can see how this gets bad quickly. The page is very slow to load and I'm not sure how much of this is the errors and how much of it is the numerous iterations of the TinyMCE editor.
The only other option is to use a Textarea for a multi-line entry, but this lacks all of the formatting options so severely limits things that way too.
So I'm after an opinion if there is a better way to generate a modal that can be used generically with Toolset view loop items without it being in the loop itself, or if there is any known way of working around this issue with the TinyMCE editor with the Toolset WYSIWYG fields and speeding up page loads.
Hello. Thank you for contacting the Toolset support.
You are using custom solution and as per our support policy we do not entertain such custom edits.
However:
You're adding 50+ instances of tinyMCE editor to the page, even though via the modal you may only end up displaying one of them. (Or none.)
It's a poor way to do this, but in the context of Toolset Views and Forms, there isn't really another way.
A better solution would use the REST API or an ajax request to only get the form to display in the modal when the modal was opened but I'm not sure if you able to achieve that or contact any of our certified partners for such custom programming.
- https://toolset.com/contractors/
I would suggest that they at least if you can paginate the page where they are adding the forms to add a smaller number of instances at a time, rather than 50+.
Or even you would like to check the following links that might help you to fix the issue:
- https://stackoverflow.com/questions/39152877/consider-marking-event-handler-as-passive-to-make-the-page-more-responsive/68004818#68004818
- https://stackoverflow.com/questions/46094912/added-non-passive-event-listener-to-a-scroll-blocking-touchstart-event
To be clear, I'm not using anything custom about Toolset whatsoever. I am simply asking you about the way Cred loads the TinyMCE editor and if there's any undocumented hooks (as I know you have plenty of them) that can be used to prevent TinyMCE loading with the page and instead load with the modal instance such as within this jquery block if it was en Elementor modal or example:
jQuery(window).load(function() { jQuery.each( elementorFrontend.documentsManager.documents, ( id, document ) => { if ( document.getModal ) { // It's a popup document document.getModal().on( 'show', () => { /*Code goes here*/ } ); } }); });
I know that loading so many instances is a bad approach, that's why I'm trying to figure out what my options are. I'm not asking you to engage with a custom solution at all, simply provide information. Given that the REST API isn't something I've considered, is there any guidance on how to load a cred form that way? The only documentation I can find on your site is regarding exposing Types fields to it: https://toolset.com/documentation/programmer-reference/toolset-integration-with-the-rest-api/
Regarding the errors generated specifically, the first link you provided suggests including a library via this line of code:
<script type="text/javascript" src="<em><u>hidden link</u></em>"></script>
This does indeed seem to resolve the Non-passive Listener Event violations, just leaving some Avoid using document.write() violations. So that's most of the issue solved at least. But these do seem to be core WordPress related issues due to their ancient implementation of TinyMCE. Does Toolset have any means or plans to integrate a more modern WYSIWYG editor?
I do not aware of the plan about adding more fancy WYSIWYG editors for now but you can always file a feature request:
- https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/
It is on your now with what approach you would like to go with. Honestly I suggest you to do not add form in popup as you may find issues with that sooner or latest when plugins/theme have updates in future. Even though we fix it for now - there is a possibility that you may have issue and it will become a cycle.
However - I'm just curious, May I know how exactly you are adding modals - is edit form link added to view?
Can you please share few screenshots how exactly you added the modal, in case I can guide you other idea otherwise.
There are a few different ways I've been using modals and popups depending on the implementation and ease. In this specific instance, it is part of the View Loop Item template like so:
<td>[wpv-post-link]</td> <td>[types field="event-start-date"][/types]</td> <td>[types field="event-start-time"][/types]</td> <td>[types field="event-capacity"][/types]</td> <td class="button-layout"> <button type="button" class="btn btn-secondary control-button" data-toggle="modal" data-target="#editEvent-[wpv-post-id]">Edit Event</button> [wpv-view name='event-attendees'] </td> <!-- Edit Event Modal ---> <div class="modal fade" id="editEvent-[wpv-post-id]" role="dialog" aria-labelledby="editEventModalLabel-[wpv-post-id]" aria-hidden="true"> <div class="modal-dialog modal-lg" role="document"> <div class="modal-content"> <div class="modal-header"> <h2 class="modal-title w-100 text-center" id="editEventModalLabel-[wpv-post-id]">Edit [wpv-post-title]</h2> <button type="button" class="close" data-dismiss="modal" aria-label="Close"> <span aria-hidden="true">×</span> </button> </div> <div class="modal-body"> [cred-form form='edit-event'] </div> </div> </div> </div>
I know that this is an implementation that isn't natively supported by Toolset (although it REALLY should be something you incorporate), but having forms popup for the users to use feels so much cleaner and more professional looking than being taken to another page for it to be shown if that makes sense.
Ok Based on the code you shared and I review that and I see you configured the modal correctly.
What if you try to add the following code:
jQuery(document).ready(function(){ document.addEventListener("wheel", function(e) { e.preventDefault(); // does nothing since the listener is passive }, { passive: true }); });
Or try to use the following:
- https://stackoverflow.com/a/48098097
You will have to follow such solution as I'm afraid I do not have any other solution or workaround to offer.
I've seen similar things but I haven't managed to get anything to work at the moment. If you could leave the ticket open I'll have a play with this when I next get a chance in a day or two and report back afterwards, just to complete the information on here if nothing else.
Ok fine - just changing the status of the ticket and ticket will be open for a week.