Ella 8:45 pm on August 20, 2014

GSoC update

Monday was the “pencils down” date for GSoC, and here’s a post about what I have done so far. It’s all related to the editor, but it can be divided into three parts: work on coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for the editor “views” and scrolling, work on the Editor Experiments pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, which contains further enhancements and work on a complete rewrite of the Front-end Editor, which includes both work on core and the other plugin.

Note that everything requires at least WordPress 4.0 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 4 to try.

Core

View related tickets (#28595, #28195, #28788, #28913, #27971, #28458 and other minor tickets), better thumbnail resizing for a responsive modal (#27423), editors scrolling (#28328) and other minor things added to core the past few months.

Editor Experiments

The goal of this project was to make it easier for plugins to add views in the editor, for example for their shortcodes. It’s been very difficult, however, to figure out the needs and support all different scenarios. Technically it’s also not easy, since we’re working in an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., all the changes are tracked by TinyMCE and the DOM can get rebuild.

As for a UIUI User interface, there are lots of options for an editing interface. WordPress should provide some options, but the experience should be customisable. Ideally it should be possible to edit views straight inside the editor. E.g. for a gallery view, it should be possible to edit captions inline and rearrange images. I decided to pick a popular shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. and see what I can do. I picked a shortcode that can display a Google Map, and it ended up like this in the editor:

You search by address, or just drag and zoom the map, change the map type etc., and it will update the shortcode for you.

I realise the is just one case, and there are a few more necessary to figure out an APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. There are also a lot of improvements needed to the view plugin in TinyMCE. Currently it is not possible to have editable text fields inside the view. It is also not possible to drag views around, let alone drag and drop items inside a view, which would be a huge deal for shortcodes that let you add form elements for example. With the “Editor Experiments” it is possible to add an “inline” toolbar to manipulate the view. Of course, you still have the option to display your own modal and update the view after it closes.

Another goal was to experiment with the concept of content blocks and inline editing. I made a TinyMCE plugin that adds a toolbar with formatting tools when you select something in the editor and that is extendible in the same way the default toolbar is. You can create your own buttons (like you did before) and add them to the toolbar, or just any existing one. In the future, we can change the buttons based on the selection.

To add a blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience., you have to put your cursor in an empty paragraph and the following will show up:

Clicking on it renders the block toolbar:

And this toolbar too is extendible. You can add any TinyMCE button to it, but of course only buttons that insert something will be useful here.

Front-end editor

The original project was called “Front-end content blocks”, but we’ve changed the goals a bit at the start to focus on the back-end editor first instead, and it kind of felt like development on the FEE has stopped in the last few months. But that’s not entirely true. All these improvements can be implemented in the FEE too. That’s why I’ve also completely rewritten the FEE from scratch and added all this stuff. The improvements include:

An inline toolbar for text, images and views. The fixed and always-visible toolbar is gone.
The “add block” toolbar to insert content. Similarly you can add a featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts..
The kind of buggy “view” implementation is now completely replaced with the view implementation in core form 3.9 and all the improvements I did for 4.0.
The editor now loads instantly on the page. No page refresh anymore. Also no page refresh on save/publish. You can simply toggle the editor on and off. It was mainly this change that required most of the rewrite…
Fixed and improved lots of other stuff. It’s just better if you try it yourself… Go to GitHub and clone the plugin. 🙂

Something else I’ve been working on, and that is currently in the FEE, is automatic markdown conversion as you type. Not that it would be useful in the current implementation for all the syntax, but for some things it is really useful. Typing * or - converts automatically to a list, 1. to a numbered list and *word* or **word** to italic and bold. 🙂

I’ll publish another post soon with more information about the Front-end Editor. I’d like to do a 1.0 release soon after the release of WordPress 4.0, and any help is really welcome.

Stephane Daury (stephdau) 8:53 pm on August 20, 2014

I, for one, have to mention how valuable your contribs were, and thank you profusely for them.
Awesome work, J. 🙂
- Ben Hansen 9:02 pm on August 20, 2014
  
  Hear Hear! Great stuff thanks for all your hard work Janneke!
- Avryl 9:06 pm on August 20, 2014
  
  Oh, thanks! 🙂 And thanks for your help with the editor scrolling.
Gregory Cornelius 9:22 pm on August 20, 2014

Thanks for all your hard work! I hope that you learned a few things along the way and are able to continue contributing to WordPress.
- Avryl 9:26 pm on August 20, 2014
  
  I learned a ton of stuff. 🙂
Matt van Andel 10:29 pm on August 20, 2014

One use-case that I’d like to see addressed is the concept of content separation… or having “blocks” of content that are handled separately by the theme… either by loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. or by loading specific named blocks.

The reason for this would be to make highly structured template pages easily maintainable in the adminadmin (and super admin) from a single edit screen. Here’s a quick-and-dirty experiment that demonstrates the concept… https://github.com/Veraxus/nv-plugins-content-blocks

You can create new blocks in the editor wherever you like – similar to adding a “more” tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) – and give them a name for reference. Those tags are then parsed out in the post object. The entire content can still be rendered out with the_content() but you can render specific blocks in the current loop with the_content_block($block_id) instead. This lets you create a structure-heavy page template and load specific chunks of content from the editor without exposing the admins to any complex, easily-broken underlying HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers..

