WordPress.org

Make WordPress Core

Updates from January, 2017 Toggle Comment Threads | Keyboard Shortcuts

  • Mel Choyce 1:16 am on January 24, 2017 Permalink |  

    Customization Meeting Notes: January 23, 2017 

    From today’s #core-customize meeting:

    Thanks @iandstewart for help with notes. Drop by #core-customize next week on Monday at 1:00pm EST for the next full meeting, or join us at the same time tomorrow for ticket triaging.

     
  • Matias Ventura 4:52 pm on January 17, 2017 Permalink |
    Tags:   

    Editor Technical Overview 

    As we start looking at the editor from a technical perspective it’s important we identify the main obstacles and requirements we face before we start conjecturing solutions. As @matt wrote before, the editor focus aims to make writing rich posts effortless. This has taken the path of treating a post as being composed of distinct pieces of content called blocks. These pieces should be easy to insert and manipulate, providing rich and contextual interfaces to interact with as you craft a post.

    So how do we go about turning this into a reality? Content in WordPress is, fundamentally, HTML-augmented text; that is to say, it has no inherent data structure. This has been a very important aspect of WordPress and a force for the open web—it speaks to the sense of ownership and freedom WordPress gives you, since it’s always easy to get the full content of your publications—yet the lack of structure gets in the way of the goal to treat content as composed from individual pieces. (This reality also became an issue for the development of post formats a few years ago, but I digress.)

    It’s relatively easy to add structure, but it’s not trivial to do so in a way that doesn’t harm data integrity, portability, and the cohesiveness of the post_content. So let’s lay out a first requirement:

    ① Shape of the Data: Portable Text

    To ensure we keep a key component of WordPress’ strength intact, the source of truth for the content should remain in post_content, where the bulk of the post data needs to be present in a way that is accessible and portable, while still providing additional structure on top of HTML semantics for our editing tools. Data needs to be praised and respected. This additional structure would hopefully be invisible to the document’s display context, as it ensures the rendered content is viewable in situations that may not be aware of blocks at all. (Think of email clients, RSS, older editor versions, mobile editors, database dumps, etc.)

    Storing things separately means post_content becomes either a pointer or duplicated data, which fragments the source of truth since they can get out of sync easily. (A few content block plugins do this by storing structured data in postmeta and pure data in post_content.) On the other hand, storing things together means structure can become gibberish if it’s not formatted properly before display.

    How can we then offer users a great experience when creating or manipulating content without sacrificing the spirit of integrity and data reliability that is expected from WordPress? Good representations of the data would also make it easier to develop robust collaboration tools in the future by allowing us to lock things in a more fine grained way. I believe this is important to figure out soon to allow us to prototype quickly, so I’ll follow up with an initial proposal by the end.

    Honouring HTML leads to a second requirement:

    ② Simplicity and Semantics of Representation

    Unless we are improving the semantics of the document we should minimize what markup we add to identify a block; for example, avoid adding extra DOM elements or attributes, both for simplicity and standards sake. WordPress has been a champion of web standards, and we should not venture away from this quality. How can we add structure in a way that remains invisible to the output (as meaningful content as possible) but gives the necessary hooks to infer a structured view for editing purposes?

    While we discuss how to structure the content to include invisible demarcation of blocks, the aspect of their nature leads to a third requirement:

    ③ Static & Dynamic Blocks

    Blocks can be either static or dynamic. That is to say, some blocks can be stored with all the necessary aspects needed for their display, while others need to be processed before generating their final output (shortcodes, embeds, widgets, etc). This distinction is important because the most common two blocks people will naturally use are text and images. We should not break their clarity as we treat them as blocks.

    
     # Static
    Here’s some text.

    # Dynamic
    [text id=123] // Pulls "Here's some text" from somewhere.

    This conceptual separation of blocks is useful for designing our project, yet they generate abstract complexity which users should not be exposed to, leading to a fourth requirement:

    ④ Consistent Experience

    One of the biggest benefits of blocks is that composing a post becomes more intuitive and reliable. Everything is inserted under the same assumptions; discovering what can be inserted is a natural part of inserting content. To the user all blocks behave in a consistent and familiar way, even if they provide tailored UIs for their controls.

    The user should also be able to edit a post in a different system (mobile, REST, older version of core, apps like Mars Edit, etc), even if they lose the advantages of block editing. That’s another reason why post_content as source of truth matters, compared to storing a JSON structure in postmeta. Having things in two places means they can get out of sync depending on what tool you used to edit.

    These nuances of data, UI, and display lead to a final and more general requirement, which is understanding the system we’ll be crafting:

    ⑤ The System

    The editor experience has three fundamental aspects to its system: the UI used to manipulate a block; the demarcation of the block; the rendered output of the block. These are all separate concerns, from the tools we craft to edit a post, to the document syntax that holds the data structure, to the way the final output is generated to be displayed as HTML. (With static blocks that last aspect may be of no significant concern since the document doesn’t care about the presence of static blocks, it just displays them.)

    Picturing these concerns as connected but fundamentally separate would help us figure out the best design and technical solutions for each stage, while avoiding us taking aggressive moves by coupling expectations. For instance, JavaScript is a natural technology to look at when it comes to the ability to manipulate and interact with content blocks, yet it may not be the best at all when it comes to rendering the final post to a viewer. Avoiding painting the whole flow under the same light should allow us to focus efforts, because we don’t have to change everything.

    ❶ Coda

    As a final coda, and following @joen‘s design exploration, let’s keep in mind that our first goal should be to set up a reliable foundation to allow us to iterate quickly and test assumptions. I propose we focus initially on a few static blocks (text, image with and without caption, quote) to limit scope of the project.

    In which ways can we fulfil ① and ② from the above requirements?

    Shortcodes fall short in that they are not invisible, they are opaque, not standing to the scrutiny of semantics, and are also painful to parse. Alternatives could be data-* attributes in the HTML elements or custom elements (paving the way for web components, perhaps), yet we need to be careful with adding cruft.

    One other possibility is to look at HTML comments as a way to provide explicit demarcation to post_content without affecting the node structure of the document for something that is inherently spurious to the HTML semantics. WordPress already uses comments for the more tag (<!--more-->) and splitting content into pages in a way that has proven to be quite robust.

    It could look something like this:

    <!-- wp:image -->
    <figure>
      <img src="/">
      <figcaption>A picture is worth a thousand words</figcaption>
    </figure>
    <!-- /wp -->
    

    There are drawbacks, benefits, and implications with each that we should discuss separately. Are there any other possible solutions?

    Please, join us in #core-editor if you are interested. We’re holding weekly meetings in Slack, Wednesdays at 19:00 CET.

     
    • Mike 5:33 pm on January 17, 2017 Permalink | Log in to Reply

      There is a trend towards the use of more attributes and elements. The editor needs to allow for this or for others to create a plugin to do this.

      • programmin 10:07 pm on January 17, 2017 Permalink | Log in to Reply

        How does it not already? Are you referring to how KSES strips out data-attribute=”attributes” in html?

    • Davide 'Folletto' Casali 5:34 pm on January 17, 2017 Permalink | Log in to Reply

      Thanks for outlining this so crisply. Stating all the requirements clearly is something often overlooked, and I feel it’s a great starting point. I’m sure there are going to be things to be expanded in the following weeks, but seeing everything together in this way is excellent.

      Agreed on all the pieces. Let’s the discussion move forward! 🙂

    • FolioVision 7:09 pm on January 17, 2017 Permalink | Log in to Reply

      Wow, that’s quite an essay on the content editor. We’ve been doing this for a long time and know the lay of the land. We even built a WYSIWYG editor we can’t give up (we tried for two years). First in praise of the WordPress editing experience: the Media Library has grown to be very powerful and easy to use. It’s awesome. We were delighted to retire the original image editing module we were using last year and fully integrate the Media Library.

      Still what are the issues with WordPress content editing which drive us to maintain a separate WYSWIYG editor?

      Hint, it’s not the money, thousands of hours have gone into this purely GPL and non-commercial product. It’s not boredom. We have too much to do in three lifetimes and very short weekends already.

      It’s not shortcodes. Shortcodes are great and reliable ways to easily and visibly add content to posts. As soon as you start trying to hide the pieces, reliability falls through the cracks. It’s why lawyers still use WordPerfect.

      Why were we unable to give up our own FCK WYSIWYG editor? Code and javascript mangling. The WordPress TinyMCE editor does not reliably maintain paragraphs and linebreaks. It’s a bit WYSYMightNotGet. When creating complex nested tables and code examples our editor never fails (don’t thank us, thank FCK in Poland, we just maintain a solid WordPress port).

      What is missing with the shortcodes and code inside a fairly utilitarian textbox is true WYSIWYG. The only way to preview a post properly is to open it up with “View Post” and then reload the page to see any changes. This is slow and clunky.

      We’ve done what we can to improve WYSIWYG by in our editor by allowing with just the tiniest modification of your theme CSS real WYSIWYG. This only covers the CSS though and not the javascript or the short codes.

      What would make the WordPress editing experience amazing would be a live preview tab which turns the shortcodes and media into their visuals.

      We’ve looked long and hard at alternative edit experiences (updating FCK to CK was very hard and there aren’t really any world changing benefits: CKeditor is roughly the same experience albeit, better behaved on mobile). When we looked around at an editor to build for WordPress we settled on redaktor.js. Andrew Oz is very sceptical about Redaktor’s suitability for WordPress (licensing issues aside, just speaking technically):

      I like it too. However it’s far from being ready for anything more than
      comments/bbPress editor. Been following several jQuery based editors,
      all have little more than the default browser contentEditable functionality.

      This one is definitely more polished than most but still lacks a lot of
      things. For example: no plugins, no way to extend it other than hack
      into it, very minimal APIs, try copying and pasting something from
      another browser tab, then look at the HTML. And a big one: no undo/redo
      for all actions?

      I don’t know… Probably some will as it is nice. However considering
      the amount of work needed, not sure if that would be enough. Roughly it
      would take a good team of several full-time developers at least a year
      to bring it closer to TinyMCE.

      Nearly all JS editors get off the ground fast by adding UI to the
      browsers built-in contentEditable functionality. Once there, most try to
      tackle few more tasks and stop. The next step requires a lot of work:
      creating APIs, dealing with tons of browser quirks, etc.

      Currently there are several other editors at approximately the same
      stage. The problem is that a lot of the functionality for editing HTML
      should be in the browsers. It can be handles much better there than
      trying to extend the limited contentEditable mode with JS.

      So unless the browser vendors decide to sit down and make and implement
      a nice specification for editing of HTML, don’t see how this situation
      would change.

      We are a long way from 2012. Redaktor is awesome visually, very fast, beautiful preview, lightweight fast editing tools for media. In short everything we’d like the WordPress editing experience to be. In my opinion, TinyMCE will never have that shiny and fast and brilliant feel. It’s in neither the personality or the technology of the software.

      Alas Redaktor is not open source. A platform license would be $199. I’d happily pay it myself for WordPress but it cannot be as it’s against our community GPL principles.

      Perhaps there is something else out there which comes close and does have an open source license or at least a split license like CKeditor and FCKedit?

      That’s the holy grail. The same editing capabilities in the editor, legacy shortcodes but fast responsive and with **immediate full preview**.


      What we should avoid at all costs would be to deprecate shortcodes and create endless compatibility issues. Such a decision would cripple the platform and leave most of our shared library of powerful and obscure plugin obsolete.

      • chatmandesign 4:51 pm on January 18, 2017 Permalink | Log in to Reply

        I’m a big fan of CKeditor. It’s a popular enough option for this I have to assume the WordPress team already has reasons they haven’t adopted it so far, but it really seems like a perfect fit here:

        1) Available under GPL license.

        2) Includes built-in support for managing blocks of content.

        3) Extensible architecture supports plugins.

        4) Robust, battle-tested, actively maintained—and used by a host of major companies and projects, so it will likely stay that way.

        5) As an added bonus, it supports inline editing that could be integrated into the Customizer or some form of front end editor.

    • buzztone 11:45 pm on January 17, 2017 Permalink | Log in to Reply

      Really helpful overview – I look forward to following development of this project.

    • Joy 12:03 am on January 18, 2017 Permalink | Log in to Reply

      I agree with @FolioVision that shortcodes should remain intact, and would even go so far as to say that they should be the basis of content blocks. Why isn’t there a list of registered shortcodes available when editing a post? Why can’t the editor show the shortcode as a block with the parameters editable? Why wouldn’t the preview call do_shortcode() to show what that block looks like? And why can’t widgets be handled the same way, as part of the content?

      • Xavi Ivars 12:15 am on January 18, 2017 Permalink | Log in to Reply

        And that’s what (more or less….) Shortcake already does as a plug in: shortcodes can register UI to define how they should be edited, appear rendered in the WYSIWYG editor and in plain old-style text in the text editor

    • Weston Ruter 1:35 am on January 18, 2017 Permalink | Log in to Reply

      Thanks for the great writeup. I see a lot of alignments between this and the solutions being prototyped in the JS Widgets feature plugin. The plugin specifically aligns in terms of “the UI used to manipulate a block” and “the rendered output of the block”, leaving “the demarcation of the block” to encoding data via structured HTML/Microdata/comments. Likewise in:

      JavaScript is a natural technology to look at when it comes to the ability to manipulate and interact with content blocks, yet it may not be the best at all when it comes to rendering the final post to a viewer.

      The JS Widgets plugin specifically focuses on the use of JavaScript for managing the block’s attributes (widget instance) whereas by default PHP is used to render the block to HTML.

      WordPress needs to have a standard interface for how to define a block which can represent its state, present a UI for manipulating its state, and render its state onto a template. The widget provides such an interface, and with modernization and iteration I think the widget can serve as a standard interface for defining a block which can be used both in post content as well as in widget sidebars and elsewhere.

      Also, a general note that the JS Widgets plugin is focused on improving the WP_Widget API itself. It is not concerned with widget areas (sidebars) and thus is not focused on how widgets are managed in sidebars on the widgets admin page or via the widgets panel in the customizer. Rather, the plugin is about iterating on fundamental widget building block and allowing it as an interface to be leveraged and re-used in other contexts, such as to manage content blocks in the editor (as prototyped for the Post Elements in Shortcake). It’s also not concerned with the storage of widgets, as in the case of Shortcake post elements the instance data is stored as shortcode attributes, though the instance data could be stored as data-* attributes, inside of HTML comments, in HTML5 Microdata, and so on.

      • Matias Ventura 4:36 pm on January 18, 2017 Permalink | Log in to Reply

        Thanks! The stages I see us progressing from would be:

        • Define structure of post_content document that includes representation for both static and dynamic blocks.
        • Parsing of document on the fly to infer more manageable structure (JSON representation).
        • Implementation of general UI layer around manipulation and insertion of blocks.
        • The system to generate final output of dynamic blocks.

        Those last two could converge in a single API, but I think we’ll see if that’s the best path once we get closer to prototyping it.

    • Weston Ruter 1:47 am on January 18, 2017 Permalink | Log in to Reply

      Also, circling back to Twenty Seventeen and its “front page sections” feature (subset of #37974). There’s a lot of overlap between that proposed feature and nav menu items, as well as with widgets and blocks in the editor. I think it is key that we define a common interface that can be used in all of these contexts. The nav menu item in core could be re-implemented using a specific kind of such block, and the nav menu should be a block container just like a widget sidebar is a block container and the post content is a block container, though each may have restrictions on the kinds of blocks they allow. They should all re-use the same underlying block API which is a thing that has a set of attributes, a UI for managing them, and a method for rendering them onto a template.

    • dmccan 2:38 pm on January 18, 2017 Permalink | Log in to Reply

      Thank you for laying out the challenges and requirements. A couple of things came to mind:

      • While I think it is a good idea to limit the scope in order to set up a reliable foundation, there is value in identifying the types of ‘blocks’ that we might want to support in the future. Such a backdrop would be good before starting to iterate so that we know that an architecture is capable.
      • From a user perspective, the #1 shortcoming of the editor is the lack of true, easily editable columns. There are true (not shortcode) column solutions available for WordPress.
      • There are two dimensions: layout and content. From a layout perspective, ‘blocks’ are content that fits into rows and columns. In the requirements discussion, perhaps layout needs to be addressed.
      • In the Coda section you mention data attributes and HTML comments for demarcating blocks, what about divs with reserved class names? That is standards compliant. Bootstrap got a lot of mileage out of that approach.
      • Matias Ventura 4:24 pm on January 18, 2017 Permalink | Log in to Reply

        While I think it is a good idea to limit the scope in order to set up a reliable foundation, there is value in identifying the types of ‘blocks’ that we might want to support in the future.

        Definitely! Starting small should not stop us from considering if our solutions are a good fit for more complex blocks.

        I purposely left out layout considerations at this stage (including columns) because they are a bit ortogonal to the basic requirements here. It’s probably worth focusing on how to address layout in a separate instance, starting with the design goals for it. There are questions like «Do we have layout blocks (column, box) that hold child blocks?» or «Do you setup layout placeholder that you fill in or is layout a result of disposition of blocks?» that have their own complexities.

        > what about divs with reserved class names?

        This is partially questioned in ②. We should avoid creating spurious DOM nodes for the sake of representing “blocks”, unless the semantics of the document are improved by doing that. The requirement is about separating the demarcation of where a block begins from the markup of the block.

        The demarcation should be simple and consistent to allow easy parsing, but it should not pollute markup. For instance, the best representation of many blocks are native HTML elements and wrapping them in divs with classes would worsen the document representation (a paragraph, a blockquote, etc).

        Thanks for the thoughtful reply.

    • jhned 3:04 pm on January 18, 2017 Permalink | Log in to Reply

      Here’s how I currently put “blocks” in my page content: I use Advanced Custom Fields Pro to set up flexible content layouts, that are generated and appended to the post content using the `the_content` filter. The problem with that is that I end up with tons of post meta boxes on complicated pages, which slows editing down.

      I think the best way for us to achieve this idea is to go full front-end editor. Reason 1: tinyMCE is notorious for stripping out markup. Reason 2: editing on the front-end gives users an accurate view of how the “blocks” are going to look. Reason 3: the UI for each block could be focused on the data, and then silently insert any markup necessary in the background.

      In addition to your points, @matias, I would also suggest that we ought to create an API for developers to define custom blocks, much like how we have the Shortcode API.

    • davidperez 3:45 pm on January 18, 2017 Permalink | Log in to Reply

      Why don’t go to allow insert widgets inside content? Shortcodes are hard for users. With blocks of widgets are more intuitive and the user can set all fields needed for th block easily….

    • Mark Root-Wiley 4:29 pm on January 18, 2017 Permalink | Log in to Reply

      Just want to say that this is great and makes me feel much better about some of my concerns about the future of WordPress. Getting Portability and Semantic listed as top priorities is awesome! I also think that if the editor is truly going to get overhauled, following the WCAG Authoring Tool Accessibility Guidelines from the start should be a priority. I assume that as with most accessibility work, tacking it on afterwards will almost certainly be a nightmare while including it up front won’t just make the tool accessible but more usable.

    • chatmandesign 4:32 pm on January 18, 2017 Permalink | Log in to Reply

      It seems to me that associating editable blocks with chunks of editor content without mangling the “pure data” is essentially about how to best store metadata for those chunks. I think there are two good options:

      1) HTML data attributes. Storing metadata related to chunks of HTML is literally why they exist, so it seems like a pretty good option. The benefits here are that we’d be leveraging an existing standard, instead of creating something new where it may not be needed; it keeps the metadata with the data it belongs to; and is easily extensible without risking conflicts (providing name spacing is used). The only real downside, as you noted, is that it adds some cruft to the markup—however, a post_content filter could be added to remove editor-related data attributes in display contexts.

      2) Store editable block metadata in postmeta, associated with HTML elements by ID. Storing metadata about posts is the whole purpose of the postmeta table, after all. The benefits here are largely similar: we’d be leveraging an existing WordPress system, rather than trying to create something totally new, and it’s easily extensible with name spacing. The big difference is that the metadata is stored completely outside the content itself; I think whether that’s good or bad overall may be debatable, but one definite positive is that it adds no cruft to the markup (beyond IDs, which is pretty minimal), and no extra filtering step is necessary.

      I think the big question then is: how tightly coupled should the block metadata be to the blocks themselves? The answer depends how we’re going to use it. The implication in this post is that the post_content should be raw, valid HTML that’s ready for output without extra steps to generate content from it (unlike with the existing shortcode system), and I’m inclined to agree with that for static blocks. In that case the metadata is _only_ relevant to the editor, so I don’t see any benefit to keeping the metadata stored in the HTML itself. The HTML only needs to store the final result.

      If we want to support truly dynamic blocks that pull in current data from elsewhere without requiring a manual post re-save, there are more factors to consider. In that case, the data can’t really be stored in the post. These would require some processing to display, with the block metadata potentially pointing to an external data source. It’s not too much of a stretch to imagine that sensitive data like API keys might get stored in the block metadata by some plugins—I don’t think that would be best practice, but I could easily see it happening—which makes me think that in the case of dynamic blocks, storing the metadata in the HTML could increase the risk of unintended data leaks.

    • James Nylen 6:08 pm on January 18, 2017 Permalink | Log in to Reply

      Instead of `` I think the closing tag should be `` for clarity.

      Do we anticipate a need for these custom “tags” to be nested? This is probably something we should decide up front and either plan for, or prevent.

      • James Nylen 6:11 pm on January 18, 2017 Permalink | Log in to Reply

        WP ate my HTML comments… for clarity. Instead of !-- /wp -- it should be !-- /wp:image --.

      • Mel Choyce 5:26 pm on January 19, 2017 Permalink | Log in to Reply

        I think many of them will have to be nest-able, especially once we get into the customization and layout side of things.

    • Greg Ichneumon Brown 12:50 am on January 20, 2017 Permalink | Log in to Reply

      I think one other thing to add to the list is speed on the front end. We’ve seen many cases where just outputting the final rendered content (especially on APIs) means processing the post content with very large regexp logic (especially the shortcode logic) that then can make returning a dozen posts from an api take many seconds. Most of this was all CPU time. We’ve looked at caching and other options on WP.com, but they’ve been very complicated.

      In summary: performance is a feature, particularly of our APIs and it may be good to start testing that early on.

    • Dan Boulet 12:15 am on January 22, 2017 Permalink | Log in to Reply

      Just an idea: What if the definition of each “block” was declared using a CSS-like syntax (like [Emmet.io’s Abbreviations syntax](http://docs.emmet.io/abbreviations/syntax/)):

      `.gallery>figure.gallery-item>.gallery-icon>a>img.attachment-thumbnail^^figcaption.gallery-caption`

      The post content could be scanned for markup matching the pattern on the fly, and convert it to editable blocks within the editor.

      The same pattern could be used to generate the markup which is inserted when adding new blocks.

      This is probably a simplistic solution, but it offers a few big advantages:

      • No superfluous code in the markup. Simple and portable code.
      • What is saved in the database is exactly what will be used in the front-end, no additional processing required.
      • Backwards compatibility. A post written three years ago could suddenly contain editable blocks if its content includes markup which matches a block pattern.
  • Ella Van Dorpe 8:46 pm on January 16, 2016 Permalink
    Tags: ,   

    Editor wish list for 4.5 

     
  • Ella Van Dorpe 3:39 pm on June 8, 2015 Permalink
    Tags:   

    Editor Chat Tomorrow 

    Tomorrow we have our weekly editor chat (9 June 2015 21:00 UTC) in the #core-editor Slack channel. Here are some points we want to discuss. If any of these are of particular interest to you, be sure to attend. 🙂

    • Last week we added the text pattern plugin, please test! Are there any other patterns we should add? High on the list are for a block quote, #{1,6}  for headings and --- for a horizontal rule. #31441
    • What should happen to word count? Do we (re)move it? When and how should it be refreshed? Currently it only refreshes on enter and backspace, which is not ideal. In any case we also need to fix the counter itself (ignore more unicode ranges, shortcodes…) and this makes the counter slower. #30966
    • Inline linking. We’ve been talking about this for a while. There are some interesting mock ups from @joen, we should iterate on them and code it. Link text may go away. Should we keep “Open link in a new window/tab” in core? If you want to know more about the way it will work or help out, join us. 🙂 If there is consensus it may still make 4.3.
    • Another thing that should be coded asap is the caption placeholder. #32175

    If there’s anything else you’d like to bring up that’s editor related, don’t hesitate to do so.

     
    • Shapeshifter 3 4:48 pm on June 8, 2015 Permalink | Log in to Reply

      I’m not picking on you individually Ella, but why has WordPress (whether coming from dot com OR dot.org) seemed to have been on an incremental path to limit user Link Management. The standard old Link Manager was disabled by default over two years ago, and now needs this plugin to be re-enabled: https://wordpress.org/support/view/plugin-reviews/link-manager.

      Also, I personally use “Open link in a new window/tab” every day, and wonder why the Core Contributors would want to stop offering that: https://toolbox-4-websites.com/design ?

      Why doesn’t WordPress just post a disclaimer on the homepages of both dot.com AND dot.org stating:
      “These are the things we DON’T want you to do with OUR SOFTWARE.”?

      • Ella Iseulde Van Dorpe 8:13 pm on June 8, 2015 Permalink | Log in to Reply

        The Link Manager is not related to the editor, and this is before my time. 🙂

        “Open link in a new window/tab” – I’m not saying we should remove it, just saying we should talk about it. In my humble opinion this should be the decision of the reader, not the writer.

    • Helen Hou-Sandi 5:21 pm on June 8, 2015 Permalink | Log in to Reply

      Leaving a note here to remind myself for tomorrow: I’d like to see if there’s anything we can do to make it smoother when views refresh after an undo. It’s pretty jarring right now and all the more obvious when undoing a text pattern format.

    • Robert Dall 5:31 pm on June 8, 2015 Permalink | Log in to Reply

      I personally like use and advise my clients to use the Word Count that is included in WordPress it helps me and them write content to a certain amount. Which has benefits to SEO. It small and unobtrusive if it’s not improved it should still be kept for these obvious advantages.

    • Julien 8:17 am on June 9, 2015 Permalink | Log in to Reply

      Regarding the inline linking mock ups, I personally feel that the one without dark overlay is best. It keeps the focus on writing and editing while when the overlay appears, I feel like doing something else and loosing my focus on the article. What do you guys think?

  • Ella Van Dorpe 5:34 pm on May 1, 2015 Permalink
    Tags: ,   

    Editor wish list for 4.3 

    This is a list with improvement we’ve been planning for 4.3 and beyond. It’s open for suggestions and discussion, and it will continuously be updated.

    • Improve the editor on mobile. – #29923
      • Contextual floating toolbar.
      • Fix touch and focus issues. – #31247
      • Improve the spacing around the editor?
      • Combine “Add Media” with any buttons added by plugins. – #29989
    • Save and update without a page reload. For this we will need to look into nonce refreshing. – #7756
    • cmd/ctrl+S should work in the text editor and when the visual editor is not focussed. – #31655
    • Fix word count. – #30966
    • Bullet list shortcut. – #31441
    • Drag and drop linked images, captioned images and views. – #28272, #28003, #28826
    • Caption placeholder. – #32175
    • Add tests for our TinyMCE plugins. – #31596
    • Remove old Distraction Free Writing? – #30949
    • Improve editor scrolling.
    • Better default editor styles. – #31253, #32176
    • Inline link form. – Mock ups from @joen. One step done.
    • Leaving dialog. – #28566

    Some things we started looking at for future releases:

    • Better structure for meta boxes. (needs tickets, mock ups)

    Anything you’d like to see in this release or would like to work on? Please leave a comment.

     
  • Morgan Estes 12:43 pm on April 19, 2015 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Howdy! Sorry, I dropped the ball last week so this week’s Weekly Roundup is a double issue — it covers April 4, 2015 [32003] to April 18, 2015 [32140].

    This week marks the release of RC1, which is the first release that many plugin authors and beta testers will test heavily. If you don’t already, now is a good time to check out the Alpha/Beta forums for any issues that crop up during this testing cycle.

    We’re only days away from the release of 4.2; let’s finish strong! 🏃👏 Here’s the rundown of recent changes:

    TinyMCE

    • Update to 4.1.9+. Changes:
      • Fixed bug where extra empty paragraphs would get deleted in WebKit/Blink due to recent Quriks fix.
      • Fixed bug where the editor wouldn’t work properly on IE 12 due to some required browser sniffing.
      • Fixed bug where formatting shortcut keys where interfering with Mac OS X screenshot keys. [32058] #31895
    • Disable the wp-autoresize plugin in iOS. All iframes there are already expanded to the height of the content document. [32095] #31937
    • Update the “Keyboard Shortcuts” modal. [32060] #29558
    • Fix our shortcuts on Mac, use Ctrl + Opt + letter. [32059] #29558
    • Use window.twemoji directly in the wpemoji plugin. Gives a chance to the browser to lazy load twemoji.js when reloading the page. [32142] #31901
    • Remove the empty paragraph that sometimes is left over after adding an image caption. [32141] #32003

    wpView

    • Remove selected views when inserting content but not when loading all content, and remove the ref. to the selected view node on resetting the views. [32140] #31998
    • Resize sandbox iframes on load. [32056] #31480
    • Empty the content in the timeout, so it doesn’t render iframes twice. [32022] #31669

    Build/Test Tools

    • During PHPUnit tests, don’t autodetect permalink structure during WP installation. [32139] #31994
    • Move the built media JS files up a directory to their previous location and naming convention. [32125] #31912 (see [31373])
    • Don’t reference underscore.js source map. [32065] #31477

    General/Misc.

    • WordPress 4.2-RC1 [32137] [32138]
    • Use HTTPS URLs for codex.wordpress.org. [32116] #27115
    • Explain all placeholders in translator comment, not just the first one. [32111] #31675
    • Ensure post title input is not shortened for non-public post types. [32071] #30968
    • Improve handling of incomplete From and Content-Type headers in wp_mail(). [32070] #30266
    • wpLink: always show the URL field at the top. [32017] #28206
    • Force default avatar for HiDPI avatars on Discussion Settings. [32129] #31972

    Translation and Strings

    • Merge strings that describe the same command. [32078] #31776
    • Update placeholder for FTP credentials. [32077] #31922
    • After [31941], use the decoupled strings from wp-admin/network/themes.php in wp-admin/network/site-themes.php as well. [32029] #28502
    • Correct grammar when referring to “a user” vs “an user” in several places. [32025] #31894

    Administration

    • Fix flickering of the admin menu on over-scrolling. [32089] #30900
    • Dashboard: Ensure images other than avatars (such as emoji replacements) in recent comments are not incorrectly positioned. [32076] #31919
    • Admin menu: fix colors for focus state and in IE8. [32075] #31345
    • Dismissible notices: more precise positioning across browsers. [32068] #31233
    • Reset padding for buttons in theme details modal. [32128] #31963
    • Revert [32099] per discussion in #core. [32100] #30900
    • Remove z-index from #adminmenuback. [32099] #30900
    • Don’t print the custom-background class in body_class() when a default color is in use. [32081] #28687
    • Toolbar: Search item consistency for focus state and IE8. [32074] #31322
    • Pointers: Make the dismiss icon a consistent size. [32069] #31915
    • Update more instances of default admin blues and grays. [32051] #31234

    Emoji and Smilies

    • Tweak which smiley matches which emoji. [32105] [32107] #31709
    • Update our few remaining smilies to better align with Twemoji, and add frownie.png until Twemoji provides a build containing it. [32104] #31709
    • The emoji JS files should be run through the script_loader_src filter, as they would be if they were registered scripts. [32097] #31938
    • Tidy up the wp_encode_emoji() regex, and clarify the function comment on Unicode 8 support. [32096]
    • Remove an errant / in Twemoji URLs. [32024] #31893
    • Remove executable bit from smilies. [32109] #31709

    Themes

    • Twenty Fourteen: update editor styles to better account for adaptive images in small screens. [32094] #31934
    • Twenty Fifteen: update editor styles to better account for adaptive images in small screens. [32090] #31934
    • Theme Compat: Make string translatable and add translator comments. Added in [31941]. [32084] #28502, #31921
    • Move initialization of $customizeSidebar to api.ThemesSection.initialize() to prevent cases where the result can be undefined. [32119] #31793
    • Translator comment should just reference placeholder numbers, not the actual placeholders. [32112] #31675
    • Tell developers how to correctly silence register_sidebar() notices. [32110] #31675

    Customizer

    Theme Switcher

    • Fix some esoteric breakage in iOS Safari. [32103] #31794
    • Don’t deactivate section on empty search results. [32083] #31889
    • Remove “Add New” reference from customize-controls.js. [32004] #31837
    • Use text input for the search field to prevent double tap issues for Preview and Customize buttons on iOS. [32127] #31794
    • Don’t re-render a theme control if it has already been rendered.
    • Lazy load theme screenshots. [32088] #31793
    • Fix tabbing order if section is open. [32087] #31289
    • Fix preview URL for subfolder installs. [32086] #31896

    Shiny Updates

    • Disable shiny updates from modal based on parent window [32082] #31739
    • Fix logic for details based shiny updates. [32080] #31739
    • Disable modal initiated shiny updates on wp-admin/update-core.php. [32067] #31739
    • Use dashes instead of dots as separator for jQuery events in shiny updates . is used for namespaces, so better to use dashes. [32063] #31819
    • Trigger events upon the completion of a shiny update. [32061] #31819
    • Remove Shiny Bulk Updates. Bulk updates don’t need to be ajaxified so let’s revert. [32053] #31770, #29820
    • Conditionally add AYS to leaving shiny updates. [32052] #31769
    • Enable users to initiate a shiny update from plugin detail modal. [32062] #31739

    Media

    • Don’t allow whitespace-only image captions from the Media modal. [32079] #21848
    • Fix focus and selected state for the selected attachments set. [32072] #31898
    • Rename get_media_embedded_in_content_allowed filter tomedia_embedded_in_content_allowed_types. [32113] #26675
    • Bring back spinners, now without bouncing select elements. [32101] #22839, #30725
    • Fix the media modal Insert into post button on narrow screens by limiting the width of .media-toolbar-primary and .media-toolbar-secondary only inside .attachments-browser (the top toolbar). [32121] #31908
    • Insert from URL: Make sure the link text is actually used. [32055] #29476
    • Make sure the spinner in the media modal is visible on narrow screens (without affecting the media grid). [32120] #30725

    Build Tools

    • Don’t override minified libraries included in core. [32066] #31477

    Docs

    • Remove unnecessary inline @see tags from a variety of parameter and return descriptions in wp-includes/wp-db.php. [32050] #31888
    • Remove unnecessary inline @see tags from the wpdb::process_field_charsets()DocBlock. [32049] #31888
    • Add a missing return description for has_header_image(). [32048] #31888
    • Fix a variety of inline documentation syntactical issues in wp-includes/taxonomy.php. [32047] #31888
    • Add a missing @access tag to the DocBlock for the WP_Meta_Query->$clauses property. Also adds a missing return description for WP_Meta_Query::get_clauses(). [32044] #31888
    • Add a variety of missing descriptions and fix syntax for wp_scripts(),_wp_scripts_maybe_doing_it_wrong(), and wp_script_add_data(). [32040] #31888
    • Remove an unnecessary inline @see tag and document the $wpdb global in two WP_Comment_Query methods. [32038] #31888
    • Add missing parameter and return descriptions to WP_Customize_Widgets->filter_customize_dynamic_setting_args(). [32036] #31888
    • Add parameter and return descriptions for WP_Customize_Widgets->get_setting_type(). [32035] #31888
    • Add missing @access tags to two DocBlocks in WP_Customize_Setting. [32034] #31888
    • Document the $theme property in WP_Customize_Themes_Section. Also adds a missing@access tag to the DocBlock for WP_Customize_Themes_Section->render(). [32033] #31888
    • Cleanup DocBlock syntax, add a missing parameter description for WP_Customize_Manager->set_post_value(). [32031] #31888
    • Add inline doc syntax fixes for WP_Customize_Manager->doing_ajax(). Also adds a return description. [32030] #31888
    • Add documentation for the $type and $theme properties in WP_Customize_Theme_Control. Also add some missing @access tags to various DocBlocks. [32028] #31888
    • Fix description alignment for the category_css_class filter docs. [32026] #31888
    • Add documentation for the $type, $mime_type, and $button_labels properties in WP_Customize_Media_Control. [32023] #31888
    • Clarify the DocBlock summary and parameter description forwp_edit_attachments_query_vars(). [32019] #31888
    • Add proper descriptions for the @global and @param tags in the wp_media_attach_action() DocBlock. [32018] #31888
    • Clarify the DocBlock description for wp_print_request_filesystem_credentials_modal(). [32016] #31888
    • Clarify 4.2.0 changelog entry, add global description to the DocBlock for WP_Users_List_Table->single_row(). [32015] #31888
    • Add missing @since versions from a variety of methods in WP_Press_This. [32014] #31888
    • Add missing DocBlocks for the _limit_array(), _limit_string(), _limit_url(),_limit_img(), _limit_embed(), and _process_meta_entry() utility methods in WP_Press_This. [32013] #31888
    • Add a return description to the DocBlock for WP_Posts_List_Table->is_base_request(). [32009] #31888
    • Add an @see mention for Plugin_Upgrader, plus spacing to the wp_ajax_update_plugin()delcaration. [32006] #31888
    • Add a more descriptive function summary for options_discussion_add_js(). [32005] #31888
    • Fix Docblock syntax for the taxonomy_parent_dropdown_args filter. [32003] #31888
    • Add a missing return description for wp_styles(). [32041] #31888
    • wp_install_maybe_enable_pretty_permalinks() should have a consistent @return value. [32027] #6481, #31888

    Help/About

    • All strings are available for translation. [32132] [32135] [32136] #31929
    • Change the subhead strings on credits.php and freedoms.php to match about.php.
    • Link the Emoji Codex article in the emoji blurb.
    • Add a second sentence to the JavaScript Accessibility blurb.
    • Switch positions for the JavaScript Accessibility and Complex Query Ordering sections for balance. [32131] #31929
    • Update about page for 4.2. [32118] [32123] [32130] #31929

    Upgrade/Install

    • Move wp-plugin-update-success event to after lock is released [32133] #31978, #31819
    • Use named function instead of anonymous function, making it testable and replaceable. [32126] #31964
    • When dbDelta() is checking whether an index is defined in a CREATE TABLE statement, don’t worry if MySQL has a subpart defined on an index, but the CREATE TABLE doesn’t. [32108] #31869

    Script Loader

    Press This

    • Do not show the bookmarklet upgrade notice when accessing directly press-this.php. [32122] #31968
    • Add mb_strlen() compatibility function. Works the same way as the existing mb_substr() compatibility function. [32114] #31951
    • Check the bookmarklet version and add the update notice from PHP. [32106] #31942
    • Add ARIA attributes to the alerts container. [32102] #31942
    • Fix focusing the Standard Editor link after saving draft, if the user has not focused another element. [32098] #31923
    • Change the link text to Standard Editor. [32093] #31923
    • When saving a draft change the text of the Save Draft button to “Saving…” [32092] #31923
    • Update documentation for press_this_save_redirect filter after [31992]. [32143] #31996

    Taxonomy

    • wp_update_term() should check if get_term() returned null. [32117] #31954
    • Avoid an unexpected object error when syncing global terms. Pass the expected single value, rather than object, when recursively calling global_terms(). [32064] #31914, #31149

    Editor

    Thanks to @adamsilverstein, @afercia, @awbauer, @azaozz, @boonebgorges, @DavidAnderson, @dimadin, @dlh, @DrewAPicture, @ericlewis, @hauvong, @helen, @hugobaeta, @iseulde, @jamescollins, @jeremyfelt, @joemcgill, @joen, @johnbillion, @jorbin, @kraftbj, @lancewillett, @markjaquith, @mattheu, @Michael-Arestad, @mindrun, @morganestes, @nacin, @nitkr, @obenland, @ocean90, @pavelevap, @pento, @peterwilsoncc, @samuelsidler, @SergeyBiryukov, @siobhan, @sirbrillig, @slobodanmanic, @swissspidy, @tmatsuur, @Tmeiste, @tyxla, @valendesigns, @westonruter, and @wonderboymusic for their contributions!

     
  • Pascal Birchler 3:37 pm on March 13, 2015 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi everyone, and welcome to this week’s installment of WordPress Core Weekly – covering March 5 2015 [31621] through March 13, 2015 [31764].

    If you want to write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    WordPress 4.2 Beta 1

    In case you missed it, the first beta of WordPress 4.2 was released yesterday! Read the announcement post for a quick overview of all features (emojis! 🎉🎉) and be sure to test it extensively.

    Code Updates

    General

    TinyMCE

    • Abstract the code for creating floating toolbars. Introduce editor.wp namespace to hold exported methods from our plugins. [31725] #30619
    • Hide TinyMCE help button on mobile. [31718] #31161
    • Update TinyMCE to 4.1.9. [31700] #31551
    • TinyMCE: when pasting an URL over a selection, insert a link with the URL instead of replacing the selection with it. [31691] #31571
    • In the modal state for Embed previews, only show the Title field when the preview fails. [31632] #29476

    Upgrade/Install

    • Shiny Updates: Disable body scrolling when filesystem request modal is open. [31753] #31607
    • Shiny Updates: Don’t translate an error code string. [31751] #31606

    Posts, Post Types

    • Allow is_page_template() to accept an array, as many other conditional tags do. [31754] #31271
    • Introduce a new algorithm for displaying a hierarchical list of post objects in the WP_Posts_List_Table. This reduces processing time, reduces database queries, and substantially reduces memory use on sites with a high number of Pages. [31730] #15459

    Press This

    • Remove obsolete help tab in Settings -> Writing. [31743] #26794
    • update _limit_url(), use esc_url_raw(). [31737] #31373
    • Filter and select the content on the PHP side. Then pass only the needed data to JS. [31693] #31373
    • Add preview functionality. Opens the preview in a new window or a tab next to the source tab. [31654] #31458

    Media

    • EXIF/IPTC captions should populate Caption (post_excerpt) on upload, not Description (post_content). [31694] #22768
    • Introduce a function, wp_attachment_is( $type, $post = 0 ), to collapse the logic for determining whether an attachment is an image, audio, or video. [31645] [31670] #25275

    Widgets

    Feeds

    External Libraries

    Plugins

    • Plugin details: Ensure banner image doesn’t repeat. [31719] #30773

    Embeds

    Customizer

    • Return the original value when filtering theme mods/options and the current blog has changed. [31707] #31428
    • Prevent a race condition when attempting to publish too soon after updating widget form fields with multiple edits. [31706] #31501
    • Fix previewing and applying widgets when previewing another theme. [31705] #31484
    • Introduce WP_Customize_Media_Control, a new base class for all Customizer media controls. [31698] #29215
    • Add loading indicators for the Customizer preview. [31697] #31196
    • Add audio/video previews for upload controls. [31661] #30850

    Comments

    • Improved customizability for the Submit button in comment_form(). [31699] #15015
    • Comments: Show more identifying information for moderation and editing. [31641] [31695] #23988

    Administration

    • Screen Options: Improve items per page option label. Add a default label “Number of items per page:” to WP_Screen->render_per_page_options() and remove all the existing one-word labels. [31696] #31349, #15576
    • Theme Details: Hide admin toolbar on smaller screens. [31702] #31381
    • Star ratings: Use a yellow color across the board. Keying these to color schemes originally turned out to be weird. [31747] #31424
    • Remove single-use URL parameters and create canonical link based on new URL. [31736] #23367
    • Allow swiping of the admin menu on touch devices. [31720] #31187
    • Restore <title> tag on Posts and Pages screens after [31696]. [31709] #31349
    • Replace flagrant instances of .html(”) with .empty(). [31690] #27034
    • Nav menus: Return to calling links “Custom Links”. [31748] #31344

    Networks and Sites

    • Introduce delete_site meta capability. [31673] #30470
    • Return HTTP status code 403 in network admin when access is forbidden. [31658] #31422
    • Return HTTP status code 500 by default in ms_not_installed() [31657] #30002

    Query

    Users

    • Improve experience when deleting users from a multisite network. [31656] #18132

    Bundled Theme

    • Twenty Fifteen: add ARIA attributes to menu toggle. [31644] #31527

    Thanks to @adamsilverstein, @afercia, @azaozz, @batmoo, @beaulebens, @bendoh, @boonebgorges, @celloexpressions, @codix, @coffee2code, @craig-ralston, @dd32, @doublesharp, @DrewAPicture, @elliottcarlson, @ericlewis, @Fab1en, @HarishChaudhari, @helen, @hugobaeta, @iandunn, @Idealien, @iseulde, @jeremyfelt, @jesin, @jipmoors, @joen, @johnbillion, @jorbin, @kraftbj, @lancewillett, @LeoPeo, @mattheu, @mattheu, @MattyRob, @Michael-Arestad, @MikeHansenMe, @miqrogroove, @morganestes, @morpheu5, @mkaz, @nacin, @netweb, @ninnypants, @nofearinc, @obenland, @ocean90, @OriginalEXE, @pavelevap, @pbearne, @pento, @peterwilsoncc @podpirate, @rachelbaker, @rodrigosprimo, @scott.gonzalez, @seanchayes, @senff, @SergeyBiryukov, @SergeyBiryukov, @stephdau, @stevenkword, @swissspidy, @thaicloud, @thomaswm, @tyxla, @valendesigns, @westonruter, @wonderboymusic, and @yo-l1982 for their contributions!

     
  • Samuel Sidler 4:40 pm on February 27, 2014 Permalink
    Tags:   

    Feature Plugin Chat on March 4 

    As mentioned at this week’s and last week’s meeting, we’re going to be holding a feature plugin chat on March 4 2014 21:00 UTC. If you have an idea for a new feature, this will be a great opportunity to bring it up and find others interested in helping out. In fact, just like we’ve done before, post your feature ideas here.

    Please leave one comment per feature idea with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • A list of those involved or already interested in your feature plugin (including you!)
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    This post and the accompanying chat is for posting ideas that you’d be interested in working on. It is not for posting every feature idea you have for WordPress.

    Current feature plugin leads: Please post an update for your plugin here, along with the information above.

    See you all at the chat!

     
    • scotthack 4:52 pm on February 27, 2014 Permalink | Log in to Reply

      I’d like to see a plugin built that will accept an XML file to import custom post types and taxonomies. That way theme authors can just provide an XML file with their themes. Then the end user can use the import file to create custom post types and taxonomies and it would be imported independent of the theme.

      This is in the idea stage. My coding skills are very basic, so I’d be of little to no help in the coding department. It would need to be picked up by a competent programmer to actually see it through. I’m only able to help with testing, feedback, and idea conception.

    • UaMV 5:33 pm on February 27, 2014 Permalink | Log in to Reply

      Extend proper author/contributor support when defining custom post types. Currently, when a CPT is registered with support for ‘author’, the metabox returns a list of users with the author role (even if those users don’t have ‘edit_posts’ capability for the CPT. Even in the standard post editor, the author metabox includes only users with an author role, not necessarily those who can contribute (or have edit_posts capability). I believe this metabox should return any user that has the ‘edit_posts’ capability for the specific post type in which the author metabox is being supported.

      There is currently a plugin, Authors Autocomplete Meta Box, in the repository that extends this functionality.

      Rachel Carden (aka bamadesigner) is the author of this plugin (commissioned by ereleases.com). I have, as of yet, had no contact with her regarding the plugin, but find it of great use on my site with multiple CPTs and multiple custom roles.

      Not sure at the moment how I might assist.

    • Avryl 6:36 pm on February 27, 2014 Permalink | Log in to Reply

      The Front-end Editor is a plugin that allows posts to be edited on the front-end (so it’s really WYSIWYG) and aims to have all the features available that the back-end editor has.

      It’s currently in development on GitHub and updates a posted weekly on the UI blog.

      I’m the project lead (@avryl) and those who are involved or have shown interest are @azaozz, @brainstormforce, @bravokeyl, @gcorne, @helen, @henrywright, @hugobaeta, @joen‎, @kraftbj, @markjaquith, @melchoyce, @mrahmadawais, @obenland, @protechig‎, @rafaelxt, @rhurling‎, @roundhill, @samuelsidler, @shaunandrews, @tillkruess, @ubernaut, @wholegraindigital and others.

      If you’re interested, take a look on GitHub and join our Skype chat. The next meeting will be Tuesday, 4 March 2014, 17:00 UTC in #wordpress-ui.

    • Chris Reynolds 12:46 am on February 28, 2014 Permalink | Log in to Reply

      AH-O2 (aka Admin Help) is venturing to reimagine the help system in the WordPress admin.

      It’s currently in development is on GitHub with updates being pushed weekly to the WordPress plugin repository. Updates are posted to the Docs and UI P2s.

      I’m the project lead (@jazzs3quence) and other contributors and folks who’ve been involved one way or another are:
      @brainfork, @trishasalas, @jdgrimes, @ubernaut, @zoerooney, @ninnypants, @mdbitz, @clorith, @nikv, and @veraxus

      We need help with:

      1. Documentation — new tooltips are being added to every admin page. Coders (the folks adding them) != writers, so many of these need to be (or will need to be) reviewed, fixed, updated or written. Also, it’s been pointed out that the help overviews we’re building — which replace the help tabs — may not be best suited for the existing documentation in the help tab (which we’re currently pulling from). So help documentation for those areas may need to be edited/changed/added/removed/etc.
      2. Coders — tooltips are added with javascript (and a little php, just to add the translatable string) but fear not! It’s really easy and repetitive. With about 10 minutes of guidance I think I can walk just about anyone through the process of adding a tooltip.
      3. Testers — please break our stuff (and create tickets)! https://github.com/jazzsequence/WordPress-Admin-Help/issues
      Also, extra brownie points to anyone who can test existing, open tickets to confirm/deny a behvior that has an open ticket.

      We meet weekly in #wordpress-sfd on Monday 18:30UTC.

    • Greg Ross 7:50 pm on March 4, 2014 Permalink | Log in to Reply

      The Admin Theme Experience is an update to the existing admin theme system to try and match the site theme user interface. It has two primary goals; simplify the creation of admin color themes and bring the Site Theme Experience to admin themes.

      Current plugin status: under development

      A list of those involved or already interested in your feature plugin: Me!

      What you’d like help with: Anyone with knowledge of the current site theme code would be helpful.

  • Samuel Sidler 11:15 pm on August 14, 2013 Permalink
    Tags: , ,   

    Present your 3.8 feature idea at tomorrow’s meeting 

    Tomorrow’s WordPress 3.8 meeting at Thursday 18:00 UTC is a great time to present your feature idea to the community. Many groups have already started forming around different ideas.

    Comment on this post with a group name to add your group to the list of projects presenting tomorrow. Make sure you bring the following things with you:

    • What problem(s) are you trying to solve?
    • What proposal solution(s) are you interested in exploring?
    • When and where is your group communicating?
    • Who has joined your group so far?
    • If you’ve selected someone to lead your group, who is your lead?
    • If you’ve already started work on your plugin, bring a link to your plugin page.

    See you tomorrow!

     
    • Matt Mullenweg 11:21 pm on August 14, 2013 Permalink | Log in to Reply

      And as many mockups / visuals / links to existing solutions as possible.

    • tomdryan 12:23 am on August 15, 2013 Permalink | Log in to Reply

      It’s not a feature per se, but is there a group looking at global usability improvements throughout WP that would make using WP a more pleasant experience, especially for new and casual users?

      I would happy to lead or participate in such a Usability group.

      • Sam Sidler 12:25 am on August 15, 2013 Permalink | Log in to Reply

        In general, I think you want the UI group. Minor usability updates can take place in any release cycle, including 3.7.

    • Justin Sternberg 12:31 am on August 15, 2013 Permalink | Log in to Reply

      I’m not ready to claim a big-picture group, but we at WebDevStudios have put some time and effort into re-thinking the admin’s widget admin page.
      A good post summarizing our vision, and some proof of concept mockups: http://webdevstudios.com/2013/08/14/webdevstudios-take-on-a-wordpress-core-widget-ui-refresh/
      Our p2 for discussion around the subject, open to the public:
      http://core.webdevstudios.com/
      A github repo with the skeleton of a plugin for iterating:
      https://github.com/WebDevStudios/WordPress-Widgets-Refresh

      There are also other discussions revolving around the subject both new and old.
      Shuan Andrew has some really intriguing thoughts & mockups and even a prototype:
      http://www.shaunandrews.com/
      & has posted a survey for the subject on this blog:
      https://make.wordpress.org/core/2013/08/14/howdy-everyone-theres-been-a-lot-of-discussion/

      Ipstenu has two posts discussing the subject (which we based a lot of our ideas on):
      https://make.wordpress.org/core/2013/08/08/excellent-3-8-brainstorm-session-today-people-talked-about/#comment-9697

    • shaunandrews 12:39 am on August 15, 2013 Permalink | Log in to Reply

      I’ve been thinking a lot about widgets, menu’s, post-formats-as-content-blocks, and a grid-view for the media library. A few links to share for tomorrow:

    • Konstantin Obenland 12:56 am on August 15, 2013 Permalink | Log in to Reply

      Featured Content.
      It is part of Twenty Fourteen and it would finally provide a canonical solution that is portable between themes. I talked to a lot of people in the last week, the group that has assembled around it is fairly impressive, and @wonderboymusic has already updated the base plugin with a first proposal.

    • Ryan McCue 2:30 am on August 15, 2013 Permalink | Log in to Reply

      JSON REST API.

      Working on it for now as part of GSoC, which means only I can write the core code for it at the moment, but there’s tonnes of extras around it that need doing until GSoC ends, and plenty of feedback to get at this stage. @japh, @jshreve, @mzaweb, @mordauk, @coenjacobs, @markoheijnen have all expressed interest in this for 3.8, plus @bpetty and @ericmann who are my current mentors.

      • Ryan McCue 2:35 am on August 15, 2013 Permalink | Log in to Reply

        GSoC’s pencils down date is September 23 (about 6 weeks away), which is when I’ll call the GSoC part done and move on to the core project part. In the meantime, anything out of scope is free game, including multisite, further JS API work, integrated unit tests, and any other new APIs (options? widgets?).

      • Japh 2:36 am on August 15, 2013 Permalink | Log in to Reply

        Yep, would love to get in on this one.

      • Andrew Nacin 3:13 am on August 15, 2013 Permalink | Log in to Reply

        I think this will need more time. Which, by the way, is completely OK. Let’s just be wary of saying “for 3.8” — it should remain as a plugin until it and core are both ready.

        • Ryan McCue 3:58 am on August 15, 2013 Permalink | Log in to Reply

          Definitely. I’d like to push hard to get it ready for 3.8, but if it ends up slipping then that’s not a big deal, IMO.

        • Bryan Petty 3:58 am on August 15, 2013 Permalink | Log in to Reply

          Right, definitely, but worth mentioning that it could be awesome to see a large focus on this with a full team and lots of eyes.

          This probably should not be happening, but I know there’s at least one mobile project putting bets on this making good progress quickly.

    • Matías Ventura 3:19 am on August 15, 2013 Permalink | Log in to Reply

      Theme Experience for 3.8 and beyond, or THX38 for short.

      To significantly improve and re-imagine the admin theme screens for a better user experience. More beautiful, visually focused, fast, and up to date with the current times of mobile ubiquitousness, flexible resolutions and retina devices. Aiming to bridge the admin themes.php and the .org directory experiences, so that searching for and installing a theme is equally rewarding and consistent no matter where you start. Initial thread. Anyone who is up for this, please, chime in.

    • Mel Choyce 2:37 pm on August 15, 2013 Permalink | Log in to Reply

      Content Editing User Experience (CEUX)

      This group will be focused around streamlining and improving the overall content editing experience in WordPress. We’ll be exploring better methods for curating and formatting content within the post and page editors. We have a preliminary set of mockups that we’ll be expanding and iterating on as we start.

      Currently involved in this group are @wonderboymusic, @saracannon, @DavidHickox, and to a lesser extent @joen will be contributing feedback and ideas. We’ll also be communicating closely with the Page + Menu team. @jenmylo has graciously agreed to advise this group. We’ll be working out a time and place for meetings shortly.

      The content blocks plugin has been set up here.

    • jacob.dubail 3:47 pm on August 15, 2013 Permalink | Log in to Reply

      I was bummed that I missed the last 3.8 meeting. Hoping it’s not too late to get involved. See ya’ll online in a couple hours.

    • Siobhan 5:19 pm on August 15, 2013 Permalink | Log in to Reply

      Admin Help

      This group will focus on creating useful help for WordPress users within the admin. We’ll start by conducting research into the problems that users are having, and research into the tools available to us. We’re also looking into how other platforms implement admin help. Once we have identified the problem we will select the right tools and get to work with mockups then plugin. We have put together some specs for the project, started work on user testing, and looking at tools.

      So far involved in the group are: me, @trishasalas, @jazz3quence, the docs team, and we will be getting input from the accessibility team. Other people who expressed an interested are @japh, @ipstenu, @dllh, @JerrySarcastic, @kimparsell We’ve been using make/docs for discussions so far (under the admin help tag), and will set a regular time for meetings soon.

    • George Stephanis 6:08 pm on August 15, 2013 Permalink | Log in to Reply

      Omnisearch!

      jetpack.me/support/omnisearch

      • George Stephanis 6:26 pm on August 15, 2013 Permalink | Log in to Reply

        DNS has been sketchy, so wanted to get a slug in first.

        History:

        Back when working on 3.5, @lessbloat worked up a new Welcome Screen that we worked on. In the trac ticket, #21368-core, @rhc3 mentioned his Hopscotch plugin that indexed the page’s links to provide suggestions and autocomplete for when someone was having a hard time tracking down what they wanted to do in the menu. It also included hooks to let third parties offer results as well. Some of this functionality was later duplicated by Japh Thompson of Envato, as a part of WP Butler.

        The search functionality wound up getting sacked, but I’ve had the idea of a ‘search-everything’ field in my mind ever since then.

        I built it out, wound up rolling it into Jetpack as a central core, to quickly iterate and make available but it’s built extensibly so any plugin can provide results. I think it’s a terrific UX win, and would like to test it and offer it for inclusion into core.

        • Japh 10:24 pm on August 15, 2013 Permalink | Log in to Reply

          I’d like to be involved with this (obviously, as I built WP Butler to serve a similar function)
          🙂

    • MartyThornley 6:10 pm on August 15, 2013 Permalink | Log in to Reply

      I started a quick plugin as a proof of concept ( very early ) for rethinking the user and site signup and login process, especially concerning multisite. The idea is to consolidate and streamline it all. Also, to make things easier, make the urls more friendly – with /signup, /signin, /signout. https://github.com/MartyThornley/better-signups

    • @ubernaut 6:14 pm on August 15, 2013 Permalink | Log in to Reply

      here’s an idea which may be too crazy and it’s very basic so far no mock ups or anything but basically it to as much as possible do away with the distinction between front end and back end. Inspiration of this idea belong to Matt’s 2013 Stat of the Word speech and the problem of blog abandonment also some belongs to the existence of p2 as well.

      i have found that when teaching people that are new to wp that dichotomy between front and back end (which makes perfect sense to me btw) is a tumbling block and doing away with it may be very beneficial for learning curve.

      Obviously there are some task and admin stuff that would still need to exist but i think it could be very limited fro many user roles.

      • Avryl 12:45 am on August 16, 2013 Permalink | Log in to Reply

        @ubernaut I’d really like to help with this in any aspect. Who’s currently working on this? Are the people here still interested?

        • @ubernaut 5:23 pm on August 16, 2013 Permalink | Log in to Reply

          Great! Well trishasalas also expressed interest and George Stephanis also agreed to help me break down my idea to see exactly what it would take.

          Right now i’m just taking a day or two to think out the different aspects of how i invasion the all to work. mainly the idea i think in my head at least at this point is basically bring all the tools normally only accessible in the admin area to the front end via sort of context sensitive modal overlays.

          i guess i wanted to throw together a few simple mockups together so people could see what i’m thinking. I’m going to try to get a thread started so it will be easier to collect our thoughts on the will update here with a link once i have that going.

      • paaljoachim 2:54 pm on August 19, 2013 Permalink | Log in to Reply

        Frontend editing is an area that really needed to make things easier in learning about how to use WordPress. I helped a friend of mine who uses wix.com and it uses the frontend to edit the page. Wix is more basic but it has two important features: Easy for the user to select a skin/theme/template and from there they use the frontend to edit the skin. There is a video showing some of this on their web site. Incorporating backend features into the frontend is as see it a must. I look forward to helping in whichever way that I can.

        • @ubernaut 10:23 pm on August 19, 2013 Permalink | Log in to Reply

          • paaljoachim 9:54 am on August 20, 2013 Permalink | Log in to Reply

            Hey ubernaut. I see your screenshots and my mind began thinking. I have posted the below on your web site as well:

            Thinking out loud about the process…
            WordPress installed.
            The first thing one sees is the default theme front page. A box up in the right corner to login. The user logs in. The dashboard bar shows at the top. Since it is the first login a link below the login box is seen: “tour the interface.” User clicks and a short video is seen.

            Showing:

            • How to select a theme from the front end. Perhaps a link all the way to the right of the Dashboard top bar with the name of “Choose Theme”. Click the link and see a drop down of small thumbnails and at the bottom of the drop down a see additional themes option. As the user moves the cursor over the thumbnails they are automatically bigger to the side of the drop down showing 2-3 fairly large screenshots with some key info below the screenshots. The user selects a theme and the front end automatically adjusts to show the theme selected.
            • Hover over elements on the page an outline is seen and one can click inside and an edit bar is seen.
            • Drag elements around to replace.
            • Turn on grid to align elements.
            • Click directly on an menu link to move to the page.
            • At the top Dashboard bar click the +New (OR use the Template button next to it to use an existing saved page) to create a post/page/category.

            A blank page is seen and blocks are seen on the right side (depending on if it is a post/page/category). Main elements – Header, menu, sidebar, content, footer.
            Elements (widgets, shortcodes, block elements all in one).
            One drags the various elements to create the page. Click the save button top right to the left of the login area. Beside it is the copy page button on hover it will say save as template.
            Create a new page – and at the top right – save, copy, use template button.

            A lot of these things can be very similar on the backend and frontend.

    • Helen Hou-Sandi 6:23 pm on August 15, 2013 Permalink | Log in to Reply

      New overall admin style, by way of MP6. I will serve as interim lead while MT is on sabbatical.

    • lessbloat 6:31 pm on August 15, 2013 Permalink | Log in to Reply

      Dashboard

      I plan to play around with some ideas for ways to update the dashboard. Perhaps simplify it a bit. Look at ways to possibly make it more easily extensible/customizable.

  • Mark Jaquith 11:10 pm on February 18, 2013 Permalink
    Tags: , , ,   

    A first draft of the Twenty Thirteen theme… 

    Screen Shot 2013-02-18 at 5.15.50 PM

    A first draft of the Twenty Thirteen theme is now in core, for your inspection and iteration. See: r23452

    A demo site is available for you to browse.

    @matt set the goals for this theme: a focus on blogging, and great support for post formats (which are getting attention on the backend in 3.6 as well). Under Matt’s guidance, @joen explored the artistic possibilities and was joined by @obenland and @lancewillett in bringing it to fruition.

    What you’ll notice first is the colors. Way more use of color than a bundled WordPress theme has had before. Each post format has its own color, so each is distinct, yet they are all complimentary. The bold colors encourage authors to try out all the different formats. This color extends the full width of the window, which breaks your blog up into a lush, segmented timeline. This effect is even more pronounced on mobile browsers, where the screen can be dominated by one or two posts at a time, in all of their chromatic fullness.

    On closer inspection, you’ll notice details, like the font-based icons (“Genericons”, by @joen) that scale up to any resolution or zoom level and can be easily recolored using CSS.

    You may notice some playful details, like the size-offset pagination arrows:

    Screen Shot 2013-02-18 at 4.52.23 PM

    Or the 404 page (which I’ll leave to you to find).

    One of the goals of having a new theme every year was to give ourself room to experiment. That hasn’t really happened. We’ve been far too conservative, trying to make themes that work reasonably well for everyone, but don’t push boundaries too much. That changes with Twenty Thirteen. It’s hard not to have a strong feeling about the theme, one way or another. It defies you to give it a shrug or a kurt nod. Some of you will hate it. And that’s okay. We’ll still be shipping Twenty Twelve, which is an excellent base theme and a canvas on which you can build anything from a blog to a static content site. But with Twenty Thirteen we’re taking a bold stance: this theme was meant for blogging, and it’s not a blank canvas. It comes pre-marinated with playfulness and warmth and opinions.

    Twenty Thirteen really prefers a single column layout. Widgets live best in the footer, where jQuery Masonry bricks them together (but it supports a sidebar, if you really insist). Header images have a fixed width and height, and will be cropped at smaller resolutions, so the best choice is an artistic header where not 100% needs to be shown all the time (it ships with three).

    Now that we have a first draft of Twenty Thirteen in core, it’s time to start iterating and sanding off some of the rough edges. Accessibility is still important, even when making bold artistic statements, and I’d be surprised if we didn’t have work to do there. We’ll need testing on lots of different browsers and platforms, and with lots of different plugins. @helen‘s Post Format UI team will need to give feedback on upgrading Twenty Thirteen to use the new post format API functions that are available.

    @lancewillett and @obenland will be holding Twenty Thirteen office hours on Tuesdays and Thursdays at 1700 UTC. Interested parties should make an effort to attend and help us get this beauty ready for beta!

     
    • Amy Hendrix (sabreuse) 11:18 pm on February 18, 2013 Permalink | Log in to Reply

      First impression: WOW

    • Michael Beckwith 11:18 pm on February 18, 2013 Permalink | Log in to Reply

      Holy color!

    • Alison Foxall 11:24 pm on February 18, 2013 Permalink | Log in to Reply

      Nice Mark!

      First thing I notice is that although the search bar sticks to the top with the Twenty Thirteen branding while you scroll, the main navigation is not up there with it on both large desktop screens and small device screens. Was there a reason for this or can this be changed by the user? And of course I\’m wondering if the user will be able to change those colors for each post format. 🙂

      • Mark Jaquith 2:26 am on February 19, 2013 Permalink | Log in to Reply

        It’s a known issue, and something I’d like rectified. The dropdown menu that you get on small screens would be great up there. And colors could be overridden by a child theme — probably a lot of option overload if we exposed that.

    • Mel Choyce 11:30 pm on February 18, 2013 Permalink | Log in to Reply

      WOW, instant love! The colors are bold but harmonious, the type is GREAT, and it’s got such a fabulous funky retro futurist feel. Thumbs up!

    • Emil Uzelac 11:34 pm on February 18, 2013 Permalink | Log in to Reply

      Pretty good for the first draft!

    • Xavier Borderie 11:46 pm on February 18, 2013 Permalink | Log in to Reply

      Wow indeed! I too was getting a feeling that the “clear white” theme spirit could feel overplayed if 2013 had it. I for one am very glad that the team is making such a bold move in a creative direction. I trust there will be enough theme option and color schemes so that users can make it their own in a few clicks.

      Great work!

    • aradams 12:10 am on February 19, 2013 Permalink | Log in to Reply

      Love the colors, love the flow. Nice to see creativity unleashed on the default theme!

    • Ipstenu (Mika Epstein) 12:13 am on February 19, 2013 Permalink | Log in to Reply

      Nice! Just … Amazingly nice. I’m gonna have to find a site to use that on. Maybe my own!

    • Marcel van der Horst 12:14 am on February 19, 2013 Permalink | Log in to Reply

      Can’t wait to try it out..

    • BrentLeavitt 12:22 am on February 19, 2013 Permalink | Log in to Reply

      I find that to be just delightful!

    • Aaron D. Campbell 12:23 am on February 19, 2013 Permalink | Log in to Reply

      So excited to have this in. It really is great!

    • Tony Scott 12:27 am on February 19, 2013 Permalink | Log in to Reply

      http://genericons.com/ seems to be behind a WP.com password.

    • Chuck Reynolds 12:32 am on February 19, 2013 Permalink | Log in to Reply

      Looking forward to the post format specific layouts and metadata.
      Would be nice if the video, once ‘fetched’, would autopopulate the title.

    • @mercime 12:50 am on February 19, 2013 Permalink | Log in to Reply

      Very Nice! Shades of BuddyPress 🙂

    • trishasalas 1:01 am on February 19, 2013 Permalink | Log in to Reply

      …beautiful, you’ve managed to stick with the mimimal yet spice it up with jazzy colors. Instant LOVE <3

    • Austin Passy 1:03 am on February 19, 2013 Permalink | Log in to Reply

      The theme demo looks great. Like the direction it heading in.

    • Jose Castaneda 1:09 am on February 19, 2013 Permalink | Log in to Reply

      Looking forward to testing the formats. Now to get home and uptade core.

    • Eduardo Zulian 1:36 am on February 19, 2013 Permalink | Log in to Reply

      Just finished testing Twenty Thirteen with the new post formats scheme. Sweet. : )

    • Lori Berkowitz 1:37 am on February 19, 2013 Permalink | Log in to Reply

      Looks great! Also nice to see some post formats love 🙂

    • Edward Caissie 1:39 am on February 19, 2013 Permalink | Log in to Reply

      Except for the header trick … sorry, it’s just not doing anything for me.

    • Anthony Hortin 2:00 am on February 19, 2013 Permalink | Log in to Reply

      It’s lookin’ great so far! Well done to all involved!

    • Matt Mullenweg 2:12 am on February 19, 2013 Permalink | Log in to Reply

      It’s counterintuitive because this is a visually much more aesthetically opinionated base than we’ve had probably since Kubrick, but I think we’ll see a lot more customization and variations on Twenty Thirteen than Eleven or Twelve. It’s a delightful canvas to play on.

    • Justin Sternberg 4:25 am on February 19, 2013 Permalink | Log in to Reply

      Nice work all around! I couldn’t help myself: http://jtsternberg.com/

    • Sovit - (Theme Horse) 5:37 am on February 19, 2013 Permalink | Log in to Reply

      This one will be the great example to show that without choosing white color can also make clean and beautiful theme. Love the way designer play the colors.
      Thanks to all contributors. Its really Fantastic ! Can’t wait to see it out in my themes directory.

    • Noel Tock 8:04 am on February 19, 2013 Permalink | Log in to Reply

      Love the new direction, looking versatile and fluid, +1

    • Ryan Hellyer 9:37 am on February 19, 2013 Permalink | Log in to Reply

      And here I was thinking that WordPress default themes need to be bland and white.

    • Petya Raykovska 9:50 am on February 19, 2013 Permalink | Log in to Reply

      Wow. Bold move, I love it.

      I’d make the main navigation sticky though, together with the search bar and the site name.

      And it would be great to have some color palettes to choose from as visually color is the first thing you experience with this theme.

    • emzo 10:06 am on February 19, 2013 Permalink | Log in to Reply

      Default WordPress themes have always been great, but they’ve needed to be versatile and cater to the majority, and in doing so have had to be more conservative. This puts the fun back into WordPress, and definitely brings a smile to my face. I do agree that the collapsed mobile menu should be placed in the fixed header when scrolling though.

    • Luc De Brouwer 10:55 am on February 19, 2013 Permalink | Log in to Reply

      This. Looks. Awesome.

    • lonchbox 12:14 pm on February 19, 2013 Permalink | Log in to Reply

      Excellent work! I love the post formats styles 🙂

    • sourceforge 12:59 pm on February 19, 2013 Permalink | Log in to Reply

      there was a theme in tumblr directory by peter vidani, which used the colors for post types!

    • Monika 2:01 pm on February 19, 2013 Permalink | Log in to Reply

      it looks like Windows8 🙂 colorful and dizzying.

    • mindctrl 2:12 pm on February 19, 2013 Permalink | Log in to Reply

      Nice and different direction. With this new bold approach, I’d like to see the base font size increased a bit more. Chrome is telling me it’s 16px, and with Source Sans Pro 16px looks more like 14px. It looks good and is easier to read at 18 or even 20px.

    • Aaron Aiken 2:50 pm on February 19, 2013 Permalink | Log in to Reply

      Absolutely beautiful. Good work!

    • Arnan de Gans 3:15 pm on February 19, 2013 Permalink | Log in to Reply

      Sponsored by Ubuntu I see…

    • Nashwan Doaqan 8:08 pm on February 19, 2013 Permalink | Log in to Reply

      It’s really a beautiful theme , but I don’t think It’s good to be a default theme ,It’s too colourful … Yes it’s different direction but many of WP users like the default themes because they are simple and have a less colours , I was thinking if you can make the colours system is optional in the theme control panel ….

      As I am seeing now , Its seems to be hard to use it as a framework , the default theme should be simple , clean , easy to customize and express WordPress main features !

      • Aaron D. Campbell 8:24 pm on February 20, 2013 Permalink | Log in to Reply

        Twenty Twelve will still be packaged with WordPress too. I do however think this theme will actually be pretty easy to extend.

      • Emil Uzelac 12:40 am on February 21, 2013 Permalink | Log in to Reply

        This is actually going to be a perfect default Theme and honestly, very easy to customize as well.

        Colors are post formats and they can be changed or removed 😉

    • Daniel 10:15 pm on February 19, 2013 Permalink | Log in to Reply

      Is there a reason why the fixed navbar replaces the navigation menu with the site title? Doesn’t that pretty much defeat the purpose of the fixed navbar to provide better accessibility to the site’s navigation? Why would I need a static bar with just a link to the front page?

    • David Radovanovic 12:37 am on February 20, 2013 Permalink | Log in to Reply

      ooooooooo, ahhhhhh – very awesome indeed! The long scrolling homepage, ever-adaptive elements, and I’m sure much more will be realized with a test drive. Thanks!! BTW – why the persistent header with banner on all pages? Am I alone in wondering why is the banner needed on pages other the homepage?

    • Jean-Francois Arseneault 5:35 am on February 20, 2013 Permalink | Log in to Reply

      Surprised to still see ‘Links’ in there as a post type…

    • shazdeh 9:03 pm on February 20, 2013 Permalink | Log in to Reply

      Love at first sight. 🙂

    • Zulfikar Nore 10:47 pm on February 20, 2013 Permalink | Log in to Reply

      Bold And Beautiful! A total change in direction from previous “Default” themes – this will make an awesome parent theme for developers to tinker with.

      Would like to chime in on the menu though….the sticky menu “bar” minus the menu is not doing it for me – I would like to see the menus as I scroll the page instead of a blank “bar”.

      Further more, since its bold in terms of color scheme – I would like to see the options to adjust the various sections incorporated in the Customizer’s Color section and not having to rely on changing them via child themes. As it is the child theme option would work for developer but not for the novice end user.

      But all in all, I’m totally loving what I see so far – now its time to go break it apart and see what I can conjure up 🙂

    • bjornsennbrink 9:48 am on February 21, 2013 Permalink | Log in to Reply

      What is up with the breaking of words in titles and in text? It was there in Twenty Twelve and is still around. Any insight on the word-breaking thingy would be great 🙂

    • alvarogois 2:58 pm on February 21, 2013 Permalink | Log in to Reply

      Strange unanimity… I’m a guy who likes color and bold, though I’m more for minimal. I don’t understand this theme and can’t picture it as a default WordPress theme. Maybe the focus here is on blogs, I get it, and giving the author a panoplia of customization options. I get it too. Nevertheless, I fail to realise how one goes from twentytwelve to this twentythirteen. Sure, it’s a cut, but I don’t see it as a step forward, something new, more like something else.

      (I could be wrong, though… me and Nashwan Doaqan up there…)

    • Marco Raaphorst 3:55 pm on February 21, 2013 Permalink | Log in to Reply

      cool, love it!

    • rilwis 5:32 pm on February 21, 2013 Permalink | Log in to Reply

      Amazing theme. I like it and have a good feeling when I see it at first. It’s great when you can push the boundaries so far. It’s time to show people that WordPress is easy to customize.

    • Brad Dalton 9:16 pm on February 21, 2013 Permalink | Log in to Reply

      Its like it or not based on my readers feedback. Personally i love it but also know you guys could seriously blow the socks off any premium theme out there. Built in hooks and conditional tags is where its headed i think. WordPress theme users are smarter now and want more. They understand the basics of coding. Extend further.

    • tomjanski 9:44 pm on February 21, 2013 Permalink | Log in to Reply

      The bold colors and bold theme. Bravo. It’s going to be a good one.

    • Shea Bunge 4:39 am on February 22, 2013 Permalink | Log in to Reply

      Wow… really, really good. It”d be nice to get the default theme out early this year. (I;ve always thought that the annual themes should be released at the start of the year, not the end 😉

    • lisafirke 3:34 pm on February 22, 2013 Permalink | Log in to Reply

      Gorgeous and playful. Bravo!

    • Tatiane Pires 3:06 pm on February 24, 2013 Permalink | Log in to Reply

      Great!
      I can’t wait to make a new theme for my blog based on Twentythirteen.

    • suzybyrnes 12:54 pm on February 27, 2013 Permalink | Log in to Reply

      love the full width. Agree with comments about fixed nav bar. Look forward to seeing what people do with it. Thanks v much.

    • bru.scopelliti 4:50 pm on February 27, 2013 Permalink | Log in to Reply

      What I have seen is very promising. Can’t wait the release

    • ecksteing 10:01 pm on February 28, 2013 Permalink | Log in to Reply

      Twenty Thirteen is absolutely beautiful. Love the use of differing colours per Post Format.

    • Hassan 8:04 pm on March 2, 2013 Permalink | Log in to Reply

      My first impression was color-shock!

      It reminds me of the new refresh of Windows.com after the release of Windows 8. Oh, and those arrows for Newer and Older Posts, It’s hard not to see the “Metro effect” there 😉

      Also, I love the theme!

    • Misha 5:37 pm on March 3, 2013 Permalink | Log in to Reply

      Oh, this theme is really nice on the whole! It’s interesting how it will look with a sidebar… I really need it.

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