Make WordPress Core

Tagged: gsoc Toggle Comment Threads | Keyboard Shortcuts

  • Nick Halsey 12:20 am on August 8, 2014 Permalink
    Tags: , gsoc, , ,   

    GSoC Menu Customizer Update: Live-previewing Menus 

    I’ve finished implementing menu-previewing in the Menu Customizer plugin, building on the scalable approach to saving menus that I discussed in my last update. The entire Menus experience is now consolidated into a Menus panel in the Customizer, where you can preview your menus as you make changes. It’s really nice to have Menus easily accessible alongside the rest of the site-appearance-management tools in the Customizer.

    I only have about a week and a half left in my GSoC project, and I’m hoping to focus on improving the add-new-menu-item panel in my remaining time, making it scale and implementing the search functionality. I’m also planning on cleaning up the codebase and implementing the ability to manage menu hierarchy (submenus).

    If you’re interested in testing the Menu Customizer, and live-previewing changes to your menus, you can get the plugin here. Please note that it currently requires PHP 5.3+, but it’s getting less and less alpha by the day.

    Post-GSoC Plans

    After the GSoC coding period is over, I’m planning on transitioning Menu Customizer development to the feature-plugin format, gathering a group of interested contributors and holding weekly meetings to coordinate our efforts. While it won’t be ready for core consideration by 4.1, and requires some more core Customizer infrastructure to really work well, we’ll continue working on the plugin until menus in the Customizer really shine, and are ready for core.

  • Nick Halsey 3:15 pm on July 15, 2014 Permalink
    Tags: , gsoc, , ,   

    GSoC Menu Customizer Update: Scalable Menus 

    Since my last GSoC update, I’ve spent a fair amount of time helping prepare the Customizer for 4.0 beta 1. But I’ve also continued working on the Menu Customizer and have a lot of progress to report.

    Add & Delete Menus

    You can now add new menus, via the “+ New Menu” section. Added menus currently have some issues, though; you’ll probably need to reload the page before adding items works. The problems stem from the lack of a proper JS API for adding, deleting, and managing Sections and Settings (and Panels), and the incompleteness of the existing Control JS API. This will probably need to be resolved in core before the Menu Customizer can be considered for core integration, see #28709.

    I’ve also implemented a menu-deletion mode, which can be toggled from the add-menu section. It’s too easy to delete menus otherwise, even with an AYS confirming the delete, because deleted menus cannot be restored, and are not “previewed” before being published to the db (added menus aren’t either). It’s probably worth augmenting the AYS to state the menu name being deleted, and to add an extra warning if it’s active in a theme location or a widget.

    Saving Menus and Menu Item Data in a Scalable Way

    In core, menus do not scale well at all. You don’t have to look very deep into the code to see why – massive amounts of data for each item are hidden on the admin screens (much of which never changes) and then must be updated every time a change is made.

    Since one of the goals of this project is to experiment with new approaches, I’ve begun implementing a new approach for saving menu data, which is currently in use in the plugin. Thanks to my mentors @ethitter and @obenland for guiding me on the best approach to take here, and @westonruter for the way he implemented the Widget Customizer UI, which inspired this exact approach. Here’s how it works:

    • Each menu has a nav_menu Customizer control that contains an ordered array of numerical menu item ids (known throughout the core menus codebase as their db ids).
    • When an item is added, it is created as an orphaned draft via ajax, and its id is added to the nav_menu setting’s array.
    • When an item is deleted, its id is removed from the nav_menu setting’s array.
    • When menu items are reordered, the order of ids in the nav_menu id is updated to match.
    • When menu items are moved into and out of sub-menus, the parent menu item id is updated in the individual item’s data (not yet implemented).
    • When a menu item field is changed (by default, this would mean changing the label or, for custom items, url fileds; there are screen options for several others), the original item is cloned and the copy is updated with the new data, using a wrapper for wp_update_nav_menu_item() that doesn’t require passing all existing (unchanged) menu item data. The cloned item’s id is returned and replaces the original id in the nav_menu setting (thereby marking the original item for deletion). Additional changes are saved to the cloned item until the settings are saved, at which point all items are marked for a new clone to be created if changes are made (not yet implemented).
    • When the user saves their changes from the Customizer (via the customize_update_nav_menu action), the array of ids is compared to the currently-published menu’s items. If there are items that are no longer present, those are marked for deletion. For each of the new ids, the corresponding menu item (which already exists) is updated to be published, assigned to the corresponding menu (for the new items created as orphaned drafts), and the item’s menu_order is set to the id’s position in the nav_menus setting array. Finally, all of the removed items are deleted.

    While menu previewing in the customizer is not yet implemented, it will also be able to use the nav_menu setting’s array of ids to display an augmented set of menu items. I’m also still working on ensuring that menu item data is not posted during the customize-save ajax, but the data isn’t needed so we’re most of the way there already.

    UI Aside


    Quick aside: @DrewAPicture pointed out in IRC that the new Customizer close and panel-back icons don’t really match the save button. I’ve done some rough explorations of potential alternatives; if anyone’s interested in discussing them and possibly implementing a change here, feel free to ping me in IRC (@celloexpressions) and/or create a ticket and/or comment here.

    Finally, I’m hoping to finish implementing menu previewing by the end of this week, fully utilizing the Customizer. Once this is done, I’ll essentially be at feature-complete stage (other than some little details and several known bugs) and ready to iterate (I’m already planning on working on the add-menu-items backend, as it currently doesn’t scale).

    • michalzuber 5:30 pm on July 17, 2014 Permalink | Log in to Reply

      I’m figuring out why is `todo: Remove choices` in the `wp-includes/class-wp-customize-control.php` ? Couldn’t get it.

      • Nick Halsey 5:43 pm on July 17, 2014 Permalink | Log in to Reply

        That’s more related to the Customizer post, but I think that’s leftover from the initial customizer development in 3.4. We can remove the todo, since removing $choices is no longer an option due to back-compat.

    • Weston Ruter 8:26 pm on July 22, 2014 Permalink | Log in to Reply

      When an item is added, it is created as an orphaned draft via ajax, and its id is added to the nav_menu setting’s array.

      Something that I’ve been exploring with Customize Posts is the addition and deletion of postmeta. Instead of actually mutating the database, when creating new meta I’m creating faux post meta IDs and then referring to them in the preview filter. When saving the Customizer settings, these posts meta are then inserted at that time. It’s not quite done yet, as I need to now gather the post meta IDs that were inserted at the time of saving, and update the setting to refer to them.

      Generating a virtual post meta ID: https://github.com/x-team/wp-customize-posts/blob/85dc4e562ea806c17480899f5d94f93d42297de1/js/customize-posts.js#L611-L618

      Sanitizing a setting that includes virtual post meta ID: https://github.com/x-team/wp-customize-posts/blob/develop/php/class-wp-customize-posts.php#L303-L310

      It would be ideal if Menu Customizer could add new menu items virtually without touching the DB.

      • Nick Halsey 10:12 pm on July 22, 2014 Permalink | Log in to Reply

        I’m not sure if it would be possible to add items without touching the DB in a scalable way. The primary reason for doing that is so that menu item data doesn’t need to be sent to the server all at once when saving, which causes scaling problems currently (for example, imagine if 100+ menu items were added to several different menus upon initial setup of a site – that data would all go up together).

        In the existing menus system, items are similarly added to the db via ajax before being made available for manipulation in the UI. So, the concept of orphaned draft menu item posts is existing and currently being leveraged here.

  • Nick Halsey 2:44 am on June 28, 2014 Permalink
    Tags: , gsoc, , ,   

    GSoC Menu Customizer Update 

    Since this is my first post here, a quick introduction. I’m a student at the University of Southern California studying Civil Engineering, Architecture, and Music Composition. I’ve been contributing to WordPress Core for just over a year and this summer I’m pleased to be working on WordPress full-time for my Google Summer of Code project.


    The goal of the Menu Customizer project is to add Custom Menu management to the Customizer. Ideally, the project should be able to replace the existing Menus screen, with full feature parity, but that’s obviously a bigger discussion that would take place later. For more details, check out my initial proposal.

    Current Status

    I started six weeks ago and have built out most of the plugin’s UI and structure. However, I still need to build the menu-item previewing and saving components of the project. The UI closely resembles the Widgets-in-customizer UI, with sections for each menu and controls for each item. New menu items are added via a slide-out panel, where they’re currently grouped by post type/taxonomy, custom links, and a global search feature. The existing “Navigation” Customizer section has been re-branded to “Theme Locations,” and emphasizes the ability to add menus to widgets. Development is being done on the plugin repo, and you can download and play with it from there, but note that adding items creates orphaned draft menu items that are never published currently. Here’s a demo of the current plugin:

    (If the embedded video doesn’t play for you, try this link: https://cloudup.com/cVJbk3u32QV)

    The add-menu-item UI and implementation will be getting a lot of attention throughout the rest of my project. Items are added immediately, rather than the existing two-step checkboxes and adding several at once process, and menu items can now be deleted without having to open their settings, making deletion and addition more streamlined.

    When editing menu items, changing the navigation label of an item instantly updates its drag-and-drop handle, and updating a menu name updates the corresponding Customizer section. Items can be reordered or moved into sub-menus via either drag-and-drop or a reordering mode similar to that of the Widget Customizer.

    To minimalize the UI, given the limited space in the customizer, the “Title Attribute” field has been turned off by default, and all of the existing menu-item-field screen options are available, syncing with the existing Menus screen. I might look into building a core API for customizer screen options now that #27406 is in trunk, time permitting.

    A good amount of my time in the past couple weeks has been dedicated to #27406, which is a prerequisite for the Menu Customizer to be realistic given the need to allow users to create new menus (and in turn, new Customizer sections). Committed to trunk yesterday, it introduces a “Panels” API to the Customizer. Panels are a way to group sections, adding a new layer of hierarchy to the Customizer. In the Widget Customizer, all widget areas are added to the Widgets panel, allowing widgets to take over the entire Customizer as needed. The Menu Customizer plugin does the same thing with Menus, and requires trunk accordingly.

    Upcoming Work

    My next steps are to implement menu-adding and deleting, to implement reorderability/sortability, and then to spend quite a bit of time developing a saving/previewing system that scales well (see #14134  and related). This will most likely involve creating clones of changed menu items (posts) and menus (taxonomy terms). Once all of that’s finished, the plugin should be feature-complete, and ready for iteration.

    Core Patches

    I’ve also taken the opportunity to spend a fair amount of time working on core patches related to either Menus or the Customizer, as this project is widely expanding my knowledge of both areas. A couple of examples that have made it into core include #27406 – Customizer Panels, and #23076 – which adds live menu-item label-updating to the existing Menu screen. I’m planning on continuing to work on Menus and the Customizer via tickets/patches throughout my project as time allows.

    • helgatheviking 3:00 am on June 28, 2014 Permalink | Log in to Reply

      The video is pretty sweet!, great work! I’m definitely interested in seeing #14134 get fixed because it has been holding up the addition of an [18584: action hook for custom menu item meta](https://core.trac.wordpress.org/ticket/18584), which is causing all menu modifying plugins (and themes) to not be compatible with each other.

      • Nick Halsey 3:21 am on June 28, 2014 Permalink | Log in to Reply

        Thanks! I’m hoping to both fix the scaling issues and add some hooks in the new interface. The addition of a hook would really open up the possibilities for what menus can do, as your plugin and others already demonstrate.

        That being said I’m thinking that an API for custom menu fields might be even better than a hook, as that would make it easier to work with and match other core patterns for this type of structure. We’re essentially looking at custom post fields here given the way menus work. I’ll definitely look into this more once I get to the initial feature-completion stage. The ongoing Metadata UI API project might be able to be integrated here in some form, too.

    • nikeo 8:28 am on June 28, 2014 Permalink | Log in to Reply

      Great work! The plugin’s code is really clean and well commented.
      Thanks for sharing

    • Rami Yushuvaev 5:05 pm on June 28, 2014 Permalink | Log in to Reply

      Have you tested this in RTL mode?

      • Nick Halsey 5:54 pm on June 29, 2014 Permalink | Log in to Reply

        Not yet, that’ll come once we’re ready to test on different devices & environments after the basic functionality is complete. That being said, I’m guessing that the core build process will handle most of it automatically.

    • Graham Armfield 10:24 am on July 8, 2014 Permalink | Log in to Reply

      I think some accessibility testing needs to be done on this to ensure that anyone not using a mouse, and screen reader users are catered for here.

  • Ella Van Dorpe 11:39 pm on June 20, 2014 Permalink
    Tags: , gsoc   

    GSoC: Editor Experiments #2 

    I meant to do a post last week, so this one is a bit late, but here it is anyway. I’ve mostly been working on the extendibility of views in TinyMCE and little improvements to the views themselves.


    I’m trying to find a way to make it as easy as possible for plugins to create a view for their shortcode (though it doesn’t necesarily have to be a shortcode). At the moment the biggest challenge is the handling of scripts for those views. Views with scripts are sandboxed in an iframe, but while this is great for a view that just displays external content (like a map or tweet), it’s not so great for normal content because the iframe doesn’t inherit the styles of its parent. Sure, we could “detect” some styles, but that’s not good enough. We could also put editor-style.css in each iframe, but that will break once you switch formats or categories, unless we change every iframe’s body class simultaneously. I wish all major browsers supported “seamless” frames. 🙁

    On the front-end, however, we wouldn’t have this problem. The content is not wrapped in an iframe, so scripts can be added where they normally would.

    The current registation of a shortcode and view looks like this. It will change a lot though.

    register_shortcode( 'my_shortcode', array(
    	'__FILE__' => __FILE__,
    	'content' => '',
    	'block' => true,
    	'attributes' => array(
    		'my_attribute' => array(
    			'title' => __( 'My Title' ),
    			'defaults' => ''
    	'scripts' => array( 'script-handle', ... ),
    ) );

    Notice that all the attributes must be defined here, unlike add_shortcode(). Now you’ll need to create a directory my_shortcode in the directory of __FILE__.



    This is what the shortcode will output on the front-end. This file receives the variables $attributes, $content and $tag.


    This file registers the view for the TinyMCE editor.

    ( function( $, views ) {
    	'use strict';
    	views.register( 'my_shortcode', {
    		getHTML: function( attributes, content, tag ) {
    			// Content goes here.
    		edit: function( shortcode, attributes, content, tag, node ) {
    			// This function is run when the user clicks on the edit icon.
    			// E.g. you could create a default modal (or create your own).
    			// This modal will display the `edit.php` template. You can provide a callback to do some crazy stuff.
    			// If edit.php is set up correctly, all the attributes will be filled in for you.
    			this.modal( node, callback );
    			// OR
    			// While the modal above will handle the update automatically when the user clicks on <input type="sumbit">,
    			// you can also do it manually.
    			this.refresh( attributes_or_shortcode, node );
    	} );
    } )( jQuery, wp.mce.views );


    A script to run with the view’s content. This could also go in a <script> tag inside the content. Both will trigger an iframe.


    An html template to display the input fields. This will be optional, by default it would just display input fields for all the attributes you registered. You can hide certain attributes and set up your own controls by providing a custom edit.php template and add JavaScript using the modal callback.

    The name attributes that match the registered shortcode attributes will be filled in automatically with the old shortcode attributes and the defaults when using this.modal().

    <input type="text" name="my_attribute" value"">
    <input type="submit" class="button button-primary">

    An example

    Eventually I’ll create several examples to illustrate all this. So far I’ve made an example for a map (a Google map). The code can be found in a child plugin: https://github.com/avryl/editor-experiments/tree/master/google-maps-block. You can see all the files I described when you enter the map directory.

    In the editor, it just looks like this.

    Screen Shot 2014-06-20 at 09.55.34

    The edit view looks like this. You can search, add a marker, drag and drop it, move the map, change it to satellite and save it all.

    Screen Shot 2014-06-20 at 09.59.06

    View for embed

    I’ve also been working a bit on the embed view for core. You can now paste an embeddable URL and it will automatically create a view for it. See #28195.

    View improvements

    I experimented a bit with the views themselves to make navigation and editing around them easier. Right now you can’t put your cursor right before or after a view. But with the Editor Experiments plugin you can! This is done by creating a fake cursor next to the view and detecting when the cursor enters and leaves the view. The cursor behaves exactly like a normal cursor (though the height is equal to the view), you can’t see the difference.

    Screen Shot 2014-06-19 at 14.54.34

    • Dinesh Kesarwani 5:48 am on June 21, 2014 Permalink | Log in to Reply

      It’s awesome.

      But how hierarchical shortcodes will be handled? For (basic) example

      [grid col=”6″]thecontent[/grid]
      [grid col=”6″]thecontent[/grid]


      • Florian Girardey 8:22 am on June 21, 2014 Permalink | Log in to Reply

        I love this Idea, i think that hierarchical shortcodes will be handled as they are actually. Each shortcode tag wrapp will render an html output.
        But i think that we need first to resolve the bug of nested shortcodes with the same tag :/

      • Avryl 3:29 pm on June 21, 2014 Permalink | Log in to Reply

        If all the shortcodes that you nest belong to the same plugin, the plugin can easily handle that. Actually, there’s no need at all for shortcodes within the main shortcode, because you create the shortcode through a UI. You can simply output HTML. But it’s still possible.

        If there are shortcodes inside the content of a shortcode by another plugin, it’s up to that plugin to parse them or not. But you can’t have a view inside a view atm. I’m also not sure if that’s necessary. I’d like to see some use case for such a scenario.

    • J.D. Grimes 12:22 pm on June 21, 2014 Permalink | Log in to Reply

      This is exciting, especially the shortcodes. I would love to see that make it to core. I’ll definitely be following along here..

    • TV productions 1:44 pm on June 21, 2014 Permalink | Log in to Reply

      I really like the idea! Views for shortcodes is a thing that seperates WordPress from being a multicontent CMS. I hope there is some space for the overall layout, so that the flow for inserting/editing a shortcode will look (almost) the same for each shortcode. I will be keeping an eye on this project 😉

    • programmin 12:53 am on June 25, 2014 Permalink | Log in to Reply

      Cool! So this will be a consistent api for creating shortcodes with the edit/delete buttons like most wp-core shortcodes? (related to bug introduced in 3.9 – https://core.trac.wordpress.org/ticket/28169) That will be great – especially for Nextgen-gallery and others that awkwardly have a click-event on a preview image to go to edit special content.

      Btw when you say “I wish all major browsers supported “seamless” frames”, are you talking about how stylesheets don’t apply within the iframes in the page (like TinyMCE’s iframes)? Because the latest MCE4 releases have support for inline mode – which uses a contentEditable in the page, without iframes:


      Btw am I the only one seeing “Notify me of follow-up comments by email” on this comments form?

      • Avryl 2:30 am on June 25, 2014 Permalink | Log in to Reply

        More or less, yes. I’m actually trying to make all of this work inline, so you’re in “edit mode” immediately when you click anywhere on the view. You could then add your own buttons inline to open a modal, or have all the controls inline.

        I don’t think it’s a good idea to use inline mode in the admin. With an iframe you create a sandbox for both CSS and JS, which makes it a lot easier to add something like editor-style.css without having to reset all the admin styles. I think TinyMCE is also going to use a seamless iframe for inline mode once it’s better supported.

    • Nick Haskins 6:18 pm on July 27, 2014 Permalink | Log in to Reply

      Really some great work on this Janneke! We’ve been watching the progress of this and wpview pretty closely, and have been waiting for this api to truly take advantage of it within our plugin.

      I see that this is labeled “experiment.” Am I correct in assuming that this codeset won’t be in 4.0? If it will be, in what form?


  • Ella Van Dorpe 2:13 pm on May 30, 2014 Permalink
    Tags: , gsoc   

    GSoC: Editor Experiments 

    I’ve not posted on /core before, so, hello everyone! 🙂 I’m Janneke and I’m currently working on my GSoC project. I’m from Belgium, but I currently live in Scotland and study philosophy at the University of Glasgow. This is something different entirely, but I started playing with WordPress a bit last year and enjoyed it a lot. 🙂

    The original proposal was focussed on the front-end editor and content blocks, but that has changed a bit. I’ll focus on the back-end editor first instead, though the work will likely be reusable for a front-end editor. I’ll also focus on a bit more than just “content blocks”, so that’s why I’ve titled this “Editor Experiments”.

    My general goals are to try to simplify and visualise the editor more, and to improve the workflow by providing as many tools as possible inline, at the right place and time. A lot of these ideas are not new, of course, and can be found in other editors and Joen‘s and Mel‘s mockups from last year. In order to visualise the editor more, I’ll try to make it easy for plugins to register shortcodes with previews for them, like there are now previews for a couple of media shortcodes such as galleries.

    I’ll post an update on this blog every Friday with the progress I’ve made. I meant to publish a post last Friday, but didn’t have access to this blog yet, so here’s one for both weeks. I’ve set up a GitHub repo, and for now that’s the only place where you can download the plugin.


    I’ve empty the TinyMCE toolbar, leaving only the most general tools, undo/redo, paste as plain text, remove format and help. On the other side we can control the the screen: switch between visual and text mode and activate fullscreen mode.

    Screen Shot 2014-05-30 at 13.35.31

    Instead of putting the title in a tiny box, I moved it to the editor as a first heading so it looks the same as on the front-end. Themes can style it appropriately.

    Screen Shot 2014-05-30 at 13.41.37

    Whenever you move the focus to an empty paragraph, a suggestion pops up to insert a “content block”.

    Screen Shot 2014-05-30 at 13.46.29

    To insert aligned images, you can put your cursor at the start of a paragraph.

    Screen Shot 2014-05-30 at 13.58.42

    Clicking on it gives you some kind of modal, where you can choose a block to add to your post. Of course, in the future plugins will be able to add their own blocks by registering shortcodes. So blocks can be block level HTML elements and block level shortcodes.

    Screen Shot 2014-05-30 at 13.49.21

    What happens after clicking on one of the blocks will depend on the block. Clicking on any of the media blocks will forward you to the media modal. Plugins can have a custom modal to configure the shortcode, which will likely also be used to edit it. Of course, blocks that require no configuration are added immediately (like a horizontal rule).

    To format text, you should select it, and a toolbar will pop up.

    Screen Shot 2014-05-30 at 14.03.56

    And let’s add a link.

    Screen Shot 2014-05-30 at 14.06.06

    That’s it for now. 🙂

    In the next two weeks I’ll work on the registration of views for shortcodes.

    Now I’d love to hear what you think! I really value your opinion and brilliant ideas. Please do try it, and file issues on GitHub.

    • andrei1709 2:21 pm on May 30, 2014 Permalink | Log in to Reply

      Hello and pleased to meet you!
      Your suggestion looks good, but wouldn’t this send too many GET requests to the server, thus making the text editor more laggy?

      • Avryl 3:59 pm on May 30, 2014 Permalink | Log in to Reply

        For the previews? Currently galleries, playlists etc. are already previewed in the editor. They’re put together from templates, so the output of the shortcode is not requested. But yes, depending on the shortcode, it will always take some time to generate it, but not more than on the front-end.

    • Remkus de Vries 2:23 pm on May 30, 2014 Permalink | Log in to Reply

      I like where this is going. One thing we’d have to be careful with is not putting to much stuff in the modal pop-up. All the various media types would only need one button and take if from there to what we know now.

    • tomdryan 2:26 pm on May 30, 2014 Permalink | Log in to Reply

      Good stuff!

      I’ve wanted to see the registration of shortcodes, along with content blocks and I’m glad you are working on it. In your registration procedure/data structure, please include a description of the shortcode function, supported parameters and the source of the shortcode (which plugin created it).

      Also, it would be nice if you enabled standard widgets to be inserted anywhere and if you enabled any widgets to have a corresponding shortcode (there are plugins that do this now, but it should be included as part of your overall re-envisioning of content creation).

      Keep up the good work!

      • Avryl 4:01 pm on May 30, 2014 Permalink | Log in to Reply

        Yes, these are good ideas. I’ve also always wanted to see shortcodes and widgets merged into one concept.

    • tomdryan 2:32 pm on May 30, 2014 Permalink | Log in to Reply

      Also, it would be nice if you put this in the form of a plug in at some point, so those of us non-coders can test it out and provide feedback.

    • Brad Touesnard 2:37 pm on May 30, 2014 Permalink | Log in to Reply

      Very cool, great work, looking forward to seeing more of this.

    • Eric Binnion 2:47 pm on May 30, 2014 Permalink | Log in to Reply

      Looks interesting! I went ahead and starred the Github repo and I look forward to playing with this 🙂

    • Christiaan Conover 2:56 pm on May 30, 2014 Permalink | Log in to Reply

      Great idea! I love seeing a new take on the way the editor functions to make it more flexible and extensible. I’ll definitely be trying out your solution!

    • Seth Rubenstein 3:25 pm on May 30, 2014 Permalink | Log in to Reply

      Great idea. Can’t wait to see what’s possible with the shortcode registration.

    • @ubernaut 3:32 pm on May 30, 2014 Permalink | Log in to Reply

      looking good.

    • camu 4:02 pm on May 30, 2014 Permalink | Log in to Reply

      It reminds me of Visual Composer (check CodeCanyon).

      • Avryl 4:13 pm on May 30, 2014 Permalink | Log in to Reply

        The biggest difference is that Visual Composer is more like a page builder. If you just want to write something, it’s very confusing.

        • binarymoon 4:22 pm on May 30, 2014 Permalink | Log in to Reply

          that said – I’d love to see some visual composer style functionality built into this. Even if it’s just the ability to add additional shortcodes to the popup through a plugin.

          Regardless – I think this looks sweet. If you create a plugin for it so I can install through wp.org then I’d love to test it out.

    • Chris Reynolds 4:19 pm on May 30, 2014 Permalink | Log in to Reply

      I’d be really interested in seeing how this fares vs. the regular editor in user testing. It looks good, but I wonder about the lack of the WYSIWYG (or, more specifically, the stripped-down toolbar). For me, I use keyboard controls to do things like bold or italics, so selecting text and waiting for the pop up wouldn’t bug me much, but some of the other things (content blocks and links) might not be immediately intuitive. But I have no idea — would be great to see some testing 🙂 and +1 for the pluginified version. You get a plugin for this and maybe the admin-help-come-user-testing team can maybe run some tests for it (or at least add it to the list).

      • Avryl 4:23 pm on May 30, 2014 Permalink | Log in to Reply

        Yes, I’d definitely like to do some user testing in a few weeks! It’d be great if you could help with that. 🙂

      • Andy McIlwain 9:25 pm on June 3, 2014 Permalink | Log in to Reply

        An issue I’ve seen with some users — including myself — is when we’re writing long-form content and we need to scroll up/down the screen to get back at the toolbar.

        Moving the text formatting inline would ease some of those frustrations.

    • Diego de Oliveira 4:49 pm on May 30, 2014 Permalink | Log in to Reply

      Just tested this plugin and… wow, it’s already awesome! Congratulations!

      I think that this approach could really solve the main issues of CEUX project and would integrate really good with the FEE. The editing experience reminds a lot of Medium editor, which is good. And I really liked the modal for content blocks, looks like a good solution for scalability of content blocks.

      One thing that the CEUX project had was the possibility to sort / reorder content blocks. Any plans for something like this? I know that drag / drop is naturally possible for media objects (and other possible views), but it would be cool if we could do the same with the usual elements, like paragraphs, lists, tables, etc.

      And please, keep the awesome work!

      • Avryl 4:58 pm on May 30, 2014 Permalink | Log in to Reply

        Great! Thanks for giving it a try!

        Yes, maybe. I’ve experimented a bit with with drag and drop of direct children of the body, which is challenging, but could work. That be really cool. I know that arrow are really useful sometimes, especially on touch devices, but I really hate adding so much buttons/icons. 🙂

        • Diego de Oliveira 5:14 pm on May 30, 2014 Permalink | Log in to Reply

          Yeah, “less is more”, almost always! More buttons/icons = more cluttering, and a strong point for your approach is how clean is the process of editing content. But for touch devices… that’s would be challenging, for sure!

          There are some sortable js libraries that works on touch devices too, but I don’t know if it would work for a really long content that would be edited in a smartphone. Still, I would prefer drag ‘n drop instead of arrows. At least for me, it feels more intuitive.

      • Avryl 4:59 pm on May 30, 2014 Permalink | Log in to Reply

        I’ve experimented a bit with with drag and drop of direct children of the body

        This sounds so weird out of context.

    • Paal Joachim Romdahl 5:12 pm on May 30, 2014 Permalink | Log in to Reply

      I am thinking beside the eye (visual) mode there can also be a grid icon. Turn on the grid to place elements in grid cells (kinda like table data cells). Click inside a cell and see the cell walls go darker blue. Write and add content into the specific cell. Turn off the grid to see how the content is aligned into nice columns and rows.

      Adding break points. Resize the browser and click somewhere to make a break point. At each break point redo any of the content. Easy way to create media queries directly inside the content creation area. Perhaps a way to turn break point view on or off.

      • Avryl 5:18 pm on May 30, 2014 Permalink | Log in to Reply

        Yes, columns is a much requested feature… I’m not sure if something like this should added in the content itself. The theme should handle that. What if you divide your content into 2 columns and switch to a smaller width theme? :/

        I’m not sure what you mean in the second paragraph.

        • Paal Joachim Romdahl 5:33 pm on May 30, 2014 Permalink | Log in to Reply

          Ok instead of a grid it is important to add items to columns one can see. To directly see how it looks. A grid is basically about seeing how elements are together on a page.

          Another way to to drop/click an element next to another automatically creating a row of two elements.

          Break points to where the page changes to another layout. Here is an example on how it is done in Macaw: https://www.youtube.com/watch?v=lz7MlRSAR-I

          Creating visual media queries directly in the content screen instead of creating them through CSS (or having the option to do so).

          • Avryl 5:51 pm on May 30, 2014 Permalink | Log in to Reply

            Break points to where the page changes to another layout. Here is an example on how it is done in Macaw: https://www.youtube.com/watch?v=lz7MlRSAR-I

            Creating visual media queries directly in the content screen instead of creating them through CSS (or having the option to do so).

            Why would you want to do that? Isn’t that something for the theme to handle? I don’t really want to make it more difficult for writers to write something in WordPress. I want to make it easier. 🙂

    • Juanfra Aldasoro 5:28 pm on May 30, 2014 Permalink | Log in to Reply

      Looking and working great 🙂 I think that something like this (if it is coded with an extensibility approach) could normalize the diverse world the page builders are suffering these days. This way WordPress would have a final answer for the call on builders and shortcodes – as it did before with the customizer and options/settings for example.

    • Robert Chapin 2:09 pm on June 1, 2014 Permalink | Log in to Reply

      This is conceptually awesome. The editor is the soul of WordPress and yet is often neglected during discussions of new features.

    • bduclos 9:00 am on June 2, 2014 Permalink | Log in to Reply

      Looks really good!
      Is it planned for WordPress 4.0 or later?

    • PeterRKnight 11:27 am on June 2, 2014 Permalink | Log in to Reply

      Looks amazing already. I love where this is going.

    • Andy McIlwain 9:27 pm on June 3, 2014 Permalink | Log in to Reply

      Really liking this, especially the inline text formatting.

      Have accessibility considerations been made for keyboard-only input?

      • Avryl 3:20 pm on June 19, 2014 Permalink | Log in to Reply

        It wouldn’t be less accessible than the current toolbar. You can still use keyboard shortcuts to execute editor commands. The toolbar currently shows up when selecting content with your keyboard, but I’ll need to add a shortcut to move the focus to the toolbar. If you have any suggestions, feel free to share. 🙂

    • Manny Fleurmond 9:08 pm on June 10, 2014 Permalink | Log in to Reply

      Little iffy on the title being part of the editor but everything else is awesome. Having shortcodes being registered in your modal would be awesome for plugin developers. I’d probably find a way to merge your modal with the existing media modal, since all of the media buttons are repeated. Heck, it could be a chance to abstract the media modal to an “insert content block’ modal.

      I’m definitely keeping an eye on this. Great job.

    • morethinking 9:07 am on June 19, 2014 Permalink | Log in to Reply

      First of all, thanks for doing this. This is something that many people in the WordPress community have been wanting for a long time (as the popularity of page builders indicates).

      With that said, I would like to offer my two-sense worth on the issue of columns.

      You wrote:

      “Yes, columns is a much requested feature… I’m not sure if something like this should added in the content itself. The theme should handle that. What if you divide your content into 2 columns and switch to a smaller width theme?”

      In my opinion, columns are more often than not an issue of content and should be part of the editor. What’s more, I believe there are solutions to the issue that you raised. Take a look at the Live Grid Example here: http://getbootstrap.com/2.3.2/scaffolding.html.

      Beyond that, obviously a user needs to pick a theme that works with his or her particular content. If someone wants columns and a particular theme doesn’t work with their columns then they should either choose a different theme, modify the theme so that it fits in with their content or give up on using columns.

      What I don’t think should be done is to leave the option of users organizing their content into columns to theme developers (except in those cases where columns are being used more for design purposes). I also don’t see why the option shouldn’t be included because of those rare cases where a problem may develop.

      One last thought/point. It may be worth taking some time to look at the Squarespace layout editor to see what they have done in general as well as how they handle columns.

      With that said, once again thanks for the great work.

      • Avryl 3:30 pm on June 19, 2014 Permalink | Log in to Reply

        When people talk about columns, the first thing I think of is splitting the whole content in two columns, but that’s not what they mean in most cases. That’s why I suggested that the theme should handle it, because in that case it makes sense.

        Sure, I can see why it’d be useful. I’m not sure if it can be done within TinyMCE, but I have some ideas. I’ll definitely give it a try at some point.

        I’ve looked at most editors on the internet, including Squarespace. 🙂

    • morethinking 9:07 am on June 22, 2014 Permalink | Log in to Reply

      I see that you have done your homework :).

      Glad to hear that you are willing to give it a try.

      Just one question, I’m not sure what you mean by ‘splitting the whole content in two columns’. What I have in what one might find on a home page — with different sections of the page divided into different columns to display the content differently. It would be nice if the end user could have control for laying out content like that.

  • Jen 7:15 pm on April 21, 2014 Permalink
    Tags: gsoc,   

    GSoC students announced! https://make.wordpress.org/community/2014/04/21/gsoc-students-accepted/

    (core projects are the minority this year, which is why I posted over on the community site under mentorship programs)

  • Samuel Sidler 10:22 pm on March 19, 2014 Permalink
    Tags: gsoc,   

    GSoC Chat Tomorrow 

    For those interested in Google Summer of Code, we’ll be holding a chat tomorrow on IRC in #wordpress-gsoc, March 20, at 18:00 UTC (2pm EDT, 11am PDT). Bring your proposal along and you’ll have five minutes to talk through your proposal with mentors. We’ll try to fit everyone.

    If you haven’t already, be sure to submit your proposal as soon as possible. There’s not much time left to get feedback prior to the submission deadline! Keep in mind that you can modify your proposal up until the deadline.

    See you all tomorrow!

    • Andrew Nacin 10:25 pm on March 19, 2014 Permalink | Log in to Reply

      The deadline is Friday, March 21 at 19:00 UTC..

      Worth pointing out that you can edit your proposal after it is submitted, up until the deadline. After that, you can still comment on your proposal, such as if any mentors ask you questions.

  • Jen 5:25 pm on March 10, 2014 Permalink
    Tags: gsoc,   

    GSoC IRC Chats 

    The application period opens today and closes on March 21. Between now and then, we’ll set up a handful of IRC chats starting this Wednesday (We’ll use #wordpress-gsoc so as not to distract from the beta work in -dev, and won’t get too close to the dev chat time-wise) to allow some real-time chatting with potential students about their project ideas.

    All mentors should sign up for at least one time slot so the students will know which chat time will have appropriate mentors in the room. Everyone is welcome to attend these chats, not just mentors.

    I’d like to pick 2 times of day and do the chats on Thursday the 13th, Saturday the 15th, Tuesday the 18th, and Thursday the 20th. 21:00 UTC seems to work well for dev chat, so I’m thinking that could be one of the times, but would like a 2nd time that we could do at least once or twice to make it easier on anyone on Australia/Russia side of the world.

    Mentors: Please leave a comment with which days/times you can be available for chats in IRC. If anyone has an idea for a good 2nd chat time, suggestions welcome.


    • Bryan Petty 6:00 pm on March 10, 2014 Permalink | Log in to Reply

      I’ll be at WC Atlanta, leaving the 13th and back on the 16th. I’m pretty sure I won’t be available for the 13th, but might still be able to fit the 15th in. I can commit to the 18th and/or 20th though.

      An Australian/Russian friendly time is certainly a good idea, since GSoC always seems to actually be hugely popular with colleges in India.

    • Ian Dunn 6:13 pm on March 10, 2014 Permalink | Log in to Reply

      21:00 UTC on the 18th works for me.

      (The 13th and 20th would also work if necessary, but the 18th would be a little better.)

    • Aaron Jorbin 6:25 pm on March 10, 2014 Permalink | Log in to Reply

      13th and 20th work best for me.

      13th – 19:00 UTC till 23:59 UTC work best

      20th – 15:00 UTC til 05:00 the next day UTC works best

      I’m not sure there is a time that is good for Russia, East Coast USA and Australia. 0500 is one idea. It’s only 1am on the US East Coast, while being 4pm in Sydney and 9am in Moscow.

    • George Stephanis 9:17 pm on March 10, 2014 Permalink | Log in to Reply

      Most anytime — I’ll be around. 🙂

    • Yoav Farhi 8:08 am on March 11, 2014 Permalink | Log in to Reply

      The 18th on 21:00 UTC or earlier.

    • Marko Heijnen 8:45 am on March 13, 2014 Permalink | Log in to Reply

      All other dates then today works for me.

    • Eric 4:30 pm on March 14, 2014 Permalink | Log in to Reply

      I’m game for Tuesday the 18th, and Thursday the 20th

    • Aaron Douglas 7:37 pm on March 14, 2014 Permalink | Log in to Reply

      Tuesday the 18th and Thursday the 20th are good for me

  • Jen 7:00 pm on February 24, 2014 Permalink
    Tags: gsoc,   

    We’ve been accepted as a mentoring organization for GSoC! Now comes the work of interacting with potential students on wp-hackers (let’s try to be responsive, and nice) and in #wordpress-dev and #wordpress-gsoc (I’ll set up a few scheduled chats soon, but idle in the channel if you can to field questions) during the application period. Mentors, I’ll contact you within the next couple of days to set up chat times and discuss the application review process.

    Thanks to everyone who helped get our Ideas page filled!

  • Jen 6:16 pm on February 13, 2014 Permalink
    Tags: gsoc,   

    GSoC 2014 Application Status 

    I’ve submitted our GSoC application. If anyone is interested in seeing the essay/short-answer questions they ask and how I answered them, I posted that part of the application over at https://make.wordpress.org/community/2014/02/13/gsoc-2014-application/

    If you haven’t posted an idea to the codex page https://codex.wordpress.org/GSoC2014 but have time now, go ahead and add it. More ideas = more possible students applying for something that grabs their attention. Also, Google will be reviewing applications Feb 17-21, so adding more ideas (don’t forget to use the template and provide description) between now and the 17th is especially helpful. Not having enough ideas is why we didn’t get accepted in 2012.

    Google will announce participating organizations on February 24.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar