WordPress.org

Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 8:37 am on June 16, 2015 Permalink |
    Tags: ,   

    This week in 4.3: June 15 – 21 

    A day late, but I didn’t want to start another week without one:
    This is the jump-start post for the seventh week of the WordPress 4.3 release cycle.

    The feature plugin merge window is scheduled to close this week on Wednesday, June 17th. With that we only have two short weeks left before beta1.

    Priority Tickets this week:

    Core Meetings this week:

    4.3 Feature Chats this week:

    Notable updates from last week:

     
    • Helen Hou-Sandi 4:13 pm on June 17, 2015 Permalink | Log in to Reply

      A note that Admin UI won’t be having a chat this week as I’ll be at CSSConf. I encourage people to get together and go through any UI tickets milestoned for 4.3 during that time, but I won’t be available. I’ll also mention this during dev chat later today.

    • lanetalkesh 12:59 pm on June 26, 2015 Permalink | Log in to Reply

      Hey Team.. there is major update in tinymce editor with new version 4.2.0 and here is a released link – http://www.tinymce.com/forum/viewtopic.php?id=35724.

      Please check it and I thought there will be another changes with wordpress editor same like in WordPress 3.9 release.

      I hope wordpress core team are updated with this news.

      Thanks

  • Ryan Boren 3:00 am on June 15, 2015 Permalink |  

    Maintaining Core Component Pages 

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

    That page lists our components and their maintainers. I use this page when determining which component to use when creating tickets and when picking triage tags for make/flow posts. The component pages linked from there offer useful information to contributors. I’d like to make them more useful. The customizer component has set a good example with their page.

    https://make.wordpress.org/core/components/customize/

    Screen Shot 2015-06-14 at 10.50.47 PM

    If you’re a component maintainer, give your component page some attention. Make it useful to prospective contributors looking to get involved and follow along. If you use github as part of your development flow, link to your github resources. Also, if your component has a slack channel, link to your component page in your channel topic. If you need make/core editing privileges, let us know.

     
  • Jeremy Felt 3:50 pm on June 12, 2015 Permalink |
    Tags: contributor day,   

    How you can help with the Network Admin UI during contributor day 

    A previous write-up explains how you can help test and capture the network admin UI. Here’s a specific version for how you can help during contributor day this weekend.

    There are four steps to the workflow at the moment:

    1. Capture a visual record of network admin screens.
      • Ideally on a device/browser combination that has not yet been captured.
      • If comfortable, post the screen captures and notes on make.wordpress.org/flow.
      • If you need access to Make/Flow, ask in #core-flow on Slack or around the physical room you’re in (if it’s full of contributors).
    2. Observe screens, actions, and results throughout the network admin.
      • This can happen during or after step 1. You can also just do this without the first step.
      • Look for things that don’t make sense, visual errors, pieces that are difficult on mobile, etc…
    3. Document observations in the screen sweep sheet.
      • This can be with or without a Trac ticket. With or without a screenshot.
      • Acts as a note so that we know that to come back to as part of the overall admin UI improvement effort.
    4. Help with the screen sweep sheet.
      • Open a ticket if there is none. Add screenshots if there are none. Confirm/deny the issue.
      • And patch. If there’s a ticket on the screen sweep sheet that you can patch, submit away.

    While this is an ordered list, you do not need to treat it like one. Pick a step that feels comfortable and concentrate on that. If you need guidance, there are folks in Slack that are always happy to help.

    Current captured visual records:

    By all means, if you have a device that is already captured, don’t hesitate to capture it in your own way or to skip step 1 entirely and start observing.

    Thanks for the help!

     
    • Saravanan 2:57 am on June 13, 2015 Permalink | Log in to Reply

      I would like to help out with this. I will need access to sites to test them on my iPhone 6 plus; and Mac. Thanks.

  • Mel Choyce 7:01 pm on June 11, 2015 Permalink |
    Tags:   

    Moving Dashicons from an Icon Font to SVG 

    In the next couple months, we’re going to focus on converting the Dashicons icon font in core to SVG. The process of adding and updating the Dashicons font is an incredibly labor intensive, tedious process that is currently limited to a small number of people who have the ability to add new characters to the .glyphs source file. By moving to SVG, we’re not only making the process easier for Dashicons maintainers, but also making the process of adding and updating icons easier and more open to the entire design community.

    Why SVG?

    When we initially built Dashicons, we tried out a couple different methods for including them in the admin. SVG was our preferred method, but due to lack of support and fallbacks for SVG at the time, we opted to go for the more widely support icon font method.

    However, there have tremendous strides to improve support and understanding around SVG in the past year and a half, and we think now is a good time to start the transition process in core.

    Here are some of the benefits SVG icons provide:

    • The icons are straight up vector — that means no font antialiasing issues when you use the icons outside of their 20×20 pixel grid, making the icons much more versatile
    • Better CSS control — switching to SVG introduces the possibility of multi-color icons
    • Better positioning control than icon fonts
    • SVG won’t fail to load like a font might, because inline SVGs are included right there in the document
    • Potentially better for accessibility [source]
    • Much easier to maintain than the current icon font
    • Easier for plugin and theme authors to add custom SVGs

    The cons:

    • Less native browser support (but fallback options exist)
    • Figuring out backwards compatibility in core will be challenging (but not insurmountable)

    Chris Coyier has a pretty fantastic rundown on SVG vs. icon fonts.

    Just to note: we’re not talking about supporting uploading SVGs in the media library. These would be SVGs built by us, included inline in the WordPress dashboard.

    The Roadmap

    Here’s the plan:

    • As much as possible, we’re going to attempt to build this as a feature plugin — but we’ve already started running into some issues with what we can and can’t do in a plugin.
    • The MVP will be svg icons being generated into a sprite through a Grunt build process. For the MVP, we’re not going to focus on browser support.
    • Once we have an MVP up, we’re going to explore the best way to provide browser support using techniques outlined by Chris Coyier in Github, as well as figure our backwards compatibility with the icon font.
    • Finally, we’re going to explore breaking up SVGs into different icon “packs” (TinyMCE, admin bar, CPT, etc.) and figure out if we can enqueue them on the fly.

    Ideally, we’d like to do as much of this during the 4.3 cycle as possible, with the idea of merging in 4.4. This means we’ll need to have a solid MVP by August, which is feasible if we can get more help. That’s why we’d like you to…

    Join us

    We would love to get more people involved in this project. Specifically, we’re looking for people to help build out the MVP, and people to work on compatibility issues.

    We’re going to be building out the plugin on github:  https://github.com/ryelle/svg-dashicons-plugin. There’s nothing there yet, but we hope to get some early work up soon. (We also did some very early explorations in another repo, if you want to see some of the past conversations and issues.)

    Our meetings take place in #design-dashicons every Thursday at 18:30 UTC. Please join in and help us make Dashicons even better.

    If you have questions, feel free to leave a comment here or ask in slack.

     
  • Konstantin Obenland 8:58 am on June 11, 2015 Permalink |
    Tags: ,   

    Dev Chat Summary, June 10 

    Agenda, Slack log.

    Menu Customizer Status Update (#)
    @westonruter
    The a11y review did not unveil any blockers, although it wasn’t done on the feature branch the team is currently working on. Introduction of a blocker there was deemed unlikely however. A new plugin version can’t be released since it’s now dependent on some core patches being applied.

    For the rest of the requirements: The biggest blockers are almost complete, Customizer setting re-architecture and sub-menu drag & drop. The settings re-architecture has been integrated into JS for the nav menu items, allowing nav menus to be edited, added, removed all with 100% previewability and not making any changes to the DB. Once Save & Publish is done, any newly created nav menu items get inserted at that time. Same goes for nav menu deletion. The submenu drag & drop has been merged into the same branch and it is all working together now.

    The biggest outstanding pieces are:

    • adding back the ability to add/remove entire menus
    • updating keyboard-accessible reordering to work with new menu settings
    • more unit testing for PHP, and write tests for JS

    Estimated time of completion is June 11, which leaves 5 – 6 days to merge.

    Admin UI (#)
    @helen
    Even more prep work has gone into list tables, now working on the responsive part on #32395. They have gotten some feedback so far, would love more even on the rough cuts. Helen will be at wordcamp philly’s contributor day this weekend, looking to knock through a bunch of the low hanging fruit on the screen sweep spreadsheet, and find takers for some make-flow tickets (#29906 in particular). She has some catch up to do with other contributors on visual regression testing and media-new, which will happen at tomorrow’s meeting.

    Network Admin UI (#)
    @jeremyfelt

    Objectives from last week:

    • #32434 is in. Jeremy is still poking at #22383 and #32503 with a target of this evening.
    • They had no additional iterations on WP_Network and WP_Network_Query, but @jjj is working on having something this week.
    • Did not yet generate discussion around HTTPS. Moving this objective along to this week.
    • They made quite a bit of progress with flows. @kraft added Nexus and @earnjam has iPad screencaptures he will be publishing shortly. Their next push is to start creating tickets. Jeremy wrote a post to try and drum up support – https://make.wordpress.org/core/2015/06/05/help-test-and-capture-the-network-admin-ui/ – and they had a handful of people hop in. Pretty optimistic that they’ll start making progress here, especially with a couple contributor days this weekend.

    Objectives for this week:

    • New tickets to address found issues in flow. These issues logged in the screen sweep spreadsheet.
    • Iterations on WP_Site and WP_Network. Discussion around iterations.
    • #22383 and #32503 committed.
    • Write post, generate discussion around HTTPS in multisite.

    Better Passwords (#)
    @markjaquith
    Mark turned the plugin into a patch for the new UI. After a cleanup, that can land, and we can iterate a bit, as well as tackle the new user password flow, which is different. The expiration of reset links (#32429) needs testing (human and unit), before that lands. And the “notify users of password and email changes” patch (#32430) needs a review on the hooks in it. I’m not sure we’re passing the right things along. Like, email instead of the whole user array.

    Favicons (Site Icon) (#)
    @johnbillion
    There’s been a status update on make/core. It’s looking like #29211 would be a better approach to a reusable control with image cropping functionality. So John is wondering whether we should aim for 29211 for 4.3 and site icon for 4.4. On the topic of using the Customizer or not: much of the image cropping control for the header image is also used on the old header image screen (it’s mostly media library and ajax functionality), so it’s not necessarily tied to being a customizer control.
    Let’s meet today June 11 2015, 20:00 UTC to discuss what a good approach could look like.

    Next chat will be on June 17 2015, 20:00 UTC

     
  • John Blackbourn 2:29 pm on June 10, 2015 Permalink |  

    Site icon and image cropping controls 

    A couple of weeks later than intended, a brief update on the site icon functionality which has been touted as a potential feature for 4.3. The site icon functionality aims to provide an admin UI (via the Customizer, at least initially) for users to upload an icon which is then output as a favicon and associated touch icons, while also allowing themes or plugins to re-use the icon in other places as they see fit.

    The existing header image control in the Customizer (and its corresponding functionality on the old custom-header screen) provides a means for uploading a header image and then cropping it to the desired size. Unfortunately this control is fairly tightly coupled with the header image functionality, and therefore extending it for use with the site icon control has meant duplicating a lot of code.

    It’s looking more and more like #29211 should be tackled before the site icon functionality, in order to avoid this duplication and in order to allow other controls to provide a croppable image upload (such as for background images in #32403).

    Due to my limited availability to work on the site icon feature in the coming weeks, I think it would be worthwhile instead focusing on #29211 and the introduction of an abstracted control that supports image cropping, which can then be used for the site icon and custom background controls.

    The current non-working site icon feature plugin can be found in this repo on GitHub. It uses considerable code from the custom header image control. If someone wants to take that and run with it that would be great, or if someone wants to tackle #29211 instead, that would be great too.

     
    • Marko Heijnen 2:44 pm on June 10, 2015 Permalink | Log in to Reply

      I’m more then happy to help out. Image cropping etc is what I did before.

    • Greg Ross 2:48 pm on June 10, 2015 Permalink | Log in to Reply

      I spent quite a bit of time working on this problem when I built my OS Integration plugin (https://wordpress.org/plugins/os-integration/), but I didn’t integrate it in to the customize.

    • Ciprian 3:11 pm on June 10, 2015 Permalink | Log in to Reply

      Would this replace the Jetpack favicon feature? Would they be developed/maintained in parallel?

    • Mel Choyce 5:14 pm on June 10, 2015 Permalink | Log in to Reply

      Are there any plans to support .ico?

      • Samuel Wood (Otto) 5:45 pm on June 10, 2015 Permalink | Log in to Reply

        ICO files are somewhat difficult to do. Supporting them should be an optional thing, I think, not necessarily a blocker for implementing the underlying support for favicons as png-only to start with.

        A few ICO producing libraries were mentioned in #16434, and if something like this is created as PNG first, then adding on code to also save ICO files would not be difficult if the right library to do so can be found or created.

    • Nick Halsey 1:40 am on June 11, 2015 Permalink | Log in to Reply

      A note regarding #29211 – that was originally written before 4.1, when we redid the other core media controls. So the best approach would probably to make a cropped-image control that extends WP_Customize_Media_Control, using header images as inspiration, then update the header image control to leverage it. Header images no longer use the latest and greatest in the Customizer, so it’s worth a bit more of a rethink than generalizing their functionality I think.

    • imath 5:29 pm on June 23, 2015 Permalink | Log in to Reply

      Hi @johnbillion thanks a lot for your great work about this feature, i’ve been exploring the plugin on the github repo and just posted some suggestions into a pull request :)

  • Konstantin Obenland 2:26 pm on June 10, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for June 10 

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

    Time/Date: June 10 2015 20:00 UTC:

    1. Menu Customizer Status Review@westonruter
    2. Feature Updates
      1. Admin UI – @helen
      2. Multisite Admin UI – @jeremyfelt
      3. Passwords – @markjaquith
    3. Component Updates (if time permits)

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

    Recommended reading: Trust, Live Preview, and Menus in the Customizer.

     
  • Jeremy Felt 10:07 pm on June 9, 2015 Permalink |
    Tags:   

    Multisite Office Hours Recap (June 9, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    Today’s chat log
    Overall 4.3 Release Objectives

    Last week’s objectives:

    • Have all 3 of these tickets closed and committed. #22383, #32434, #32503
    • Additional iterations on `WP_Network` and `WP_Network_Query`.
    • Generate discussion around HTTPS on #14172. @jeremyfelt will gather a list of HTTPS related tickets.
    • Nexus and iPad flows. Tickets created for bugs found in existing flows. Volunteers needed! :)

    Today’s meeting agenda:

    • Status on additional flows/visual records and next steps toward ticket creation.
    • New thoughts/discussion on `WP_Network`, `WP_Site` and friends?
    • Status of #22383, #32434, and #32503
    • Open floor for tickets, thoughts, etc…

    Topic Details:

    Status on additional flows/visual records. Next steps toward ticket creation.

    chat log

    We have new flows captured. @kraftbj posted the Nexus 6 results and @earnjam will be posting iPad shots within the next couple days. @topdown volunteered to capture screens for Samsung Note 8 and possibly other devices as well.

    To date, our device list includes: Nexus 6, iPhone 5s, iPhone 6, and Desktop, with additional screens specific to network upgrade.

    We posted some info late last week on how someone could help test and capture the network admin UI. Test installations of multisite are available for anyone to use if you have a device but just have no way of accessing a multisite installation. Please leave a comment on the post or in #core-multisite if you’d like to get started.

    As we create tickets and find bugs, we need to populate this spreadsheet as part of the overall screen sweep effort.

    Objective for next week: New tickets to address found issues. These issues logged in the screen sweep spreadsheet.

    New thoughts/discussion on `WP_Network`, `WP_Site`, and friends?

    Tickets: #31985, #32450, #32504, #31148
    chat log

    Not much discussion here. @johnjamesjacoby is going to have iterations of `WP_Site` and `WP_Network` this week. We should have a chat in #core-multisite soon after.

    Objective for next week: Iterations on `WP_Site` and `WP_Network`. Discussion around iterations.

    Status of #22383, #32434, and #32503

    Tickets: #22383, #32434, #32503
    chat log

    Objective for next week: Let’s cross our fingers that these are closed by tomorrow.

    Other items:

    Tickets: #14172, #32602
    chat log

    • @jeremyfelt still needs to generate discussion around HTTPS for #14172
    • @ipstenu found an issue with the plugin details modal when viewing plugin details on a sub site that has a different domain/scheme from the network admin. The switch to `network_admin_url()` that causes this came in #17902. A new ticket #32602 is open.

    Thanks everyone!

     
  • Boone Gorges 7:52 pm on June 9, 2015 Permalink |
    Tags: ,   

    Eliminating shared taxonomy terms in WordPress 4.3 

    Work on the taxonomy roadmap, started in earnest during the 4.1 dev cycle, continues to chug along for WordPress 4.3. We’ve been focusing on the elimination of shared terms: terms in different taxonomies that share the same term_id and thus the same row in the wp_terms database table. In 4.1, we stopped creating shared terms. In 4.2, we began splitting existing taxonomy terms when those terms were updated.

    In 4.3, we’ll take the final step. When a WordPress site upgrades to 4.3, all existing shared terms will be split.

    Toward that end, I’d like to make (a) a final warning to plugin authors, and (b) a plea for help from taxonomy mavens and those who maintain very large and complex WordPress installations.

    Plugin authors: Dress rehearsal is nearly over

    Since 4.2, saving a shared term (via any interface that uses wp_update_term()) causes that term to be split. It’s fairly rare to update a taxonomy term, which has made 4.2 a sort of trial run for authors to ensure that their plugins are ready for the transition. A quick scan of the plugin repo shows that a few dozen authors have taken advantage of this opportunity. I dub these developers Heroes of WordPress and grant them 🌟🌟 many gold stars 🌟🌟. Many authors, however, have neglected to make the necessary updates.

    All WP developers should take note that the upgrade to 4.3 is likely to surface many more odd bugs related to shared terms than 4.2 did. Plugin authors are strongly encouraged to review the 4.2 term splitting field guide to understand the potential repercussions for their public plugins as well as their custom client work, and to review techniques for ensuring a smooth transition.

    Get involved

    The 4.3 ticket for splitting taxonomy terms on WP upgrade, #30261, is sorely in need of developer feedback. The process of splitting shared terms en masse is potentially resource-intensive, especially on sites with very large numbers of terms (and especially with very large numbers of shared terms). The latest patch on the ticket has some optimizations so that sites with many hundreds of shared terms can be migrated in just a few seconds. If you maintain a site with a large number of (shared) taxonomy terms, or if you maintain a WordPress network with a very large number of sites (especially if you have a custom routine for rolling out database updates), your review and testing of the upgrade routine would be much appreciated.

    Booyah

    The fun stuff on the taxonomy roadmap – like termmeta – depends on the complete elimination of shared terms. Let’s get the hard stuff done in 4.3, so that we can make all of your taxonomy dreams come true in the next couple releases.

     
    • brianvan 8:31 pm on June 9, 2015 Permalink | Log in to Reply

      Great work here. Sounds like the team has been thorough in addressing any major issues that come out of this. Looking forward to the future stuff on the taxonomy roadmap!

  • Ryan Boren 3:50 pm on June 9, 2015 Permalink |
    Tags:   

    Trust, Live Preview, and Menus in the Customizer 

    One of the most important things in WordPress is users being able to feel confident as they make changes to their content and more generally to their sites. Being able to make non-destructive changes and preview them is an important component of building that trust. This is perhaps most noticeable in the “save and surprise” approach of the widgets admin screen – every time you add a new widget, modify its settings, or move one around, the changes are saved and appear live on your site, even if you’re not ready yet. The customizer is our framework for live previewing changes. We are committed to providing live preview for all aspects of site customization and making it usable on all devices from phones to large screens.

    The customizer is the result of a tremendous amount of work over many releases. It was first introduced in 3.4. In 3.9, it received its first big updates in the form of widgets support and improved header upload and cropping. 4.0 brought panels and contextual controls. Development really started to take off in 4.1 when JS-templated customizer controls and a JS api were introduced, making possible an ecosystem of live preview compatible plugins and themes. 4.2 followed that up with two important features, theme switching and mobile support.

    That brings us to today and the ongoing 4.3 development effort. Revamped navigation for the customizer is already in trunk and the nighty builds. The menu customizer feature plugin is a merge candidate for 4.3 and could land soon. These marquee features further our commitment to live preview and need all of the attention we can muster.

    The customizer has come a long way, but it still lacks some features and needs time to mature. We have many improvements planned and in-progress, including transactions, partial refresh, theme installation, speedier loading, scaling to large screens, and possibly even integration with front end editing. Our live preview framework offers many possibilities.

    Meanwhile, the Appearance screens will remain and will be maintained. Appearance > Menus recently received some attention in the form of a few fixes. More attention is needed and will be given. There are still differences in the flows each approach best enables, whether it’s new site/theme setup, small maintenance tasks, or dedicated content managers for heavy usage of widgets, menus, or other pieces of content that benefit from having a preview mechanism. We should gather quantifiable metrics when it comes to performance and time to completion for a given flow, as well as evaluating the less-objectively-quantifiable perceived performance. There may come a time where the worlds converge; however, that time is not now.

    The feature plugin merge window is currently scheduled for June 17th. We have 8 days to get the Menu Customizer plugin ready for merge. Feature plugins must meet several criteria to be considered for inclusion in a release. To meet this criteria, the flow team has started testing and documenting flow and visuals for the menu customizer as well as the recently landed navigation changes. Merge criteria include identifying flows through the customizer, creating visual records of those flows, and creating flow comparisons of existing flow through Appearance > Menus versus flow through the customizer. This is a great and necessary way to contribute that requires no coding. All you need to do is take screenshots and publish them as a captioned gallery using the tool we’re making together, WordPress. We endeavor to be an Alan Lomax of flow, capturing and cataloging real user scenarios. Please help us capture the flows through Appearance > Menus used by you and your clients. We need this information to ensure our new interfaces are mindful and aware of how WordPress is actually used. Information on how to test and contribute visual records is available on the 4.3 development tracking page.

    @ryan, @helen, @designsimply

     

     
    • codezag 3:59 pm on June 9, 2015 Permalink | Log in to Reply

      the database structure of the menus will be changed ?
      is there any chnages to the menu walkers & database ?

      thanks

      • Fabien Quatravaux 7:49 am on June 11, 2015 Permalink | Log in to Reply

        As far as I know, this menu customizer will not introduce any change visible on the front-end side : no database structure change and no change to Menu Walkers. The only issue is about plugins or themes that added features to the Appearance > Menu admin page : those features may require some work to be available in the new menu customizer.

    • Frankie Jarrett 4:02 pm on June 9, 2015 Permalink | Log in to Reply

      Great to see that the core team is so committed to advancing the Customizer! I really believe it’s a glimpse into the future for a more JS-driven WordPress. Takes a bit of time to steer a ship of 75 million sites, but I know we’ll get there, and we’ll do it responsibly without leaving folks behind :-) /fives!

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

      Ryan,

      A very thorough synopsis of the current plan.

      Thank you!

    • kevinwhoffman 4:49 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan, thanks for the update. The parallel development of the Menu Customizer alongside maintenance of the existing Menus screen is a good strategy moving forward until the Customizer is better proven.

      I also appreciate the rationale behind the importance of live previewing in different use cases. The more guesswork we can take out of the editing process, the better.

    • Jon Brown 4:52 pm on June 9, 2015 Permalink | Log in to Reply

      Great summery Ryan. I think the backlash against the menu customizer would have been a lot tamer if the proposal hasn’t included removing the appearance/menu page and stating that “this was the solution” for all the long un-addressed bugs in the appearance/menu page.

      Personally I don’t like the UI/UX of the customizer. I think stuffing that much GUI in the side panel is a mistake and editing should happen directly “on the page”. I wouldn’t object strongly to menu editing being added to the customizer panel as on option though, especially since I can always disable it like many of the customizer controls my client base find cluttered and confusing.

    • Morten Rand-Hendriksen 5:14 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan is a calm shore in a raging storm.

      • George Stephanis 6:45 pm on June 9, 2015 Permalink | Log in to Reply

        Yes, behold my lord Boren, the rock, the hard place, like a wind from Texas he sweeps by blown far from his homeland in search of glory and honor, we walk… in the garden of his turbulence!

        (as paraphrased from A Knight’s Tale)

    • Gabe Shackle 5:28 pm on June 9, 2015 Permalink | Log in to Reply

      It’s a great addition to WordPress but the release approach has been terrible. Virtually all the opposition to the Customizer could have been avoided if it didn’t seem like everyone was being forced to use it.

      Things like changing the Widgets link from the admin bar, requiring all settings being in the Customizer by the TRT, and then with this last push that included language to remove the menus admin completely from the dashboard, it’s no wonder people were fairly upset and wrote the entire system off.

      If it had simply been released like this:

      “Check out this great new way to manage menus and widgets.”

      Rather than:

      “Here is the new way to manage widgets and menus. We’re going to be removing the interface you’re familiar with because we feel this new method is better and we don’t have enough resources to maintain both.”

      There would have been almost no push back at all. If the Customizer is truly as great as its developers say, let it stand on it’s own and prove it.

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

        Let’s take a moment to reflect on reactions being similarly imperfect in language choices and emotive content, and the very real effects that has on attracting and retaining the contributors we need to be able to maintain and improve those interfaces. Continuing to snipe at each other about tone, semantics, and hypothetical “should”s as though everything is predictable is not particularly productive.

        • Gabe Shackle 5:52 pm on June 9, 2015 Permalink | Log in to Reply

          I was merely offering my perspective and a possible reason for the negative reaction. No sniping intended at all.

        • PeterRKnight 10:22 pm on June 9, 2015 Permalink | Log in to Reply

          I thought a lot of the (unfair) reactions were coming from a lack of understanding about why these changes are happening and the way they are coming about. It’s always painful to see folks talking like there’s some kind of powertrip happening amongst some illusory ruling elite.

          But I’m agreeing with Gabe here, I think better communication would have prevented some of the kneejerk reactions that can be demotivating toward the developers.

          Because Gabe is right in that some people are interpreting this as tools being taken away from them, instead of being excited about a new powerful way of managing menus.

        • dmccan 3:26 pm on June 12, 2015 Permalink | Log in to Reply

          This post is great. It communicates and helps people to understand the thinking, planning, work, and process.

          Compared to some feedback I’ve seen, the feedback to this post has mostly been positive and generally constructive. We are all human and learning along the way. It is important to encourage and acknowledge contributions as well as provide constructive feedback. In this case the constructive feedback is that more good communication, like this article, is helpful.

    • Weston Ruter 7:02 pm on June 9, 2015 Permalink | Log in to Reply

      Thank you for writing this, @boren.

    • Knut Sparhell 7:36 pm on June 9, 2015 Permalink | Log in to Reply

      It’s already said, but again: Thank you for writing this, @boren. Record the flows of common tasks, on every kind of device.

    • Jose Castaneda 7:52 pm on June 9, 2015 Permalink | Log in to Reply

      Great write-up! Thank you for this. :)

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