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

  • Scott Kingsley Clark 4:15 pm on August 3, 2015 Permalink |
    Tags: ,   

    Fields API: Request for review of direction 

    Over the past many months this year, I have been working with guidance from @helen on the new Fields API with the intention of inclusion into WordPress core. It’s based on the Customizer API, so those who have experience with it will see a lot of similarities. The goal isn’t to create a duplicate API though, and in our proposal we would be implementing the Fields API within the Customizer API.

    What does that bring to core as a whole? It gives core a very real and far reaching API to add fields to any type of object in a standard interface. Given the growth of the Customizer API and its inclusion of fields, @helen and I both agreed it’d be great to leverage everything it can do in our efforts here. The goal isn’t focused on the actual Customizer UI or editing on the front-end, it’s all data-oriented.

    We would create implementations behind the scenes in the various existing APIs such as the Customizer API (now) and Settings API (later) while maintaining backwards compatibility. We’re also hoping to implement the Fields API within the User profile screen. This would give core more flexibility towards revamping the User profile screen in the future, without having to tackle even more than just a UI refresh. That’s also not mentioning the fact that plugin and theme authors could leverage this API to extend WordPress with their own fields in the various areas. Future places we’d look at integrating Fields API with would be the Post editor, which I’ve pegged as our third focus, behind User profile fields and the Customizer API.

    Anyways, that leads us to the point we’re at now, we have an API but we don’t have all of the built-in Field Types (control types) yet or the latest Customizer API changes from 4.3 merged upstream into the Fields API. There are unit tests that are running (and passing!) so that is going to help us on our road towards core for sure.

    We need developers to give their feedback on the direction we’re heading. Here are the relevant links for those reviewing:

    I’d love more feedback from anyone contributing to WordPress, or the *countless* plugin and theme developers who would use the Fields API. Please comment on this post, or if you’d like to discuss further, you can hop into our weekly meetings on Mondays (Monday 20:00 UTC 2015) in the WP Slack #core-fields channel, or ping me there anytime.

     
    • Matt Gibbs 4:48 pm on August 3, 2015 Permalink | Log in to Reply

      Thanks for all the hard work, Scott and Helen! The specifications doc looks very detailed. I’d like to see more usage examples though. Similar to the one on https://make.wordpress.org/core/2015/05/27/metadata-api-project-reborn-the-new-fields-api-project/

      1. How to create custom field types (or Controls as its called now)?
      2. Does a field require a section?
      3. What happens if the field capability isn’t set? Does it fallback to the parent section / screen?
      4. How are repeatable fields handled in the current spec?
      5. Is the field API itself concerned about field order? Should it be?
      6. How granular are field sections? E.g. can a field be added to a single post item (or user) only?

      • Scott Kingsley Clark 5:55 pm on August 3, 2015 Permalink | Log in to Reply

        1. We’re still ironing that part out, control types / field types is the next area of the spec we have to nail down. Feel free to join us on Mondays for our weekly meetings if you want to help us get that part finished.

        2. Currently, it functions the same as the Customizer API, which allows you to add as many fields as you want, without sections or screens (panels). The differentiation is when you add a control, you specify the section or screen you want to add it to.

        3. Fields don’t require capabilities, controls don’t either. We handle the same capabilities checks as the Customizer API does right now — https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-customize-setting.php#L439 — which is to say, if you don’t provide a capability check, it is wide open. We should nail this down further and I think it’d be good to default to no-access. We need dev input on that.

        4. There is no preparations for repeatable fields or repeatable groups at the moment, that’s something we want to nail down in the control types / field types discussion, as there may be things we want to do there. The existing Fields API spec is almost entirely based off of the Customizer API and no additional functionality has been added for that yet. It’s on our list though, we want to ensure any effort we put forth into core does not limit developers or the common ‘loop field’ use-cases. Whether ‘loop fields’ go into core or not, that’s not something I can speak to at this point.

        5. Yes, the spec makes use of the ‘priority’ option for screens, sections, and controls. Works just like filter/action priorities do.

        6. Screens, sections, controls, and fields are all added to a specific object type / name (for example: post type : post). Further definition based on a conditional like a specific ID, capability, etc, could all be handled through an additional callback or filter that we can add inside of the check_capability methods for screens / sections / fields.

    • Brent Jett 8:23 pm on August 3, 2015 Permalink | Log in to Reply

      Cool spec! I like the idea of a broad-reaching common syntax for adding fields from themes/plugins, but I’m wondering if there isn’t a more modern/human-readable format or syntax for this. My immediate thought was JSON files (OOP code underneath obviously). WordPress exposed object oriented API so late in it’s relative lifespan that OOP code like the customizer API still looks very foreign to themers. Given that most app platforms now use JSON manifest files to declare things like configuration, it would seem to me very natural for WP to look at adding a more approachable syntax like that to it’s theme configuration APIs.
      But I could be way off. Nice work either way.

    • Mike Nelson 10:14 pm on August 3, 2015 Permalink | Log in to Reply

      In Event Espresso we created a similar system called the “Forms System”, inspired primarily by Django’s forms. EE Forms basically define how to display an HTML form, how to validate the user-provided input on both the client-and-server side, and how to sanitize/normalize the data for use in the PHP code. (It leaves the job of saving data to either our models system, wp options api, and sometimes direct wpdb).
      EE “form sections” are roughly equivalent to your “screens” and “sections”, and EE “inputs” are roughly equivalent to your “controls”.
      Some differences that might spark some ideas for you:

      1. EE form-sections are nestable; so you can have sub-sub-sub-sections etc. This has allowed for more re-use. Eg, say you wanted to have screen section for multiple post custom fields: the “custom fields” would be a section, and then it would have a different sub-section for each post custom field.
      2. Each form section can have its own “layout strategy”, a separate class that dictates how to layout the form section’s inputs in the HTML, and its sub-form-sections. So if you want to layout your form’s inputs in a very standard way, you’d select one of the pre-set layout strategies.
      3. If you want to layout your forms input in the HTML in a very custom way, template code can be passed a form section which gives the template code access to the sub-sections and inputs and the template code can dictate where to place what
      4. sub-sections can actually just be chunks of HTML, “html subsections”. These have been good for extra stuff that’s important for the display of the form, but aren’t necessarily related to form-data
      5. the EE forms system is separate from our “model system”, although they’re sometimes related. The forms system is primarily focused on displaying HTML forms, and then validating and sanitizing the user’s input; whereas the models system focused on defining the underlying data stored in the database, how that data is related to other data, how to save and retrieve that data, etc. We have a form section base type that can automatically create sub-sections and inputs based on a particular model.

      Other than that, it’s really quite similar.

      Also it’s not that clear: is the fields API intended for use in the frontend too?
      Also it seems if this is intended primarily for defining the HTML forms and how they get validated/sanitized. I think having a separate API for defining the underlying data would be beneficial, in cases where you don’t want every attribute of the data to necessarily be represented in HTML forms, or you might want to provide different forms for editing the same underlying data.

    • thomask 11:02 pm on August 3, 2015 Permalink | Log in to Reply

      I am really looking forwards to this, actually for me this is the second most crucial missing feature for WP – the first is multilanguage support. I use Advanced Custom Fields for almost every web i do, and however it is very nicely written and easy to use, i would prefer some build-in support.
      I have read it all just briefly and will have to try it, from my experience what is important is
      1. support for multilanguage fields (so that i can have common field for all languages version of one post, as well as translatable field) – but this is i guess more question on the multilanguage plugin (or future WP multilanguage support)
      2. text field (just simple text), term fields and post field (N:N relation field), wysiwyg field, user selection field … and/or easy way how to create new field types with standardised look, values control etc.
      3. allowed values control and definition, read only possibility, required field possibility
      4. possibility to add fields also to terms (!!!) – imo terms (edit-tags.php) are currently very stupidly different from the posts – it should have the same look, so that we could use the same fields and functions.
      5. easy definition of post types and other conditions, that are required for field to be displayed
      6. advanced feature, but very usefull in many cases – possibility to set-up condition for field, that should be calculated live on the post screen depending on some live changes – e.g. “this field should be visible only when category is “blabla”).
      7. field could be added also to attachments – but dont forget, that it does not have only the standard post.php, but that the fields are displayed also on the attachments popup screen
      8. dont forget the field versioning (with older version of post you see also older version of its fields)
      9. posibility to create groups of the fields with their conditions
      10. possibility to e.g. display fields in two columns
      11. very advanced field – repeater field (e.g. something like this http://www.advancedcustomfields.com/add-ons/repeater-field/) – possibility to create field table. This is very complex, but very often this is the only way how some things can be solved, as currently there is only simple ID->key->value in WP, but very often you need ID->key->array(subkeyN->valueN), so without this field type many users will still have to use some solution as advanced custom fields.

  • George Stephanis 12:10 pm on August 3, 2015 Permalink |
    Tags:   

    Two-Factor Authentication Weekly Update! 

    We met on Thursday and discussed the providers in progress — TOTP, FIDO U2F, and Backup Codes.

    https://wordpress.slack.com/archives/core-passwords/p1438290019000492

    In Attendance:

    Last week we merged in the functionality to support fallback methods and have a great pull from @valendesigns to better automate the workflows and systems, as well as adding in some unit tests — https://github.com/georgestephanis/two-factor/pull/8

    We also need some Design help with some flows and options screens, so if any designers are interested in pitching in, let me know! :)

    Next meeting will be Thursday, August 6th at 21:00 UTC

     
  • Ella Iseulde Van Dorpe 8:54 am on August 1, 2015 Permalink |
    Tags: , ,   

    Editor Enhancements in 4.3 

    Text Patterns

    We added a small set of text patterns, or text shortcuts if you will. These will hopefully keep you focussed better on your writing and save you some time. :)

    Typing *  or -  will automatically give you a proper HTML list right away. Same for 1.  or  1) , but then ordered. Not your intention? Pressing backspace will undo this change. You can also use the undo button, ctrl/cmd+z or esc.

    Starting your paragraph with two to six number signs # will convert that paragraph to a heading. Similarly the greater-than symbol > will convert the paragraph to a blockquote.

    We’re planning to add some more next release, and a way for plugins to extend this.

    Here’s a demo video @boren made.

    Inline Link Toolbar

    This toolbar will show up when you put your cursor in a link. You’ll now be able to see a short version of the URL without having to open the link modal all the time. Clicking it will open the page that it links to in a new browser tab. If you wanted to do this before, you had to open the link modal and copy paste the URL in a new browser tab yourself.

    It also comes with an edit and remove button. We hope to move the editing experience inline next release as well.

    Inline link toolbar

     
  • Rian Rietveld 2:04 am on July 31, 2015 Permalink |
    Tags: , ,   

    Headings in Admin screens change in WordPress 4.3 

    Are you a theme, plugin or framework developer for WordPress? Take note: the heading structure in the Admin screens will change in WordPress 4.3.

    From H2 to H1

    Currently, in WordPress 4.2 and before, the main heading in admin screens is an <h2>. However, if you want to have a correct, semantic heading structure, a page should an <h1>, but only one, which describes what the page is about.

    People using assistive technology use the <h1> to identify a page and quickly know where they are. Further, proper HTML5 dictates that an <h1> should be the initial heading.

    Therefore, in WordPress 4.3 the headings of all admin screens have been changed from <h2> to <h1> (see #31650).

    Related CSS changes

    If your theme or plugin still uses <h2> for admin screens, don’t worry; styles for <h2> are still supported in the admin CSS so that, visually, nothing changes during the update to 4.3. However, a new class was introduced to properly style <h1>s, page-title-action. Here’s an example of the new class in use:

    <h1>Posts <a href="[..]/wp-admin/post-new.php" class="page-title-action">Add New</a></h1>

    The old class .wrap .add-new-h2 is still supported but has been labeled deprecated. It has been replaced by: .wrap .page-title-action.

    More changes ahead

    After the release of WordPress 4.3, the accessibility team will continue making changes to heading so that they are semantically correct. Current <h3>s will become <h2>s, <h4>s will become <h3>s, and so on.

    Check your code

    Does your plugin, theme, or framework have admin screens? Check the heading structure. Change the main heading from an <h2> into an <h1>. If you’re feeling generous, check the rest of your heading structure to ensure it’s semantic.

    Making these semantic changes will ensure your plugin or theme is in sync with WordPress and that people using a screen reader can understand your admin screens better.

    If you have any questions, ask them in the comment section below, or contact the WordPress accessibility team in the #accessibility channel in WordPress Slack.

     
  • Samuel Sidler 8:50 pm on July 30, 2015 Permalink |
    Tags: , 4.2.4   

    WordPress 4.2.4 Release Candidate 1 

    tl;dr WordPress 4.2.4 RC1 is available (download) for testing and fixes an issue with inline scripts.

    A change in WordPress 4.2.3 had the unintentional side effect of breaking some inline scripts when the CDATA block is used (see #33106). For example, consider the intended content here:

    <script>// <![CDATA[
    _my_function('data');
    // ]]>
    </script>

    In 4.2.2, this content is left as is and _my_function() fires as expected. In 4.2.3, the content is manipulated as such:

    <script>// <![CDATA[ _my_function('data'); // ]]></script>

    This results in the script being commented out by the // and it will not fire. A workaround for this is to use /* for commenting.

    <script> /* <![CDATA[ */ _my_function('data'); /* ]]> */ </script>

    However, this workaround should not be necessary. As a result, we intend on releasing WordPress 4.2.4 to fix this issue.

    Additionally, WordPress 4.2.3 caused issues when using shortcodes within angle brackets (see #33116). For example, this shortcode usage worked in 4.2.2 but did not work in 4.2.3:

    <[shortcode]>

    While we do not recommend this use of shortcodes and strongly encourage plugin developers to move away from this use of shortcodes, the breakage was unintentional and we have restored the behavior in WordPress 4.2.4 RC1.

    Please download and test WordPress 4.2.4 RC1 and report any issues to core trac or to this post.

     
    • Mickey Kay 6:54 am on July 31, 2015 Permalink | Log in to Reply

      Yay! Thanks for hearing the community feedback and responding as best you could! It’s much appreciated – thanks for all the hard (volunteer) work.

    • twinsmagic 7:19 pm on July 31, 2015 Permalink | Log in to Reply

      Still is broken for me. I’m merging contact details onto my page and before was able to set the value in form fields automatically but now it shows as half of my shortcode. See this example:

      http://www.blueandgoldentertainment.com/4-2-4-rc1-test/?Email1=test@test.com&mc-firstname=David

      You’ll see merging that sample name and email onto the standard content of the page works fine just not when I have it in the value attribute of the form field, ie: value=”[SHORTCODE]”

    • Dave Navarro, Jr. 5:39 pm on August 3, 2015 Permalink | Log in to Reply

      “While we do not recommend this use of shortcodes and strongly encourage plugin developers to move away from this use of shortcodes”

      From a “user” point of view, using a short code as an attribute in an HTML tag is **VERY** natural. Especially when I am pulling URLs from post-meta:

      <a href="[url_shortcode]">Click Me</a>

      So saying that it’s not recommended seems counter-intuitive to the goal of WordPress being “easy to use”. Especially since it’s BEEN WORKING for years.

    • programmin 6:47 pm on August 3, 2015 Permalink | Log in to Reply

      Will there also be a 4.1.7 update?

  • Dominik Schilling (ocean90) 8:38 pm on July 30, 2015 Permalink |
    Tags: , ,   

    get_transient() is now more strict in 4.3 

    WordPress 4.3 includes a change to get_transient(). As reported in #23881 and #30380, get_transient() had a check for get_option( $transient_timeout ) < time().

    Because get_option() can return false and false is always < time() 😖, get_transient() could delete transient timeout options in an unexpected way or cause two more unnecessary queries.

    WordPress 4.3 now checks the return value first before comparing with the current time. This means that WordPress will no longer delete broken transients via get_transient() if you have only deleted the timeout option. See [33110].

    If you have to delete a transient manually, please make sure that you’re deleting _transient_timeout_$transient and '_transient_' . $transient. (Hint: Transients can be stored in an external object cache too.)

    See also: the Transients API Codex page.

     
  • Dominik Schilling (ocean90) 5:41 pm on July 30, 2015 Permalink |
    Tags: , ,   

    Legacy Theme Preview Removed in 4.3 

    This release we removed the old code for the Legacy Theme Preview, which hasn’t been maintained since the introduction of the customizer in WordPress 3.5. Recently, we noticed that the theme preview no longer works when using a static front page. We kept the old theme preview for no-JS and some browsers that were less capable. But since browsers are doing a better job today we don’t need to continue fixing/shipping this legacy code. That’s why we removed it. See [33492].

     
  • Weston Ruter 10:45 pm on July 29, 2015 Permalink |
    Tags: , , , ,   

    Fast previewing changes to Menus in the Customizer 

    The foundation of the Customizer is built on the concept of the “setting”, an abstract representation of anything in WordPress: options, theme mods, posts, terms, and so on. Settings are linked to controls which are responsible for manipulating them. When a setting is changed it gets pushed into the preview window so that the modification can be reviewed before being published live.

    There are two ways (transports) for how a setting can be pushed into the preview: refresh and postMessage. The refresh transport does a full page refresh with the modified settings applied, and so it relies on PHP to apply the setting changes. The refresh transport is designed to be compatible with all themes, but for heavy sites refresh can be excruciating slow and taxing on the server. For this reason, the postMessage transport was introduced for previewing changes. This transport uses JavaScript to apply the changes instantly in the preview without any Ajax requests or PHP calls. This is great, but themes have to opt-in to postMessage transport for settings because they must also include JavaScript code which duplicates the logic which is already being executed on the server by PHP. The postMessage transport violates the DRY principle.

    With that background out of the way…

    Partial Refresh of Menus

    In WordPress 4.3 menu management is being added to the Customizer, extending the types of objects that the Customizer can manipulate to include nav_menu taxonomy terms and nav_menu_item posts. We wanted this menu management experience to be fast so it had to avoid the slow full-page refresh transport. Nevertheless, the postMessage transport wasn’t possible to use either since we wouldn’t be able to duplicate all of the PHP menu walker logic and theme/plugin extensions for rendering menus purely in JavaScript. We also wanted to enable fast previewing of menu changes by default. So we implemented a postMessage/refresh hybrid approach which uses postMessage to sync the menus settings to the preview, and then the preview does an Ajax request to render just the contents of the menu container, and this Ajax response is then inserted into the DOM to replace the previous menu container. The technical name for this approach we have been calling “partial refresh”, but you can call it “fast preview”.

    When the Customizer determines it can’t do a partial refresh, it falls back to performing a full page refresh. Conditions for why a menu change will get a full page refresh include:

    • if the menu was just assigned to a location for the first time or removed from being assigned to a location, since the theme may have some changes to the layout that it may need to perform;
    • or if wp_nav_menu() is called with with echo being false, since the theme may be doing some string replacement in this case which we can’t replicate in the partial-refresh Ajax request;
    • or if wp_nav_menu() is called with with a non-JSON serializable fallback_cb, such as a closure or a object method—this arg has to be empty or a string;
    • or if wp_nav_menu() is called with with a walker object instance, as opposed to a class name string;
    • or if wp_nav_menu() is called without a theme_location arg and the menu arg is not an term ID or a menu object;
    • or if the menu selected in a Custom Menu widget is changed, since partial refresh for widgets is not yet supported (however, see feature plugin)—subsequent changes to the menu will result in fast partial refreshes if the above conditions

    When a menu is being updated via partial refresh, the menu container will receive a classname customize-partial-refreshing, which by default changes the opacity to 25%.

    Theme Support

    The fast preview for menu changes is being enabled by default so that theme authors don’t have to opt-in to the functionality like they do for instant preview (postMessage transport). In general this should be fine. However, if the theme includes some JavaScript which dynamically manipulates the rendered menu container, such as adding event handlers for expanding/collapsing submenus, then the theme would need to include some JS to re-apply the modifications once the menu is partial-refreshed, as the old DOM for the menu container gets replaced.

    The Twenty Fifteen theme actually uses JS to expand/collapse submenu items, so it needed a patch in 4.3 to re-setup a partial-refreshed main nav menu. In addition to firing the menu container DOM setup logic once at jQuery.ready(), it now invokes the functionality whenever the menu is partial-refreshed. See the initMainNavigation() JS function.

    So in general, if your theme needs to dynamically initialize menus with JavaScript, the pattern for the initialization code should be:

    jQuery(function($) {
    	function initMainNavigation( container ) {
    		/* set up container... */
    	}
    	initMainNavigation( $( '.main-navigation' ) );
    
    	$( document ).on( 'customize-preview-menu-refreshed', function( e, params ) {
    		if ( 'primary' === params.wpNavMenuArgs.theme_location ) {
    			initMainNavigation( params.newContainer );
    			/* optionally sync a previous menu state from params.oldContainer... */
    		}
    	});
    });
    

    The params being passed to the event handler consists of the following properties:

    • newContainer: jQuery object containing the new menu container element retrieved from Ajax; this is what you would manipulate to initialize.
    • oldContainer: the previous jQuery object holding the element for the replaced menu container; this is useful if there is any state in the old menu that should persist in the new menu, such as which submenus are expanded (as in Twenty Fifteen).
    • wpNavMenuArgs: The array of arguments passed to wp_nav_menu() in the template, such as template_location.
    • instanceNumber: The index for which wp_nav_menu() call being updated.

    The Future

    Partial refresh is an “experimental transport” introduced here specifically for menus. In 4.4 we hope to generalize the framework so that any setting can be setup for fast preview, starting with widgets (see #27355). There is a Customize Partial Refresh feature plugin that implements widget partial refresh in a beta state. This partial refresh functionality I’ve also identified as being critical for Customizer Transactions.

     
    • nicholas_io 2:53 am on July 30, 2015 Permalink | Log in to Reply

      This is awesome. But what happens if the menu doesn’t have a container (container arg set to false)? It will fallback to a full-page refresh?

      • Weston Ruter 6:16 pm on July 30, 2015 Permalink | Log in to Reply

        @nicholas_io: Good question! I wasn’t sure actually, but I tried it out and it works fine. The critical logic here is found in WP_Customize_Nav_Menus::filter_wp_nav_menu().

        You can see that it attaches the required CSS class names to the class attribute it finds. When the container arg is false then the root ul element is used, and it will have a class name if the normal walker is used, at least. I tried partial refresh with set to false, and it continued to work as expected. As long as the items_wrap continues to have the default value of <ul id="%1$s" class="%2$s">%3$s</ul> then it will work.

        We should harden this, however, to not just find the first class attribute, but look at the first (root) element and amend an existing class attribute or insert one if it doesn’t exist already.

      • Weston Ruter 6:40 pm on July 30, 2015 Permalink | Log in to Reply

        Here’s a patch for what I have in mind: https://github.com/xwp/wordpress-develop/pull/110/files

        • nicholas_io 1:28 am on July 31, 2015 Permalink | Log in to Reply

          It’s a good patch for me, the original approach could lead to problems in some edge cases (and from what I understand with this patch we could still have partial refresh even if the user alter items_wrap and remove the class attribute.)

  • Ella Iseulde Van Dorpe 9:26 pm on July 29, 2015 Permalink |
    Tags: , ,   

    Old Distraction Free Writing Code Removed in 4.3 

    This release we removed all old DFW code, which hasn’t been used in core since 4.1. We left it in core for two releases so plugin authors had the time to update. If it is essential to your plugin, the files in 4.2 can still be reused and improved. See [32677].

     
  • Konstantin Obenland 5:04 pm on July 29, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for July 29 

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

    We’re getting ready for RC1 so lets discuss blocker, RC guidelines, and everything else related to RC.

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

    1. RC Notes
    2. Feature Updates
    3. Component Updates
    4. Open Floor
     
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