New TipTap WYSIWYG Editor

Help
1

Anyone else in a real pickle with the change to TIpTap? We primarily use Directus as a page builder and we had several custom block level formatting options to add classes to paragraphs in the TinyMCE WYSIWYG editor. But the TipTap editor only allows adding classes and attributes to inline elements.

Also lost the ability to add in the custom CSS through the “content_style” key in the options override. We were using that to style things in the WYSIWYG editor so that they looked the way it was going to look on the page.

I also had a custom extension that allowed us to wrap images in a figure tag with a figcaption.

Worst of all is the option to change the default save option is also in v12.2 and I can’t use it until we figure all this out!

It would be super helpful to see an example of creating a custom extension for the TipTap editor within Directus. I used this one as a model for creating the figure/figcaption extension for TinyMCE.

I don’t know how many other extensions on that list probably need a note that they probably won’t work with Directus v12.2 if it is using TinyMCE under the hood?

1 Answer

1
2

Thanks for the feedback @matt! This is just the beginning of our adoption of TipTap. We’ve discussed many of the things you’ve highlighted, and I hope to have things like custom extensions and customizations added soon.

One thing they might help us a bit would be some example markup that matches how you’re using TinyMCE today. This way we can evaluate if/how to handle that ourselves or how to help you extend it yourself to address it. This can help us identify gaps we didn’t anticipate and help you be able to adopt it more quickly!

So we had some formatting options to apply classes to block level elements. Like applying a "float-left" class on an image so we could float an image next to text. Or adding an "eyebrow" class to style some text. Or adding a "latex" class to a paragraph so I know to run it through our LaTeX processor. I had a class to make the first letter of that paragraph a dropcap.

 –

Continuing my previous comment since I can only add 600 characters. I understand that I can shift to adding spans in the block to add those classes, but that means I have to go and change my CSS to handle both the old way and the new way. It's just one of those things that clutters up my code because I have to handle the pre-v12.2 fields that are already saved as well as the post-v12.2 differences. And wrapping everything in spans just looks weird to me. I know it doesn't functionally make much difference, but I'll know its there.

 –

But the thing that is going to prevent us from moving to 12.2 is the figure and figcaption. And adding the classes to float items in the markup is probably also going to be weird but I need to spin up a dev environment (something that was a lot easier before the licensing changes) to test a bunch of stuff. But if there are updates that alleviate these things then we'll probably just wait for those.

 –

Very helpful. I don't have any kind of timeframe at the moment, but I'll discuss it with the team and see what we can do.

 –

Oh, another thing that would be AMAZING is if we could change the alt text behavior when adding an image via WYSIWYG. I would love something like a feature flag environment variable we could enable that would force the users to enter alt text on an image or purposefully mark it as decorative. I have always found the behavior of the imageDrawer component or useImage automatically adding the filename as the alt text to be troublesome because the file name is never going to be good alt text. If that's too much, then the default should be to leave it blank so we know to just mark it decorative.

 –