WordPress.org

Make WordPress Core

Welcome to the official blog of the core development team for the WordPress open source project.

Here, we make WordPress core. Follow our progress with general updates, status reports, and the occasional code debate.

We’d love for you to help out.

Looking to file a bug?

It’s easy to create a ticket on our bug tracker.

Want to contribute?

Get started quickly. We have some tickets marked as good first bugs for new contributors. There’s more on our reports page, like patches needing testing.

We also have a detailed handbook for contributors, complete with tutorials.

Weekly meetings

We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Wednesday at 20:00 UTC in the #core channel on Slack. (Find out more about Slack.)

You can find meeting agendas on this blog. You’re welcome to join us or listen in.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 11:54 pm on July 28, 2015 Permalink |
    Tags: , ,   

    Passwords in 4.3: Strong by Default 

    One of the development efforts in the WordPress 4.3 cycle was improving the way that passwords are chosen and changed. Before, people had to start from scratch when choosing a password. They were presented with an empty box, and had to use a really terrible tool for generating secure passwords: the human brain.

    Here’s how things look now, as we approach 4.3’s release candidate…

    Screen Shot

    And when you click that button…

    Screen Shot

    You start out with a strong password. And if you like, you can just accept that. Most modern browsers will offer to remember it for you (as well as password managers like 1Password and LastPass). Or, you could go old school and write it on a sticky note. Hey: anything is better than choosing “letmein”!

    You can, of course, click into the field and edit it. But now the password strength meter is better integrated with the field. Things start to look dire as you go your own way.

    Screen Shot

    That red seems to signal danger. And hey, look, below. This password is SO BAD that WordPress wants to make extra sure you know you’re doing something monstrously foolhardy.

    If you’re in a public location, you can hide your password, to prevent people from peeking over your shoulder.

    Screen Shot

    This new interface is also integrated into the Add New User screen. By default, we won’t even reveal the password. We’ll just send the user a reset link.

    Screen Shot

    But if you’re in a non-email environment or would like to pass this password to the user in a secure method such as iMessage, Signal, or TextSecure, you can reveal it…

    Screen Shot

    The new interface can also be found on the password reset screen and the WordPress install screen. They all start you out with a long, random, unguessable password. Although WordPress isn’t stopping you from choosing terrible passwords, the default in 4.3 is that you get secure passwords, and making them less secure takes a bit of work.

    In addition to this new UI, we have also stopped e-mailing passwords, so valid passwords aren’t going to sit in your e-mail inbox, waiting for some future e-mail hacker to gain access. Password reset links now expire in 24 hours by default. And when your password or e-mail changes, we send you an e-mail (in the case of e-mail, to your old address), so if someone hijacks your browser session and changes those critical items, at least you’ll be aware that it happened, and you can take action. You can disable these e-mails via the send_pass_change_email and send_email_change_email filters (just have them return false).

    Huge thanks to everyone who contributed code, testing, UI, and thoughtful feedback on this feature!

     
  • Konstantin Obenland 10:00 pm on July 27, 2015 Permalink |
    Tags: , , ,   

    Site Icon 

    WordPress 4.3 adds the ability for site owners to manage their site’s favicon on desktop and mobile. Site Icons work out of the box, are theme independent, and don’t require theme support. There are four sizes that WordPress supports by default:

    • 32x32px favicon.
    • 180x180px app icon for iOS up to the iPhone 6+.
    • 192x192px Android/Chrome app icon.
    • 270x270px medium-sized tile for Windows.

    The public API is very simple:

    • wp_site_icon() displays all available favicons and app icons.
    • get_site_icon_url() returns the url to the current site’s icon, or the default passed to it.
    • site_icon_url() displays an escaped version of the url to the current site’s icon.
    • has_site_icon() returns whether the current site has an icon set up or not.

    At this point we discourage theme authors from using site icons as logos in the front-end. It’s unexpected behavior for users since it doesn’t fit the API’s purpose.

    Custom Site Icons

    Plugin authors can add custom sizes to the site icon feature. To do this, filter the array of available sizes on the admin side and the array of meta tags on the front-end, like so:

    <?php
    
    function prefix_custom_site_icon_size( $sizes ) {
       $sizes[] = 64;
    
       return $sizes;
    }
    add_filter( 'site_icon_image_sizes', 'prefix_custom_site_icon_size' );
    
    function prefix_custom_site_icon_tag( $meta_tags ) {
       $meta_tags[] = sprintf( '<link rel="icon" href="%s" sizes="64x64" />', esc_url( get_site_icon_url( null, 64 ) ) );
    
       return $meta_tags;
    }
    add_filter( 'site_icon_meta_tags', 'prefix_custom_site_icon_tag' );
    

    Customizer Controls

    Nick Halsey published an article about the new Customizer controls that were introduced for Site Icon. The new controls make it trivial for any theme or plugin author to add custom features that require cropped images. For example, a logo manager. 😉

     
    • Rouven Hurling 6:26 am on July 29, 2015 Permalink | Log in to Reply

      Is it possible to disable Custom Site Icons?
      I already implemented something like it which uses the realfavicongenerator.net API, although I’ll probably modify it to use the new Customizer Controls.

  • Nick Halsey 9:29 pm on July 27, 2015 Permalink |
    Tags: , ,   

    Changes to Customizer Panels and Sections in 4.3 

    WordPress 4.3 contains some important changes to the Panels and Sections APIs. These won’t impact basic usage – add_section() and add_panel(), for example – but could potentially have compatibility issues for any custom panels or sections that override default methods. If you have themes or plugins that create custom sections or panels, please be sure to test with the latest 4.3 beta. Additionally, we’ve built out the API to support dynamically-added and more JS-driven panels and sections in 4.3. Details below.

    Changes to the Default Panel & Section UI

    Ticket #31336 introduced a new user experience for core Customizer sections, and made some adjustments to panels in the process. Sections in general now slide in sideways (like panels) rather than expanding open vertically in the “accordion” style. This change adds a heading within section containers that contains context for the user’s location within the Customizer hierarchy of sections/panels as well as the navigation back out of the panel.

    If you have a custom section that overrides WP_Customize_Section::render(), you will probably need to add the new section header markup that has been added to the base section. Without at least the back button, users could potentially become stuck within an open section because of this core change. Additionally, the panel-back button has moved from a single button in the header (over the Customizer close button) to being contained within the panel header, similarly to the section header. If you’re overriding WP_Customize_Panel::render_content() in a custom panel, you’ll probably need to add the panel back button there. For panels and sections, if you’re overriding the onChangeExpanded method in JavaScript, you would need to implement the core changes there as well, although odds are your implementation is custom enough that the changes to the default objects won’t affect you. Because custom section and panel implementations will vary widely, your best bet is to look at the revised code in trunk and adjust your code accordingly (see wp-includes/class-wp-customize-section.php). However, for basic sections using a UI close to the default one, adding the following to your render_template() method within ul.accordion-section-content is likely to work (note this is a JS template; can be converted to a PHP template fairly easily):

    
    
    <li class="customize-section-description-container">
    
    
    	<div class="customize-section-title">
    		<button class="customize-section-back" tabindex="-1">
    			<span class="screen-reader-text"><?php _e( 'Back' ); ?></span>
    		</button>
    
    
    		<h3>
    			<span class="customize-action">
    				{{{ data.customizeAction }}}
    			</span>
    			{{ data.title }}
    		</h3>
    
    
    	</div>
    
    
    	<# if ( data.description ) { #>
    
    
    		<div class="description customize-section-description">
    			{{{ data.description }}}
    		</div>
    
    
    	<# } #>
    </li>
    
    
    

    Note that custom sections and panels are generally designed to allow different UI implementations than the default behavior, so in many cases the changes to the default objects shouldn’t break your custom versions.

    JavaScript-templated Panels and Sections

    Building on the work done in 4.1 for controls, #30737 introduces JavaScript templates for panels and sections. The built-in core panel and section objects now use JS templates to render all instances by default. The PHP-rendered object API is still present and fully supported, but developers are recommended to strongly consider using JavaScript templates for control, section, and panel UI instead. These templates allow objects to be more easily created dynamically and improve performance by loading an object’s data (in JSON format) and a single template for the HTML structure rather than the complete fully-rendered HTML structure for repetitive (PHP-generated) UI.

    Menus in the Customizer drove the completion of this API addition, and it facilitates the dynamic creation of Customizer sections and controls when creating new menus. Further plans in this area include using JS templates for the base WP_Customize_Control object by default ( #30738) and building out the API for dynamically-created controls by implementing container templates similar to what panels have ( #30741).

    The remainder of this post will outline the various API additions that facilitate this, with code examples. Please review the initial post about JS templates and sections, as the new API for sections and panels is conceptually identical to what was introduced for controls in 4.1, taking a few more steps beyond it.

    Registered Panel and Section Types

    Similarly to the concept of registered control types introduced in 4.1, WP_Customize_Manager now supports registered section and panel types. For those that haven’t previously worked with custom sections or panels, they’re just like custom controls. You can override different pieces of the base object as needed to create custom UI. A great example in core is WP_Customize_New_Menu_Section, which is displayed as a button that toggles display of its controls inline, rather than a sliding panel.

    Registering a section or panel type tells the Customizer to print one copy of the object’s JS template to the page, so that any object with this type can be rendered dynamically. Instances added in PHP will be automatically inserted into the DOM after being rendered from the JS template when ready, and the template can also be used when adding an instance dynamically in JS (for example, when adding a new section when a new menu is created).

    Registering panel and section types works just like it does for controls:

    add_action( 'customize_register', 'prefix_customize_register' );
    function prefix_customize_register( $wp_customize ) {
      // Define a custom section class, WP_Customize_Custom_Section.
      // Register the class so that its JS template is available in the Customizer.
      $wp_customize->register_section_type( 'WP_Customize_Custom_Section' );
    }
    

     

    Sending PHP Data to JavaScript

    Customizer panel and section data has been passed to the relevant JS models since 4.1, but you’re much more likely to need to send data down when working with JS templates. Anything that you would want access to in render_content() in PHP will need to be exported to JavaScript to be accessible in your section or panel template. Since JS templates are now used by default for sections and panels, most of the core class variables for these objects are passed already. To add custom ones, override WP_Customize_Panel::json()/WP_Customize_Section::json() in your custom subclass. In most cases, you’ll want to merge with the return value of the parent class’s json() method also, to ensure that all core variables are exported as well. Here’s an example from the core nav menu section class:

    /**
     * Get section parameters for JS.
     *
     * @since 4.3.0
     * @access public
     * @return array Exported parameters.
     */
    public function json() {
    	$exported = parent::json();
    	$exported['menu_id'] = intval( preg_replace( '/^nav_menu\[(\d+)\]/', '$1', $this->id ) );
    	return $exported;
    }

    Using JS/Underscore Templates

    Once you’ve registered your custom section or panel class as a section or panel type and exported any custom class variables, you can create the template that will render the section or panel UI. This works slightly differently for sections and panels, because panels have a distinct container and content that can be overridden separately as needed.

    Sections

    For sections, you’ll override WP_Customize_Section::render_template() instead of WP_Customize_Section::render(). The render function is now empty in the base core control, so there’s no need to override it if you’re using a custom template. If you are using the existing PHP API, the JS template will not be used if content exists after running the render() function. The default section’s template looks like this in 4.3:

    /**
     * An Underscore (JS) template for rendering this section.
     *
     * Class variables for this section class are available in the `data` JS object;
     * export custom variables by overriding WP_Customize_Section::json().
     *
     * @since 4.3.0
     * @access protected
     *
     * @see WP_Customize_Section::print_template()
     */
    protected function render_template() {
    
    
    <li id="accordion-section-{{ data.id }}" class="accordion-section control-section control-section-{{ data.type }}">
    
    
    	<h3 class="accordion-section-title" tabindex="0">
    		{{ data.title }}
    		<span class="screen-reader-text"><?php _e( 'Press return or enter to open' ); ?></span>
    	</h3>
    
    
    
    
    	<ul class="accordion-section-content">
    
    
    		<li class="customize-section-description-container">
    
    
    			<div class="customize-section-title">
    				<button class="customize-section-back" tabindex="-1">
    					<span class="screen-reader-text"><?php _e( 'Back' ); ?></span>
    				</button>
    
    
    				<h3>
    					<span class="customize-action">
    						{{{ data.customizeAction }}}
    					</span>
    					{{ data.title }}
    				</h3>
    
    
    			</div>
    
    
    			<# if ( data.description ) { #>
    
    
    				<div class="description customize-section-description">
    					{{{ data.description }}}
    				</div>
    
    
    			<# } #>
    		</li>
    
    
    	</ul>
    
    
    </li>
    
    
    }
    

    As you can see, Underscore-style templates are very similar to PHP. As more and more of WordPress core becomes JavaScript-driven, these templates are becoming increasingly more common. Besides the Customizer, sample template code in core can be found in media, revisions, the theme browser, and even in the Twenty Fifteen theme, where a JS template is used to both save the color scheme data and instantly preview color scheme changes in the Customizer. The best way to learn how these templates work is to study similar code in core.

    Panels

    Panels have two distinct pieces to their UI: the container, which is displayed in a list with other panels and sections at the top level of the Customizer UI, and the content, which is the context that the Customizer enters when the panel is opened. Note that this distinction is due to the philosophical design of Panels to be distinct contexts, rather than simply being a way to group related sections together. This is also based on the distinction between the container and the content in control objects. However, the distinction between panels and sections in terms of UI is less visually clear in WordPress 4.3.

    Panel containers are rendered with the render_template() function, and the content template is inserted into the container in JS by looking for .accordion-sub-container. It will rarely be necessary to override the container template in a custom panel, as the custom UI will typically go in the content of the panel. The default panel template looks like this:

    /**
     * An Underscore (JS) template for rendering this panel's container.
     *
     * Class variables for this panel class are available in the `data` JS object;
     * export custom variables by overriding WP_Customize_Panel::json().
     *
     * @see WP_Customize_Panel::print_template()
     *
     * @since 4.3.0
     * @access protected
     */
    protected function render_template() {
    	?>
    
    
    	<li id="accordion-panel-{{ data.id }}" class="accordion-section control-section control-panel control-panel-{{ data.type }}">
    
    
    		<h3 class="accordion-section-title" tabindex="0">
    			{{ data.title }}
    			<span class="screen-reader-text"><?php _e( 'Press return or enter to open this panel' ); ?></span>
    		</h3>
    
    
    
    
    		<ul class="accordion-sub-container control-panel-content"></ul>
    
    
    	</li>
    
    
    	<?php
    }
    

    Panel contents are rendered with the content_template() function, similarly to the way control templates work. In the future, this part of the API will be completed with the addition of container templates for controls, see #30741. The default panel content template in 4.3 looks like this:

    /**
     * An Underscore (JS) template for this panel's content (but not its container).
     *
     * Class variables for this panel class are available in the `data` JS object;
     * export custom variables by overriding WP_Customize_Panel::json().
     *
     * @see WP_Customize_Panel::print_template()
     *
     * @since 4.3.0
     * @access protected
     */
    protected function content_template() {
    	?>
    
    
    	<li class="panel-meta customize-info accordion-section <# if ( ! data.description ) { #> cannot-expand<# } #>">
    		<button class="customize-panel-back" tabindex="-1"><span class="screen-reader-text"><?php _e( 'Back' ); ?></span></button>
    
    
    		<div class="accordion-section-title">
    			<span class="preview-notice"><?php
    				/* translators: %s is the site/panel title in the Customizer */
    				echo sprintf( __( 'You are customizing %s' ), '<strong class="panel-title">{{ data.title }}</strong>' );
    			?></span>
    			<button class="customize-help-toggle dashicons dashicons-editor-help" tabindex="0" aria-expanded="false"><span class="screen-reader-text"><?php _e( 'Help' ); ?></span></button>
    		</div>
    
    
    		<# if ( data.description ) { #>
    
    
    			<div class="description customize-panel-description">
    				{{{ data.description }}}
    			</div>
    
    
    		<# } #>
    	</li>
    
    
    	<?php
    }
    

    In core, the nav menus panel, which adds screen options for the panel, is a good example of a panel with a custom content template.

     
  • Konstantin Obenland 3:00 pm on July 27, 2015 Permalink |
    Tags: ,   

    This week in 4.3: Jul 27 – Aug 2 

    This is the jump-start post for the twelfth week of the WordPress 4.3 release cycle.

    We’re in the final stages of the release, by Wednesday we want to be able to present our Release Candidate to the community. A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. In this stage all product features have been designed, coded, and tested through a few beta cycles with no known showstopper-class bug.

    Priority Tickets this week:

    Core Meetings this week:

     
  • George Stephanis 12:09 pm on July 24, 2015 Permalink |
    Tags:   

    Two Factor Meeting Recap 

    Next week’s meeting will be on July 30th, 2015 at 17:00 ET — two hours later than this week’s meeting, to try and not drop it at 4am for some of our people.

    Log: https://wordpress.slack.com/archives/core-passwords/p1437678027000327

    Folks in attendance:

    @georgestephanis
    @bjornjohansen
    @swissspidy
    @stevenkword
    @aaroncampbell
    @jeffmatson
    @extendwings
    @cconover
    @julien731
    @deltafactory
    @tomdxw
    @valendesigns

    Reviewed rough plans with authentication provider classes and who is working on each. @julien731 has a wealth of experience with TOTP and @extendwings with U2F, and will likely be helping with each respectively.

    I’m expecting to have the fallback methods branch finished and merged in by EOD today or tomorrow. At that point, it will likely need some design love, as it will need to account for three different things — what the user’s primary provider is, what providers the user has enabled, and configuring providers. For the moment we’re going for functionality over design, so it’ll just be checkboxes for available, radio button for primary, and letting each provider handle configuration.

    Added @valendesigns and @stevenkword as committers on the repo.

     
    • CotswoldPhoto 6:39 pm on July 24, 2015 Permalink | Log in to Reply

      I am hoping to use the Google one (I currently use the one written by Henrick Schack together with the Per User Prompt written by Ian Dunn), so I hope it has a lazy code option (allow codes +/- time error) as the time window on the standard version is too tight for many servers to be accurate to. Also, for security reasons, I hope the system uses a per user prompt; the standard WP login box at first, if user and pw are correct, a new box appears to prompt for the 2FA code. Errors returned (to hacking bots) do not reveal that 2FA is active for that user.

  • Jeremy Felt 6:14 am on July 24, 2015 Permalink |
    Tags: , ,   

    Multisite Focused Changes in 4.3 

    Howdy! We’ve made quite a bit of progress in multisite as part of the 4.3 cycle and have a bunch slated to continue working on throughout the year. If you’d like to follow along, stop by our weekly office hours on Tuesdays at 20:00 UTC in #core-multisite.

    Here’s what we have coming in 4.3…

    Begin streamlining the interface for setting a site’s URL.

    Editing a site’s address for what it is—a combination of domain and path—becomes more straightforward in 4.3. A full address with or without scheme can now be entered if multisite is configured as subdomain. Network administrators have been hacking at this anyway for years when the two fields were separate to provide arbitrary domain support. See #22383 for all the details.

    In combination with this, the checkbox for “Update siteurl and home as well” has been removed when editing a site. Instead we can make an educated decision based on the current state. If the home and/or siteurl domain and path match the existing domain and path of the site, we assume that we can update all values with the new information. See #32503 for details.

    And to better enforce URLs vs domain and path, we’ve improved the default columns displayed in MS Sites List Table. The full URL is now show instead of the domain or the path. We also now show a total user count for each site rather than the first 5 users. See #32434 for details.

    Introduce get_main_network_id()

    This likely isn’t too useful to many, though will come in handy for those working with custom multi-network configurations. It will always return 1 on single site or if the current network has an ID of 1. It will return PRIMARY_NETWORK_ID if defined. And if those conditions aren’t met, it will go to the database to determine which ID is the first in line.

    It is possible to filter this value with the new get_main_network_id filter for those who have multiple networks and would like to avoid the incremental assumptions. See #30294 for the details.

    Visual and interface enhancements:

    • Better responsive styling for my-sites.php, a screen that would love to have a complete overhaul one day but now looks much better on smaller devices. #31685
    • Also in my-sites.php, the Save Changes button is conditionally displayed only if the user is a member of more than one site OR if a plugin or theme has filtered the HTML on this screen and may be expecting a Save Changes button to exist. #32645
    • Achieve parity between single and multisite by removing the Upgrades subsection in the menu and moving Updates to Dashboard. #32431
    • Provide a link to the dashboard when editing a site in the network admin. Previously, only the URL would show in the title area of the site screens with no great way to access the dashboard. Now, the full site name is shown as the title and smaller text URLs are displayed underneath for Visit and Dashboard. #32525
    • Mobile display of the network admin has been improved in general. A few inputs have been adjusted on mobile to make them act as expected. #32643, #32644, #32646. A full sweep of “content overruns” was done to ensure admin screens don’t overflow the screen on small mobile devices. #32846, #32962.

    Bugs of note fixed:

    • Don’t allow usernames over 60 characters long, a limit that was already in place via the database schema but was not enforced explicitly in code. #26784
    • Calculate the storage space used correctly for the main site. Previously, it was possible that the main site would reach it’s calculated space limit because the storage of all other sites was included in the total. #30202
    • get_blogs_of_user() now returns proper values for the archived, spam, and deleted properties. These were previously forced to 0 only when using this function. #32281
    • Deleting a super admin user via wpmu_delete_user() is no longer possible. This matches the expectation previously set by the UI. #32935

    And because some are smaller and were left out of the above, here’s a full list of multisite focused changes made in 4.3.

     
  • Robert Chapin 8:05 pm on July 23, 2015 Permalink |
    Tags: , ,   

    Changes to the Shortcode API 

    Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API. Due to the nature of the fix – as is often the case with security fixes – we were unable to alert plugin authors ahead of time, however we did make efforts to scan the plugin directory for plugins that may have been affected.

    With this change, every effort has been made to preserve all of the core features of the Shortcode API. That said, there are some new limitations that affect some rare uses of shortcodes.

    Reminder: Never, under any circumstances, should you hack core files. This includes downgrading specific files. Doing so could have unintended consequences on your WordPress installation, including major security implications.

    Basic Shortcode Usage

    A brief explanation on the original purpose of shortcodes will help to explain the change. In a basic post, like this example, shortcodes are used to insert dynamic code:

    Here are my images. [gallery]

    Here you can see that the shortcode stands on its own as a dynamic element within the blog post content. This is the central premise of the Shortcode API: make it easy to insert blocks of dynamic code.

    Shortcodes with Filtered Styles

    In today’s release of WordPress 4.2.3, however, we’ve added some new limitations that affect some existing plugins. Take, for example, the following shortcode, which is no longer recognized:

    <div style="background-image: url('[shortcode]');">

    The shortcode in the example above appears in a context that is no longer supported. Further, this use of a shortcode stretches the imagination for how the Shortcode API was intended to be used. Fortunately, there are some workarounds still available, so that site administrators are not overly restricted in their use of HTML.

    Workaround

    The following example still functions as expected and is considered more acceptable:

    <div [shortcode]>

    Going forward, plugins implementing shortcodes for inline styles should output the entire style attribute rather than a bare value. Keep in mind that this workaround – just as the original example above – is only available to administrators and editors (i.e. only roles with unfiltered_html). Less-privileged users are still prevented from using shortcodes to output whole attributes in this manner. If a plugin is intended to work with author and contributor roles, we recommend that the plugin output an entire <div>.

    Shortcodes with Bad Quotes

    The following example is also no longer allowed:

    <a href="/[shortcode query="?ref="]">

    In the above situation, the shortcode is now properly recognized as HTML and it is rejected by the API. Apart from the example being confusing, WordPress cannot parse that shortcode.

    Workaround

    Instead, either of the following examples would be appropriate:

    Example 1: <a href="/[shortcode query='?ref=']">
    Example 2: <a href='/[shortcode query="?ref="]'>

    Administrators as well as lesser-privileged authors can continue to use shortcodes in this way, as long is it conforms to the usual HTML filtering rules. However, as explained in the first example, administrators are now somewhat limited in this situation in one case: if the content in this href attribute is generated by a shortcode that does not conform to the HTML filters, then the shortcode is rejected for all users.

    We do not make this change lightly and understand that it may affect some usecases. The above examples and explanations should help plugin authors make the modifications needed to support the Shortcode API.

     
    • Mickey Kay 9:30 pm on July 23, 2015 Permalink | Log in to Reply

      And. . . half our client sites just broke :)

    • Dave Navarro, Jr. 9:55 pm on July 23, 2015 Permalink | Log in to Reply

      may affect “some” usecases…

      LOL! How about, you broke half the internet without so much as a “howdy do”.

      And if it worked before, why exactly can’t it work now? I am still not understanding why it had to change. WordPress itself was not intended for many of its uses today, are you going to start forcing people back into blogging? Designers/developers made better use of it than you intended and you don’t like that?

    • arippberger 9:56 pm on July 23, 2015 Permalink | Log in to Reply

      Can we get a list of the affected plugins?

    • Dave Navarro, Jr. 10:07 pm on July 23, 2015 Permalink | Log in to Reply

      Every single plugin that adds shortcodes that could be used inside of an HTML element. Not because it’s a security issue, but because someone doesn’t like how we play with our toys in their sandbox.

    • kitchin 10:12 pm on July 23, 2015 Permalink | Log in to Reply

      The shortcode API has never been well-defined, as far as I know. What html is allowed in a shortcode, and how shortcodes are allowed in html tags has changed over time. Scanning for the use case above would be difficult since it would involve the help files and sample tags shown to users, which may be formatted with sprintf, etc.

      The API should be defined. The test cases are the de-facto definition, but they are ad-hoc and clearly not complete. It’s very complex, with nesting issues and all the rest.

      I don’t know the security bug, but I wonder if malicious uses could have been filtered out more directly as a short-term fix, until the API was rewritten.

      • kitchin 10:20 pm on July 23, 2015 Permalink | Log in to Reply

        As a further example of complexity, many people are not aware that < and > are legal characters in html attributes, and some authors use them, for instance in sample code in the jQuery plugin Cycle2.

        The shortcode API was never intended to contain a complete html parser, and never claimed to. But it also did not strictly limit html or quoting, as it should have. Really it should have allowed either tags in html or html in tags but not both. Too late now.

    • Braad 10:19 pm on July 23, 2015 Permalink | Log in to Reply

      We’re experiencing some major frustration as a result of this change, and now plugins like Toolset’s Types and Views are basically non-functional. There are a lot of confused and unhappy people filling up their support forum right now: https://wp-types.com/forums/topic/types-shortcode-breaks-after-wordpress-4-2-3-autoupgrade/

      Even if this was a necessary change, it’s one that has far reaching implications, and it would have been nice to get a heads up that this was coming so we could have prepared. A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

      We’re already seeing people on support forums tell each other to just replace the shortcodes.php file with the version from 4.2.2, which as Mark Jaquith has pointed out is not a good idea, but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

      • chriscct7 10:49 pm on July 23, 2015 Permalink | Log in to Reply

        A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

        As stated above, this was not possible.

        but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

        The majority of WordPress users who are not developers will not know how to replace a file on a remote web server.

        • Braad 12:31 am on July 24, 2015 Permalink | Log in to Reply

          Saying something like “Here is a use case for Shortcodes that will no longer be supported” is different from saying “Here is a security vulnerability and how you exploit it”. I have a hard time believing that some form of notice couldn’t have been given, even if it was only given a day before the update.

          But that said, the core devs who deal with this stuff are in a tough position and deserve a big thanks for their hard work. Hopefully they can find a way to keep supporting the affected shortcode use cases while still keeping things secure.

    • Angelika Reisiger 10:20 pm on July 23, 2015 Permalink | Log in to Reply

      Sorry, please delete my previous two posts. I could not post the complete code snippet.

      So here again:

      I tried to follow your recommendation in the article. But whatever I try, it does not fix the issue ticket #33097
      Below is the code:

      http://pastebin.com/8xvN2eb1

    • mvandemar 10:41 pm on July 23, 2015 Permalink | Log in to Reply

      This change is listed as “Improve the reliablity of shortcodes inside HTML tags.” It says absolutely nothing about this being a security issue. Do you have a link to the actual security issue this change fixed?

    • James Huff 10:44 pm on July 23, 2015 Permalink | Log in to Reply

      Thanks for doing this, both the security fix and the write-up!

      I appreciate that the concern was on security over functionality. Existing functionality can always be fixed, and sometimes a better way of doing things is found, but recovering from a security vulnerability is a *nightmare*.

      Thanks again for keeping us safe!

      • Dave Navarro, Jr. 10:56 pm on July 23, 2015 Permalink | Log in to Reply

        Nothing in this write-up says that this is a security issue. Nothing in the release notes say this is a security issue. This is about how they don’t like how shortcodes are being used, so they put a stop to it. And I guess if they don’t like it, they can change it. But if it’s not a security issue, why change it in a security release without any notification so that it breaks hundreds of thousands of web sites? Why not announce “in 4.3 your shortcodes aren’t going to work anymore” and release it then? Well, because someone messed up and merged the update into core prematurely. So rather than fix the mistake, just roll with it…

        • James Huff 11:00 pm on July 23, 2015 Permalink | Log in to Reply

          Nothing in this write-up says that this is a security issue.

          It’s in the very first sentence, “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You’re welcome to form whatever theory you’d like to, I’m just reflecting the published facts.

          As far as I see it, the developers had to make a choice, security or functionality. They chose security over functionality, and I’m thankful they did. It’s the right choice.

        • mvandemar 11:01 pm on July 23, 2015 Permalink | Log in to Reply

          @Dave – the very first sentence in here says that it is a security issue:

          “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You are correct though that nothing in the release notes, or the bug track that I can see, indicates that this is the case.

    • Curtiss Grymala 11:07 pm on July 23, 2015 Permalink | Log in to Reply

      First of all, I want to say that I do truly appreciate the quick security fix, and I fully appreciate how much work is going into keeping this codebase up-to-date.

      Granted, the original example I originally posted in my trac ticket (<a href="/[shortcode query='?ref=']">) was a bit confusing, but I don’t necessarily agree with the idea that this can’t be fixed just because it’s “invalid inout”. A perfectly reasonable example could have been something more like <img src="[post-thumbnail size="thumbnail" id=55]" alt="I want an alt attribute"/> (maybe an example where you want the user to be able to dynamically reference the featured image of another post) or something like that. I don’t see that example being confusing at all, but the results, for most users, will be terribly confusing.

      As someone else already mentioned, this had a major effect on the functionality of the Toolset (Views) plugin, but it also has major implications on a number of other plugins, and, due to the fact that these changes only occur inside of HTML tags (so things may not be visibly broken), it may be a long time before people fully realize how much of their sites are broken.

      Normal users will not understand why things don’t work; they’ll just know that they don’t work (as we have seen from all of the reports blaming the authors of Types & Views for these new issues).

      As plugin authors, we are now responsible for telling users that, if they want to use double quotes in their HTML tags, they have to wrap their shortcode attributes in single quotes. However, if, for some reason, they want to use single quotes in their HTML tags, then they have to wrap their shortcode attributes in double quotes. As if that’s not confusing enough; if we try to help our users out by building an MCE plugin that auto-inserts our shortcodes, we either have to build it to be smart enough to recognize whether there are single quotes or double quotes around the selection, or we’ll have to tell our users to change the tag because it won’t work this way.

      I, better than most, understand just how difficult fixing this issue can be without rolling back the fixes/changes that were released today, but I am not excited about the prospect of breaking so many existing implementations just because it’s tough to come up with a fix. I hope that some minds greater than mine will continue to look into possible solutions for this issue (not necessarily the background-image example, but at least the quotes-within-quotes issue), rather than just writing it off as a won’t-fix.

      • Ipstenu (Mika Epstein) 11:19 pm on July 23, 2015 Permalink | Log in to Reply

        For those playing at home, the trac ticket is https://core.trac.wordpress.org/ticket/33102

        • Curtiss Grymala 11:44 pm on July 23, 2015 Permalink | Log in to Reply

          Thanks, Mika. I probably should have included that link in my reply.

          Also, again, I want to make it clear that I’m not complaining about the security fix (I hope I’m not coming across that way). I agree 100% with @macmanx above, in that I’d much rather have to go through and fix code issues for clients (even if I have to do so for free) than have to deal with security intrusions.

      • Dave Navarro, Jr. 12:11 am on July 24, 2015 Permalink | Log in to Reply

        Custom Content Shortcode, Advanced Custom Fields, and hundreds of other plugins. This isn’t “just a few plugins” or “just a few sites”.

        And if it’s a legit security issue (I still don’t see it that way), then fine.. but handle it better. “We just couldn’t do it is a BS excuse.” And even if you couldn’t, you still should have posted a HUGE MONSTER post about the issue immediately so that there weren’t lost hours of trying to figure out the problem.

        Again, this was VERY VERY poorly handled and all I’m seeing are excuses.

    • mvandemar 11:19 pm on July 23, 2015 Permalink | Log in to Reply

      Actually, I see it now. The fixer of the XSS vulnerability is the same one who owns the bug ticket, namely miqrogroove. Someone just let me know that was where the actual issue was.

    • Mickey Kay 12:20 am on July 24, 2015 Permalink | Log in to Reply

      Third times a charm. . .

      Just to provide another example, in case it’s helpful, of the issue as experienced when using the Types & Views plugins (which seem to be a pretty huge use case based on feedback re: this issue).

      One example of how we might commonly use shortcodes within a Views template to output custom fields:

      <a href="[wpv-post-url]" title="[wpv-post-titlle]" rel="nofollow">[wpv-post-titlle]</a>

      If I had to guess, I would venture that we have upwards of 100+ sites we’ve built that use some form of the above example – all of which are now in theory broken.

      Just for clarification, can you illuminate how this is any more of a security risk than using PHP to spit out the custom field directly? Is it an issue of validation/sanitization? If that’s the case, then why is the decision being made to force a certain format, when validation and sanitization are the developer’s burden in all other cases (custom fields, theme options, customizer controls, etc)? Am I missing something?

      Thanks, and appreciate the open ears to all the feedback (however rough it might be getting at times :)

    • Mickey Kay 12:23 am on July 24, 2015 Permalink | Log in to Reply

      Goodness, this is ridiculous – tried 3 methods to include my code. How the heck do you include code in here? Not normal markdown?

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        It’s not markdown at all. Use code tags.

        <code>

      • Curtiss Grymala 12:49 am on July 24, 2015 Permalink | Log in to Reply

        You have to encode the angle brackets yourself (type the ampersand symbol, followed by either “lt;” or “gt;” – so, &lt; gets turned into <)

      • Samuel Wood (Otto) 8:52 pm on July 24, 2015 Permalink | Log in to Reply

        Perhaps unsurprisingly, we use shortcodes for that. The word “code” in square brackets will do the job for you on the make blogs.. Use “/code” to close the block.

        Example of code
        

        You can also use “php” for PHP code and “css” for CSS. Then it will have syntax highlighting as well.

        <div> html works too, it will encode the brackets for you </div>
        

        I fixed your most recent comment to have the correct syntax.

    • Dave Navarro, Jr. 12:23 am on July 24, 2015 Permalink | Log in to Reply

      So Gary Pendergast and others have convinced me that there really was a security issue, so my apologies for claiming it wasn’t. However, it still comes down to someone not taking the time to fix the security issue WITHOUT breaking so many live `web sites`.

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        Sadly that’s not always a tenable option.

        Once a security issue is known, it’s a mad race against time to get it patched before news gets out and people get hacked.

        • Dave Navarro, Jr. 12:56 am on July 24, 2015 Permalink | Log in to Reply

          Okay, well, I still think they could have make THIS post at the time the update was released and saved a lot of wasted time trying to figure out why sites didn’t work anymore…

          I’m gonna go see if I can find a snickers and if it will make me less cranky. I’ve bitched about this enough that someone on Facebook challenged me to do a better patch… Sadly regular expressions are a major weakness in my dev skills, but I’m gonna try anyway. There’s got to be a way to fix the security problem AND keep the prior functionality.

        • Timothy Jacobs 8:54 am on July 24, 2015 Permalink | Log in to Reply

          That is true in many cases, but not this one. The bug was disclosed in November of last year. Both were responsibly disclosed. And if you look at the trojan emoji security release, the core team has the ability to work on a patch for a long time. There simply wasn’t enough testing done before releasing this patch.

          • chriscct7 9:03 am on July 24, 2015 Permalink | Log in to Reply

            There was a heck of alot of testing done. However regardless of the amount of testing the way less than 1% of 1% of 1% of people use shortcodes makes it impossible not to break sites. For example: nested shortcodes inside of a single html attribute with mixed quotes.

            • Timothy Jacobs 9:23 am on July 24, 2015 Permalink

              I know not all bugs can be caught, but Views & Types seems to have quite a large user base… It just seems that the amount of testing done for this is much less than the trojan emoji bug.

    • mountainguy2 3:25 am on July 24, 2015 Permalink | Log in to Reply

      Downdate 4.2.3 broke my main site, took me 6 hours this morning to fix as I’m a total amature. These automatic updates are the height of lameness. It needs a one-click revert function, as well as a one-click revert that can be done somehow if admin access is broken, as happened to me.

      What is more, near as I could tell from reading, I was at risk for none of the vulnerabilities, I thus had my site broken for no good reason. Again the height of lame.

      MTN

    • codepage 4:42 am on July 24, 2015 Permalink | Log in to Reply

      this fix has broken easy 2 douzen websites of mine plus more of partners of mine. many plugins are broken. i’m working a lot with shortcodes and attributes in my designs. i have no idea on how to hack stuff where only the path is saved and i have for example an id as attribute. please fix this!

      • codepage 4:45 am on July 24, 2015 Permalink | Log in to Reply

        i use plugin OptionTree to make designs configurable. eg:
        <img src="[getoption">

        broke. how am i supposed to fix this? having the customer fill in the html code in a text field? that sucks.

    • lkraav 5:05 am on July 24, 2015 Permalink | Log in to Reply

      Following

    • Shailesh 5:51 am on July 24, 2015 Permalink | Log in to Reply

      Is this change also affect this case?

      <a href="[homeurl]/contact" rel="nofollow">Contact Us</a>

      In most themes I am using [homeurl] and [themeurl] to make dynamic url in links. So I don’t need to worry when I move site from local to live or sub directory to main.

    • Sam Rohn 6:04 am on July 24, 2015 Permalink | Log in to Reply

      here is an easy fix, this resolved WP 4.2.3 breaking some s2member shortcodes on one of my sites

      use single quotes ' for html attributes surrounding the shortcode, and double quotes " for the shortcode’s own attributes

      like this

      a href='[shortcode value="foo"]'

      NOT like this

      a href="[shortcode value="foo"]"

    • twinsmagic 6:39 am on July 24, 2015 Permalink | Log in to Reply

      I’m trying to get this to work:

      I also tried

      @Sam Rohn, your suggestion didn’t work for me unfortunately.

    • AmirHelzer 9:00 am on July 24, 2015 Permalink | Log in to Reply

      We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.

      This is a straight forward change, which takes us one day to complete.

      Would have been great to receive a heads-up about an upcoming change in WordPress, so we could do this change on time.

      We received a huge amount of support requests due to this, but this isn’t the issue. We can deal with a wave a support issues. This time it wasn’t “our fault”, but sometimes it is.

      What worries us, as mentioned above, is seeing our clients (folks who build WordPress sites for a living), losing their faith in the system. They feel like the system sees them as little ants and not as humans. People don’t like seeing their problems being dismissed.

      Many of them run hundreds of sites. They cannot afford to stop everything and fix content on so many sites. Especially not if they are currently away for their family vacation.

      What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.

      We are your partners.

      Without WordPress (secure, stable and reliable), we would not exist.

      Without great themes and plugins, WordPress would not power 24% of the Web.

      WordPress core members already volunteer a lot of their time. I’m not asking for anyone to volunteer more time. Need help? Ask us. There is a huge community of developers who rely on WordPress. We would be happy to get involved and set up whatever is needed.

      Does this make any sense?

      • gfazioli 9:14 am on July 24, 2015 Permalink | Log in to Reply

        I agree!!

      • Mario Peshev 10:46 am on July 24, 2015 Permalink | Log in to Reply

        +1 – it’s not a one-time thing, it’s a process problem. And we had a late night urgent maintenance iteration due to a bunch of broken things for the same reason.

        It’s demoralizing for us and some of our clients don’t trust WordPress to be a stable and reliable platform that will run their business and let them sleep at night, without being afraid that things will break with zero changes on their end.

      • Rasheed Bydousi 2:10 pm on July 24, 2015 Permalink | Log in to Reply

        +1 You’re right. It shouldn’t be conducted in such a way. It is so annoying. Such changes shouldn’t be made arbitrarily. This isn’t a typical behavior pattern when it reaches to WordPress.

      • schutzsmith 2:50 pm on July 24, 2015 Permalink | Log in to Reply

        +1 Absolutely sums up how I’m feeling as well Amir! For instance, our digital agency runs on WordPress, we’ve built over 100 websites for clients on it, but as I tweeted this morning, this was the final nail in the coffin, we have to move away from WP because it’s literally killing our relationships with our own clients.

        I’m truly saddened by it because we’ve loved the community up until the last few months. It’s now at a point where we can no longer keep relying on WordPress to run a smooth and fruitful business.

      • Eliot Akira 3:03 pm on July 24, 2015 Permalink | Log in to Reply

        +1 – Thank you for articulating a sensible and constructive suggestion from the developers’ perspective. As someone who is one of the “folks who build WordPress sites for a living”, this issue has affected me greatly – spent most of the night trying to fix clients’ sites as well as doing the best to help plugin users. But more than the unexpected time and effort for support, as Amir states, the biggest worry for me is the loss of trust and reputation, both for myself as a developer but also for the clients regarding the reliability of the WordPress system.

        Last night, in a desperate attempt to find even a temporary solution, I made a plugin update which provided an option to patch one of the core files so that sites will be functional again. In hindsight, it was a poor judgement and bad mistake – but how the issue was handled was very disappointing. Apparently it was against the rules, and the plugin has been blocked from the official repository – without any warning or message to me. If someone had contacted me, I would have gladly removed the offending code. After all, I was only trying to help the situation. But now, I have no way to provide a reasonable update, and the users cannot access the support forum to get any information about why their sites are broken or what to do about it. Since there doesn’t seem to be any motivation to address the issue from the core side, we are all left hanging.

        “We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.”

        This seems to be the direction I need to take as a workaround solution, to resolve/render plugin shortcodes before passing to WP to process content. Just to note, in the original announcement are listed two cases (Shortcodes with Filtered Styles and Shortcodes with Bad Quotes) – but neither apply to the issue that I’m seeing across numerous sites.

        “What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.”

        I agree with this. At the same time, I can also see why the update was rolled out so quickly without prior notice, due to its sensitive nature. Perhaps the reasoning for not informing plugin developers is that some of them might try to exploit it. Another reason could be that there was no clear way to determine which plugins would be affected – and informing thousands of developers about a security vulnerability would have defeated the purpose of the update.

        I’m glad to see someone suggesting a positive way to look at the whole situation – what can we as developers and users learn from this on-going situation, and how can we contribute to improve the reliability and stability of WordPress sites.

        P.S. If someone of authority can contact me regarding the blocked plugin, I would really appreciate knowing how to remedy it. Almost immediately after the problematic update,I have pushed another update which removed the change. Both myself and the plugin users are waiting for any information that could help us.

      • safesoundaudio 4:03 pm on July 24, 2015 Permalink | Log in to Reply

        Well said Amir! You speak for many hundreds of us in this wonderful WordPress community.

      • dmccan 4:32 pm on July 25, 2015 Permalink | Log in to Reply

        I appreciate that the core team addresses these security issues. At this point, the WordPress ecosystem is so large that it is difficult to ascertain the impact of core changes, so I agree with Amir that we need a better process.

    • Herre 9:14 am on July 24, 2015 Permalink | Log in to Reply

      I fully understand this is an issue… but isn’t this a weird way of updating… almost al our clients are calling / e-mailing us at the moment as their sites seem to be broken…

      Normally it would be better to announce such huge impact changed to the plugin and theme developers…

      This means I need to fully reschedule my agenda… which already is full during holiday season…

    • JesseHeap 1:26 pm on July 24, 2015 Permalink | Log in to Reply

      Wondering if someone could provide some advice for us as I’m having a little trouble understanding what needs to change with shortcodes to fix our particular issue.

      The simpliest example I can give is below:

      Use Case: We use a short code to pass the HTTP_REFERER as a hidden value in our form:

      SHORTCODE in PAGE:

      Code in Theme Functions:
      //pcbReferrer
      function pcbReferrer_func() {
      return(getenv('HTTP_REFERER'));
      }
      add_shortcode( 'pcbReferrer', 'pcbReferrer_func' );

      Based on my understanding of the above, I’m not clear what I would change since we aren’t using attributes for this short code. I have other short codes that do use attributes which I’m trying to fix as well, but that’s a different story.

      • JesseHeap 4:09 pm on July 24, 2015 Permalink | Log in to Reply

        Here’s the solve in case this helps anyone:

        –ORIGINAL SHORTCODE THAT WAS NOT WORKING–

        Page Shortcode Reference:

        Themes Function Code:
        //pcbReferrer
        function pcbReferrer_func() {
        return(getenv(‘HTTP_REFERER’));
        }
        add_shortcode( ‘pcbReferrer’, ‘pcbReferrer_func’ );

        –NEW SHORTCODE THAT IS NOW WORKING–

        To solve this I moved the HTML into Themes Function PHP file. So I changed my form page shortcode to just:


        [pcbReferrer]

        And modified the function to include the HTML that was originally in the page:

        //pcbReferrer
        function pcbreferrer_func() {
        $output = '';
        return ($output);
        }

        Less then ideal as it intermingles more of the HTML with the shortcode and I always try to maintain as much separation as possible.

        But I certainly do not understand the security concerns of the prior approach so I’ll just assume this is the new constraint that we’ll need to follow for the sake of security…

        • JesseHeap 5:57 pm on July 24, 2015 Permalink | Log in to Reply

          Sorry I thought the <code> tags would leave the HTML alone but they are still stripping it away… This commenting system is a little frustrating…

    • safesoundaudio 4:02 pm on July 24, 2015 Permalink | Log in to Reply

      The change to allowed shortcode usage has NOT just affected a few RARE cases of shortcode uses. It has affected the functionality of hundreds (maybe even thousands) of websites including my own commercial site. Aside from the disaster it has caused to hundreds of web designers who use the excellent Toolset plugins, it has destroyed the functionality of a large number of other plug-ins. The forum is just full of examples today.

      As far as I can tell there was no advance notice. SOMEONE should have stopped and thought, ‘best we tell the community what we are planning’ The folks at Toolset seem to have been given no notice and they are probably the biggest plugin designers of the now disallowed shortcode usage.

      We can debate for ever what should be allowed and not allowed with shortcodes but that misses the point. Most of us are in the communication industry and this update has been very sadly lacking in foresight and communication.

      PLEASE role back this disaster of an update. I am 100% sure it was well intended but PLEASE look at the reality of what has happened.

    • crazycanuck27 6:00 pm on July 24, 2015 Permalink | Log in to Reply

      So I’m trying to pass a User Shortcode [currentuser_iserid] as a variable in an iframe and what worked for v4.2.2 suddenly broke and working to recover.


      … used to work but now it passes the shortcode as text. The shortcode works on its own. So is this an issue with the iframe and trying to pass a shortcode .. or quotes, or something else?

    • Claudio Esperanca 11:03 pm on July 25, 2015 Permalink | Log in to Reply

      is removed by TinyMCE when switching between HTML and WYSIWYG views as it is considered an invalid attribute for the tag, so it isn’t a perfect workaround.
    • minderdl 8:55 pm on July 26, 2015 Permalink | Log in to Reply

      While I can agree that wrong quotations do not need to work (i.e. one should only use single quotes inside double quotes and vice versa) the change also killed wrapping shortcodes:

      [blockcode]
      <a href="[myurl]">[mytitle]</a>
      [/blockcode]

      The href attribute will be empty, only mytitle will be replaced.

      Is this also considered “wrong” use of shortcodes??? Wrapping shortcodes are used for conditions, loops, etc. by several plugins. And this could not be changed in the same easy way like just changing quotation :-(

      With version 4.2.3 the part inside a wrapping shortcode is first processed by do_shortcodes_in_html_tags(). There all the replacement of the inner shortcode is done. Only afterwards, the result is passed to the wrapping shortcode callback. This has several problems: For wrapping shortcodes implementing a condition substitions will take place that might be completely unnecessary (ok, only a performance problem). But for wrapping shortcodes implementing a loop, the content will always be the same – i.e. the whole thing is completely broken.

      Did anyone thought about this?

  • Ella Iseulde Van Dorpe 1:17 pm on July 23, 2015 Permalink |
    Tags: ,   

    Word/character count updates in 4.3 

    Here are several adjustments we did:

    • Instead of updating on enter/return, it will now refresh when you stop typing.
    • For word count, it will exclude a lot more characters that shouldn’t be counted as words.
    • For character count, we no longer exclude any of these characters. This means that numbers and common western punctuation are no longer excluded compared to 4.2. Emoji and other astral characters are now counted as one character instead of two.
    • We added a new type all, in addition to words and characters, that will count characters including spaces. This seemed necessary for Japanese and maybe other languages.
    • Shortcodes and HTML comments are now excluded.

    See ticket #30966 for more information.

    Please test the latest beta which includes these changes.

     
  • Ryan McCue 12:06 am on July 23, 2015 Permalink |
    Tags:   

    REST API: Who’s Using This Thing? 

    Hi everyone!

    This is a break from your regularly scheduled release posts. We’re looking to gather some feedback on the lead up to merging into core, to assess what your thoughts are on the API. Whether you’ve used the API or not, we’d love to hear your thoughts.

    Here’s a bunch of questions to start you off:

    • What are you doing with the API?
    • What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)
    • What improvements would you like to see? (What sucks?)
    • Is the API important to you?
    • Anything else you’d like to tell us?

    We really want to make sure this API fits your needs. Without your support, the API really means nothing, so we want to make sure we get this basically perfect first. We’d love to hear feedback from everyone using this, from JS-only developers coming to WP for the first time, through WordPress plugin and theme developers, all the way through to PHP developers not involved with WordPress.

    If your comment is too long to fit here, or you’d like to wax lyrical about the API, feel free to comment on your own blog and cross-post a link across to here.

    If you can’t comment publicly due to disclosure, you can leave a message for me personally at me at ryanmccue.info. Please specify if you will allow me to share your private feedback with the WP REST API project and core team, or if you’d prefer to keep it completely private between the two of us.

    Help us make this the best feature to ever land in WordPress. :)

     
    • nicholosophy 12:17 am on July 23, 2015 Permalink | Log in to Reply

      I’m not currently using the API. I do think the API is important to the future of WordPress.

      There are many systems that I interact with at $dayjob that have an API, and it allows me to create custom solutions to control these systems in ways that the developers wouldn’t have imagined, or did and didn’t want to support. I can use an API to work with our SaaS professional services automation (PSA) software to make changes not possible via the provided UI and that would require db access otherwise. I can use it to extract data out to create scheduled notifications or reports and trigger actions where there isn’t native functionality for that.

      We have a WordPress intranet and to be fair I wouldn’t NEED the API for that as I can access the installation and its database. However an API could be used to schedule a data grab to produce a report showing who accessed stuff for the day, or who updated what. This can be done in other ways with plugins, but if the site is locked off or hosted as SaaS then that isn’t always possible.

      It also allows WordPress to become the core of SaaS solutions with purposes way outside those envisioned for a standard WordPress install. The ability to add onto the API means that a full SaaS with API could be built based on the core WP-API codebase.

      WordPress would survive without an API in core. With an API in core, WordPress will only grow and flourish more, and that can’t be a negative.

    • sethshoultes 12:20 am on July 23, 2015 Permalink | Log in to Reply

      Event Espresso 4 REST API Add-on is built on top of the API:
      http://eventespresso.com/2015/07/event-espresso-4-rest-api-add-on-available/

      • Mike Nelson 4:25 am on July 23, 2015 Permalink | Log in to Reply

        More details on that, specifically addressing Ryan’s questions:

        What are you doing with the API?

        We’ve extended it for our event registration plugin, so that events (custom post types), venues (custom post types), datetimes-of-events, tickets-for-events, registrations, payments, etc are accessible via the API (some public data, some for logged-in users only).

        API Client application things that we and our community want to build: an event calendar that uses event data from the API; javascript code snippets that can show upcoming events on other, non-wp sites (example code snippets); mobile apps for event admins to check registrants at the door, etc.

        What would you like to do with it?
        We’ve had requests for PUSHING API data to remote servers whenever specific events happen in our system (eg, when a post or event is published, send its json data to a specified URL). I think this could be a nice future feature, but not essential right now.

        What improvements would you like to see?
        Some system for accessing wp options seems important no? If not complete access, at least a simplified way for the api to be extended to grant access to wp options designed by the developer. For example it would be nice if could just do

        apply_filter( 'wp_rest_api_exposed_options', 'my_callback_for_options_i_want_exposed');
        function my_callback_for_options_i_want_exposed( $option_names) {
        return array_merge( $option_names, array( 'my_plugins_option_1', 'my_plugins_option_2');
        }

        Or something simple like that. I understand right now wp options CAN be exposed (we’re exposing one or two for READ-only right now) by registering custom endpoints etc; but some simplified method would be friendly.

        Is the API important to you?
        Fairly. We’ve put in enough effort to make our plugins’ data READABLE, but aren’t moving ahead with making our data WRITEABLE until we see some more demand for it in our community

        Anything else you’d like to tell us
        Extending the API was easy thanks to documentation and uncomplicated code, thanks!
        We’d love some feedback on our extension of the WP API if you’re ever in the mood.

    • @modemlooper 12:26 am on July 23, 2015 Permalink | Log in to Reply

      http://reactorapps.io

      We use the api to create apps that digest the api themselves. So meta!

    • Ryan McCue 12:27 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      We’re (Human Made) building a bunch of client sites using the API. These are built because either users want the WP admin, but want something more flexible for the frontend; or because we want to add superpowers to the frontend we’re building out.

      I’m personally working on two projects using the API. The first of these is a client project. The client wants to use a Node-powered frontend, but have the familiar WordPress admin and flexibility available to them. They also need a fair amount of custom work for the stuff specific to their site, which is provided through custom fields and endpoints in the API.

      The second project is a theme powered entirely via the API. Internally, it uses the API along with some crazy backend rendering, which allows sharing templates between the frontend and backend. This theme is intended as a communication tool, so it’s very complex and interactable compared to a normal theme. It uses the core endpoints mainly, but also adds extra fields to the data returned for presentational data like CSS classes.

      What would you like to do with it?

      Basically everything I need to do is already covered. Some of the presentational data that’s required needs to be added manually, but this also doesn’t make sense to expose to all clients, so it makes sense that it’s not exposed through the API automatically. (I’m also biased, in that if I need something, I can commit it to the plugin :) )

      What improvements would you like to see?

      One of the things I’d like to see is WP permalink-to-route mapping, to allow taking an arbitrary link and working out the data for that link. This should be possible, and I’m exploring ways of doing that. It’s not something the API needs drastically, but would be a nice feature in the future.

      Is the API important to you?

      The API is the single part of WordPress I care most about, but again, I’m biased. :)

      Anything else you’d like to tell us?

      My fellow development is so dang awesome. Truly, you are all the best. Thanks to all of our contributors, with special thanks to Joe Hoyle and Daniel Bachhuber for your work on the latest releases.

      Extra-special mention to my partner-in-crime, Rachel Baker. Without you, I’d have thrown in the towel a long time ago. Thank you, thank you, thank you.

      • Matthew Haines-Young 9:33 am on July 23, 2015 Permalink | Log in to Reply

        I’m working with Ryan on a client project, and the API has really allowed us to separate out our responsibilities. We can more easily work along side each other and front end devs don’t have to touch WordPress theme files so they can just focus on building a great site.

      • Ken Newman 7:24 pm on July 23, 2015 Permalink | Log in to Reply

        Those projects sound awesome, let us know if any open-source code or tutorials come out of those projects!

    • David Bisset 12:36 am on July 23, 2015 Permalink | Log in to Reply

      The REST API would make some fundamental positive improvements to the WordPress project if you look at it long-term. The API represents a greater amount of possibilities for both users and developers – especially in the age of mobile. By promising to include it in core, you’ll be giving a big mental “green light” to many more developers to jump on the train.

      So much hard work, planning, and testing has been done (with more to be done in the future of course). Let’s allow this to transform over 24% of the web.

    • Nick Haskins 12:36 am on July 23, 2015 Permalink | Log in to Reply

      Short and sweet.

      I’m using the REST API it in a premium plugin called Lasso (name soon to change) https://lasso.is , which allows the user to view all posts from the front-end of the site, as well as in a free plugin called WP Live Search (https://wordpress.org/plugins/wp-search-live/) which uses the REST API to perform site searches.

      I’m apprehensive about diving full force into it for fear that it may not actually be included in WordPress core. Until the REST API is fully merged, I won’t be spending any more time with it.

    • Pete Nelson 12:42 am on July 23, 2015 Permalink | Log in to Reply

      I’ve been working on a logging plugin for the REST API (https://wordpress.org/plugins/wp-rest-api-log/), have some rewrites I’m working on before I feel like it’s done, but want to say thank you for making it so extensible.

    • Aleksandar Perisic 12:57 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      • some android native app that pull down json and images from WP,
      • angularJS as frontend (still messing around but i like it for online apps)

      What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)

      • Remove some parts from json output

      What improvements would you like to see? (What sucks?)

      • Documentation look like half way done… maybe its just me..
      • Need alot of examples
      • More functions (easier output cleaning)
      • Maybe more control in backend ?

      Is the API important to you?

      • Yeah

      Anything else you’d like to tell us?

      • API API makes WP people HAPPY! and give us, one day, best offline/online auto sync and you guys can go to heaven
    • Josh Pollock 1:41 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      I write about it quite a bit for Torque Magazine. I’ve also written an add-on for SearchWP (https://github.com/CalderaWP/searchwp-api-route) and an add-on for WordPress SEO by Yoast (https://github.com/CalderaWP/seo-rest-api-fields). I’ve posted a bunch of other stuff on my Github as well, can’t keep track of it all.

      On my company CalderaWP’s site (https://calderawp.com/), we run custom endpoints (combining data from various post types and EDD functions) that we use to power the “featured plugins” feeds in our plugins’ admins. In the plugins themselves we have the template for rendering the response. (source: https://github.com/CalderaWP/calderawp-api/tree/wordpress)

      I’ve consulted with several non-WordPress developers who are building apps that use WordPress as their backend and needed advice or a little customization.

      I’m also a contributor to Lasso and helped with the one part that does use the REST API: https://github.com/AesopInteractive/lasso/blob/master/public/assets/js/source/all-posts.js The rest (pun?) uses a custom API for AJAX handling, that works and is efficient but is not “the WordPress” way.

      What would you like to do with it?

      It’s a pretty awesome and complete — for the front-end. I think that options handling, while a huge ball of worms would be great.

      Most of all, I’d like to tell potential users and potential users this was The WordPress REST API, without adding a bunch of confusing clarifications.

      Anything else you’d like to tell us?
      Can we all take a minute to thank Ryan, Rachel, Joe and Daniel, for putting so much work into making something that is so awesome? Also, thank you to their employers for enabling them.

      Seriously folks, read the v2 source code, this is good stuff that we could be proud to have in core.

    • darrinb 3:45 am on July 23, 2015 Permalink | Log in to Reply

      I LOVE the API. I’ve used it on 2 client projects so far and both have been great successes. With the more recent project, my client–a large industrial real estate firm–manages their properties via an internal proprietary .NET app. Their public-facing site is powered by WP. We’re utilizing the API to sync property data (in real time) between their internal app and their site so their real estate listings will always be current.

    • saisasank 6:53 am on July 23, 2015 Permalink | Log in to Reply

      I am already using the API for building mobile apps. The other use cases that I intend to utilize are enabling users to connect their WP sites to my web app. So I have read/write access to their website. Forexample, if they want to do a SEO analysis of their website, I would want a list of their posts with the word count etc. Instead of installing a plugin they can just connect their website to my app using the API.

    • kdpuvvadi 7:46 am on July 23, 2015 Permalink | Log in to Reply

      I have used it while making a mobile app for client local news websites, it full filled my needs but why REST API as a some other optional feature in a plugin like jetpack not in the core. May be responsive designs and all may work for mobile and future is mobile, responsive designs are neither new nor better suit for all needs, for me designing entire mobile Is suitable but it is pain the ass to start over I’ve been using rest APIs from jetpack for mobile sites and I do not think it’ll full fill all needs. And I tried using WP REST APIs project and setting up those is really messy and I’ve never used after that. I’m not making a point here but may be a little.

    • NateWr 8:03 am on July 23, 2015 Permalink | Log in to Reply

      *What are you doing with the API?*
      1. I built a small SaaS app for child care providers in the UK. The app runs alongside a WordPress install that also runs my client’s eCommerce site for digital and physical products. By leveraging robust existing platforms (WordPress, Easy Digital Downloads, MemberPress) as well as the REST API and its associated tools (client lib for Backbone.js), I was able to build a quality, mobile-first at a fraction of the cost. Otherwise, a project like this simply wouldn’t have been within her budget.

      2. The Public Knowledge Project builds open source software that helps tens of thousands of academic societies, many from developing countries, publish their research on an Open Access model. Their software is a standalone product, but their website runs on WordPress.

      As part of the next generation of the software, I’ve built a plugin repository system for their WordPress site. People submit plugins for the software and we approve/reject them. Then thousands of sites around the world, which are not running WordPress, will ping our site via the REST API to find and install plugins for their site. It’s a mini wordpress.org/plugins/ setup.

      The new version is scheduled for release around the new year. And we highly value the REST API going into core, primarily for the peace of mind that comes from knowing it will get much wider exposure to security and stability tests.

      https://pkp.sfu.ca/

      If WP democratizes publishing, we’re democratizing academic publishing, fighting against a massive cash grab from major publishers, as they have begun to charge huge and unsustainable article processing fees for Open Access publishing (academic publishers have some of the highest profit margins of any industry).

      *What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)*
      Put it in core, so that as a plugin developer I can make use of it in my products. I built the most popular Restaurant Reservations plugin in the .org repo, and I am eager to add a robust capacity/table management component for it using the REST API and a jQuery/Underscore/Backbone stack.

      *What improvements would you like to see? (What sucks?)*
      (ahem) https://github.com/WP-API/WP-API/issues/660 :)

      *Is the API important to you?*
      Yes. As my skills improve with frontend technologies the relevance and utility of WordPress’s PHP-based templating system is waning. It’s still handy to have around, and it won’t be going away in the product space. But nearly every interesting personal project I dream up these days requires less and less of a WP frontend.

      *Anything else you’d like to tell us?*
      Thanks to everyone pushing this forward. I really don’t want to have to go learn Laravel. 😉

    • divydovy 8:14 am on July 23, 2015 Permalink | Log in to Reply

      Thanks Ryan.

      _What are you doing with the API?_

      Our biggest project with it is this: https://www.joininuk.org/widget/ – an embeddable JS widget.

      _What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)_

      So much we’d like to do, haven’t hit any limits except finding clients that have requirements to use it.

      _What improvements would you like to see? (What sucks?)_

      Nothing so far

      _Is the API important to you?_

      Yes, very.

      _Anything else you’d like to tell us?_

      You’re doing a fabulous job.

    • Benjamin Lupu 8:29 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      I have use it in some of my projects (media sites) but mainly experimenting with it.

      I am also part of the team developing WP-AppKit, a plugin to create mobile apps connected to WordPress. At the moment, we use our own JSON API. The only reason is because we wait for it to be part of the core..

      Anything else you’d like to tell us?
      The WP API is a cornerstone of the future of WordPress. WordPress has grown because of its user friendliness, ease of access, extendability… It is and it will remain a major asset. But at the same time, WordPress has struggled to step in the enterprise world. It struggles to connect with other major technical groups. Yes it happens more and more but too often it almost sneaks in enterprises and agencies. We want the non-WordPress world to interact with our favorite tool and the WP API is key to that. Yes it can be done with the API as a plugin but it would send a bad message out there. The API in core is the way to ensure a standard way that interact with WordPress. It is also a huge asset to make the best mobile and SaaS backend in the world! As we have democratized publishing, we will use the WP API to ease the pain of creating mobile apps (with the help of other wonderful open source technologies such as Cordova) and SaaS products. I can imagine numerous use cases for it. All WordPress developers around me are experimenting with the WP API. And beyond them, more and more non-WordPress developers are experimenting with the WP API. This is the first time I feel that we are maybe at the dawn of connecting with outside technical islands.

      So, please don’t let this happening, it would be a very sad day for WordPress: the WP API has to be in core.

      I’d like to thank the team behind it. It’s a huge achievement. I am also wondering what kind of message to the community it could be to finally close the core door after this amount of dedication (?).

    • Van Patten Media 11:31 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      For a client site, in production, we’re using the API (v1.x) to power infinite scroll. We’ve also extended it to support accessing specific sets of custom post type data to power a special section of the site that displays content using special editorial-organised collections of posts.

      I also extended v2.x for a personal project to essentially power an iOS app, with extensions for registration, creating/responding to ‘questions’ (via posts and comments), and a payment endpoint with Stripe. Built a custom JSON web token auth method as well.

      What improvements would you like to see? (What sucks?)

      It’s something that I’m sure will change once the API moves closer to core, but the documentation is kinda weak, particularly in the “here’s how to accomplish Thing X” tutorial scenario. Reading the code is obviously great, and helps a lot, but there is a lot of power buried in the plugin that isn’t really explained anywhere yet.

      Is the API important to you?

      Very! It saved a ton of dev time.

      Anything else you’d like to tell us?

      Keep it up!

    • Per Soderlind 1:16 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      We’re using WordPress and the REST API as an backend for an iOS application. The iOS app is an “what to do when shit happen” app for the Norwegian Ministry of Petroleum and Energy.

      What would you like to do with it?

      We’re working on several other projects that uses the REST API

      What improvements would you like to see?

      Nothing so far (access to options would be nice)

      Is the API important to you?

      Yes

    • ndh01 1:21 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      I’m currently building a few iOS apps that connect to my site https://focusedonfit.com The apps use the API to pull CPTs with tons of meta, BuddyPress info, and custom DB tables. I hope to have these launched by the end of the year and beta in the next few months. I had fantastic help getting my API customization developed by Daniel Bachhuber and Rachel Baker— they were a pleasure to work with! I also used the API to create my app Simply Smoothies https://itunes.apple.com/us/app/simply-smoothies-smoothie/id975605998?mt=8&uo=6&at=1001l3mn&ct=wp Although I’m not using the API in the compiled app, I used it to seed my initial database of 130+ ingredients with full nutritional information (pulled from https://focusedonfit.com) that make up the app. It saved me a ton of time :)

      What improvements would you like to see? (What sucks?)

      Like most projects that are in development, the documentation needs improvement. I would also like to see some docs written on how to migrate from 1.x to 2.x. I’m currently on v1.x.

      Is the API important to you?

      Very important as it has jumpstarted my backend development and laid the groundwork for future features and connectivity.

      Anything else you’d like to tell us?

      Thanks for all your hard work!

      • Paul Gibbs 1:42 pm on July 23, 2015 Permalink | Log in to Reply

        If you wrote any sufficiently generic BuddyPress WP-API stuff, I’d love to see it?

        • ndh01 2:17 am on July 24, 2015 Permalink | Log in to Reply

          Hey Paul, I don’t have anything generic. It has been written specifically for the site. Currently simple BP stuff like read/write user fields. The site currently uses friends/profiles/activity components, but I don’t plan on adding that to app in the first version.

    • Preetinder 1:46 pm on July 23, 2015 Permalink | Log in to Reply

      Hi Ryan,

      Thank you for asking these questions :)

      It will be great if this can be included in Core with some improvements and more/new features. Following are my comments on your queries.

      What are you doing with the API?

      We are using it for exposing data / posts to our Android App and it works great (with some changes in the plugin code). We are using Taxonomy, Custom post types, several custom fields and then exposing all this data for consuming into Android App.

      What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)

      We plan to use it on most WordPress applications (business directories, event sites, yellow pages type sites) we build. Also please see the response to next question.

      What improvements would you like to see? (What sucks?)

      We had to make some changes into plugin files for exposing custom fields. Also as WP query doesn’t allow query on custom meta key / values, we changed that bit as well to get it to work.

      I suggest that we give users some interface where they can select which custom post types / fields they would like to be available via API. Also options for on which custom fields they would like to query and then these can be included in the code.

      Is the API important to you?

      Yes, It is very important and holds great promise with some improvements suggested above.

      Anything else you’d like to tell us?

      We are very pleased with the outcome and are planning to build another website and App using same procedure.

      Our team is also working on a session on using REST API for next wordcamp happening in Pune.

      Thanks,
      Preetinder

    • jrvandijk 2:43 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      I’m running the API behind a mobile app implementation. The mobile app is built using Titanium which uses Backbone.js as its way of syncing. The connection the the WordPress API is a breeze!

      What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)
      In my situation, WordPress as just a storage, it’s feature complete. In regards to authorisation, support for oAuth2 would be welcome. A plugin with a dependency onto http://oauth2.thephpleague.com would be awesome.

      What improvements would you like to see? (What sucks?)
      The only improvement that can be made, is to make it part of the core! :)

      Is the API important to you?
      Yes it absolutely is. Working with API’s is more easy for me then working with WordPress in general. WordPress is a specific product, whereas API’s have become more & more standardised. Thank you for your hard work!

    • Jason Coleman 4:15 pm on July 23, 2015 Permalink | Log in to Reply

      > What are you doing with the API?

      Not much yet.

      > What would you like to do with it?

      I’m really waiting for the API to be “blessed” and incorporated into WP core. Once that is done, we plan to add custom methods to Paid Memberships Pro using the API. We already have a few for the XMLRPC API, but we will add even more to control as much as possible in the PMPro data via API.

      The reason we are waiting for this to be in core is because maintaining a plugin of this size against WP Core, all of the gateways, and all of the third party integrations is already a daunting task. When gateways and thirdparty tools update THEIR APIs, we need to update our code. If in the future, the standards on building/using APIs in WordPress were to change, then we would have to change to support that and would have wasted a lot of development time on the API version that wasn’t used. Worse yet, other developers building on top of PMPro will potentially have to update how they do things.

      I’m also co-author of the book Building Web Apps with WordPress. APIs are obviously a big part of application development and we plan to expand on what we cover in the upcoming revision 2. It would be really great to be able to say “this is the one standard for building and using APIs on top of WordPress” instead of something weaker.

      > Is the API important to you?

      Yes.

    • laur3ntv 4:33 pm on July 23, 2015 Permalink | Log in to Reply

      Hi Ryan,

      I definitely think the API should be included to core.

      What are you doing with the API?
      >> Nothing for now but we have plans :)

      What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)
      >> We plan to use the API in order to create SAAS like services relying on WordPress.

      What improvements would you like to see? (What sucks?)
      >> I am not the CTO so I could not say ^^

      Is the API important to you?
      >> We think it is the future of WordPress because it opens WordPress to SAAS, to mobile apps etc.

      Anything else you’d like to tell us?
      >> Thanks to all the developers who have worked on it. Keep it up!

    • Roy Sivan 5:00 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      I build web (single page) applications powered by AngularJS and other JS frameworks. One example site is CodeCavalry.com. I have a few WordPress plugins that utilize the API as it makes custom endpoints for functionality. I also use the API at my full-time job where we use it for a number of things.

      What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)
      It does everything I need – VERY easy to extend, VERY easy to learn and work with. Especially when using in a JS environment.

      Is the API important to you?
      VERY important. I’ve been using it since it was in GSoC. Could not have built

      Anything else you’d like to tell us?
      Keep up the good work!

    • dryanpress 6:35 pm on July 23, 2015 Permalink | Log in to Reply

      > What are you doing with the API?

      Nothing at present.

      > What would you like to do with it?

      Terrific other than access to Settings API for plugins.

      > Is the API important to you?

      Absolutely. Particularly important to the news industry which has notoriously slow sites and needs easier methods to selectively query content as users flow through a session. That’s presumably a contributing reason a number of major publishers (not all) use some form of REST API if they’re using WordPress (Mashable, Wired, Quartz, etc).

      > Anything else you’d like to tell us?

      The REST API…

      • Enables more dynamic, powerful and human interactions with our content and our data. Sites that use it have implemented exciting patterns that aren’t as simple or resource-light in PHP.
      • Opens WordPress to a wider community of developers working on both Core and Plugins.
      • Helps diversify WordPress for longevity.
      • Can only improve the kind of features written for WordPress client mobile apps.
      • Opens door for more mobile apps powered by WordPress.
      • Shines increased value on BuddyPress, maybe.
      • Increases speed, decreases channel interference (reloading requires reorienting), empowers developers and will excite lay users with an improved experiences they’ll have difficulty quantifying but they will “feel.”

      WP.com got a REST API in 2012, clearly it was needed and is still around. Strange conversation to have in 2015 frankly. Even if WP.com/Jetpack adoption was low(?), that would be no reason to reject similar functionality for Core which is naturally a different user base.

      Disappointing talented developers doing good work with the API are being spooked.

    • Jonathan Brinley 6:39 pm on July 23, 2015 Permalink | Log in to Reply

      At Modern Tribe, we’re starting to build some sites that use the REST API to power both Handlebars and full page React templates in our themes. For example, we’ll have a post type loop (let’s say a listing of Publications) to which we’ll add optional filters for taxonomy terms, P2P relationships, etc. Screenshot: https://cloudup.com/coGx9enyOhp The initial page render includes the search and filter fields. The posts come from ajax requests to the REST API, and update when filter selections change.

      Some particular challenges we’ve faced:

      1. Querying on multiple terms from multiple taxonomies. We worked around this by setting up our own query var and building the supporting queries.

      2. Related post data. P2P relationships are integral to many of our content types, and we need to display information about the related posts as part of the main post type loop. Rather than making separate requests, we include the related post objects as properties of the main post objects in the response.

      3. Access control. Some posts (and even some specific meta fields) have access restrictions (e.g., you have to be logged into view it, or have a certain role, etc.). We have to make sure that these restrictions carry over to the JSON response, as well, giving one response to the public and another to authenticated users.

      4. Caching. Building up the JSON responses with related post data, access control for certain fields, etc., can be slow and requires a lot of queries. We were able to speed this up substantially by caching the post objects (complete with all of their meta and related post data) in a new database table (with separate caches maintained for each access role). This leads to the question of cache invalidation, which we solved with another table of invalidation triggers. When a post in this latter table is updated, it triggers an invalidation of the cache in the former table to ensure that all of our related post data remains fresh.

      Additional challenges we’re still working out:

      1. Multisite usage. We’re just now starting to experiment with the API with multisite installations. Seems to have some quirks that we’re working to identify and mitigate. Would also be interested in experimenting with the API to perform queries that span multiple sites.

      2. Theme Customizer and Admin UI. The WP Core team is thinking of powering the whole Admin UI with the WP REST API or some variation of it. That would open the door to making the Admin UI and the Theme Customizer “modern” web-application like environments. The UX gap between the Theme Customizer as it is and the Admin side is already apparent: that will likely widen in the future. Think of a React (or whatever is “a la mode” at the moment) powered panel builder or Admin UI.

      3. The Events Calendar. As we build solutions for client sites, we’re also thinking about how we can start adding support for the REST API into our open source plugins. We’re in the early stages of determining how that integration might work, both for reading and authoring events.

      4. Tailoring the API Response. It would be nice to have a method to remove unused data from the response, if possible.

    • Ken Newman 7:23 pm on July 23, 2015 Permalink | Log in to Reply

      Hi, I’ve used the API to build a very simple Angular App that was basically a portfolio of galleries. It was extremely simple to do (as it was read only).

      My coworker is building a Meteor.js subsite to a WordPress powered main site, and authentication could certainly be easier (no command-line support on our server configuration for example) and tutorials are sparse (tho I do understand that this is because of the newness of the project).

      What I’d like to do is exactly what Ryan McCue is doing in his two project examples. 😉

      In my second job, our workflow is incredibly dependent on this API going forward, as just about everything we’ve been planning to do takes advantage of the API…

      Also want to say, Great Job Rachel, Ryan, Daniel, and Joe and everyone else! You are awesome beyond belief!

    • Ashworth Creative 7:27 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      Powering interactive calendars and timelines; allowing downloadable software to consume and update highly customized data that is stored in and managed by WordPress as purely a CMS; transmitting data across domains so that dedicated mobile sites could pull content from main sites, preventing redundancy.

      What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)
      The biggest issue right now is that the REST API isn’t included in core. If we build plugins or a theme that needs to consume data asynchronously, we’d either have to bundle the api and have to maintain it in our repositories as a dependency, or have clients install and maintain it on their own.

      What improvements would you like to see? (What sucks?)
      Some form of caching each call along an endpoint. We worked around this on the server level by having Varnish cache everything for an indefinite period, with invalidation occurring via PURGE requests made any time the data was updated. This obviously wouldn’t work on shared hosts.

      Improved user authentication would be nice, especially with regards to caching. The endpoints we needed to cache didn’t require authentication, so we have no workaround for that.

      Is the API important to you?
      Yes, very much so.

      Anything else you’d like to tell us?
      You’re all amazing.

    • Luc Princen 10:47 pm on July 23, 2015 Permalink | Log in to Reply

      We’ve created a Backbone app running medical caretakers can create and edit a profile, so users can search, based on there location. It pulls in data to create a interactive google map. After a click, you end up on a caretaker-profile.

      The fields related to a profile are generated by Advanced Custom Fields, which we also fetch using the API, to build the frontend and edit-screens. Admins can therefor change and update the fields on a profile-page as they wish.

      Editting a profile page is also completely done in javascript. Including inline validation and auto-saving on input-blur. We’ve gotten so much questions about where the save-button was that we finally put up a notice; ” Everything will be saved automatically. Dont’ worry :-)

    • Lara Littlefield 1:52 am on July 24, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      We’re using it at http://simmerwp.com to help build our own developer APIs, but also help others make cookbooks into mobile apps that they can easily sell, or monetize with app purchases.

      I also wrote about the API and its far-reaching implications for the democratization of a lot of great types of software entrepreneurship, especially in the long term. http://laralittlefield.pub/24-percent-internet-scale-wp-api/

      I love the WP API and was first inspired by it during Scott Taylor’s WordCamp Maine keynote! 🎉

      Is the API important to you?
      It’s incredibly important, since we’re really focused on building native apps for mobile and the future of the Internet of Things in the kitchen 🍴

      Anything else you’d like to tell us?
      It’s incredible to be able to witness the incorporation of the WP API into core in such a multi-layered community like this. Thank you so much to the project leads and volunteers, this is awesome open source stuff. Your dedication is truly appreciated. Thank you for being able to do what you do during your jobs during the “day” while also dedicating so much time to the future WordPress.

      • Lara Littlefield 3:08 pm on July 26, 2015 Permalink | Log in to Reply

        I want to also add that we’re going to put WordPress in every kitchen in the world as part of the future Internet of Things. We can only do that with the WP API.

        As the number of user interfaces in every human’s life continues to grow, we’re going to be there to make sure that in the kitchen they are open source, standardized, and follow a lot of the core philosophies of WordPress (80/20, lean, etc…)

        This is all coming together in a blog post that will be published this week. I’ll update this post when it’s released ☺️

      • Lara Littlefield 2:27 pm on July 28, 2015 Permalink | Log in to Reply

        Hi again! I just published a blog post on the future of the Internet of Things, open source, and the WP API as a way to express the many ways in which it will be used. This post focuses on the kitchen, but as you can surmise, the benefits will spread to cars, and many other uses for the home, too.

        http://laralittlefield.pub/wordpress-iot-kitchen/ 🍴

    • Michael Beil 3:56 am on July 24, 2015 Permalink | Log in to Reply

      We are using it in Lasso and Nick Haskins is running the API on WP Live Search.

      I’ve also been working with Roy Sivan on a plugin that could be using the REST API in the future.

      Josh Pollock has some great work that he has introduced to me regarding the REST API as well.

      Needless to say, I would love for the REST API to be included in core, as was the expected outcome of all the work being done over the past few years. I think the overall market share for WordPress can be increased with the introduction of this REST API.

      Thank you to Ryan, Rachel, Daniel, Joe, and the rest of the team for all of your hard work.

    • Martin Sotirov 6:47 am on July 24, 2015 Permalink | Log in to Reply

      I am gonna be building a client project with the API in the coming month. It’s gonna be a mostly static portfolio site with dynamic SPA-like content loading. Still haven’t decided on whether to use Backbone or React for the front end. I’m going to run some tests first to see which fits better in my desired approach — I want to have server side rendering by PHP for SEO purposes and to still use many of the WP templating functions, especially in the header and footer parts.

    • Dave Navarro, Jr. 2:48 pm on July 24, 2015 Permalink | Log in to Reply

      Item #1 – I built an Advertising Management platform using Custom Post Types and the REST API. It allows our sales people to sell ads for our web sites and manage them all from a single central web site. I have a companion plugin that runs on the individual web sites and pulls the ad data using the REST API.

      Item #2 – I manage numerous News web sites for radio stations. When ever a reporter posts a story on their web site, the post is copied to a central web site using the REST API. It then becomes available via a TinyMCE button to insert stories from the central web site. Kind of a mini-newswire between all of our sister news stations around the country. Both content and attachments are copied.

      Item #3 – I’m building a user management system between all of our web sites. Again, using a central web site you can set permissions/roles for each user and that info is copied to all of the child sites. When a user changes their password on any site, it will be updated across all of the sites and we can disable a user’s access to all sites from the central site.

    • Daniel Milner 3:08 pm on July 24, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      I used it recently to power an entire mobile app. Custom Post Types, Pages, Menus, etc are all pulled in to the app to make it completely dynamic.

      What would you like to do with it?
      Additional methods to authenticate with the API would be nice. Like API Keys or something, for times when you want an end user to write data (populate a CPT for example), without the user having an account on the website.

    • jeroensmeets 5:51 pm on July 24, 2015 Permalink | Log in to Reply

      Hi Ryan,

      Great to see the attention the API is getting. I have been using it on several occasions, mostly for client projects.

      Two main types of projects:
      1) copying post data to another site — for the Dutch foundation that organizes the Open Monument Weekend I built a plug-in for cities to copy their list of participating monuments and activities to their own site (for one city, that is). It uses WordPress ids to control if a post is new or updated from last year, and can build an archive per year.
      2) enabling search in a custom built search page or app. For these types of data access I find the current API code too slow, and I tend to replace this with e.g. Elastic Search.

      My main concern for the API at the moment is speed and caching, esp. when getting data from it. Much slower than the site itself and extra steps are needed for production.

      Debugging can be trying at times, so some attention to this would be helpful.

      I seem to remember I found myself in need of extra filtering options during the building of my last project. As I’m on holiday right now, I’d have to check when I return home.

      Found this post through the wptavern article, and will subscribe to this blog. Thanks! The API is already really useful and I hope to see it grow to core soon.

    • Ahmad Awais 12:32 am on July 25, 2015 Permalink | Log in to Reply

      I’ll keep it short.

      What are you doing with the API?
      Right now I am playing around with it, learning it by reading the source and about a few weeks shy of working out a module. E.g. here is an example here is a jQuery way of fetching posts and building a simple CMS agnostic Widget (http://codepen.io/ahmadawais/pen/aORdVV)

      What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)
      Well, right now with two versions in place there is a bit of a mess around what to do what not to do. oAuth needs a lot of improvement and there is definitely pretty little documentation.

      What improvements would you like to see? (What sucks?)
      First of all there should be SOPs so that we could start thinking of doing stuff on a commercial scale. Then there is documentation.

      Is the API important to you?
      Yes, it really is! It should be included in the core as soon as possible. We all can agree on the advantages it can bring to WP community. If it is not in the core, it ain’t an API. To help build commercial apps/plugins with it, we need it to be in the core.

      Anything else you’d like to tell us?
      I’d like to thank Ryan, Rachel, Daniel and Joe and everyone else involved in this project for making it possible. I think WordPress API is the first step towards THE NEXT WordPress.

    • LumberHack 6:53 pm on July 25, 2015 Permalink | Log in to Reply

      Here is my 2 cents.

      I’m usually a fence sitter but this discussion was too important for me to keep quiet. The API is really important and useful if you ask me. I build mobile apps and without this I cant imagine the extra work I’d need to put in to get the same functionality working.

      As a developer / power user of WordPress I think this is invaluable and a move in the right direction. I can see WP integrating nicely and playing well with a lot of the other platforms out there. It should be included in the core soon.

      What improvements would you like to see?

      Cache
      OAuth improvements.
      Docs
      Perfomance improvements

    • Luis Rodrigues 1:41 am on July 27, 2015 Permalink | Log in to Reply

      We’re using the WP REST API on a number of client projects, where we have it powering native mobile apps, live search features and even a (sometimes offline) slideshow application for videowalls.

      We’ve also created B3, a Backbone.Marionette-based starter theme that uses the WP REST API. It’s still using v1, but we’ll be transitioning to v2 now that it’s stable. Github: https://github.com/B3ST/B3. Demo: http://demo.beebeebee.be.

      There’s a handful of features we needed for B3, like menus, widgets, access to (a limited set of) options, as well as permalink settings, but that didn’t stop us: we simply added support for those via a plugin. And so, because the API is so easy to extend, I would probably set aside new functionality to focus on security and performance for a while.

      I think this API is really important for the future of WordPress. Leveraging JS on the frontend is just one of its most obvious applications, and certainly the way forward, but there’s immense power waiting to be tapped if you’re integrating with different platforms in the enterprise or on the internet at large.

      Kudos to the team! Looking forward to seeing the API in the core!

    • Matt 1:25 pm on July 28, 2015 Permalink | Log in to Reply

      I’m using the Rest API to build a completely Angular driven front end where WordPress is used for cms and admin. The biggest thing that’s missing is better support for Posts to Posts, but that is also a WordPress issue.

      This api is very important and is the only reason this app is being developed on WordPress.

      Thanks team!

    • Doug Smith 3:53 pm on July 28, 2015 Permalink | Log in to Reply

      We’re using the API to integrate a custom Rails app with our users and data in WordPress, bbPress, and WooCommerce. Some of the big benefits are single sign on and one page account management for everything.

      As others have mentioned, I’m also wishing for oAuth2.

      A big thank you to everyone working on the API project! It is making possible many things that I’ve wanted to do for a long time.

    • aaronsmulktis 1:49 am on July 29, 2015 Permalink | Log in to Reply

      I’m using it to build a node webapp editorial media site for GaloreMag.com. I’m also going to use it to pull profiles & posts from custom taxonomy/endpoints/routes thru the WP-API for the separate social media talent agency KittenAgency.com

    • amando96 7:31 am on July 29, 2015 Permalink | Log in to Reply

      I’m currently using it to power my personal website, as it currently is an angular SPA, but I want to integrate wordpress for the backend, this API makes it possible. I’m also using it at work for some things I can’t disclose fully :)

  • Konstantin Obenland 10:38 pm on July 21, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for July 22 

    Here’s the agenda for tomorrow’s Dev Chat in the #core channel on Slack.

    During Beta Notes @iseulde would like to discuss headings and whether to convert on space or enter in #31441. Please download the latest nightly and test the feature before Dev Chat, so we can talk about it.

    Time/Date: July 22 2015 20:00 UTC:

    1. Beta Notes
    2. Feature Updates
      1. Admin UI – If @helen can make it
      2. Menu Customizer – @westonruter
      3. Passwords – @markjaquith
      4. Site Icon – @obenland
    3. Component Updates
    4. Open Floor
     
    • Ryan Boren 11:05 pm on July 21, 2015 Permalink | Log in to Reply

      Looks like a lot of ui discussion, potentially. Fresh screenshots posted to tickets or make/flow go well with ui discussions. 😉

    • Stephen Edgar 12:06 am on July 22, 2015 Permalink | Log in to Reply

      As I won’t be around for dev chat (Too early for us Aussies).

      I think the conversion should be on enter, after testing just now here’s why:

      As I start to type a heading ## as soon as I hit tap the spacebar any resemblance of what I typed on the screen is now gone and I’m a little perplexed why it vanished, as I start typing I see I’m now typing a h2 header, though grokking what just happened is not entirely clear.

      I’d much prefer to continue to see on screen what I’m typing so as I type ## my h2 heading all of that text remains on screen verbatim of how I typed it until I hit enter, hitting enter magic happens and I’m most suitably impressed and rejoice spontaneously with three cheers, “Hip Hip Hooray, WordPress”

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
Skip to toolbar