WordPress.org

Make WordPress Core

Updates from Matt Mullenweg Toggle Comment Threads | Keyboard Shortcuts

  • Matt Mullenweg 5:32 pm on January 9, 2017 Permalink |
    Tags:   

    Aaron Campbell Leading Security 

    @aaroncampbell is now the new lead of security triage and resolution for the WordPress project, also known as the Security Czar. Many thanks to Nikolay Bachiyski for kicking this role off and getting a lot of the infrastructure we use in place. This is also a good time to thank the dozens of volunteers who participate in the security group, and the researchers and reporters who bring issues to our attention.

     
  • Matt Mullenweg 10:32 pm on January 4, 2017 Permalink |
    Tags: , ,   

    Focus Tech and Design Leads 

    There are three main focuses this year: the REST API, the editor, and the customizer.

    For the REST API we’re going to work on getting first party wp-admin usage of the new endpoints, and hopefully replace all of the core places where we still use admin-ajax.

    The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

    The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

    Each focus will have a tech lead, and a design lead, and I’ll be working closely with each to make sure we’re aligned and moving diligently in the right direction even though we don’t have the normal release hooks. These starting leads will be:

    REST API: Ryan McCue and KAdam White.

    Editor: Matias Ventura and Joen Asmussen.

    Customizer: Weston Ruter and Mel Choyce.

    Given there is no set timeline for releases that would normally set a term, these leads are free to bow out at any time they feel they can’t contribute fully and we’ll find a replacement.

    You might be wondering what each lead is responsible for. The REST team gave some thought to this for their focus, and this is the list they came up with:

    Tech Lead responsibilities:

    • identify and ensure implementation of first-class REST API usage within WP-Admin,
    • replacing/refactoring admin-ajax use.
    • overall REST API architecture
    • infrastructure and endpoint performance
    • security at an infrastructure and endpoint (data-exposure) level
    • improving authentication options and documentation
    • working with the Design Lead to build new, or expand on existing, endpoints
    • working with the Design Lead to address usability feedback for the infrastructure and endpoints

    Design Lead responsibilities:

    • usability of endpoints for internal or external clients
    • usability of the infrastructure from the perspective of a API client
    • working with the Editor and Customizer focus teams to collect requirements and gather feedback
    • identifying ways to improve the overall experience for folks building clients or consuming endpoints (like documentation)
     
    • Jon Brown 10:38 pm on January 4, 2017 Permalink | Log in to Reply

      This all sounds awesome and I’m excited to see the fruits of this new paradigm.

      I do have one technical question I haven’t heard addressed… how are these being handled code/repo wise?

      Otto can come after me with a whip… but wouldn’t each of these major efforts be much easier managed as separate git branches than with SVN’s patching/branching system? I just can’t wrap my head around ever being able to merge the results of each of those efforts independently any other way.

      I’m not trying to start yet another svn/git war… just asking, what’s the plan for the fruits of this effort being merged into trunk someday?

      • Matt Mullenweg 10:41 pm on January 4, 2017 Permalink | Log in to Reply

        It is super tempting to also want to change all our tools and workflows at the same time, but we shouldn’t try to innovate in too many areas at once. So no SVN / Git war today. ๐Ÿ™‚

        • Jon Brown 5:42 am on January 5, 2017 Permalink | Log in to Reply

          I guess my question wasn’t clear. What’s the plan?

          I totally understand the logic of not switching tools… The existing SVN patch paradigm seems unwieldly for anything this size. Is the plan to utilize SVN branches and merging? figured it out as we go?

      • Ryan McCue 1:33 am on January 5, 2017 Permalink | Log in to Reply

        As well as what @matt said, a lot of these pieces will (hopefully) tie in with each other quite heavily, and I expect we’ll all be working together a fair bit, so separate branches probably wouldn’t help. ๐Ÿ™‚

    • Tammie Lister 10:39 pm on January 4, 2017 Permalink | Log in to Reply

      Congratulations everyone leading! Really looking forward to seeing the focuses evolve.

    • Luke Cavanagh 10:40 pm on January 4, 2017 Permalink | Log in to Reply

      Seems an interesting change of focus for WP core. Where will other features as plugins stand, if they do not fit within the three main focus areas?

    • Scott Kingsley Clark 10:47 pm on January 4, 2017 Permalink | Log in to Reply

      I’d like to get the Fields API into the Editor focus if the meta boxes and fields on the screen fits into your definition well enough. There may be a lot of crossover between what the Fields API could take on and the remarks you’ve made above about the Editor focus which would make a great pairing.

      • Matt Mullenweg 10:51 pm on January 4, 2017 Permalink | Log in to Reply

        Could look at it later in the year, I think the first half will be focused on more foundational things.

        • Scott Kingsley Clark 10:59 pm on January 4, 2017 Permalink | Log in to Reply

          OK, I’m just concerned as we add new methods for adding structures that Fields API has even more work to be done in order to unify them. But glad you’re not opposed to it. I can rest soundly now ๐Ÿ™‚

      • Nick Halsey 12:13 am on January 5, 2017 Permalink | Log in to Reply

        On the other hand as the editor becomes integrated with the customize API via customize posts/broader live preview, the customize API could potentially be used directly for fields that manage any type of content throughout WordPress (this is already possible, but perhaps not obvious in terms of resulting usability). It’s probably best to wait and see where that heads before going too much further with a separate fields API.

      • Marcus 12:13 pm on January 5, 2017 Permalink | Log in to Reply

        I think Fields API is one of those things that is getting overlooked, yet would benefit the project so greatly by providing standards and consistency for developers working with WP.

        From the consistency/standardization point of view, I envisage similarities with how the introduction of Custom Post Types created a standard for content other than regular posts/pages.

        Whilst I don’t know much about the Customize API, I think Fields API make an awesome foundation for fields used in any other API or UI.

        • Scott Kingsley Clark 1:30 pm on January 5, 2017 Permalink | Log in to Reply

          I imagine that the Customizer API would ultimately fetch configurations from the Fields API to make use of them in its own context, but that Fields API would stretch across WordPress beyond things that need previewing.

          • Marcus 2:39 pm on January 6, 2017 Permalink | Log in to Reply

            Exactly! Everything on WP uses fields for gathering info; plugins, themes, customizer, core… yet each implementation handles it in its own way. A single API for this will help in so many ways.

      • Jon Brown 8:17 pm on January 6, 2017 Permalink | Log in to Reply

        +1 on getting the Fields API into the Editor focus. It seems to make sense that content blocks would use the Fields API and both would become available to the customizer.

    • Rachel Baker 11:01 pm on January 4, 2017 Permalink | Log in to Reply

      Congratulations to all the Focus Leads!
      Defining the responsibilities of the two roles was a valuable exercise for the REST API team. Thanks for sharing @matt.

    • Luke Cavanagh 11:10 pm on January 4, 2017 Permalink | Log in to Reply

      Final question I know performance was mentioned before, where will that focus fit? Thanks for the info.

      • Matt Mullenweg 2:18 am on January 5, 2017 Permalink | Log in to Reply

        What goes in a minor release will broaden a bit, which I know is something we have to approach carefully, but performance is very important and improvements will be something I will consider for being in a minor release.

    • Chuck Reynolds 11:37 pm on January 4, 2017 Permalink | Log in to Reply

      yay progress; very excite… let’s go!

    • Nick Halsey 1:29 am on January 5, 2017 Permalink | Log in to Reply

      Since I’m going to be generally much less available (and completely unavailable during US business hours) starting next week, I’m going to leave my thoughts on priorities and next steps for the customizer here.

      I’ve done some preliminary research on the process of making things in different industries. Preview, and live preview, is always a goal because it provides implementors with the best chance to understand what they’re making as they create it. In most cases a truly live preview is not possible due to physical constraints; for digital products and WordPress, though, live preview is possible and represents the best opportunity for improving user experience. See http://celloexpressions.com/blog/trust-wordpress-with-live-preview/ for details.

      The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization โ€œoutside of the boxโ€ of post_content, including sidebars and possibly even an entire theme.

      Because unified live preview is critical to improved user experience and trust, the best approach is probably to implement the new editor experience within the customize API, thus creating it with contextual live preview as an integral part of the experience from the start. Improving the editor within an “admin” interface that lacks live preview doesn’t address the fundamental problems with the current content editing experience and creates something that still has to be entirely rebuilt and reimagined within a live preview context eventually.

      If the editor is built on the customize API first, rather than rethinking the editor and then bringing it into the live preview API, the customize and editor contributors would be able to join forces to focus on improving the content editing experience much more effectively. The customize component has been seeing a lot of contributors helping out (over 60 in 4.7) and their knowledge of the customize API would be a big help in tackling the technical and design challenges of rethinking the editor within the unified live preview context; the opposite is unlikely to happen.

      Either way, these are the next steps that I would prioritize in working toward an improved and unified live preview experience, which could encompass much of the editor focus and would then set the stage for improving the broader approaches to “customization” on top of what’s existing:

      • Implement a term status API so that terms can be previewed
      • Complete the new theme installation experience (proposed plan)
      • Develop a core customize inline editing/partials API within the customize preview
      • Iterate on Customize Posts and the front-end editor plugin to provide inline editing within the customize preview API (this would be the basis for new editor work)
      • Load the customizer directly from the front end, making it feel like a front-end edit mode rather than a mix between the admin and front end
      • Rework option navigation UX in the customize controls pane, UX of inline editing vs. editing in a separate pane, visible edit shortcut UX, and the way posts of any type are accessed to edit (perhaps integrating with menus?) – I know @folletto has thoughts here that would be valuable
      • Iterate on Customize Snapshots and changesets to provide UI for revisions, drafted changes, and scheduled changes unified across a site’s posts and options
      • Implement term editing within the customizer (unified live preview framework)
      • Merge Customize Posts, with refined UX (this would be a likely place for editor-contents work to happen as well)

      My general feeling is that we need to bring live preview to content editing before the editor and customizer goals above (in the post) can be effectively tackled, so that there’s a complete framework to build those; however, work on these goals can progress simultaneously if expectations are established appropriately at the beginning.

      I’m not sure how much time I’ll be able to contribute moving forward, but my priorities (as a user first) are to advance the proposed roadmap I listed above.

      • Andrew Ozz 4:07 am on January 5, 2017 Permalink | Log in to Reply

        Nice thoughts and ideas. I’ve also been thinking about this and agree with many of the above points.

        My general feeling is that we need to bring live preview to content editing

        Yes. Even not “live preview to content editing” but rather “inline content editing where no preview is necessary”. As far as preview is concerned, the best experience is to edit “the real thing”, i.e. some form of front-end editing directly into the theme.

        Because unified live preview is critical to improved user experience and trust, the best approach is probably to implement the new editor experience within the customize API, thus creating it with contextual live preview as an…

        I’m not sure what “unified” live preview and “contextual” live preview mean. The best “preview” is when something is edited inline. Unfortunately this is not available in the current customizer. The second best is when the editing UI is inline, right at the place that is affected by the edit. This also is not available in the current customizer.

        If the editor is built on the customize API first, rather than rethinking the editor and then bringing it into the live preview API…

        Don’t think this is good. As far as I see the current customizer UI will have to be redesigned together with the way it works. Don’t see a reason why the UI should be similar to a “frameset” site from the late 90’s. We can do a lot better than that ๐Ÿ™‚

        Rework option navigation UX in the customize controls pane, UX of inline editing vs. editing in a separate pane, visible edit shortcut UX, and the way posts of any type are accessed to edit (perhaps integrating with menus?)

        Exactly (I read that as UI not UX). Further, the customization will happen from the theme/front-end, the “control” sidebar will go or be replaced with a proper navigation menu, everything will be 100% JavaScript and REST API driven, most controls will be inline or in some form of dialogs (with ample space/not overcrowded) that will have help or hints build right into them, etc.

        • Nick Halsey 7:17 am on January 5, 2017 Permalink | Log in to Reply

          Thanks for the reply. I should clarify some of the terminology I used:

          • Live preview and inline editing (can/should) mean the same thing. The basic idea is that you see the end product as you create it. Inline editing is a more specific form of live preview.
          • Expanding on that, most interactions should probably happen directly “on the site” (or in the preview). However, there are cases where that doesn’t make sense (for example, a theme’s color options or changing a post format) – that’s where some sort of sidebar, modal, popup, or other approach would be necessary, and this is where we need a lot of research and design work to find the best solution. A hybrid solution like this also makes theme compatibility and progressive enhancement with theme-support much more realistic.
          • “Unified” live preview is essentially being able to edit any part of a site within the same editing mode/workflow (without having to publish any changes).
          • “Contextual” live preview would be something like front-end editing, versus an editor that provides live previews of styling for the content area and media within it but is missing the context of the rest of the site, and may not be able to accurately reflect the way all content is displayed as a result.
          • In terms of API, the customize API is currently the core framework/API for live previewing anything. I might use customize API and live preview API somewhat interchangeably because I see this as the best path forward as a basis for building everything; @westonruter could probably discuss the advantages to that direction in more depth.
          • The customize API is 90% of the way to being able to fully manage live previewing any change to a site with controls to make changes happening either inline or in a separate place (the current customize “pane”). Specifically, once “Develop a core customize inline editing/partials API within the customize preview” is implemented on top of the base partials API currently in core, the customize API would support both approaches to making changes pretty robustly, as opposed to starting from scratch. That would also do a lot for the goal of unified live preview (and theme/back-compat) if content editing comes into the same framework that’s already used for many non-content options.

          So I think we’re largely in agreement about end goals, and should spend some time refining the direction on how to get there, both in terms of tech and design ๐Ÿ™‚ The current “customizer” should certainly evolve in terms of usability but the internals are beginning to converge with long-standing feature plugins and the editor goals into something that could really take WordPress to the next level with unified live preview and inline editing as a central focus.

        • Weston Ruter 12:59 am on January 6, 2017 Permalink | Log in to Reply

          @azaozz:

          The best โ€œpreviewโ€ is when something is edited inline. Unfortunately this is not available in the current customizer. The second best is when the editing UI is inline, right at the place that is affected by the edit. This also is not available in the current customizer.

          Right, it isn’t available but as of 4.7 it is possible. With the introduction of changesets and with selective refresh it is now possible to live preview. Actually, it was possible even before this as was prototyped in Customize Inline Editing but now it is possible implement that concept without ever loading customize.php or enter into any iframe at all. I want to build on the new edit shortcuts to provide a UI to start inline editing an element while on the frontend.

          As far as I see the current customizer UI will have to be redesigned together with the way it works.

          Yes, the current customize.php app should fade away as we bootstrap the customizer into the frontend context. Controls should appear in the sidebar only when needed. Otherwise, controls can appear inline even with direct manipulation where possible.

          The benefit of using the Customize API is not only having a framework for previewing changes but also we get โ€œfor freeโ€ an system for batching together an arbitrary number of changes (menus, widgets, options, etc) and having them all go live together once a changeset is published (even after it is scheduled or going through an editorial review process).

          Also, I think that the more we can treat โ€œthe Editorโ€ as a component rather than the admin screen the better. As with #35760 we should be able to instantiate a TinyMCE editor anywhere to manipulate content and content blocks, whether this be on the admin screen or in the customizer. For example since Shortcake integrates with the TinyMCE editor then the Post Elements interfaces it provides then (mostly) automatically become available to the TinyMCE editor embedded in the customizer via the Customize Posts plugin.

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

          So the Editor component should be appear on the admin screen and on the frontend (with customizer bootstrapped). When you do โ€œPreviewโ€ from the edit post screen this should take you to the frontend with the customizer bootstrapped so that not only can you preview the changes you made on the edit post screen but you can also continue to edit changes in that context and see the additional changes live. This is implemented today in Customize Posts.

    • Ryan McCue 1:35 am on January 5, 2017 Permalink | Log in to Reply

      Looking forward to working with you Matt, as well as all the other leads. Exciting times. ๐Ÿ™‚

    • Julien 6:53 am on January 5, 2017 Permalink | Log in to Reply

      Great news, we’re definitely looking at Editor “blocks” features.

    • Ahmad Awais 9:21 am on January 5, 2017 Permalink | Log in to Reply

      Congratulations all the tech and design leads. I am excited to see what’s next.
      I think most of the time I contribute this year will go towards Customizer, looking forward to working with you @westonruter & @melchoyce!

      Moreover, I am very much interested in standardizing REST API authentication area as much as e can while keeping it flexible.

      @matt the concept of editor blocks sounds very much interesting to me. The only question rather a suggestion is that if we make the process more transparent, then it will help the theme developers in the long run. Right now, as a theme developer, I am not sure what to expect from WP 4.8’s editor. A more clear timeline will go a long way to help both WordPress and us (theme devs). For example…
      1. Setting the right expectation: What to expect from the final version of Editor.
      2. The concept of “Blocks” is exciting, expanding more on it, early on, will help us prepare our new themes accordingly.
      3. Transparency will lead to more and better comprehension, which in turns can bring more contributors to the WP core. I for one, plan to contribute my fair share to the editor this year, mostly because it has a direct impact on the revenue my company makes.
      4. If possible, the focus of editor could be supported by data/numbers; editing is BTW most important feature of WordPress, even a teeny tiny change to that component will impact more than 100 Million users? (A rough guess). It’s only fair, that what we change here is supported by feedback from the community and that we can comprehend how it impacts the future of writing/editing and theming in WordPress. It will not only help us make an informed decision but will help theme devs prepare for it in advance. WIN-WIN?!

      Having not set release cycle is something new, but setting the right expectations, that I think can help?
      What are your thoughts about this?

      • Weston Ruter 6:03 pm on January 6, 2017 Permalink | Log in to Reply

        @mrahmadawais My perspective is that WordPress already has the key pieces for content blocks in the form of widgets, shortcodes, and TinyMCE views. I think the gallery shortcode should be considered perhaps the proto content block. The Shortcake plugin has demonstrated content blocks in the editor and this plugin has a significant number of installs at 10,000+. I now have a proposal drafted for using widgets as the underlying construct for the shortcode UI and storage mechanism, while shortcodes and TinyMCE views would continue to be how the content blocks are embedded and visualized in the content editor. My opinion is that Shortcake combined with widgets will provide us with the key pieces for content blocks, where a content block an be used either in the post content editor or in a sidebar widget area.

        I’m waiting to publish my technical proposal until @matveb has has had a chance to review. I fully expect the process of designing and implementing content blocks to be done openly and transparently.

        • Ahmad Awais 7:10 am on January 7, 2017 Permalink | Log in to Reply

          @westonruter great, looking forward to it.

        • Weston Ruter 6:03 pm on January 9, 2017 Permalink | Log in to Reply

          I’ll also reiterate that this โ€œWidgets as Content Blocksโ€ proposal is just a proposal. I’m eager to get feedback on it and the JS Widgets feature plugin because I think it has a lot of promise for content blocks and also for widgets in general. But given this year being design-lead, the technical proposal post may wait to be published until design has first set the direction for the editor.

    • Davide 'Folletto' Casali 10:16 am on January 5, 2017 Permalink | Log in to Reply

      I couldn’t agree more on the combination of a design and a tech lead, as well as having explicit reference people for each project.

      I’m happy to see this direction, and specifically the people chosen there are probably the best choices I can think of. It’s going to be great. ๐Ÿ™‚

    • Joen Asmussen 10:30 am on January 5, 2017 Permalink | Log in to Reply

      ๐ŸŽ‰

      Interesting times ahead. Can’t wait to see what cool stuff we’ll build together!

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

      Looking forward to working with all the other leads this year! ๐Ÿ™Œ

  • Matt Mullenweg 9:30 pm on December 28, 2016 Permalink |
    Tags: wp-cli   

    Supporting the Future of wp-cli 

    wp-cli is a command-line interface that is deployed and relied upon by almost every major user of WordPress out there. As we head into 2017, I wanted to make sure that its future is certain for everyone who builds on it, and that the major contributors to the project, chiefly Daniel Bachhuber, are able to work on it even more in the coming year.

    To that end there are two big announcements:

    1. The website of wp-cli.org, the code / GitHub, Twitter, and such are all coming in under the WordPress.org umbrella and there will be a CLI Make site with a P2 and all of the resources that used to be under wp-cli.org. There is already #cli on Slack and that will continue. (Will live at https://make.wordpress.org/cli.)

    2. I’m going to be bringing together a number of companies in the WordPress ecosystem to solidify their financial support of runcommand so that Daniel and others can devote more time to making wp-cli better and better through 2017. This is a continuation of the fundraising started a few weeks ago.

    This will all happen the first part of January, and I’m looking to a full and exciting year for wp-cli. Also big thanks to everyone who has chipped in, whether time or money, to support the project in the past. It has been one of the highest impact developments for WP in many years.

    Many of the logistics are yet to be determined. Feel free to weigh in with questions, feedback, etc. in the comments, or join #cli on Slack. We’ll do our best to keep everyone in the loop as things develop.

     
  • Matt Mullenweg 8:27 pm on May 12, 2016 Permalink
    Tags:   

    New lead for 4.7: Helen Hou-Sandรญ 

    Due to some unexpected constraints on my time this year, I’m going to be stepping down as the 4.7 lead, and I’m happy to announce that Helen Hou-Sandรญ is stepping up to lead the release in my stead. I’ll still be behind the scenes providing whatever support is necessary, and I’m really looking forward to the release . You might remember Helen for her famous work on WordPress 4.0.

     
  • Matt Mullenweg 5:35 pm on December 12, 2013 Permalink  

    Since some people read this and not the news blog, 3.8 is out. ๐Ÿ™‚

     
  • Matt Mullenweg 8:41 am on December 6, 2013 Permalink
    Tags:   

    State of 3.8, and thoughts on the next week 

    tl; dr: Still on track for release next Thursday. We’re extending the window for code changes by 3 days, through the 8th. RC2 package on the 9th will be what ships on the 12th.

    December 5th, our targeted but controversial freeze date, is drawing to a close. First the bad news: there are two blockers and we could not ship the package we have tonight, despite a lot of great effort. The good news is we are close, there are good priorities on the remaining issues, the new features appear resilient and are live on WP.com which has generated a ton of testing, and weโ€™re far enough out from our target (the 12th) that Iโ€™m confident we can ship that morning and still have had a 4-day freeze.

    As a side-effect of the longer freeze and predictable date, I also think the best WP hosts will push it to their customers same-day and we’ll continue or improve our record of having localized versions ready to go.

    What could break it? If an unknown unknown blocker pops up on Tuesday or Wednesday, weโ€™re going to have to delay the release until the following week. Discovering that issue sooner, so it wouldn’t cause a delay, is a function of testing โ€” the more we can test and cover now the better. We want to shake out big issues now, not next week. The more people that can run the RC or trunk at this point, the healthier the release will be.

    What’s open right now? Our most substantial blocker, no-JS fallback for THX #25964, was raised a few weeks ago and we could have flagged its priority and developed a solution then, rather than the flurry of activity its had over the last two days. Our other blocker, the about.php page, is similar: I should have kicked off that page (#26387) when we nailed down exactly what headline features would be in the release, which was much earlier. Often user-focused non-code deliverables wind up as the last thing we do, but they’re so visible they deserve time to bake just like a complex backend change would. Of the the other 15-ish open issues there is nothing intractable, but thereโ€™s also nothing trivial, and for some issues we need to make a non-obvious decision to move it forward. We made the decision to punt or revert a number of things that weren’t fully ready yet, like the new author widget and RSSJS.

    The things we missed are not a matter of having enough time, they’re a matter of priority. I think properly triaging issues as soon as they come in and being disciplined about working from highest to lowest will allow future release to avoid these problems. Even though thatโ€™s not hard to understand intellectually, sometimes you have to make the mistake to really grok it. I’m extremely proud of everyone who has been involved so far and in the amount of learning and growth I’ve observed even in our accelerated cycle.

     
    • Gtantra 8:44 am on December 6, 2013 Permalink | Log in to Reply

      Give us a break already … we’re just getting used to 3.7 and already the next release !!!

      • Matt Mullenweg 8:51 am on December 6, 2013 Permalink | Log in to Reply

        Once you’ve used the new stuff, it’s hard to go back. ๐Ÿ™‚

        We’re unapologetic about trying to get improvements in the hands of our community as soon as possible, but I do agree with you that upgrades can be a burden. How I’d like to solve that is not by avoiding upgrades, but by making them so seamless and effortless that people wouldn’t mind if we did them every day.

        • krembo99 9:07 am on December 6, 2013 Permalink | Log in to Reply

          I am not going to dispute the wordpress upgrades that are always great – but I agree that the frequency has become a bit high ( Not to say “Autodesky” ) – I believe no one will Dispute security, or bug related upgrades – but what is the reasoning behind too frequent feature upgrades ?

        • Jon Brown 9:20 am on December 6, 2013 Permalink | Log in to Reply

          +10

        • Hassan 12:30 pm on December 6, 2013 Permalink | Log in to Reply

          “Weโ€™re unapologetic…”

          Matt, you should work for Apple ๐Ÿ˜‰

        • emzo 4:56 pm on December 6, 2013 Permalink | Log in to Reply

          Yes, like Chrome updates (and many other applications these days). I’ve absolutely no idea what version of Chrome I’m running, and I don’t really care, but I’m safe in the knowledge that it’s constantly kept up to date – and I don’t even know it’s happening.

      • Clorith 9:24 am on December 6, 2013 Permalink | Log in to Reply

        3.8 is so worth it, if only for the new Admin UI along, it’s so beautiful, really pulls everything together nicely

    • JohnRip89 3:56 pm on December 6, 2013 Permalink | Log in to Reply

      Matt the testing build you posted is not 3.8 RC1 is not working it is set to 3.7.1 (“Download WordPress 3.8 RC1 (zip) or use the WordPress Beta Tester plugin (youโ€™ll want โ€œbleeding edge nightliesโ€.) here is the link to that post: https://wordpress.org/news/2013/12/3-8-almost/

    • mor10 4:25 pm on December 6, 2013 Permalink | Log in to Reply

      Hats off to Matt and everyone else for setting a hard release date and sticking to it. This is the kind of decision and process that fosters trust in the market and shows everyone WordPress is a mature platform ready for the challenges ahead. The develop new features as plugins method also seems to have worked out quite well and I hope it continues moving forward.

      Impressive work from everyone involved.

    • Hassan 8:37 pm on December 6, 2013 Permalink | Log in to Reply

      The only thing that worries me is if/when plugin devs will jump aboard the MP6… err, NEW dashboard aesthetics. They have a couple of things to adjust for the new design, with menu icons being the first thing that pops in mind. I feel like I’m going to halt updating to 3.8 on my sites for while until most plugins adapt to the new look. Not a major thing, but it does worry me and I hope plugin devs do cooperate! Otherwise, I’m gonna nag them like a brat!

    • Brian Cruikshank 3:47 am on December 7, 2013 Permalink | Log in to Reply

      Thanks for the update, Matt. The pace of WordPress innovation is tremendously exciting.

      Is there any way #25838 can get some attention? All my author posts still 404s in WordPress 3.8-RC1 and it’s an update blocker to me.

    • Robert Chapin 7:38 pm on December 7, 2013 Permalink | Log in to Reply

      I’m hoping to offer a smooth upgrade experience to the Fix Admin Contrast plugin users. I see the major changes in the WordPress UI design, yet the same eye-strain-inducing invisible input fields throughout. Haven’t looked at any of the code yet. Is it very different? Just very little time to offer here.

    • bnovotny 10:09 pm on December 7, 2013 Permalink | Log in to Reply

      I would like to see a few actions added regarding the login & users-new pages. One for the password change screen so that we can add a security question. I was trying to do that on a new release for my plugin in and wound up wasting too much time trying to implement a more secure lost password recovery option. A couple other ones for the user-new.php file so that folks that have plugins that add extra fields can extend to that page. (http://www.youtube.com/watch?feature=player_embedded&v=BhjEk5dTa7E)

      Thanks, that is all for now.

    • David Angel 4:08 am on December 10, 2013 Permalink | Log in to Reply

      Looking forward to trying it out (right now!)

    • Brin 5:55 am on December 10, 2013 Permalink | Log in to Reply

      Just taken a look at the RC – serious amounts of awesome stuff – can’t wait!

    • PILOTUSA123 5:13 am on December 11, 2013 Permalink | Log in to Reply

      Good luck….I hope you guys keep up with the multisite installs. Multisite dashboard has been super slow…I see lot`s of people with the same problem on multisites…
      Please Matt help us out with this matter.

  • Matt Mullenweg 7:20 pm on August 8, 2013 Permalink
    Tags:   

    Excellent 3.8 brainstorm session today. People talked about a number of interesting ideas and started to form some groups around them. Not everyone is in IRC, so wanted to give an opportunity for people to post a comment with a given area here, and if you’re interested in contributing to that area reply to that comment. This allows people to connect asynchronously. As people comment please connect with them directly in IRC, email, whatever, and discuss.

    Next week groups will bring more fleshed out proposals for forming a Plugin Project team, including a lead, mockups, user tests, existing plugins…

     
  • Matt Mullenweg 8:36 pm on September 16, 2012 Permalink  

    An upcoming free Stanford HCI (human computer interaction) course coming up:

    https://www.coursera.org/course/hci

    (Hat tip: @DanielBachhuber.)

     
  • Matt Mullenweg 7:09 pm on August 3, 2012 Permalink
    Tags: meta,   

    You might notice that this P2 has gotten a big head. All of the Make P2s have actually, and like the rug in the Big Lebowski we think it really ties the room together.

    The Get Involved tab has been added, docs have been moved under support, home has been hidden. This isn’t ideal — we’d eventually like to move to more of a verb-oriented navigation system — but it is better than everything under Make being its own island and not really linked to or from the main WP.org side, or to each other. Hopefully it will also let more folks know about how to get involved (I added a link to the Make Core Handbook to the top sidebar widget.)

    I’ll be talking more about some of the improvements to WP.org tomorrow at 11am PST and you can still get streaming tickets if you’d like to tune in: http://2012.sf.wordcamp.org/tickets/

     
  • Matt Mullenweg 12:10 am on July 28, 2012 Permalink
    Tags:   

    Looking for a lead 

    The Core Contributor Handbook is live here, and has a lot of great content from a number of contributors already:

    https://make.wordpress.org/core/handbook/

    What we’re looking for is someone to “own” the CCH and be responsible for:

    • Expanding and editing it, getting feedback from devs.
    • Walking people through it to get ideas on how to improve it (and get people involved with WP!).
    • Soliciting other contributors (don’t want a one-person show) and keeping an eye on all the changes.
    • Figure out a cool way to package and print the handbook.

    Let me know if you’re interested in taking on this role, a comment on this post is fine.

    This also reminds me — it would be great to be able to see a feed of changes on a site, like edits to a page. Anyone have a favorite plugin there?

     
    • dremeda 12:19 am on July 28, 2012 Permalink | Log in to Reply

      Good stuff, Matt. I would like to contribute here. Whoever ends up owning it, you have your first contributor/volunteer.

    • Ben Tremblay 1:48 am on July 28, 2012 Permalink | Log in to Reply

      Detail: that URL was not clickable in EMail. ThunderBird is pretty well behaved with that sorta thing.
      Odd it wasn’t a live link.
      Links in header and footer were just fine.

    • dllh 2:24 am on July 28, 2012 Permalink | Log in to Reply

      Can you clarify what level of involvement with the community the lead for this should have had to date? For example, I’ve gotten a few patches in here and there but don’t know that I’m sufficiently familiar with all the things to be a useful lead on something like this. Wouldn’t surprise me to learn that others who’re interested in pitching in have similar feelings. Are you hoping to land somebody who already has a solid insider view of things or are you after a fresh perspective?

      • Matt Mullenweg 2:01 pm on July 28, 2012 Permalink | Log in to Reply

        I don’t think being super-involved in core is necessary, in fact it’s probably better to have a beginners mind with regard to much of this. However you’ll want to run things by folks with more experience just to make sure you’re leading people on the right track.

    • Emil Uzelac 2:55 am on July 28, 2012 Permalink | Log in to Reply

      Good stuff indeed ๐Ÿ™‚

    • Tom Auger 5:16 am on July 28, 2012 Permalink | Log in to Reply

      Boy oh boy, this is such an important piece of the WordPress puzzle! My own journey (still in its infancy) in becoming a useful contributor has been fraught with good intentions and big learning curves. If I had more experience I’d definitely volunteer to shepherd this thing into a true roadmap for the would-be contributor.

    • Mike Bijon 9:37 am on July 28, 2012 Permalink | Log in to Reply

      Hi Matt, I’d like to be considered for this position too. I’m a 1-time core contributor and have worked with the PDX WP Meetup and Codex lately. More details, http://www.mbijon.com/about-mike-bijon/. Now that I’m not a full-time developer at work, and take on a lot more planning & PMing tasks, I think I could be a lot more productive with this than I’ve been with trying to make rare, quiet coding windows.

      Also, for tracking changes to the CCH:
      Audit Trail has most of what you need, https://wordpress.org/extend/plugins/audit-trail/, but would have to be turned into a feed. Adding some open diff tools could help make it more readable, http://www.raymondhill.net/blog/?p=441, or https://github.com/austincheney/Pretty-Diff. Although what would be interesting is to build a way to deploy all content via a git or Github repo, http://drupal.org/project/content_staging (which would also solve a lot of commercial users’ Dev > Production deploy problems).

    • Japh 1:34 pm on July 28, 2012 Permalink | Log in to Reply

      Hey Matt, the Core Contributor Handbook is already an excellent resource, and I’d love to see it grow even further.

      I would also like more information about what your expectations are for this role. Specifically, how much experience with core contribution do you feel is necessary? How much time per week do you expect this role will require?

      • Matt Mullenweg 2:02 pm on July 28, 2012 Permalink | Log in to Reply

        Answered the experience question above. As for time, I would plan for 10 hours a week as a good baseline, as with any serious volunteer commitment across WordPress.

    • Siobhan 3:59 pm on July 28, 2012 Permalink | Log in to Reply

      Hi Matt – I’d love to help out with this. I was looking at it before and wondering if you needed someone to help out.

      I’m a documentation specialist (http://wordsforwp.com) and I spend a lot of time communicating with devs and translating what they say into beginner speak. I build a lot of documentation projects from the ground up, and work with a lot of developers on similar projects to this, so it’s right up my street. I’d be more than happy to get involved. My time is a little limited over the next few weeks but as of the end of August I have 10 hours per week for sure.

    • Azizur Rahman 5:22 pm on July 28, 2012 Permalink | Log in to Reply

      Hi Matt, count me in to be one of the volunteer. I don’t think I can do 10 hours at the moment to take a lead, due to my other volunteering commitment at the moment. I am happy to be supporting whoever ends up taking the lead.

    • Beau Lebens 10:59 pm on July 29, 2012 Permalink | Log in to Reply

      If anyone is planning on coming to the Dev Day for WCSF, I plan on making contributions to the CCH part of the action for the day.

    • Chris Olbekson 1:33 am on August 2, 2012 Permalink | Log in to Reply

      I would love to help where ever possible on this. I think the perfect plugin to help manage the project is Edit Flow https://wordpress.org/extend/plugins/edit-flow/. I’m not sure if it has a feed but the notifications and editorial comments will be very helpful.

    • Doug Provencio 9:27 pm on August 5, 2012 Permalink | Log in to Reply

      I added a section called Suggestions, for people to add suggestions about Missing Sections, Style and Navigations, and Sections still needing major work.

      Do we want to break off a list of which pages still need work (and who’s working on them) onto its own page?

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