Defer initialization until interaction

[john-golden]

Bug description

It it possible to defer the initialization of the TinyMCE instances until a user interacts with the editor? If there are multiple instances on pages using replicator sets the usage limit is quickly reached.

Steps to reproduce

Use the TinyMCE field in a multiple instances per page.

Environment and versions

Environment
Application Name: Statamic
Laravel Version: 11.8.0
PHP Version: 8.2.12
Composer Version: 2.6.3
Environment: staging
Debug Mode: ENABLED
URL: localhost
Maintenance Mode: OFF

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: statamic
Database: mysql
Logs: stack / single
Mail: mailgun
Queue: sync
Session: file

Statamic
Addons: 5
Sites: 1
Stache Watcher: Enabled
Static Caching: Disabled
Version: 5.6.1 PRO

Statamic Addons
mitydigital/feedamic: 2.3.3
mitydigital/statamic-tinymce-cloud: 3.0.0
rias/statamic-data-import: 1.5.0
statamic/seo-pro: 6.0.3
teamnovu/statamic-images-missing-alt: 1.0.4

Additional details

No response

[martyf]

There is one thing we could do - which is a bit poor from a user authoring experience. This would need to be opt-in too (as not everyone would want/need this).

But could have a "deferred loading" mode that would show a preview of the current value (maybe just wrapped with a prose wrapper - but would lack other styles (unless you link to something like the content_css option within the CP too), and have a button that says "enable editor" that when clicked loads that instance only.

Something like:

Plus side: only loads when needed Downside: every instance would need a click, and preview may be a bit poor

Config-wise this needs a few things: 1 - a content_css option at the main config option (so you can set the CSS per editor config globally) 2 - a deferred loading option at the main config per editor config (sets the default for that editor type), and 3 - a deferred loading option that can use the default or override the editor instance (i.e. force it) within a specific blueprint/fieldset

Do you think that would solve the problem for you, but still give a decent authoring experience (given the restrictions we're working towards)?

By the way, what limit are you reaching with Tiny? Is it stopping too many instances being rendered, or the number of loads per month?

[john-golden]

Thanks for the reply and looking into it! I think your solution makes perfect sense and would solve the problem.

The limit we are reaching is just the 1000 hit per month limit on the free account. Normally it wouldn't be much of an issue, but when using these in a Replicator field for a page builder setup and most blocks have a content editor, the hits start adding up really quick during the content population phase for a new site.

Thanks again for looking into this; especially since it's kind of an edge case scenario.

[martyf]

Cool bananas, that all makes sense.

I'll get this polished up sometime this week and pushed out as a minor update. I'll keep the issue open until then and will let you know when it's tagged (and will update the docs to help you configure it all too).

[martyf]

This has been released in 3.1.0.

Full details at: https://docs.mity.com.au/tinymce-cloud/configuration/defer-initialisation

[john-golden]

@martyf Thanks for turning that around so quickly! I'm having a couple issues however that you may be able to help me resolve hopefully. After the update and without deferral turned on, I'm getting the "Your requested Tiny Cloud config could not be found. Please confirm your Blueprint and Tiny Cloud configurations." error when loading an instance in the admin. I tried removing and regenerating the config with php artisan vendor:publish --tag="statamic-tinymce-cloud-config" but that did not help.

If I do enable deferral, on the content preview/enable section does not appear in some instances. From what I can tell it is when there is more than one instance of tinymce on the page. If I have a singular instance I do see the option to enable the editor, and then when I do it throws the same error regarding the config not being able to be found.

[john-golden]

I was able to resolve the missing configuration issue. It seems like it programmatically removed "config: {{config_name}}" from the .yaml file for the field. Once I replaced that the error resolved.

[john-golden]

And the other issue seems to have been caused by the removal of that config line also, so I'm all good and it's working wonderfully. Thanks again for adding this feature!

[martyf]

That's really odd @john-golden, I can't replicate. I created a new install with 3.0.1, and got it up and running and working correctly. Upgraded to 3.1.0 and everything continued to work. I don't suppose you can replicate it?

[john-golden]

@martyf no I can't replicate it again. Probably safe to assume it was something I caused at this point.