The preview in CKEditor does not use the same Twig template as the one on the front end (default theme)

This sounds like the preview route doesn't use the front end theme.

Actually, turns out this was fixed shortly after you reported it, over in #2778355: TypeError: Drupal.theme.bootstrapModal is not a function! 🎉

I explained over at #3026433-7: `entity_embed.dialog` route should not use `_theme: ajax_base_page`; no longer required as of Drupal 8.2 why #5 was wrong, why this issue is still relevant, and why #3026433: `entity_embed.dialog` route should not use `_theme: ajax_base_page`; no longer required as of Drupal 8.2 actually originally reported the same bug as was reported here, almost exactly two years later.

Per #2745953: AjaxBasePageNegotiator should not require _theme: ajax_base_page to be specified, we can remove the use of _theme: ajax_base_page for the embed.preview route, but that still doesn't solve the reported problem. (It's just a related thing we should fix here.)

The root cause of the problem is that embed.preview doesn't account for the reality that (unlike Quick Edit), it tends to be executed from the back end (admin theme) yet it tries to preview the front end (default theme). This means it cannot rely on default theme negotiation, and hence the active theme that gets set for its request by default by Drupal.
To solve this, the embed.preview route needs to ensure the front end (default) theme is negotiated. But this means the same problem that #2778355: TypeError: Drupal.theme.bootstrapModal is not a function fixed may reappear for certain themes, because it also affects asset library loading/AJAX page state and so on. So at first glance, this seems a dead end.
The other way to solve this, is to have the client-side code not do something like Drupal.ajax({url: Drupal.url('embed/preview/…, which automatically triggers the AJAX system. Which doesn't really make sense here: we're not changing the application/page state, we're merely fetching HTML.

I just realized a hybrid approach is possible to minimize change: thanks to the logic in \Drupal\Core\Theme\AjaxBasePageNegotiator::determineActiveTheme(), the JS could options.data['ajax_page_state[theme]'] = 'name of default theme' just before sending the request, combined with using jQuery.ajax() instead of Drupal.ajax() to not trigger client-side processing of Drupal AJAX responses (which would reintroduce the TypeError: Drupal.theme.bootstrapModal is not a function problem from before). Then Entity Embed wouldn't be blocked on Embed getting updated to fix this problem.

In fact, then we could just as well send a GET request instead of a POST request and not use the AJAX system at all, and instead rely on \Drupal\Core\Theme\DefaultNegotiator!

That means we still have to parse a "Drupal AJAX response", but we'll just treat it as plain text, happening to contain transformed HTML for the HTML we sent. Which happens to be safer as well.

This is actually largely just reverting eae03700d4b1743890a7b5ee1b995c94e473e4e2. Until embed.preview is also changed, this will have to remain as hacky as it is in this patch.

Ugh, apparently using the AJAX system for all this was intentional! The git history makes this nearly impossible to track down due to pull requests that were merged rather than squashed and rebased. This resulted in wasted hours sadly 😫

#2350463: Previewing an entity in the WYSIWYG does not add any attached styles or javascript from the AJAX callback was apparently the issue where this was requested, https://github.com/drupal-media/entity_embed/pull/103 is where the bulk of the information lives.

If that's the case, then my pragmatic proposal in #8 is not an option. #8 assumes that only just having HTML previewed is sufficient; it assumes that no associated CSS and/or JS needs to be loaded.

Hence moving this back to embed's issue queue, since this is then a problem that needs to be solved there. I'm not sure it can be done though to provide a front-end theme preview, if we must also continue to support CSS + JS for previewed embeds, since those then also need to match of the back end theme to not trigger the TypeError: Drupal.theme.bootstrapModal is not a function error …

⚠️ Note that we already know that CKEditor 5 (see #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10) does not and will not have an iframe mode. Therefore mixing front-end templates (and asset libraries) and back-end templates (and asset libaries) on the same page will become impossible. (Unless every preview itself gets wrapped in an <iframe>, to provide the necessary isolation.)

Unfortunately https://github.com/drupal-media/entity_embed/pull/103 was done in a time when Drupal had no testing infrastructure capable of executing JS at all, and at this point it's hard to determine what the exact intended and supported behavior is.

Having worked on this more for #2511404: Image entities/fields embedded using Entity Embed cannot be linked in CKEditor, I'm becoming more convinced that the solution chosen in PR103/#2350463 was wrong: rather than having the Drupal AJAX system inject all that CSS and JS into the text editor, it should've been solved instead by having full blown entities (with forms and JS and whatnot) either:

1. NOT be loaded at all
2. or be loaded through an <iframe>, to get its own layer of isolation

Either way, just like https://ckeditor.com/docs/ckeditor4/latest/examples/mediaembed.html already does, an embed should not be interactive in the text editor anyway; it should merely be a preview. In that example, you see a Youtube video embedded, and it renders exactly like it would on the front end, but it's not interactive: you can't trigger it playing!

Thoughts?

(Moving back to the Entity Embed issue queue because this pretty deeply affects how that works, plus it can be improved without needing to depend on the Embed module.)

Sometimes, if for some foolish reason, business requirements demand a very large embed, having a small alternate display in the wysiwyg is helpful. Therefore, keeping the option to use a different twig template would be nice. Generally though, having the wysiwyg preview use the main theme and display properly without jumping through hoops would be amazing.

I may be biased, but I'd like to step back a bit and ask ourselves how hard we actually need / want to solve this.

The concept of a "preview" is where we should start, IMHO. If we agree (which I believe most of us would) the preview should _not_ be interactive in the admin theme, we are already starting with a preview that is not 100% accurate the the FE rendering. This would probably mean:
- No JS behaviors
- No form elements accessible/actionable
- No quick-edit
- No contextual links (maybe? this will certainly reduce confusion, but it can be arguable.)

Also, normally the WYSIWYG form element is constrained to a fraction of the page, so unless editors use CKEditor in full-screen mode, they might already be used to the idea of a "preview" that gives them just a rough idea of what the content is, while not 100% accurate to how things will look
in the front-end.

Stretching that idea a bit further, I question whether we need a preview at all, and if we couldn't provide almost the same experience with just a placeholder that contains enough information for the editor to understand what that embedded entity is. Displaying the entity label, bundle, and maybe some other metadata that affects the rendering (published/unpublished, viewmode?, etc...) in the placeholder, could hopefully be enough for us to provide a reasonable experience to editors while avoiding this whole problem of FE assets being displayed in the BE theme.

#12: How are you achieving alternative representations using Twig templates today?

#13 👏👏👏👏👏👏👏👏👏👏👏👏👏👏

I agree with the overall sentiment. I very strongly agree with the should _not_ be interactive, which is the most dangerous, most brittle, most questionable aspect of how Entity Embed's CKEditor widget works today. In fact, if you look at the official CKEditor media embedding demo, you'll see that it actively prevents interaction with the underlying content (which I learned yesterday can be achieved with a single flag).

What you're alluding to, is a WYSIWYM editing experience, rather than WYSIWYG. I personally strongly favor that too (see https://wimleers.com/blog/collaborative-cross-platform-writing and https://wimleers.com/article/drupal-8-structured-content-authoring-exper...), but that doesn't match the expectations of the majority of people.

That being said, it is fair to expect that it at least structurally looks like the front end. That's also why \Drupal\ckeditor\Plugin\Editor\CKEditor::buildContentsCssJSSetting() calls _ckeditor_theme_css(), which specifically looks up the default theme (99% probably that this is the front end theme), checks if it specifies any ckeditor_stylesheets in its *.info.yml file. This allows adding general styles.

For example, bartik.info.yml:

ckeditor_stylesheets:
  - css/base/elements.css
  - css/components/captions.css
  - css/components/table.css
  - css/components/text-formatted.css

(Note specifically captions.css!)

However, that infrastructure was added to CKEditor at a time (#1890502: WYSIWYG: Add CKEditor module to core, 2013) where it was not yet possible for themes to attach asset libraries inside Twig templates, which is currently the recommended best practice (#2398331: Add the ability to attach asset libraries directly from a template file, 2014 — and Drupal 9 is doubling down on it in #3050386: Allow loading CSS and JavaScript directly from templates). In that scenario, it also seems reasonable to expect that attached CSS is also loaded in the CKEditor instance.

If we accept that, then we:

• MUST fix this issue (wrong theme used)
• MUST continue to use AJAX requests, to have CSS loaded into the CKEditor instance (an <iframe>)
• MAY continue to have JS loaded into the CKEditor instance, but this seems more questionable, because

Looking forward to your thoughts!

Excellent feedback, thank you @John Pitcairn!

Before I answer in detail, I'm going to ask you the same question I asked @oknate:

How are you achieving alternative representations using Twig templates today?

I … completely understand. The Entity Embed module has been usable for many, but ideal for few, and abandoned by who knows how many. Hopefully this new push forward will help make it a viable option for more :)

That being said, the confusing view mode vs display plugin selection UI problem is not going away. I complained about that and warned against it since the very beginning. We can't remove it now because it'd break BC for >40K sites using it.

But … we won't be bringing those @EntityEmbedDisplay plugins to Drupal core. In Drupal core we'll only support view modes.

First: I have no intent to remove ckeditor_stylesheets :) We actually can't, it'd break backwards compatibility!

WRT your {% if ckeditor %} proposal: my initial reaction is why not create a specific Text Editor Embed Preview view mode? And make that the only enabled entity embed display? I think I know the answer already though: because you need the content creator to be able to pick between view modes.
My follow-up question then is: why do you need a different template in the CKEditor at all? What problem does it solve? Is that merely a request born out of thinking of a way to work around the problem in the title of this issue, that the default theme's template is not used?

Thanks, that's super helpful! 🙂

I have one more question to better understand your needs. You wrote:

able to load different/additional css libraries from within that template

Why do you want different assets to be loaded depending on whether CKEditor is used or not? What problem are you trying to solve with that?

so the embedded entity may need additional or different styling and media queries to display sensibly.

Those additional media queries also probably make sense on the front end, since CKEditor iframe instances' viewports tend to be even wider than smartphone's viewports?
Also: that's just CSS?

And if we're talking just media queries and you want embedded entities to be rendered inside CKEditor instances, then ckeditor_stylesheets actually seems like a reasonable place to do that. Hopefully your embedded entities don't need per-entity type custom CSS, so a single CSS file listed in your theme's ckeditor_stylesheets is going to be enough to produce a "near-wysiwyg presentation" (which I think is a sensible thing to do).

No big deal, if the twig template is used and its css libraries loaded, I can also add ckeditor-specific rules there by prefixing with the appropriate html/body class selector.

Right! That's actually a reasonable way to achieve the same: just prefix every CKEditor-specific styling with .cke_editable !

I have a mixed mind on this one.

On the one hand, generating a fully interactive preview using the front-end templates is currently brittle and fraught with problems, as has been pointed out. It's also probably more than we strictly "need" to do. But, it's probably the clearest thing, from the editor perspective. And it demos well.

On the other hand, it's easy to go wrong if we switch to non-interactive placeholders. We'd have to get design and UX input to make sure that we were generating placeholders which really made sense to people, and that there was enough flexibility to make those placeholders customizable to some degree.

What I'm wondering is, what do other content management systems do in this situation?

What I'm wondering is, what do other content management systems do in this situation?

CKEditor is used by lots of content management systems, and they prevent interactions with interactive embeds.

I only noticed today that I missed an important fact in #2350463: Previewing an entity in the WYSIWYG does not add any attached styles or javascript from the AJAX callback and its associated pull request https://github.com/drupal-media/entity_embed/pull/103:

Works beautifully when the CKeditor is in divarea mode. In iframe mode, the CSS do not get applied to the content of the iframe, but that is to be expected

In other words: loading CSS & JS works onlywhen using an inline CKEditor instance, not when using an <iframe> CKEditor instance!

I only realized that after digging in today in how Entity Embed's AJAX-based preview loading works and for the life of me being unable to figure out how it loads attached CSS and JS into the <iframe>. That's because it does not! 🙃

I never realized this until now, and I suspect I'm not alone. That also explains why in #2350463: Previewing an entity in the WYSIWYG does not add any attached styles or javascript from the AJAX callback and the PR no attention was given to the negotiated theme: because when using an inline CKEditor instance, it by definition happens on the front end (default) theme, and hence any AJAX requests automatically negotiate that theme too.

So for example what I wrote in #14 is simply wrong:

• MUST continue to use AJAX requests, to have CSS loaded into the CKEditor instance (an <iframe>)

And more importantly, what I wrote in #9 is wrong too:

If that's the case, then my pragmatic proposal in #8 is not an option. #8 assumes that only just having HTML previewed is sufficient; it assumes that no associated CSS and/or JS needs to be loaded.

Turns out that's not the case, because this never even worked in <iframe> CKEditor instances!

Given that, I think we should just commit #8. It fixes the reported bug. It is simpler. It means that inline and <iframe> CKEditor instances behave the same way. It only negatively impacts the very small percentage of sites relying on additional CSS and JS being loaded in inline CKEditor instances. And let's be honest, very few people use Quick Edit (which you need to get inline CKEditor instances) in the first place.

So I think it's fair to choose to cause a regression for a tiny percentage of users and gain more simplicity, consistency and have the >95% scenario behave as expected, which is the scenario @John Pitcairn reported.

Yesterday, jquery was removed from plugin.js: #3064256: The CKEditor plugin is using jQuery only for two things, refactor to remove that dependency
And now patch #25 uses it:

-          var previewLoaderAjax = Drupal.ajax({
+          jQuery.ajax({

Maybe it was premature to remove it? Or could this be refactored to not use jQuery?

I tested manually patch #25. I don't see any difference with it (which is good). I'm not exactly sure what I'm supposed to be looking for. Re-reading the issue summary now.

I think we need:

1. an issue summary update.
2. Steps to reproduce the issue on a clean install. This is covering ground we haven't added test coverage for yet, which template is being output from what theme.
3. We should probably add test coverage.

I have definitely run into issues where I was copying templates and css to my admin theme in order to get them to look right for certain embed types. Generally, I think I have only run into issues where it is displaying the wrong view mode template when that template does not exist in my admin theme. I think the fix here should be to use the templates from the theme that will output the entity, the FE template.

Added steps to reproduce to issue summary as well as expected behavior. This takes care of #27.1 and #27.2.

I have manually tested the patch, based on the steps to reproduce in the issue summary and expected behavior and can confirm the fix. This is going to make a lot of people happy.

Maybe it was premature to remove it? Or could this be refactored to not use jQuery?

It was not premature, because we managed to remove all direct uses of jQuery. If we need to reintroduce one, that's fine :)

This is going to make a lot of people happy.

🥳

Wrote a test. It was very painful to get it to work 😑The test-only patch is also the interdiff.

+++ b/js/plugins/drupalentity/plugin.js
@@ -309,20 +309,18 @@
+          jQuery.ajax({
...
+            success: function (data) {
+              for (var i = 0; i < data.length; i++) {
+                if (data[i].command === 'embed_insert') {
+                  widget.element.setHtml(data[i].data);
+                  callback(widget);
+                }
+              }
+            }

This shows we're now using nothing of the Drupal AJAX system. So this is unneeded complexity. But I'll leave it to #3064340: Make preview responses cacheable to accelerate previews to improve that. The scope of this issue was only to make the preview use the default theme. This did that.

Note for future readers and them being concerned about the front end (default) HTML being used but the CSS not being loaded: the default theme already should be specifying ckeditor_stylesheets. So if you know that certain entities could be embedded, and you want the preview in CKEditor to match the front end, then just add the relevant CSS files to ckeditor_stylesheets in your theme's *.info.yml. Yes, this is some extra effort. but loading all of the default theme's CSS in CKEditor also has negative consequences (performance, only a subset of the HTML structure being present, etc). It's good that we have to be conscious about injecting certain CSS into a CKEditor <iframe> instance. It's not ideal, but it's a pragmatic balancing act. Hopefully we can do better in CKEditor 5/Drupal 9. 🤞If we're going to bring back loading of CSS and JS associated with the preview, we'll need to make it work everywhere, rather than only in an edge case.

Fix nits.

1. +++ b/js/plugins/drupalentity/plugin.js
   @@ -309,20 +306,18 @@
   +          jQuery.ajax({
   

   This is using jQuery again, so we should import that from the window scope.

2. +++ b/js/plugins/drupalentity/plugin.js
   @@ -309,20 +306,18 @@
   +                if (data[i].command === 'embed_insert') {
   +                  widget.element.setHtml(data[i].data);
   +                  callback(widget);
   +                }
   

   This means that we're no longer relying on the embed/embed asset library's embed.js.

   This means we are able to remove a few more lines of JS, and we're able to update \Drupal\entity_embed\Plugin\CKEditorPlugin\DrupalEntity::getLibraries() 👍

Yay for solid test coverage! 🥳😅

This still needs the core/drupal.ajax asset library to be able to open the dialog! \Drupal\ckeditor\Plugin\CKEditorPlugin\DrupalLink and \Drupal\ckeditor\Plugin\CKEditorPlugin\DrupalImage also depend on this library for the same reason.

Given everything written above, including my assessment, but also @marcoscano's, @John Pitcairn's sharing of his real-world needs and problems and @oknate's experience with a large deployment using Entity Embed and his enthusiasm in #30, I feel safe to (re-)RTBC and commit this.

For the at most handful and likely single site that is impacted by this change, see #25 and the note at the end of #41. To keep things working for you, I suggest you write a custom module named entity_embed_load_css_js_for_preview_in_inline_ckeditor, write a @CKEditorPlugin plugin that implements \Drupal\ckeditor\CKEditorPluginContextualInterface and enables itself automatically, then have your plugin.js do something like what core/modules/ckeditor/js/plugins/drupalimagecaption/plugin.js and core/modules/ckeditor/js/plugins/drupalimage/plugin.js do: they each decorate specific methods on a CKEditor Widget they're enhancing. That way, you get to keep your current behavior and can update to the upcoming 8.x-1.0 release.

🚢

i've been actively following Entity Embed and use it heavily. i've just upgraded from RC2 to 1.0 and things have quietly snapped in half. Nothing renders in the WYSIWYG or when I view the save/node. No doubt it is some customization (I use both UI Patterns and Display Suite), but I am thinking this might be the most likely culprit. Nothing in watchdog, nothing in the console. I'll dig in now - perhaps it will be a separate ticket or, most likely, just something I have to adapt to.

Cheers!

We have extensive test coverage that the filter functions properly on a vanilla install of Drupal 8.7 and 8.8-dev, so I doubt it's an undiscovered bug.

Please let us know what you discover so others can benefit from your experience.

yeah, it is probably some choice we've made that was not strictly supported. I am debugging preview now - my entity's 'view' function is never called (which it is on RC2) ... i'll get there. hopefully it won't be fatal, as our whole systems is built around entity embed.

i sniffed it out. is down to this line in EntityReferenceFieldFormatter

$build['#access'] = $entity->access('view', NULL, TRUE);

over to me. will avoid commenting further on this ticket, as clear nothing to do with it.

#53: oh wow! That was unexpected! That … sounds like content editors were previously able to see previews of entities that they technically weren't allowed to see. That's scary 😦 Please check the permissions and any access control customizations you have for the entity type whose embeds are no longer showing up!

i am sorry, i got that totally wrong. it is the next line that causes the problem. the addition there of the #pre_render callbacks. my (custom) field formatter returns a RenderElement that has a #pre_render hook. after the build method is called the entity embed filter calls 'render' on it ... in the Drupal renderer when it combines the settings from the RenderElement with the settings from the build array ... the pre_render hooks added by entity_embed prevent the RenderElement's pre_render hook from being added (this code from renderer only adds things that werent in the build array)

    if (isset($elements['#type']) && empty($elements['#defaults_loaded'])) {
      $elements += $this->elementInfo->getInfo($elements['#type']);
    }

Maybe my field should not be returning a RenderElement ... I was trying to be a bit fancy (returning a #type). I sidestepped it .. although ... with a sharp intake of breath.

@AndyThornton: D'oh! This is getting very unwieldy though — this issue already has dozens of comments and was committed. Could you please create a new issue and continue this conversation there? That'll be clearer 🙏😊

absolutely ... i am assuming it is 'me'

I wouldn't assume that — I bet it's just something pretty advanced that you're doing and Entity Embed didn't take that into account. 😊

thank you for not putting advanced in quotes :-)

HAH! Why would I though? You're looking at RenderElement internals and are mentioning a custom field formatter with #pre_render call backs and returning a #type. That is advanced 😉

Anyway, looking forward to your issue. It might be valuable to also post your custom field formatter, that might help us pinpoint the cause much faster. It doesn't need to be all of the code: if there's sensitive stuff in there just remove all that and just share the overall structure :)

I had a stab .. https://www.drupal.org/project/entity_embed/issues/3066047.

Thanks!

This introduces a regression that #3081825: Entity not embedding in ckeditor fixes.

So we updated a big site to Entity Embed 1.0 recently and this changed affected is negatively, but I understand it why it was done.

We have a lot of complicated media bundles that we embed in the body field of news articles on this site - things like media galleries and slideshows. Previous to this change, the admin theme was used to render the previews, which allowed us to provide admin-theme specific versions of the media bundle twig templates. That allowed us to provide a WYSIWYM experience. For example, for slideshows we had a template that just output the first image of the slideshow with some text indicating it was a slideshow.

Now with this change, these media bundles were trying to output as if they were rendered in front-end theme, but without any of the JS needed to make them actually look like a slideshow. Things got weird from there :)

I think I'll need to come up with a plan internally to make these previews work correctly the with front-end theme moving forward, but it may be quite difficult without some way for the template to know if it's being rendered as a preview or not.

In the meantime, I've written a very simple theme negotiator that forces the admin theme for the entity embed preview AJAX route to bring us back to previous behavior. If anyone is interested, here's the code:

namespace Drupal\[your_custom_module]\Theme;

use Drupal\Core\Config\ConfigFactoryInterface;
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drupal\Core\Routing\RouteMatchInterface;
use Drupal\Core\Session\AccountInterface;
use Drupal\Core\Theme\ThemeNegotiatorInterface;

/**
 * Class EntityEmbedPreviewThemeNegotiator
 *
 * Provides a theme negotiator to force the theme used for entity embed
 * previews to the admin theme. This is how the entity embed module operated
 * previous to the change implemented in https://drupal.org/i/2844822.
 *
 * This site was built when the admin theme was used to render the previews,
 * which allowed us to provide specific templates for the previews for the
 * admin theme. This allowed us to create more reasonable representations of
 * certain media types, like slideshows.
 *
 * When embed previews are rendered using the front-end theme, all sorts of
 * things break for us. This fixes that.
 */
class EntityEmbedPreviewThemeNegotiator implements ThemeNegotiatorInterface {

  /**
   * The current user.
   *
   * @var \Drupal\Core\Session\AccountInterface
   */
  protected $user;

  /**
   * The config factory.
   *
   * @var \Drupal\Core\Config\ConfigFactoryInterface
   */
  protected $configFactory;

  /**
   * The entity type manager.
   *
   * @var \Drupal\Core\Entity\EntityTypeManagerInterface
   */
  protected $entityTypeManager;

  /**
   * Creates a new AdminNegotiator instance.
   *
   * @param \Drupal\Core\Session\AccountInterface $user
   *   The current user.
   * @param \Drupal\Core\Config\ConfigFactoryInterface $config_factory
   *   The config factory.
   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
   *   The entity type manager.
   */
  public function __construct(AccountInterface $user, ConfigFactoryInterface $config_factory, EntityTypeManagerInterface $entity_type_manager) {
    $this->user = $user;
    $this->configFactory = $config_factory;
    $this->entityTypeManager = $entity_type_manager;
  }

  /**
   * {@inheritdoc}
   */
  public function applies(RouteMatchInterface $route_match) {
    return ($route_match->getRouteName() === 'entity_embed.preview' && $this->entityTypeManager->hasHandler('user_role', 'storage') && $this->user->hasPermission('view the administration theme'));
  }

  /**
   * {@inheritdoc}
   */
  public function determineActiveTheme(RouteMatchInterface $route_match) {
    return $this->configFactory->get('system.theme')->get('admin');
  }

}

This just needs to be registered in the services file of a custom module.

@bkosborne Thanks for the code snippet.

We too use different twig file overrides on the admin theme to offer a reduced / simplified version to users in CKEditor.
We also add inline text annotation to image elements for example to provide the user with more information such as Image name, Image Caption and General Notes. This allows the user to have quick access to this information directly within CKeditor without having to open up the separate Image Editor screen. We would not want this additional meta data presenting to the general website visitor, certainly not in the way in which we present it in CKeditor.

Some of our embedded entities use large full width banners which would reduce the user experience in CKeditor if we attempted to display these as we do on the front end. We ask our users to use the Drupal preview rather than use CKeditor to give an exact view of how the content will look on the website.

This is a great module, one that works great for us so we thank all that are involved. We just hope that any further develop will take account of this type of use case.

Thanks @bkosborne, this snippet worked well for me too!