In other words, it helps keep the HTML in the theme templates and the raw content in the editor.

Now my current approach may not be the best, but it addresses a problem that is becoming more and more common as WordPress gets ever more popular as a full CMS.
- Avryl 10:50 pm on August 20, 2014
  
  Do you have a use case for that? Just not sure what the benefit would be.
  - camu 3:20 am on August 21, 2014
    
    There’s already a very powerful pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that does this. I use it all the time: Visual Composer. You can find it on CodeCanyon.
    - Matt van Andel 3:44 pm on August 21, 2014
      
      Thanks for the heads up, but that’s nuclear-grade overkill what I’m asking.
      
      Example A:
      You are building a website for a business that makes and sells a specialized piece of computer hardware. As you scroll down the homepage, you give the visitor a tour of what makes this hardware special, from the inside out. As you scroll down the page, the entire system assembles itself on the left of the screen, with new hardware coming up from the bottom and being “stickied” to what is already there… motherboard, CPU, chipsets, case… with information appearing to the right of the hardware at each step.
      
      Example B:
      You have a page that is a detailed Timeline of an organization’s history. Each date is a full-width fluid box with a background image. Floating above that background image is a lightly transparent white box with the date and descriptive text. The adminadmin (and super admin) should be able to adjust dates (post title) and copy, and change the image at any point… or add new points in the timeline.
      
      * *
      
      Traditionally, anything with that amount of structure, animation, or other complex technical requirements would have to be entirely hand-coded in a theme template as TinyMCE is horrific at handling complex HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers., particularly when you want a client to be able to easily edit things in the visual editor, without worrying about any important HTML breaking.
      
      But how do we expose those individual blocks of copy to admins in an elegant, highly usable way… so that they can be easily updated at any time (without anyone needing to futz with template files)? Ideally, the admin user would be able to edit anything on the homepage simply by editing the Homepage and being presented with all the blocks, neatly separated, that can be edited… but this is not something that WordPress currently supports at all.
      
      One old hacky solution I’ve used for years is to set up each “blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.” as a sub-page of Home, and then load those posts on a case-by-case basis. I’m not a fan of this approach as it’s a usability nightmare (one page is built out of many sub-pages), although the specific mechanics (blocks become a special kind of child post) may work well as a technical solution if a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party provides the right kind of admin UIUI User interface to support it (including hiding child pages from list tables that are technically blocks and not standalone pages).
      
      Another hacky solution (the one I linked to earlier) uses the HTML comment <!–block–> to split content in the same editor into blocks, just like &lt!–more–> – but those can be loaded in the template individually or looped. The current version is inelegant and ugly as hell, and currently only identifies blocks by array index instead of a more flexible title or tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)… but it keeps all of a pages content neatly in one place… the editor for that specific page, where it belongs. Then the theme can control how and where those blocks are displayed on the page.
      
      Hopefully that makes that more clear.
      - Avryl 3:54 pm on August 21, 2014
        
        I get the idea, but these seem to be very specific use cases. There is actually already a similar concept to what you’re describing with and that’s . You can access the array of blocks with the global $pages. It sounds like your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is doing exactly this, and nextpage is build in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. You just tell the user to separate the content with page breaks and add the button to the editor, since it’s not there by default.
        Other option is to add more instances of TinyMCE under each other, but that might be a bit of an overkill.
Fab1en 7:53 am on August 21, 2014

Thanks a lot Janneke for your great work !
The possibility for pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to add views to the TinyMce editor looks very promising. I can provide you some use case examples where a custom view is needed.

The first use case is exposed is the following WPSE question : Adding more options to the instance of an image. The user wants to modify the markup inserted for an image without switching to Text view. So that requires to extend the default image view with more options.

