WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Nick Halsey 2:44 am on June 28, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    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.

    Overview

    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.

  • Alex Shiels 2:24 am on June 28, 2014 Permalink | Log in to leave a Comment  

    Update on the Plugins page work 

    A quick update on the Plugins page (previously: here and here). The three major areas of work are the Detail modal view; the plugin-install.php landing page; and the plugin list views. Some progress so far:

    #22599 has a minimal patch for displaying plugin reviews and ratings in the Detail modal. More work is needed.

    #27440 now has API support for image banners in the Detail modal.

    @stephdau is working on the next steps for the modal, which will probably include experimenting with removing or replacing the Thickbox code, and iterating on the UI.

    I’m working on the plugin-install.php page. There’s no specific ticket for it yet, but step 1 will be a basic overhaul incorporating some of the ideas in @melchoyce‘s thread in a rudimentary fashion.

    The plan is to get these minimally functional with API support very soon, and then experiment from there with the UI and incremental improvements.

    Some closely related tickets and posts:

    #28646 and #17902 suggest some improvements to the list views, both related to unifying the search list and the installed plugins list.

    #20002 suggests API improvements related to querying multiple plugins.

    This post includes screenshots of many web/app stores, which suggest some design cues. If you’d like to help out, we could use feedback and incremental patches on those tickets; and of course the Plugins component has many other tickets in need of attention.

     

     

     
    • Pippin Williamson 2:59 am on June 28, 2014 Permalink | Log in to Reply

      I love see these kind of updates. They make me so happy :)

    • Gustavo Bordoni 11:03 am on June 30, 2014 Permalink | Log in to Reply

      +1 for these, there is a lot of love for the Plugins!

    • Paal Joachim Romdahl 7:16 pm on July 1, 2014 Permalink | Log in to Reply

      Clicking the details of a plugin opens a modal box. If one wants to check the next plugin in the search list one has to first close the existing modal box and then click the next plugin details. What about including arrows to signal a forward and backward through the detail list of plugins one made a search for? (Similar to the themes screen.)

  • Eric Andrew Lewis 1:39 am on June 28, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Media Grid Update 

    Media Grid started as a standalone plugin by Shaun Andrews, which was a reimagining of the UI as an alternative to the traditional post list view in the Media Library. The argument was that images are the ubiquitous media type in most users’ libraries, so we should provide an interface to browse media visually.

    I joined the project in late April, attempting to integrate existing Media modal code. This work was merged into the standalone plugin, and into trunk(see #24716) in early June. In the process, I created documentation for the Media code, which is the most comprehensive resource for untangling the Backbone wires in media.

    Questions were raised about what problem the grid was solving, so in order to get a more hands-on understanding of user engagement with the Media Library, Jerry Bates performed user interviews. These confirmed our assumption that images are the pervasive media type, but also surfaced the fact that users identify media in different ways – some by the thumbnail, some by what post a media item is uploaded to, some by title.

    After a good amount of UX/UI chatter in weekly meetings, we decided we could serve users better by making a few changes to the original implementation merged into trunk. We’ve landed on mock-ups for a quick pivot, which I’m working on implementing . I’ll be dropping diffs for y’all Javascript Jedis to peruse on #24716, feedback welcome and appreciated. I hope to have merge-ables by Monday morning, and then to progress to user testing.

     
  • Helen Hou-Sandi 2:42 am on June 27, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 6/25 dev chat (IRC log):

    General

    • Beta 1 is being pushed back to July 9 from July 2, with each successive beta and RC 1 also pushing back a week. The schedule has been updated.
    • oEmbed (@azaozz), i18n / language packs (@nacin), media grid (@ericlewis), and plugin installer (@tellyworth) should each have an update post published here before the weekend, outlining what has been done thus far, next steps, points needing discussion, and relevant tickets.
    • Each of the above should have a new patch ready by Monday. Across the board, it would be nice to see more work-in-progress patches — props @ericandrewlewis for recent patches on the media grid ticket
    • Daily scrubs in #wordpress-dev happening at 15:00 UTC.
    • @johnbillion would like to help coordinate people who are given time by their employers to work on WP; Make/Core post forthcoming.

    oEmbed

    • Recent updates to oEmbed: previews in the editor, media modal, added a bunch of providers
    • Todos: SSL, script sandboxing, caching improvements, UI/UX tweaks
    • Two thirds of our supported providers don’t support SSL: #28507
    • @sams suggested SSL should be a requirement for oEmbed providers going forward (have since revised to an important consideration for the time being).
    • Insecure iframes and/or insecure contained content will be blocked by newer Chrome and Firefox.
    • Two options: placeholder or a nonced, authed, proxied iframe.
    • For Monday: Placeholder fallback for SSL admin and non-SSL oEmbeds.

    i18n

    Media Grid

    • A quick phase 2 of the media grid is going forward
    • Media Grid needs a fair amount of work, not user testable yet.
    • Reminder: watch out for strings like “Edit Media” (#) won’t work well for long translations, i.e. ru_RU.
    • @ericandrewlewis asked for feedback on the JavaScript application structural decisions around Media Grid. This is likely worth a separate discussion.
    • For Monday: A user-testable patch.

    Plugin Installer

    • Screenshots for possibly comparable things.
    • @tellyworth is working on plugin-install.php and @stephdau is working on the details modal / page.
    • Next: Need to discuss what kind of data is most helpful to display for users when they are trying to figure out which plugin it is they want.
    • For Monday: @tellyworth and @stephdau will post patches in progress.

    Other

    With thanks (again) to @designsimply for note collation.

     
  • Helen Hou-Sandi 3:30 pm on June 26, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Daily scrubs for 4.0 

    Let’s do daily scrubs / ticket triage for the duration of the 4.0 release cycle at 15:00 UTC in #wordpress-dev. Fellow committers and component maintainers, please comment below if you can pledge to be there at least once or twice a week, and potentially help drive that particular scrub.

    For those who aren’t as familiar with scrubs / scheduled ticket triage sessions, they aim to provide some structure and a known time to focus on existing Trac tickets. At least one committer should be around for each one for rapid feedback. If you are unable to make the time, that’s okay – there are often contributors at various hours in the #wordpress-dev IRC channel who can give feedback and look at tickets, and ad hoc scrubs are very much encouraged. Those who are interested in reviewing patches and triaging tickets are especially welcome, and anybody is welcome to bring a ticket for eyes. If no specific tickets come up, we’ll move to reports, such as that for the next major release or ancient tickets.

     
    • Konstantin Obenland 8:28 pm on June 26, 2014 Permalink | Log in to Reply

      please comment below if you can pledge to be there at least once or twice a week

      I should be available at least once or twice a week.

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

      I have standing client meetings during this time every weekday, except for Monday and Tuesday (thanks to Canada Day :-) ). So I can be there next week. #widgets #customize

  • Helen Hou-Sandi 7:12 pm on June 25, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Agenda for today’s dev chat:

    • Beta timing – on schedule for next week, 7/2.
    • Organize and rally around pushes on features: oEmbed, i18n, plugin install experience, media grid.
    • #22023: Remove UNIQUE for slug in wp_terms.
    • Texturize/formatting.

    Please propose other items in the comments below.

     
    • Robert Chapin 7:32 pm on June 25, 2014 Permalink | Log in to Reply

      Texturize is going well. #28564 started a bit of a debate about exotic forms of shortcode and HTML nesting. I’ve ensured that most HTML can still go inside of shortcodes. Several old issues about inline comments, escaped shortcodes, and [ and ] in hyperlinks have been resolved and unit tested. A few performance issues were fixed.

    • John Blackbourn 8:04 pm on June 25, 2014 Permalink | Log in to Reply

      Let’s talk about whether the findings of #28507 is going to be a problem sandboxed oEmbeds

    • helgatheviking 9:28 pm on June 25, 2014 Permalink | Log in to Reply

      Is this ticket Menu Item limits: https://core.trac.wordpress.org/ticket/14134 getting any love for 4.0 or is it relying on the results of the GSOC? If I ever wanted to take a crack at it, is it safe to rely on javascript for things? The entire admin requires it right?

  • Ryan McCue 2:01 am on June 23, 2014 Permalink | Log in to leave a Comment
    Tags:   

    JSON REST API: Version 1.1 

    I’m happy to announce the availability of version 1.1 of the JSON REST API.

    This release is a bit of a smaller, more focussed release as we work on increasing test coverage and squashing bugs. Here’s the juicy details:

    • Add new routes for taxonomies and terms.

      Taxonomies and terms have now been moved from the /posts/types/<type>
      namespace to global routes: /taxonomies, /taxonomies/<tax>,
      /taxonomies/<tax>/terms and /taxonomies/<tax>/terms/<term>

      Test coverage for taxonomy endpoints has also been increased to 100%.

      Deprecation warning: The /posts/types/<type>/taxonomies endpoint (and
      sub-endpoints with the same prefix) have been deprecated in favour of the new
      endpoints. These deprecated endpoints will now return a
      X-WP-DeprecatedFunction header indicating that the endpoint should not be
      used for new development, but will continue to work in the future.

      (props @kadamwhite, @rachelbaker, @rmccue, #198, #211)

    • Allow customizing the API resources prefix

      The API base (typically wp-json/) can now be customized to a different
      prefix using the json_url_prefix filter. Note that rewrites will need to be
      flushed manually after changing this.

      (props @ericandrewlewis, @rmccue, #104, #244, #278)

    • Give null as date for draft posts.

      Draft posts would previously return “0000-00-00 00:00:00″ or
      “1970-01-01T00:00:00″, as draft posts are not assigned a publish date. The API
      now returns null where a date is not available.

      Compatibility warning: Clients should be prepared to accept null as a
      value for date/time fields, and treat it as if no value is set.

      (props @rmccue, #229, #230)

    • Fix errors with excerpt.

      Posts without excerpts could previously return nonsense strings, excerpts from
      other posts, or cause internal PHP errors. Posts without excerpts will now
      always return an excerpt, typically automatically generated from the post
      content.

      The excerpt_raw field was added to the edit context on posts. This field
      contains the raw excerpt data saved for the post, including empty
      string values.

      (props @rmccue, #222, #226)

    • Only expose email for edit context.

      User email addresses are now only exposed for context=edit, which requires
      the edit_users permission (not required for the current user).

      The email address field will now return false instead of a string if the
      field is not exposed.

      (props @pkevan, @rmccue, #290, #296)

    • Correct password-protected post handling.

      Password-protected posts could previously be exposed to all users, however
      could also have broken behaviour with excerpts. Password-protected posts are
      now hidden to unauthenticated users, while content and excerpts are shown
      correctly for the edit context.

      (Note that hiding password-protected posts is intended to be a temporary
      measure, and will likely change in the future.)

      (props @rmccue, #286, #313)

    • Add documentation on authentication methods.

      Full documentation on authentication
      is now available. This documentation explains the difference between the
      various available authentication methods, and notes which should be used.

      (props @rmccue, #242)

    • Include new client JS from github.io

      The WP-API Javascript library is now loaded dynamically from
      wp-api.github.io to ensure it is always up-to-date.

      (props @tlovett1, #179, #240)

    • Don’t allow setting the modification date on post creation/update.

      As it turns out, WP core doesn’t allow us to set this, so this was previously
      a no-op anyway. Discovered during test coverage phase.

      (props @rachelbaker, @rmccue, #285, #288)

    • Check post parent correctly on insertion.

      Posts could previously be added with an invalid parent ID. These IDs are now
      checked to ensure the post exists.

      (props @rmccue, #228, #231)

    • Make sure the type is actually evaluated for json_prepare_${type} filter.

      This value was previously not interpolated correctly, due to the use of the
      single-quoted string type.

      (props @danielbachhuber, #266)

    • Return WP_Error instead of array of empty objects for a revisions
      permissions error.

      Previously, when trying to access post revisions without correct permissions,
      a JSON list of internal error objects would be returned. This has been
      corrected to return a standard API error instead.

      (props @rachelbaker, @tlovett1, #251, #276)

    • Flip user parameters check for insert/update.

      Previously, you could add a user without specifying username/password/email,
      but couldn’t update a user without those parameters. The logic has been
      inverted here instead.

      (props @rmccue, #221, #289)

    • Add revision endpoints tests

      (props @danielbachhuber, @rachelbaker, @rmccue, #275, #277, #284, #279)

    • Add post endpoint testing

      Now at >54% coverage for the whole class, and >80% for the main methods. This
      figure will continue to rise over the next few releases.

      (props @rachelbaker, @rmccue, #99)

    • Separate helper functions into global namespace.

      WP_JSON_Server::get_timezone(), WP_JSON_Server::get_date_with_gmt(),
      WP_JSON_Server::get_avatar_url() and `WP_JSON_Server::parse_date() have
      all been moved into the global namespace to decouple them from the server
      class.

      Deprecation warning: These methods have been deprecated. The new
      json_get_timezone(), json_get_date_with_gmt(), json_get_avatar_url() and
      json_parse_date() methods should now be used instead.

      (props @rmccue, #185, #298)

    As always, we’ve got a full list of all the changes and a longer changelog. Here’s who contributed to this release:

    $ git shortlog 1.0...1.1 --summary
         8  Daniel Bachhuber
        12  DrewAPicture
         3  Eric Lewis
         2  JDGrimes
         9  K.Adam White
        54  Rachel Baker
       128  Ryan McCue
         4  Taylor Lovett
         1  jeremyfelt
         1  pkevan

    Version 1.2

    We’ve already started work on 1.2, and as always, we’re looking for help!

    With version 1.2 and onwards, we’ll be tackling a bunch of extra testing for our endpoints, with the aim of eventually reaching >90% coverage. As always, we’ll also be adding new features and fixing bugs.

    We’re also working on improving the new documentation site, and expect to see the majority of documentation migrated over there. Thanks to Sarah Gooding for helping out on the documentation side.

    Core Integration

    In case you missed it, the API is now slated for integration in WordPress 4.1. WP Tavern has a great writeup on the details.

    As always, we look forward to seeing you at the team o2 and on GitHub. Now’s also a great time to remind you that you can get support for the plugin on WP.org, or by tweeting at me. Thanks to everyone who made this release great, and thanks to everyone using the plugin!

     
    • Ian Dunn 4:14 pm on June 23, 2014 Permalink | Log in to Reply

      Include new client JS from github.io

      Is this intended to be a permanent change? I could be wrong, but I think Core’s policy (and also the wporg plugin directory’s) is that assets should be local.

      (Open Sans is an exception, because it’s very difficult to reproduce everything that Google’s API does locally.)

    • Stephane Daury (stephdau) 6:20 pm on June 25, 2014 Permalink | Log in to Reply

      Awesome work, gang.

  • Scott Kingsley Clark 6:06 pm on June 22, 2014 Permalink | Log in to leave a Comment
    Tags:   

    WP Metadata API / UI office hours this Friday 

    We will continue our weekly meetings this Friday. As no other suggestions have been made, it will remain at 18:00 UTC on Fridays in #wordpress-core-plugins on Freenode IRC.

    We may be transitioning from meeting into office hours as we haven’t had as many contributors joining us at the meetings as we had hoped. We will continue developing some awesomeness over at https://github.com/wordpress-metadata/metadata-ui-api

    Feel free to hop into the issues and take ownership of new field types or documentation. We’re also looking for help with styling of the form fields and JS in relation to support for repeatable fields.

     
    • Slobodan Manic 7:47 pm on June 22, 2014 Permalink | Log in to Reply

      Fridays work for me. I can continue working on field types, submitted a PR with four new input fields (email, range, number, color).

    • nofearinc 7:56 pm on June 22, 2014 Permalink | Log in to Reply

      9pm EEST on Fridays is not really the best timing for some of us either, which is 8pm for CEST (Central Europe) folks too (sorry for not being available, but that timing is a bit off here).

    • Ryan McCue 1:21 am on June 23, 2014 Permalink | Log in to Reply

      We may be transitioning from meeting into office hours as we haven’t had as many contributors joining us at the meetings as we had hoped.

      I think that’s just a common thing with feature-as-a-plugin teams; don’t be disheartened! :)

    • deltafactory 2:06 pm on June 23, 2014 Permalink | Log in to Reply

      Was last week’s cancelled? I was there and tried to get the conversation started but no one answered.

      • Scott Kingsley Clark 2:11 pm on June 23, 2014 Permalink | Log in to Reply

        Saw you and someone else were there, unfortunately Mike couldn’t make it and I was stuck in traffic trying to get home. We are all currently planning to be there this Friday, I won’t be cutting it so close with my plans on Friday either :)

    • Scott Kingsley Clark 8:32 pm on June 27, 2014 Permalink | Log in to Reply

      It turned out that Mike Schinkel couldn’t make it this week and I once again was stuck in traffic trying to get back from a WP lunch meetup.

      I think we’re going to try and push the ‘office hours’ a little earlier in the day so we can get some of our european contributors more involved.

      But going forward, I think in general, Fridays in #wordpress-core-plugins, I’ll be in there, and if you want to chat, we can chat, not sure if an hour long meeting slot is best while we’re in the current stage, until we have more movement and planning to be done as a group. Right now we’re just executing plans as we’ve laid them out.

  • Helen Hou-Sandi 4:38 am on June 22, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 6/18 dev chat (IRC log):

    Thanks to @designsimply for her help with notes and summaries this release!

     
  • Janneke Van Dorpe 11:39 pm on June 20, 2014 Permalink | Log in to leave a Comment
    Tags:   

    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.

    Registration

    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__.

    __FILE__
    /myshortcode
    	/template.php
    	/register.js
    	/preview.js
    	/edit.php
    

    template.php

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

    register.js

    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 );
    

    preview.js

    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.

    edit.php

    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

      [container]
      [row]
      [grid col="6"]thecontent[/grid]
      [grid col="6"]thecontent[/grid]
      [/row]
      [/container]

      to:

      thecontent
      thecontent
      • 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 :/

      • Janneke Van Dorpe 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:

      http://www.tinymce.com/tryit/inline.php

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

      • Janneke Van Dorpe 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?

      Thanks!
      Nick

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel