Looking for just the editor portion

  • Alexandre

    (@0xcafe-1)


    10 years ago

    Hello,

    This plugin came at a surprise ?? I just converted my blog from Ghost to WordPress and I’m looking for a way to bring back the editing experience of Ghost on a WordPress blog.

    I tried Jetpack MD but do not like the fact that it saves a rendered version of the post and the MD in a seperate column in the database. So I switched to the Typerwriter plugin to have is simply all MD. But I’m missing the preview pane of Ghost.

    Are you planning (or is it possible) to have just the editing portion of Gust? I pretty much like my WordPress original dashboard with my widgets, I would only like to have a better editing and preview screen.

    Thanks!

    https://www.ads-software.com/plugins/gust/

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Arunas Liuiza

    (@ideag)

    Hi, Gust lives together with WP admin – you can access and use both of them, as you see fit via Admin Bar, or directly via /gust and /wp-admin respectively. Gust is just editor, it is not meant to handle widgets, menus, settings, etc.

    Thread Starter Alexandre

    (@0xcafe-1)

    Thanks, I tried it and it works very well. Bravo for that.

    I can’t help but notice that it converts MD to HTML on save (and keeps the Markdown syntax in the post_content_filtered column of wp_posts). I’m looking for a pure Markdown experience where all the posts are kept as MD inside post_content and nothing inside post_content_filtered.

    Is this a planned feature?

    Thanks!

    Plugin Author Arunas Liuiza

    (@ideag)

    Hi,

    Not at the moment and it will not be, unless you can convince me storing Markdown directly into post_content would not be a very bad idea ??

    My current reasoning is as follows: The main idea of Gust is to get best of both worlds – a very nice editing experience from Ghost and a robust and powerful theme/plugin ecosystem from WordPress. To achieve this, Gust has to be as compatible with other plugins and themes as much as possible. Most of WordPress plugins that deal with post content expect post_content to be stripped down HTML + some shortcodes (shortcodes output HTML too, so more of HTML, really). Having Markdown there directly could (and will) result in breaking functionality of those plugins. Themes are also written in a way to expect HTML in post_content, so the same reasoning applies.
    I can achieve compatibility in two ways – I could convert Markdown very early on post_content read calls by filtering the_content et al, or on write calls (when saving). I think doing it on read calls is a bad idea, because:
    1. There are a lot more read calls than write calls. Markdown generation isn’t the most expensive call to run, but I would still prefer to do that a lot less times, if I can.
    2. Even if i hook in very early into the read calls, another plugin could still hook-in earlier, for very different reasons. And things could still break, so doing it on write calls is safer compatibility-wise.

    If you have reasons which you think outweigh mine, I’d be happy to hear them and reconsider.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Looking for just the editor portion’ is closed to new replies.