I am trying to add the config for the TinyMCE field, but there is no change at all. I am using a config from a sample of TinyMCE website. Am I doing something wrong? I tried many ways to make it work but none worked.
const { Wysiwyg } = require('@keystonejs/fields-wysiwyg-tinymce');
fields: {
title: { type: Text, schemaDoc: 'Title for published article' },
text: {
type: Wysiwyg, editorConfig: {
plugins: [
'advlist autolink lists link image charmap print preview anchor',
'searchreplace visualblocks code fullscreen',
'insertdatetime media table paste code help wordcount'
],
toolbar: 'undo redo | formatselect | ' +
' bold italic backcolor | alignleft aligncenter ' +
' alignright alignjustify | bullist numlist outdent indent |' +
' removeformat | help',
content_css: [
'//fonts.googleapis.com/css?family=Lato:300,300i,400,400i',
'//www.tiny.cloud/css/codepen.min.css'
]
}
},
}
Oof! The version of @keystonejs/fields-wysiwyg-tinymce with the editorConfig setting hasn't been released yet. Once #2447 is merged and you update your package everything will work.
Sorry for the confusion. The doc update got deployed before the package was 馃槵
Alright, thank you for your answer! I was very confused this morning because I was following the documentation and it was not working. Do you know if there is a release date for this new version?
Should be in the next few days.
Will one be able to pass an apiKey to TinyMCE as well, in order to be able to use premium plugins, TinyDrive, etc?
@ra-external as long as it's accepted by tinymce.init(), yes.
EDIT: looks like it's a separate option. I'll open a separate PR.
EDIT 2: actually, question. Is the apiKey only relevant when using the cloud integration?
@Vultraz -- It's my understanding that it's also required to access the premium plugins. Also, if you access to the premium plugins it's an order of magnitude cheaper with cloud hosting -- https://www.tiny.cloud/pricing.
From what I can see, when you have the apiKey you load the tinyMCE code directly from the TinyMCE CDN, whereas I believe Keystone is loading it from a file. I've been trying to work up a custom field based on your TinyMCE code which would load from the CDN, but so far it's been a bit tricky, and ideally I'd prefer to use the 'built-in' field.
Ideally one would be able to pass an optional apiKey to the Keystone TinyMCE field and if it's present the Keystone field would pull the code from the CDN, using that key, giving the user full access to their paid version of TinyMCE.
That's exactly what I was trying to implement today, actually. It doesn't look like there's any way to load from a file while still using the premium plugins, so I was trying to make it ignore the local one and fetch from the CDN if an apiKey is provided. I think I may need to submit an upstream patch to tinymce-react. The fact that it relies on a global variable instead of a prop is so annoying...
@Vultraz -- tinymce-react ? That's what I was considering, simply putting the tinymce-react component inside the custom field, because, for reasons I can't figure out, it's proving impossible to use a useScript hook to add a script there. There is the option of passing an apiKey to tinymce-react at present.
Include the apiKey option in the editor element and include your Tiny Cloud API key.
Such as:
<Editor apiKey='your-api-key' init={{ /* your other settings */ }} />
How is the data getting saved back to Keystone? Through the onChange prop that's passed into the field? So one would simply need to make the same connection with the tinymce-react component and it should work?
Yes, I switched to tinymce-react. Here's the current state of the code: https://github.com/keystonejs/keystone/blob/master/packages/fields-wysiwyg-tinymce/src/views/Field.js
It's easy to pass in an apiKey field config option and to pass it along to the Editor prop. The problem is that we want to both use the self-hosted version if no api key is provided in the field config or the CDN version if it is, and the way tinymce-react decides which to use is whether the window.tinymce variable is set: https://github.com/tinymce/tinymce-react/blob/master/src/main/ts/TinyMCE.ts I can't figure out a good way to set that conditionally.
I believe window.tinymce is set by TinyMCE itself when the script is loaded, which tinymce-react does in lines 74++ of https://github.com/tinymce/tinymce-react/blob/master/src/main/ts/components/Editor.tsx using https://github.com/tinymce/tinymce-react/blob/master/src/main/ts/ScriptLoader.ts -- or perhaps I misunderstood...
Yes, it is. The problem is window.tinymce is global, and it needs to be set by different sources depending on whether you provide an apiKey or not (local or CDN). But tinymce-react won't load anything from CDN if window.tinymce is already set. Imagine you have two different lists each with a WYSWYG field, but only one with an API key. Accessing the first one means the global window.tinymce variable is set, and then the CDN won't be properly loaded for the other...
The editorConfig option should now be available if you update your package.
Thanks -- do you mean reinstall Keystone from NPM, or download NPM from GitHub, or just the editor files themselves?
Does this include the possibility to pass an apiKey as well?
You just need to bump the'@keystonejs/fields-wysiwyg-tinymce' dependency in your project to the latest version and run yarn or npm up depending on what package manager you use.
The update doesn't include an apiKey option, though. I'll have to handle that separately.
@ra-external what would be the downsides if the field didn't import tinymce at all itself and instead required an apiKey (ie, only used CDN distribution)? Would it make it harder to use?
@Vultraz -- Could you explain what you mean in more detail? You mean the official WYSIWYG field from Keystone would only import the CDN, not have a local copy? How might that make it harder to use?
For me, anything that makes the Keystone use as similar as possible to the official TinyMCE use would be great. One thing that would be nice is to have access to the actual TinyMCE instance, since some of the TinyMCE sample code requires that (I'm thinking particularly of a file upload example).
Yes, that's what I meant. The only downside I could see would be that one would need a TinyMCE Cloud account to use the field.. but we already require that for stuff like the CloundinaryImage field. So it's not unprecedented 馃
I think one can have a free, 'community', account -- https://www.tiny.cloud/pricing/ -- and still get an apiKey, right? I'm a bit unclear because I currently have a 30 day trial, with apiKey. I don't know what happens when it expires. That is, one can pull from the CDN without paying? If not, that would be a deal-breaker.
The only other problem I see is that one would need to have internet connection to pull from the CDN, but running without connection is such an edge case I wouldn't consider it.
@Vultraz -- I tried the new package but it didn't work for me the same way tinymce-react did (I was importing tinymce-react into my custom field). Specifically, the package TinyMCE doesn't seem to recognise that there is a images_upload_handler, which should be passed, along with everything else, into init. I assume that, underneath the hood, the package is simply loading from the CDN? Or not? In answer to your earlier question, I think it would be best to load directly from the CDN just to make sure that there's always a common -- and upgraded -- source.
@ra-external tinymce-react is using the version of tinymce the fields package ships with, not the one from the CDN.
You're right, though... that option doesn't show up. 馃 I think that's because it's a function... It might have something to do with webpack and how the field config data is passed to the Admin UI...
It looks like there hasn't been any activity here in over 6 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contribution. :)