WordPress.org

Make WordPress Core

Updates from February, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Rockwell 7:14 pm on February 4, 2016 Permalink |
    Tags: ,   

    Week in Core, Jan. 26 – Feb. 2 2016 

    Hi everybody! Welcome back to the latest issue of Week in Core, covering changes from January 26th [36407] – February 2nd [36470], changesets [36407-36470]. Here are the highlights:

    • 64 commits
    • 16 contributors with props
    • 83 tickets created
    • 6 tickets reopened
    • 45 tickets closed

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help 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.

    Code Updates

    Networks and sites

    Database

    • Allow loading when only the mysqlnd extension is loaded. [36434] #33261

    Performance

    • Add a close() method to wpdb, for when the connection needs to be manually closed. [36433] #34903

    Customizer

    • Fix searching for available nav menu items by updating reference to nonce. [36432] #35617
    • Export nonce, theme, and url app settings in preview as exported in pane. [36414] #27355, #35617
    • Improve parity between JS Setting models in preview with JS Setting models in pane. [36407] #27355, #35616

    Media

    • In wp_read_image_metadata() make sure that IPTC keywords are UTF8 encoded. [36429] #35316

    Menus

    • Avoid displaying two spinners when adding selected menu items. [36427] #35682
    • After [36379] prevent “Quick Search” form submission when pressing Enter. [36426] #35374
    • Remove a redundant and unused 0 parameter from the Delete Menu link on the nav menus admin screen. [36419] #35641

    Comments

    • Add back $req variable in comments_template(). Reverts [36322]. [36425] #35473
    • Add a back link to wp_die() comment form submission error display. [36424] #4332
    • Fix set up/tear down of post types in comment query test. [36415] #35633

    Install

    • Improve the install page language chooser button style. [36423] #34547

    UI

    • Remove all the occurrences of the old CSS clearfix. [36422] #26396

    Multisite

    • Add the global cache group sites to restore_current_blog() and wp_start_object_cache(). [36413] #32450
    • Add the global cache group networks to restore_current_blog(). Missed in [36258]. [36411] #35251

    General

    • Simplify action placement in update_metadata(). [36420] #35652
    • Revert changes to wp_validate_redirect()  [35792]. This causes a regression and causes redirects to potentially fail. [35792]  #5114, #34028
    • Pass additional params to get_archive_links filter. [36418] #35573

    Docs

    • Document the difference between site_url() and home_url()[36408] #35238

    External Libraries

    • Update Random_Compat to the latest version (1.1.6). [36421] #35665

    Props

    Thanks to @afercia, @boonebgorges, @dd32, @ericlewis, @helen, @jorbin, @kouratoras, @nexurium, @ocean90, @pento, @rachelbaker, @sebastianpisula, @shamess, @Shelob9, @westonruter, and @wonderboymusic for their contributions!

     
  • Adam Silverstein 8:14 am on January 27, 2016 Permalink |
    Tags:   

    Feature Plugin chat notes for Jan 26 

    Agenda

    • Review the feature plugins for status updates from leads
    • Open floor for feature plugin proposal

    Feature Plugin Updates

    • Background Image Cropper: @celloexpressions asked for feedback for the Background Image Cropper. Current thinking is this is better explored as a standard enhancement for core. See #32403.
    • Customizer: @westonruter left status on the blog post for the Customize Pane Resizer, Customize Device preview (along with @celloexpressions), Selective Refresh, and Transactions. Please comment there if you’re interested in helping out where needed (especially requested for the Pane Resizer).
    • Fields API: @sc0ttkclark updated: term add/edit is in: props @technosailor. Team has been working on simplifying the code required for each screen implementing the Fields API. Scott posted an update on make/core and reports getting lots of feedback (especially from @helen, @drew, @technosailor & @celloexpressions)
    • Shiny Updates:  @obenland updated – Lots of progress in the last week. @ipstenu helped tremendously in getting it multisite compliant. Team decided to not pursue shiny activations/deactivations for a whole set of reasons, mostly around redirects on subsequent page loads, and fatal error protection.
      Currently working on enabling theme updates without having to open the modal, and revamping update-core.php.  An update will be posted to the make/core blog soon. The team needs more feedback and testing! Testers can get the current plugin from the wordpress.org repository.
    • WP-API: @danielbachhuber updated – released beta 11 yesterday. The team is meeting in person (minus @rachelbaker) this week at A Day of REST. Summary: in the home stretch, but there’s a ton more work to do. Friday’s contributor day (at the Day of REST) will hopefully get other people diving in and contributing to the final push.

    Open Floor

    The full logs are available on Slack.

     
    • jrf 10:52 am on January 27, 2016 Permalink | Log in to Reply

      I’d love to continue the discussion on Plugin Dependency management within WP.
      We’d very much would like to invite everyone to give their opinion on the direction we’re thinking of taking though this survey: http://goo.gl/forms/Fq1gbY9vCW

      We’d really appreciate getting as many opinions as possible about this. Thanks!

      • Felix Arntz 11:50 am on January 27, 2016 Permalink | Log in to Reply

        I just took the survey, I have a few comments on the approach.

        I certainly like that multisite will be supported, this is definitely a requirement anyway. 🙂

        About the dependency management: although I personally would prefer a JSON file, I think the theme/plugin header way is more the WordPress way, and a lot easier. People new to WordPress and even to development should be encouraged to start creating plugins/themes – external libraries/library plugins make this a lot easier, but I’m afraid a JSON file is too complex. Maybe both methods should be supported: while only the JSON approach would support the full functionality of dependency management, the file header would still allow to at least require plugins listed on wordpress.org with a minimal version number (there’s not really room in there to do more complex things). If someone needs external plugins or something like that, that should only be possible using JSON.

        The other thing is, in my opinion the recommendations feature should not be part of the feature plugin. Standard dependency management does not handle recommendations either, and I think this goes into kind of an advertising direction which I wouldn’t like to have in WordPress Core.

        I’m looking forward to this project and I’m happy you make these efforts to create a feature plugin. I think the full power of this feature however could only be leveraged if the wordpress.org plugins API would be adjusted as well to contain dependency information as this would allow notifications prior to installing which I think is even more elegant than notifications before activating (also due to the problems that this would bring on multisite). Anyway, first things first! 🙂

    • Ryan Boren 3:33 pm on January 27, 2016 Permalink | Log in to Reply

      Beta testing is much easier when feature plugins are kept up-to-date in the plugin repo. This allows using the built-in WP update mechanism to follow development. Our beta testing onboarding, such as it is, relies on feature plugins being updated regularly.

      A survey of https://wordpress.org/plugins/browse/beta/ and https://make.wordpress.org/core/features-as-plugins/:

      • Background Image Cropper: Last updated one month ago in the plugin repo. The features as plugins entry is bare.
      • Customize pane resizer: This is listed in neither browse/beta nor features-as-plugins.
      • Customize Preview Responsiveness (aka Customize Device Preview): The Customizer UI Experiments plugin was last updated two months ago. This is called three different things.
      • Customize Partial/Selective refresh: The plugin hasn’t been updated for 6 months.
      • Customizer transactions: I don’t see this in browse/beta or features-as-plugins.
      • Fields API: This is not listed in browse/beta. Does it even exist in the plugin directory?
      • Shiny Updates: This is in browse/beta and kept up-to-date. As such, I’ve been testing it.
      • WP API: This is in browse/beta and kept up-to-date. It is pretty much the only feature plugin to post on make/core regularly and do calls for testing.

      Court beta audiences. Update plugins in the plugin dir, preferably nightly. Keep features-as-plugins up-to-date. Publish calls for testing to make/core. Here’s a call for testing template and checklist. http://simp.ly/publish/XrHJDL

    • Ryan Boren 8:04 pm on January 27, 2016 Permalink | Log in to Reply

      If you have the beta tester plugin, feature plugins can be installed from Plugins > Add New > Beta Testing. Details here: https://make.wordpress.org/core/handbook/testing/beta/

  • Mike Schroder 5:42 am on December 11, 2015 Permalink |
    Tags: ,   

    December 10 Meeting Summary and 4.5 Call for Volunteers 

    We gathered together after the marvelous release of 4.4. Many congrats to @wonderboymusic, his deputies @sergeybiryukov and @ocean90, and all contributors who helped out! See the full transcript for the entire chat.

    On 4.4

    What’s Next?
    @helen is building a product design team that is kicking off shortly. I’m excited about this — it’s an opportunity to really step up our game in the UX space. She’ll be building out a few projects and calling for volunteers on make/design, so watch there if you’re interested in getting involved.

    Officially, 4.5 doesn’t kick off until early January, but I’d like to start off with a ready-to-go set of teams. The time between now and then is also great for preparing feature plugins that you’re interested in seeing merged.

    4.5 Call for Volunteers
    Currently looking for those interested in:

    • Being a Release Backup/Deputy
    • Contributing to Week in Core Summary Posts
    • Working on a particular development focus or feature

    If you’re interested in contributing in any of these areas/roles, please leave a comment! Feel free to ping me in the Make WordPress Slack (@mike) if you have any questions on these roles.

     
    • WP Sites - Brad Dalton 5:56 am on December 11, 2015 Permalink | Log in to Reply

      I’d like to be a volunteer & contribute however according to my competitiors, i don’t know what i’m doing, my code doesn’t work and i don’t know anything about WordPress!

    • yehudah 7:03 am on December 11, 2015 Permalink | Log in to Reply

      I would like to help, I don’t care in which area.

    • Nick Halsey 7:38 am on December 11, 2015 Permalink | Log in to Reply

      Count me in for working with @westonruter and others on the Customizer. Most of my availability will be in the next month, so I’m planning on trying to get moving on several UI and UX-related items (including possible new features). As I mentioned in the meeting, a possible theme of eliminating dead-ends to improve user flow is emerging and I’ll expand on that once it’s more fleshed out.

      Also, I just realized that the work to re-imagine the toolbar that was done during 4.3 was never completed – #32678. I think that should be doable for 4.5, and would help improve flow between the frontend and admin.

    • Varun Sridharan 9:17 am on December 11, 2015 Permalink | Log in to Reply

      I would like to volunteer and contribute my time to WordPress 🙂
      i am basically strong in development. so i can do development or being a release backup/Deputy

    • Justin Greer 11:19 am on December 11, 2015 Permalink | Log in to Reply

      Throw me in somewhere needed! Just let me know where! 🙂

    • Ahmad Awais 2:50 pm on December 11, 2015 Permalink | Log in to Reply

      Would love to contribute again. @westonruter‘s idea on the Customizer SPA looks pretty good to me.

    • Rami Yushuvaev 1:50 am on December 12, 2015 Permalink | Log in to Reply

      I will defiantly continue contributing to core!

    • Morgan Estes 2:32 am on December 12, 2015 Permalink | Log in to Reply

      I’m interested in working on inline JS docs, and giving the Toolbar some love. Oh, and Week in Core. 🙂

    • Joe McGill 4:44 am on December 12, 2015 Permalink | Log in to Reply

      I’d like to see if we can push forward the improved imagick compression settings from the RICG plugin project and explore the possibility of streamlining some of our media internals, maybe something like #23424.

    • Najum Rahim 4:21 pm on December 12, 2015 Permalink | Log in to Reply

      I would to contribute efforts and time to WordPress.

    • Scott Kingsley Clark 4:21 pm on December 12, 2015 Permalink | Log in to Reply

      I’ll be focusing on Fields API, not sure if it’ll be ready in time for the 4.5 merge window but I’ll be hopeful!

    • Mostafa 8:36 am on December 31, 2015 Permalink | Log in to Reply

      I really want to contribute on WordPress Core…..but how?
      Can i contribute on core just by fix a bug and make a patch for it?

    • vinorodrigues 12:49 am on January 1, 2016 Permalink | Log in to Reply

      I can help.

    • ucheng 6:05 pm on January 4, 2016 Permalink | Log in to Reply

      I have no experience on contributing to WordPress core, but I really want to make it in 2016. Since I have made a plugin for Layers WP, I want to focus on Customizer and make it better!

    • SlimBob 2:11 pm on January 5, 2016 Permalink | Log in to Reply

      I’m interested in working on a particular development focus or feature.

  • morganestes 1:45 am on October 13, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 28 – Oct. 11, 2015 

    Welcome back to the latest issue of Week in Core, covering changes from Sept. 28 – Oct. 11, 2015, changesets [34659][35029]. Here are the highlights:

    See that ↑ right there? That’s an oEmbed. And it’s loaded from inside this site.

    Feature Plugins Merged

    The Responsive Images, oEmbed Provider, and the “baby” REST API feature plugins have been merged into core. Grab the latest version of trunk and test them out.

    WordPress logo with wordmark below

    Responsive images in your posts. Just upload and insert!

    Potent Notables

    These changes were big enough to merit their own blog posts:

    Deeper Reading

    Some commits pack in a lot of info, from detailed background to best practices in using hooks. Here are a few worth reading the entire commit message:

    • WP_Term class introduced [34997] #14162
    • Fix scalability performance problem for previewing multidimensional settings in the Customizer. [35007] #32103
    • Ensure that wp.customize.Widgets.savedWidgetIds is defined up front. [34883] #33901
    • The history and implementation of oEmbeds. [34903] #32522
    • Improve role-related arguments in WP_User_Query. [34875] #22212
    • Use wp_installing() instead of WP_INSTALLING constant. [34828] #31130
    • Introduce *_network_option functions for Multisite installs. [34777] #28290
    • Ensure that comment permalinks reflect pagination. [34735] #34068, #34073

    (More …)

     
  • morganestes 7:37 pm on September 29, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 21-27, 2015 

    Oh Snap!, it’s time to usher in a new edition of Week in Core! If you have the time, throw a house party with some friends and read the full force of changes on Trac; if not, don’t sweat it — take simple pleasure in these highlights.

    This post covers changesets [34362][34658], committed during Sept. 21–27, 2015. Let’s give a hi-five and some TLC to the 102 contributors for a combined 296 updates! Together, we’re making WordPress nice & smooth.

    (More …)

     
  • Weston Ruter 2:00 pm on September 23, 2015 Permalink
    Tags: , ,   

    Outlining a possible roadmap for the Customizer 

    Planning for the future is a necessary and important part of the WordPress development process. As we consider the future of WordPress – both as a whole and individual features – we publish proposed roadmaps to encourage greater discussion and give insight into the core team’s thought process.

    The process of creating a roadmap is just as important as the vision behind it and the final roadmap itself. This process gives the entire community an opportunity to research and document history, define what specific items can be accomplished to bring us closer to the vision, and outlines how those tasks fit together within a possible timeframe.

    What follows is a potential roadmap for the Customize component. If you’re interested in the future of live preview in WordPress, now is the perfect time to get involved and leave your feedback.


    A couple of months ago, the WordPress lead developers met with the maintainers of the Customize component to discuss the future of live preview in WordPress. The goal of the chat was to come up with a potential roadmap for both the component and for how live preview can improve the user experience of WordPress for all users.

    The ultimate goal of live preview in WordPress is to create user trust and remove the “save and surprise” inherent in some of the backend features.

    After a lot of discussion, the group decided to target the following goals over the next two years:

    • Considerably improve performance.
    • Continue iterating on current live preview features to ensure they are solid and as easy-to-use as possible, including theme browsing and installation, menus, and widgets.
    • Experiment with new and different user interfaces. If we were creating live preview today, what would it look like? In what ways can we ease the feeling that you’re looking through a “porthole”?
    • Removal of the ambiguous mode. Currently, the Customizer is contained in a sidebar without the admin toolbar, but ideally there is the admin and the theme, and no in-between. One direction this may go is enabling “Customize” on the front end to immediately load the Customizer controls.
    • Experiment with a guided new user experience (NUX). Live preview lends itself to site setup. How can we improve the live preview experience and combine it with the NUX? Consider a “setup wizard” use case and ensure the flow has no dead ends, i.e. users can customize everything in one.

    Those overall goals for live preview in WordPress can be rewritten into some specific features that are in development or planned for the future of the Customize component. These include:

    • Transactions. This re-architecture of some of the Customizer internals improves compatibility with themes by loading the preview using a natural URL, and allows Ajax requests or even REST API requests to be previewed. It also allows the preview to be viewed independently of the Customizer, so changes can be shared for others to review. See #30937.
    • Selective refresh. Only a piece of the page will need to be refreshed when this backend feature is implemented. (Formerly known as “Partial Refresh”.) Currently, this is available for menus in the Customizer. This eliminates duplication of display between PHP and JS, keeping it DRY. See #27355.
    • Concurrency. Allows for “locking” settings using the Heartbeat API, improving the overall user experience by preventing users from overwriting each other’s changes. See #31436.
    • Revisions. Enables plugin developers to add features like draft, roll back, and scheduled changes (e.g. “change my background on January 1”). This builds upon transactions, as the setting changes are staged in a transaction, and this facilitates settings to be revisioned and for settings to be scheduled. See #28721, #31089.
    • Theme installation. Iterates on and completes the theme browsing experience.
    • Responsive preview. Iterates on the concept of live preview by giving users a better idea of what their site will look like on other devices. See #31195.
    • Bootstrapped Customizer. Lazy-load the Customizer into the current frontend view without having to leave the page. With selective refresh implemented, inline controls and frontend bootstrapping would be possible since full-page refreshes would no longer be required.
    • Improvements for both touch and small devices.

    Beyond those features, the group identified some specific changes that should be prioritized, in conjunction with the features planned:

    • The sliding animation between panels should feel more like “moving panels” (see: iOS).
    • Keyboard navigation should be consistent and clear.
    • Identify “dead ends” in the interface and remove them, when possible. For example, prior to menus in the Customizer, it was not possible to customize that aspect of your site’s design with the Customizer.

    The concepts surrounding live preview and the Customizer have been in development for a long time. Many of the concepts from Elastic Theme and the Visual CSS Editor have been incorporated over time. Over the next few years, experimentation with these concepts will likely take place in feature plugins. For example, this team may experiment with inline content editing, where it makes sense in the context of customizing a site. Another path for exploration is simple theme customization – e.g. change the header font, change the sidebar color, or change the width of the sidebar.

    As with all components and new features, we shouldn’t be afraid to experiment and fail and should continually push for new experiments and ideas, especially in the context of feature plugins. Further, some of the above experiments may not make it into core, but are meant as a general direction that live preview should take in WordPress.

    Taking these features together, below is a sequence outlining a possible roadmap for live preview and the Customize component in general, along with estimated targets. Please note that this is a proposed roadmap and is entirely dependent on contributor involvement. Additionally, many of these things will take place in a feature plugin prior to core inclusion.

    • Partial refresh. Performance Improvements. (Target: 4.4)
    • Responsive Preview. Transactions. (Target: 4.5)
    • Concurrency. Revisions. Theme Install. Beginning of NUX wizard. (Target: 4.6)
    • Focus on touch screen / small device improvements. (Target: 4.7)
    • Developer API improvements based on feedback from plugin developers. (Target: 4.8)
    • Improved UI after experiments in 2016. NUX “wizard mode.” (Target: 4.9)

    Live preview is one of the most critical features in WordPress as we continually combat “save and surprise.” The Customizer in its current form provides an improved user experience to WordPress users when customizing their site’s design. Each feature mentioned above is a continuation of the live preview concept, building and improving upon the Customizer.

    Everything above is just a proposal and we need your feedback to ensure it is the right direction. If you’re interested in any of the above, comment here with your feedback, or join the team in #core-customize.

    This post was a collaboration between @helen, @nacin, @mark, @celloexpressions, @samuelsidler, and yours truly.

     
    • Davide 'Folletto' Casali 4:46 pm on September 23, 2015 Permalink | Log in to Reply

      > NUX wizard

      I find a bit dangerous to think of it as a “wizard”, mostly because usually wizard UIs have specific connotations. We should think of it more as a “tutorial” like games do. Not separate UIs, but a guide through an existing UI that can be dismissed if you’re expert, or done partially, or followed all along. 🙂

      Other than that… this seems AWESOME. 🙂

      Performance is really the main thing there. That alone would reap huge benefits. Then you add Live Preview and well, boom! 🙂

    • Daniel Bachhuber 6:11 pm on September 23, 2015 Permalink | Log in to Reply

      We (Fusion) are very keen to adopt the Customizer as the UX for frontend management, and look forward to helping out with the feature plugins built as a part of the roadmap.

    • FolioVision 12:43 am on September 24, 2015 Permalink | Log in to Reply

      Weston, thanks for the comprehensive and forward thinking report.

      It would be great if the interface paradigm for Customizer would remain constant for the exterior world (i.e. agencies and clients) while a dev version gets tested by the more progressive among us.

      Perhaps a switch to throw in settings to enable experimental Customizer features? The switch could be retired when Customizer settles a bit.

      • Weston Ruter 4:05 am on September 24, 2015 Permalink | Log in to Reply

        @FolioVision yes, absolutely. This is why most of the new features will be developed in feature plugins so that they will remain opt-in until they are deemed solid for everyone.

    • devolute 4:05 pm on September 25, 2015 Permalink | Log in to Reply

      but ideally there is the admin and the theme, and no in-between.

      Here here! Does this mean that there will be a “front-end” mode, and a “dashboard” mode that fits into the current dashboard so that things can be altered without a preview being available?

      • Weston Ruter 4:16 pm on September 25, 2015 Permalink | Log in to Reply

        @devolute Basically the idea is that there would no longer be a separate “Customizer” URL (wp-admin/customize.php) that you go into. When on any frontend URL, clicking “Customize” would just slide out the Customizer sidebar pane in place. You’d still have the admin bar available and everything else that you would normally when on the frontend, except you’d also be able to make changes to the Customizer as you browse around. So no, this doesn’t have in mind making the Customizer controls available in the wp-admin without a corresponding preview.

        • devolute 4:19 pm on September 25, 2015 Permalink | Log in to Reply

          Ah, I understand your intention. I think my problem is that I’m using the customizer for things like phone numbers, addresses and other options when I perhaps should look at other solutions.

    • Ahmad Awais 3:38 pm on September 26, 2015 Permalink | Log in to Reply

      We at WPTie are slowly yet gradually adopting Customizer in all our themes and plugins (where needed). All in for customizer support in WordPress.

    • Alex Mangini 10:23 pm on September 28, 2015 Permalink | Log in to Reply

      On the “Bootstrapped Customizer” point, is this a move towards inline content editing and possibly even “page builder” type concepts?

      My biggest curiosity about the Customizer and what I really want to use it for as a developer is creating posts and pages without a 3rd party visual editor and without the drawback, as already stated, of guessing what they’ll look like after inputting content into specially built meta boxes or widgets.

      Thanks for doing these write-ups, as I build more and more WordPress plugins/products I find myself lurking around here to better educate myself and plan roadmaps for my own work.

      • Weston Ruter 10:45 pm on September 28, 2015 Permalink | Log in to Reply

        @alexmangini:

        On the “Bootstrapped Customizer” point, is this a move towards inline content editing and possibly even “page builder” type concepts?

        This is already possible, actually. For an example of inline editing, see the Customize Inline Editing plugin. And page builders are also possible now by using widgets in the Customizer. I’m currently working on a site that uses a concept of query-specific widget areas to allow every URL to have custom sidebars configured, where the main content area is just another widget area: this allows drag-and-drop building of pages just with standard widgets and any custom widgets that you define. Widgets still have a lot of room for improvement in Core, but I’m very keen to see them move in the direction of “content blocks” which can be used for building page templates in the Customizer.

    • Nick Halsey 4:19 am on September 29, 2015 Permalink | Log in to Reply

      Thanks for getting this published Weston.

      A couple of additional comments on my end:

      • We need more help. The Customizer can do (and could do) a lot, but without more contributors (not just code), it’ll take time to see big improvements go through. I’d love to see more of an effort to embrace the Customizer throughout various other core projects, and to see more community involvement in Customizer design and development.
      • In the interest of experimentation and building on the benefits of live preview, I’m planning on looking at some ways to integrate things like page templates, post formats, and featured images (with cropping) into the Customizer. While there’s a good chance none of those things will make it into core, I’d like to encourage anyone with any ideas for the Customizer to try them out and offer them for discussion. We’re no where near the limit of what users could do with the Customizer and it’s an amazing framework to build additional features on top of.
      • While many of the topics in the post are fairly developer/backend oriented, it’s important to emphasize that there is still a significant amount of design and UI/UX work to be done, including looking at entirely different approached to the live preview UI concept. Don’t be shy to share your ideas if you have any – the technical side of things is evolving to support pretty much anything we may want to try.
    • pingram3541 3:59 am on November 24, 2015 Permalink | Log in to Reply

      A little late to the game but I just wanted to say thanks for pushing the Customizer forward. I do feel it is given the least amount of attention when it comes feature progression and I can’t figure out why. Yay for menu’s but how did menu’s make it on the plate before posts??? Seriously folks, this is a huge mechanism in which we are losing ground fast to many of the new front end content builders on the web and the Customizer is behind the times.

      @westonruter your example of the Customize Inline Editing is nice but seems only to serve a very narrow focus on ability as it still provides no capability of inline editing for actual post content/post meta. Don’t get me wrong, great working example but real world we need to break outside the box of wp_options, theme_mods…we need simpler access to post objects and other areas in WordPress.

      Again @westonruter looking at your code on the Customize Posts plugin I see that your way of getting around the lack of post object availability is by providing a drop down of all posts/pages of which to perform the query against which is genius. However, it doesn’t seem natural to have to select a page/post when you’re already viewing one in the Customizer already and when needed can navigate to other post/page where their post fields could be provided rather than choose it from a long drop down list, which could become unmanageable on some larger sites.

      So yes, I’m excited for the future and the BIG ONE thing I’d love to see is:

      Access to the current preview’s post object or at least a way to capture the post id for use with $customize_update and $customize_preview. Could be as simple as adding the post id to the $wp_customize object.

      • Weston Ruter 5:54 pm on November 25, 2015 Permalink | Log in to Reply

        @pingram3541 Thanks for the reply.

        I do feel it is given the least amount of attention when it comes feature progression and I can’t figure out why. Yay for menu’s but how did menu’s make it on the plate before posts???

        There are a limited number of people to contribute to each release. @carlhancock wishes that all admin management features could be added to the Customizer at one time instead of one piece at a time, but this is not practical for an open source volunteer effort with three releases a year. As we just saw with Automattic’s Calypso announcement from @matt, it took almost two years and dozens of contributors to re-develop the entire WordPress.com admin into a new JS-driven interface. We don’t have the time or the person power to do that. However, I think that interest is building, and with that, contributors will come.

        Compared to posts, it is relatively much simpler to build support for nav menus in the Customizer. They have a UI that fits in the Customizer pane, and the data model is pretty normalized. Posts, on the other hand, would need a full-on editor experience (inline to the preview) and can have an infinite number of variations to display (shortcodes, media embeds, etc). This is a hard problem to generalize for all themes, but it is something that @iseulde has worked hard on in the Front-end editor plugin. The Customize Posts plugin was developed as a prototype to show the architecture for how posts and postmeta can be managed in the Customizer so that the Front-end editor (or another such plugin) could leverage the Customizer for previewing and staging changes.

        your example of the Customize Inline Editing is nice but seems only to serve a very narrow focus on ability as it still provides no capability of inline editing for actual post content/post meta. Don’t get me wrong, great working example but real world we need to break outside the box of wp_options, theme_mods…we need simpler access to post objects and other areas in WordPress.

        As noted in the plugin’s description, Customize Inline Editing is an example (proof of concept), again to show how inline editing can be implemented in the Customizer. So its focus is intentionally narrow. The approach taken there can be implemented for managing post data inline. See also wp-customize-posts#8.

        on the Customize Posts plugin I see that your way of getting around the lack of post object availability is by providing a drop down of all posts/pages of which to perform the query against which is genius. However, it doesn’t seem natural to have to select a page/post when you’re already viewing one in the Customizer already and when needed can navigate to other post/page where their post fields could be provided rather than choose it from a long drop down list, which could become unmanageable on some larger sites.

        Actually, it’s not a dropdown of all posts/pages. It’s a list of the posts that currently appear in the preview. The dropdown’s options change as you navigate around the site in the preview, meaning that you should only be editing a post in the Customizer that is actually visible in the preview.

        So yes, I’m excited for the future and the BIG ONE thing I’d love to see is: Access to the current preview’s post object or at least a way to capture the post id for use with $customize_update and $customize_preview. Could be as simple as adding the post id to the $wp_customize object.

        The future is now. As noted above, Customize Posts does it to communicate the list of posts in the preview to the pane for the dropdown. Also @ericlewis has implemented this in wp-custom-css-per-post. I also have on my todo list to write a post on how to create a “metabox” in the Customizer for managing postmeta for the current singular post in the preview.

    • Philip Ingram 6:57 pm on November 25, 2015 Permalink | Log in to Reply

      Thanks for the quick and detailed response. I’d love to contribute as long as my foo is strong enough, let me know how I can help or if there is a more appropriate forum for continuing this discussion =)

      Additionally, regarding @ericlewis ‘s wp-custom-css-per-post, I already have a working live css editor using codemirror to provide live updating of the preview as well as updating the hidden Customizer input setting transport to postMessage and this works great allowing live preview before saving but also allowing the saving. This has greatly improved efficiency of my front end design workflow. However this currently is limited to my site-wide custom css via theme options. What brought me here in the first place was seeking out a way to GET and POST the current posts meta which I have a custom css per post option built into my themes. So maybe I can get with @ericlewis and we can figure this out. Looking at WP Customize Posts I see the query for $_POST[‘customized’] to iterate though and retrieve post id’s but when using the Kirki toolset (I’m sure the class needs something extra for this) it’s always an empty array upon initial load of the Cusotmizer and that is where I’m stuck currently. I just need the darned post id!

      You mention that posts are way more complex than menus and yes there’s no debate there, however in the time being, if there was a simple way to capture the current previewed post’s id or maybe a clearer example how to retrieve it, that opens the door for us to pioneer further without waiting for a more core-driven method of updating post data via the Customizer.

    • Philip Ingram 10:20 pm on November 25, 2015 Permalink | Log in to Reply

      @westonruter Yes! Thank you for this.

  • morganestes 9:08 pm on September 21, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 13-21, 2015 

    Welcome to the Week in Core — Week Four, with super-exciting news from around WordPress-land, and Core changes and updates for Sept. 13–21, 2015 (commits [34093][34361]). This week’s core contributors number 106! I’m especially jazzed about the number of new names on the list, and want to thank everyone for your effort this week.

    News you can use

    The WP REST API team submitted a proposal to merge the plugin into core, with a two-phase integration plan. The merge proposal blog post also does a nice job of presenting the history of the plugin and some use cases.

    Do you use my-hacks.php in your site? Don’t. (A quick search through the plugin and theme repos shows only 10 plugins and 3 themes that mention the file.)

    Multisite is making some pretty big changes, including the addition of the  WP_Network class. Check out this blog post, which outlines some of the changes and a roadmap for future updates for 4.4.

    Interested in the user-focused part of WordPress? Of course you are! Join in the conversation about “Potential UI/UX projects in core.”

    Code changes

    Here are some highlights from the 268 change sets published to Trac; the complete report is available online in plain-text format for a bit more in-depth coverage.

    (More …)

     
  • morganestes 9:04 pm on September 16, 2015 Permalink
    Tags: ,   

    Week in Core: Aug. 31 – Sept. 12, 2015 

    Welcome to the Week in Core, with updates from weeks 2 & 3: Aug. 31 – Sept. 12, 2015, changesets [33821][34092].

    It’s been a busy couple of weeks in Core, with almost too many changes to count (for the record, this one covers 271 commits!). I’m going to keep this update shorter than usual and highlight some of the bigger changes.

    If you’re interested in helping write this weekly post, ping @morganestes in #core-weekly-update on Slack.

    Special Note: WordPress 4.3.1 was released this week, with three security-related fixes. Be sure to update your sites!

    Here’s some highlights of recent changes in core, along with some future plans and ongoing initiatives. Remember, Core moves pretty fast. If you don’t stop and look around once in a while, you could miss it.

    • WordPress will support PHP7 when it’s released. Huzzah!
    • HTTP/2 is coming! Here’s a list of tickets that need attention to get WordPress ready.
    • Get involved in Twenty Sixteen, which is in active development on GitHub.
    • Write better commit messages. The world will thank you for it. 🙂
    • As described in this post by @johnbillion, the show_ui flag for post types now gets fully honored. See #33763 for the ticket discussion.
    • A new helper function, wp_validate_action( $action = '' ), was introduced in [34059] and is used throughout admin instead of directly accessing $_REQUEST['action'].
    • A new file, wp-admin/includes/noop.php, was created to load all of the noop functions for load-script|styles.php and is only loaded by those files. DRYs in the process. [34037] #33813
    • Schema change introduced in [34030] to increase the length of wp_options.option_name to 191 chars. #13310
    • Implement a priority system for Help Tabs to add them at specific positions. [33985] #19828
    • Multisite: Don’t allow sites to be created with the following reserved slugs: wp-admin, wp-content, wp-includes [33952] #33615
    • Updated recommendations for minimum versions of PHP (5.6) and MySQL (5.5), with a special note that Oracle only actively supports MySQL for 5 years after a General Availability release. [33937] [33946]

    For the full report, visit https://core.trac.wordpress.org/log/?verbose=on&format=changelog&rev=34092&stop_rev=33821&limit=400&mode=stop_on_copy.

    Thanks to @adamsilverstein, @afercia, @amereservant, @ankit-k-gupta, @antpb, @austinginder, @azaozz, @BdN3504, @benjmay, @boonebgorges, @bradt, @brettz95, @celloexpressions, @cgrymala, @Cheffheid, @chriscct7, @codeelite, @CoenJacobs, @danielbachhuber, @daniellandau, @dannydehaan, @dd32, @dimadin, @dipeshkakadiya, @dlh, @DrewAPicture, @dustinbolton, @egower, @enshrined, @ericdaams, @ericlewis, @extendwings, @figureone, @filosofo, @gaelan, @GaryJ, @gitlost, @gnaka08, @gradyetc, @gregrickaby, @hauvong, @helen, @imath, @ippetkov, @iseulde, @ixkaito, @jazbek, @jeffstieler, @jeremyfelt, @jesin, @jobst, @johnbillion, @joostdevalk, @jorbin, @juliobox, @JustinSainton, @kevinlangleyjr, @khromov, @kitchin, @kraftbj, @lancewillett, @liljimmi, @lukecarbis, @macmanx, @MatheusFD, @mehulkaklotar, @mercime, @metodiew, @michielhab, @MikeHansenMe, @miqrogroove, @mitchoyoshitaka, @mordauk, @morganestes, @mrahmadawais, @mrmist, @Mte9, @nacin, @netweb, @nikeo, @nikolovtmw, @nofearinc, @obenland, @ocean90, @OriginalEXE, @Otto42, @paulwilde, @pavelevap, @pento, @peterwilsoncc, @racaseh, @rachelbaker, @rajnikmit, @rmccue, @rommelxcastro, @sc0ttkclark, @scribu, @SergeyBiryukov, @sillybean, @solarissmoke, @stevehenty, @swissspidy, @tmatsuur, @trepmal, @tyxla, @umeshnevase, @utkarshpatel, @wen-solutions, @wenthemes, @westonruter, @wojtekszkutnik, @wonderboymusic, @yoavf, and @zeo for their contributions!

     
  • morganestes 5:03 am on September 2, 2015 Permalink
    Tags: ,   

    WordPress Core Weekly – Aug. 24-30, 2015 

    Welcome back to the weekly core development recap post, with highlights from Trac changesets and other development updates for 4.4. This week’s update covers changesets [33721][33820], Aug. 24-30, 2015. That’s a lot of changes, but there are a few that developers need to be especially aware of:

    • File restructuring: new class and functions files have been introduced, and existing files used as loaders for the new files for backwards compatibility.
    • File and class documentation enhancements: ensuring every file gets a standard file header, even if that file only contains a class that is itself documented.
    • Switching themes now takes menu locations into account so the new theme (maybe) gets the locations of the current theme.
    • New hooks introduced: 'invite_user' (Multisite users) and 'wp_verify_nonce_failed'.
    • The Twenty Sixteen theme is being developed on GitHub.

    Now on to the firehose…

    Administration

    • Bump h3 headings to h2 on various admin screens for better accessibility:
    • Network Admin: Hide the bulk actions checkbox for super admins. [33777] #28529
    • Avoid PHP notices in redirect_canonical() and _wp_menu_item_classes_by_context() if $_SERVER['HTTP_HOST'] is not set. [33775] #32229

    General

    • Remove error from the query variables when cleaning up a URL in wp_admin_canonical_url(). [33770] #32847
    • Prevent unintended password change after clicking “Generate Password” and then “Cancel” when editing a user profile. [33766] #33419
    • When wp_json_encode() calls json_encode(), the latter will generate warnings if the string contains non-UTF-8 characters. No one likes warnings, so we need to do something about that. [33747] #33524
    • Add oEmbed support for ReverbNation. [33745] #33207
    • Remove rounded corners from “Choose from the most used tags” result in Tags meta box. [33742] #31560
    • Add some more data for shortcode unit tests. [33740] #33455
    • Allow these CSS properties in KSES: min-height', 'max-height', 'min-width', 'max-width' [33739] #31949
    • Pass option name to option and transient filters with dynamic names. [33738] #28402
    • In get_home_url(), import the $pagenow global to avoid having to check if it exists before comparing against it. [33736] #33545
    • In WP_Users_List_Table::single_row(), $actions is not always set before being used. [33735] #33491
    • foreach is a statement, not a function. [33734] #33491
    • Instead of [33713], allow WP_Posts_List_Table::get_bulk_actions() to check edit_posts AND delete_posts. [33733] #29789
    • TinyMCE: ensure the wordpress plugin is loaded before calling _createToolbar(). [33728] #33393
    • With a few modifications in wp-admin/menu.php, we can eliminate the extra logic for Post and Page menu registration. Instead, they can just declare menu_position on post type registration. [33723] #16865
    • WP_Query: add changelog for the title param after [33706] [33722] #33074

    Restructured some files for separation of purpose, so class files only contain classes, functions files only contain functions, and the existing file loads the new files for backwards compatibility.

    Taxonomy

    Move WP_Tax_Query into class-wp-tax-query.php and functions into taxonomy-functions.php; taxonomy.php contains only top-level code and loads the new files. [33760] #33413

    Posts

    Move WP_Post into class-wp-post.php and functions into post-functions.php. post.php contains only top-level code and loads the new files. [33759] #33413

    Roles

    Move classes into their own files, and functions into its own:

    • class-wp-roles.php
    • class-wp-role.php
    • class-wp-user.php
    • capbilities-functions.php

    capbilities.php contains only top-level code and loads the new files. [33752] #33413

    HTTP

    Move classes into their own files and functions into its own:

    • class-wp-http-cookie.php
    • class-wp-http-curl.php
    • class-wp-http-encoding.php
    • class-wp-http-proxy.php
    • class-wp-http-streams.php
    • http-functions.php

    http.php contains only top-level code and loads the new files, so this is 100% BC if someone is loading http.php directly.

    class-http.php requires functions from http.php, so loading it by itself wouldn’t have worked.

    WP_Http remains in class-http.php. [33748] #33413

    Meta

    Move WP_Meta_Query into class-wp-meta-query.php and functions into meta-functions.php. meta.php contains only top-level code and loads the new files. [33761] #33413

    Rewrite

    Move WP_Rewrite into class-wp-rewrite.php, functions into rewrite-functions.php, and constants into rewrite-constants.php. rewrite.php contains only top-level code and loads the new files.

    The rewrite functions have all kinds of cross-dependencies (like WP_Query), so loading the file by itself would have been bizarre (and still is). [33751] #33413

    Comments

    Move WP_Comment_Query into class-wp-comment-query.php, and functions into comment-functions.php. comment.php contains only top-level code and loads the new files. [33750] #33413

    Users

    Move WP_User_Query into class-wp-user-query.php and functions into user-functions.php. user.php contains only top-level code and loads the new files. [33749] #33413

    Widgets

    Move classes and functions into their own files:

    • class-wp-widget.php
    • class-wp-widget-factory.php
    • widget-functions.php

    widgets.php contains only top-level code and loads the new files. [33746] #33413

    Docs

    It’s important for every file in WordPress, regardless of makeup or architecture, to have its own file header, even if the file contains nothing but a class. When parsed, files and classes are mutually exclusive and should be documented with this in mind. [33755] [33756] #33413

    • Bring the file header and class DocBlock summaries for class-wp-widget.php in-line with the intention of the docs standard:
      • File headers: What the file is
      • Class DocBlocks: What purpose the class serves. Mentioning the class name in the class DocBlock is redundant [33816] #33413
    • Add inline-docblocks for the require_once() calls that now bring in the WP_Widget and WP_Widget_Factory classes, as well as general core widgets functionality, as of [33746]. [33758] #33413
    • Add a file header description and @since version to wp-includes/widget-functions.php, introduced in [33746].
      Also adds sub-section headers per the inline documentation standards for syntax. [33757] #33413
    • Add a file header to wp-includes/class-wp-widget-factory.php, created when the WP_Widget_Factory class was moved to its own file in [33746]. [33756] #33413
    • Correct the hook docs for the user_profile_update_errors action. [33769] #33537
    • After [33764], fix docblock formatting for wp_list_categories(). [33765] #33460
    • Use proper array documentation formatting for wp_list_categories().
      This changeset also corrects a few parameter descriptions, and adds a few that
      were previously missing. [33763] #33556
    • Fix copy pasta in wp_cache_decr() doc block. [33809] #33548
    • The type for the $t_time parameter in the post_date_column_time filter docs should be string, not array. [33731] #33540
    • Document the default comment data arguments for wp_new_comment(). [33730] #32369
    • After [33698], wrap the time constants in a DocBlock template. [33737] #33397
    • Clarify the return description for wp_create_user() to illustrate that a WP_Error object will be returned on failure. [33725] #33321

    Add changelog entries for a variety of hook doc parameters added in [33738]:

    hook parameter changeset/ticket
    set_site_transient_$transient $transient [33794] #28402
    site_transient_$transient $transient [33792] #28402
    pre_delete_site_option_$option $option [33789] #28402
    pre_add_site_option_$option $option [33788] #28402
    pre_site_option_$option $option [33785] #28402
    transient_$transient $transient [33783] #28402
    option_$option $option [33779] #28402
    pre_option_$option $option [33768] #28402
    pre_set_site_transient_$transient $transient [33793] #28402
    pre_site_transient_$transient $transient [33791] #28402
    pre_update_site_option_$option $option [33790] #28402
    site_option_$option $option [33787] #28402
    default_site_option_$option $option [33786] #28402
    pre_set_transient_$transient $transient [33784] #28402
    pre_transient_$transient $transient [33782] #28402
    update_option_{$option} $option [33781] #28402
    pre_update_option_$option $option [33780] #28402
    default_option_$option $option [33778] #28402

    Themes

    • Get the correct theme when template and stylesheet were both passed as arguments. Fixes a bug introduced in [21131] where $new_theme got set before the second argument was
      appropriately handled, causing the current_theme option to later always be updated to the parent theme’s name. [33815] #32635

    Widgets

    • Improve/update escaping in default widgets:
      • wrap some variables in esc_attr() before echoing
      • replace some strip_tags() calls with sanitize_text_field()
      • call esc_url() when wrapping some URLs [33814] #23012
    • Improve/update escaping in WP_Widget_Pages. [33813] #23012
    • Switch back to using array_key_exists() instead of isset() for widget instance existence check.
      Reverts unnecessary change in [32602] since array_key_exists() does actually work with ArrayIterator objects.
      Merges [33696] to the 4.3 branch. [33721] #32474, #33442

    Customizer

    Comments

    • Fix the doc block syntax for the 'wp_get_current_commenter' filter. [33811] #33304
    • get_comment_count() currently increments awaiting_moderation when comments are in the trash. This occurs because case 0: will match any value passed to switch that is a string that isn’t specified in the list of cases. This is terrifying.
      Cases for 0 and 1 should be '1' and '0'
      Add unit tests for get_comment_count(). Currently, there are none. [33806] #33414

    I18N

    • Favor using the consistent and agnostic string ‘Attach’ over ‘Attach to a post’ in the media list table. [33810] #33515
    • Make a period translatable. [33802] #33594
    • Switching themes: if the new theme doesn’t have nav_menu_locations defined, but the old theme does, copy the old theme’s nav_menu_locations into the new theme’s theme mods. [33808] #18588

    Media

    • Improve the reliability of the crop returned by image_get_intermediate_size() and add a bunch of unit tests to tests/image/intermediate_size.php. [33807] #17626
    • When inserting an image into a post, the values in wp.media.controller.Library should not default to linking the image when no user settings are present.
      The default display setting value for link is now none. User settings persist and will override or confirm this value based on user actions. [33729] #31467

    Posts, Post Types

    • In get_post_type_labels(), ensure that filtered labels contain all required default values. [33776] #33543
    • Don’t change the View Post button permalink in the sample permalink HTML when updating the slug on a published or future post. [33773] #32954
    • Pass taxonomy name to filters in get_adjacent_post(). [33805] #33568
    • Make post meta box toggles accessible. [33762] #33544

    Multisite

    • Improve the efficiency of is_user_member_of_blog() by removing its use of get_blogs_of_user(). Adds additional tests. [33771] #32472
    • Add 'invite_user' action that fires immediately after a user is invited to join a site, but before the notification is sent. [33732] #33008

    Taxonomy

    • In wp_list_categories(), ‘current_category’ should accept an array of values. [33804] #33565
    • Introduce $hide_title_if_no_cats parameter to wp_list_categories(). [33764] #33460
    • Rename param added to wp_list_categories() in [33764] to $hide_title_if_empty. [33767] #33565
    • Term Splitting: Switch to a faster cron unschedule process to benefit sites with thousands of affected jobs. Fix the cron hook name in the failsafe rescheduler. [33727] #33423
    • In WP_Query::parse_tax_query(), allow ‘cat’ and ‘tag’ querystrings to be formatted as arrays. [33724] #32454, #33532

    Date/Time

    • Simplify the weeks-per-year calculation WP_Date_Query::validate_date_values(). [33803] #30845

    Users

    • Bring network admin user searching to parity with single site user searching by wrapping search terms in asterisks. This means that searches don’t require an exact match and therefore significantly reduces friction when searching for users on the network admin screens. [33801] #32913

    Bundled Theme

    Correct license information in readme.txt.

    Text Changes

    • Drop the hyphen from e-mail and standardize on email.
      The AP Stylebook changed this in 2011, and we’re woefully inconsistent, so let’s go with the standard. [33774] #26156

    Upgrade/Install

    Security

    • Add 'wp_verify_nonce_failed' action that fires when nonce verification fails. [33744] #24030
    • Fire the check_ajax_referer action on failure as well as success. [33743] #33342

    Build Tools

    Thanks to @azaozz, @BinaryKitten, @boonebgorges, @bordoni, @Cheffheid, @chipbennett, @danielbachhuber, @dd32, @DeBAAT, @dimadin, @DrewAPicture, @ebinnion, @egill, @eherman24, @ericlewis, @garza, @hauvong, @helen, @janhenckens, @jjeato, @jmayha, @joedolson, @joehills, @joemcgill, @johnbillion, @KalenJohnson, @kitchin, @liljimmi, @luciole135, @mako09, @MikeHansenMe, @miqrogroove, @morganestes, @niallkennedy, @nikeo, @obenland, @Otto42, @pavelevap, @pento, @peterwilsoncc, @rachelbaker, @rhubbardreverb, @sammybeats, @sboisvert, @scribu, @SergeyBiryukov, @Shelob9, @tyxla, @Veraxus, @vilkatis, @Viper007Bond, @voldemortensen, @welcher, @westonruter, @wonderboymusic, and @yamchhetr for their contributions!

     
  • Helen Hou-Sandi 7:00 pm on August 26, 2015 Permalink
    Tags: ,   

    New committers for 4.4! 

    It’s that time again… Please join me in welcoming Tammie Lister (@karmatosed) as a guest committer for WordPress 4.4. There’s another committer to be announced, but we thought we’d wait until he’s back from vacation for a proper welcome.

    You may recognize Tammie from her role as an admin on the theme review team, and she’s also a theme developer extraordinaire at Automattic. Tammie will be heading up development of the new default theme, Twenty Sixteen.

    The lead developers review and appoint new committers to serve each release cycle, often to work on a particular component or feature. This guest commit access comes up for review after each release and can be renewed. Ella Van Dorpe, Konstantin Obenland, and Weston Ruter, all new committers at the beginning of the 4.3 cycle, have been renewed for 4.4.

    Over the last few cycles, both Aaron Jorbin and Jeremy Felt have been working through long-term plans, smashing through tickets, and improving the entire codebase, especially when it comes to tests and multisite. I’m happy to announce that both are now permanent committers. Please join me in congratulating everyone!

     
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