The second use case is for a shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. provided by Aesop Story Engine. The need is to position an element with the mouse, so jquery ui draggable widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. is needed. I managed to achieve this, but jQuery ui needs to be loaded inside TinyMCE iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. to make this work.
- Avryl 3:40 pm on August 21, 2014
  
  Thanks for the feedback!
  
  For the first case, you should take a look at this pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party: https://wordpress.org/plugins/advanced-image-styles/
  There is already a “view” for images, and the image details modal gives you options to change it. It’s not really a view though. It has its own TinyMCE plugin to handle everything, since at the moment views can only blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. elements in the editor and can’t be aligned. It’s also no possible yet to edit text in a view (which would be required for the caption).
  
  Yes, jQuery UIUI User interface draggable is tricky to use in iframes. It shouldn’t be necessary to enqueue it inside the iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser.. I wonder how hard is would be for jQuery to fix this. Anyway, this is why views in the front-end editor or so much easier to handle. No iframes!
  
  I’ve tried to use Aesop Story Engine several times, but I could never figure out how it works. It just inserts a bunch of shortcodes?
Ryan McCue 4:22 am on August 22, 2014

This is hugely exciting. 🙂 The inline buttons especially are awesome, but all the other parts rock too.
- Avryl 5:57 am on August 22, 2014
  
  Thanks!
  
  You asked me about using your JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. Rest APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. for the Front-end Editor a while ago, and I’m interested in using it. But I’m a bit hesitant to require another pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. I also want to release the new editor soon after WP 4.0 is released, so there might not be enough time to switch over, but it would be cool to try it out. 🙂 How is the project going, and do you still need other projects to try it?
Nick Halsey 1:39 am on August 24, 2014

Wow, great job Janneke!

I think we should start looking into integrating FEE and the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.. Both are front-end-contextual, and I see the Customizer as the place to handle non-content whereas the FEE does content. At least initially, that helps to preserve the way WordPress separates content from layout & design for the UXUX User experience.

Interestingly enough, the FEE currently works within the Customizer preview. You’ve got a much smoother experience going with your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party right now, without the need for a pageload, and that’s something we’d like the Customizer to also be able to do eventually.

I envision a “post” panel in the Customizer, contextual to single views. If the panel is opened in the Customizer, the front-end editor would load in the preview. If the front-end editor is triggered from the front-end, it would load the editor and open the Customizer, to the post panel/context. This allows users to quickly access other customization tools such as widgets and menus while editing content, but keeps content separated from everything else by making it editable in the preview rather than alongside it. And with panels, the visible UIUI User interface context is limited to post-related things.

The “post” panel would essentially contain all of the metaboxes from post.php for a given post type, as accordion/customizer sections. While experimenting with making post metadata directly editable is intriguing, I think we really need to have a more obvious mechanism for adding and managing taxonomies, featured images (the current implementation just isn’t compatible with everything themes do), things in the publish metaboxMetabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way., etc. Putting that into the Customizer would keep things visually consistent with our other front-end-contextual UI, and implementing it as a Customizer panel rather than a Customizer look-alike integrates direct access to other site Customization tools while editing content. We could also pull in the metadata UI APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. if/when it’s merged into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and/or implement post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. into the Customizer API (maybe with a postmeta setting type).

I know @westonruter has been experimenting with editing posts with the Customizer and two-way communication between the Customizer controls and preview lately too, so I imagine we’d be able to get something like this working from a technical perspective. It would definitely be a lot of work to build a fully-integrated solution, though.
- Avryl 3:29 pm on August 26, 2014
  
  Yes, definitely. I don’t see why we shouldn’t experiment with this. That’s also one of the reasons I made the change to “instant” on/off, and I’m aware the editor works in the customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.. Shhht! 🙂 I will add an item there to turn the editor on, and maybe some of the UIUI User interface can move there when uncollapsed. We can experiment with both at the same time, there’s no need to make any decisions about that direction now. Personally, I prefer to use the editor when there’s no panel making the screen smaller and with access to all buttons etc.
danieliser 5:27 am on August 25, 2014

Just tested the new editor, love love love the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. concept. What are the plans to incorporate this into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.? Any thoughts on what milestone this may be included?
- Avryl 3:30 pm on August 26, 2014
  
  There are no specific plans around that right now.

Comments are closed.

Welcome!

Communication

GSoC update

Core

Editor Experiments

Front-end editor

Welcome!

Communication

Core

Editor Experiments

Front-end editor

Share this: