WordPress.org

Make WordPress Core

Search Results for: gallery Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 8:02 am on January 29, 2014 Permalink

    Gallery 

    26 open tickets. Last 7 days: +0 tickets

    26 open tickets defect (bug) enhancement feature request
    Awaiting Review 6 6 2
    Future Release 8 3 1
     
  • Dominik Schilling (ocean90) 8:47 pm on April 20, 2016 Permalink

    4.6 

    Dev Chat Agendas | Dev Chat Summaries | Posts Tagged 4.6

    Schedule, Focus, Features

    4.6 opened for commit on April 13th and is currently scheduled for August 16th of 2016. The release is lead by Dominik Schilling (@ocean90) and Garth Mortensen (@voldemortensen). The focus will be on fixing bugs and refining existing features. Other goals are to try improving collaboration between teams of features/components, communication to the outside via make/core.

    The following table includes tickets from the community wish list and by core committers.

    Community Wish List

    ID Summary Component Type
    #35133 Make the admin menu more flexible in width Administration enhancement
    #32396 Settings Reduction Administration enhancement
    #35774 WordPress admin <title> structure Administration enhancement
    #16708 Taxonomy checkboxes to radio buttons Administration feature request
    #25669 Introduce helper function for AJAX checks Bootstrap/Load enhancement
    #25137 Enable safe mode to run WordPress without loading plugins Bootstrap/Load feature request
    #34106 Comments should have real permalinks Comments defect (bug)
    #22198 Realigning the Discussions Settings page Comments enhancement
    #27111 Turning off global comments should include existing content Comments enhancement
    #16252 Allow comment reparenting to fix poor threading Comments feature request
    #34923 Introduce basic content authorship in the Customizer Customize enhancement
    #18584 Nav menus need more hooks for extensibility (on admin page & in customizer) Customize enhancement
    #35827 Customizer: Create a dropzone for adding images Customize enhancement
    #18623 Allow themes to pre-register multiple custom backgrounds Customize feature request
    #34062 The WXR export tool should export terms metadata Export enhancement
    #22435 Export API Export enhancement
    #32802 Update Masonry (v3.3.2) & imagesLoaded (v3.2.0) package External Libraries enhancement
    #24846 Usage of a shortcode disables wpautop filter Formatting defect (bug)
    #4539 Abbreviated year followed by punctuation or markup doesn’t texturize Formatting defect (bug)
    #28449 Prevent widows Formatting enhancement
    #30130 Normalize characters with combining marks to precomposed characters Formatting enhancement
    #13429 Updating Link URL on image within Admin with Gallery Gallery defect (bug)
    #21667 Add some user agent to wp_is_mobile General enhancement
    #36335 Next generation: core autoloader proposal General feature request
    #34053 HTTP API (Curl backend) inappropriately sends Content-Length header on POST requests made through a proxy server CONNECT HTTP API defect (bug)
    #33073 Some strings need “no HTML entities” translator comments I18N enhancement
    #34625 wp-login.php site title link points to wordpress.org Login and Registration defect (bug)
    #15384 wp-login.php refactor Login and Registration enhancement
    #34401 Search mechanisms complaning of access denied error on wp-login.php?action=logout Login and Registration enhancement
    #22139 Hooks for wp-login customization Login and Registration enhancement
    #22837 WP Needs to Set “Sender” and “Reply-To” or DKIM/DMARC will not work using wp-mail (via PHPMailer) Mail defect (bug)
    #21659 wp_mail() problem with Reply-To header Mail defect (bug)
    #29513 Move heavy lifting of wp_mail() to child class of PHPMailer Mail enhancement
    #22942 Remove Post by Email Mail enhancement
    #32378 Image Uploads automatically puts “Olympus Digital Camera” as caption Media defect (bug)
    #22938 Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list Media enhancement
    #21295 Retroactively generate new images sizes if requested Media enhancement
    #31050 Better PDF Upload Management Media feature request
    #13910 Get Menu name with wp_nav_menu() Menus feature request
    #35791 WP_Site_Query class Networks and Sites task (blessed)
    #31245 Replace alloptions with a key cache Options, Meta APIs enhancement
    #17817 do_action/apply_filters/etc. recursion on same filter kills underlying call Plugins defect (bug)
    #20578 Allow users to delete a plugin without uninstalling Plugins enhancement
    #12718 Better structure for admin menu Plugins enhancement
    #15691 Network admin should have its own settings API Plugins feature request
    #32101 Ability to mark plugin as unmanaged Plugins task (blessed)
    #30352 Prevent an editor to move the front page / posts page to trash Posts, Post Types defect (bug)
    #8592 Private Pages not listed in the Parent dropdown Posts, Post Types enhancement
    #34982 New algorithm for displaying a hierarchical list of post objects in the WP_Posts_List_Table is incomplete Posts, Post Types enhancement
    #18375 Post type templates Posts, Post Types enhancement
    #12955 Add get_post filter Posts, Post Types feature request
    #12706 Custom post status bugs in the admin Posts, Post Types task (blessed)
    #16379 Better UI for doing “Page on Front” Posts, Post Types task (blessed)
    #29660 Functions in wp_includes/query.php assume non-null return value from get_queried_object Query defect (bug)
    #25473 wp_text_diff creates wrong number of columns if title arguments are set Revisions defect (bug)
    #23314 Allow published posts to be revised without being updated immediately Revisions enhancement
    #20564 Framework for storing revisions of Post Meta Revisions enhancement
    #21374 Add core support for letting custom permalink structure for different post types Rewrite Rules enhancement
    #30579 wp_enqueue_style in footer Script Loader enhancement
    #34292 Support for DNS Prefetching & Prerender Script Loader feature request
    #21022 Allow bcrypt to be enabled via filter for pass hashing Security enhancement
    #26475 Hierarchical meta box display issues when messing around with new terms Taxonomy defect (bug)
    #9777 Usability : add delete button to edit-tags.php Taxonomy enhancement
    #23421 Add sortable to taxonomy column Taxonomy enhancement
    #36574 Redesign term pages Taxonomy enhancement
    #14877 Ability to create exclusive custom taxonomies Taxonomy feature request
    #5034 Impossible to have duplicate category slugs with different parents Taxonomy feature request
    #35736 Replace ‘Lost Password’ phrase with ‘Reset Password’ Text Changes defect (bug)
    #34521 Unifying permission error messages Text Changes enhancement
    #31779 Warn users before using a built-in file editor for the first time Themes enhancement
    #30797 New function for parent theme stylesheet uri Themes enhancement
    #22355 Template stack – Beyond parent/child theme relationships Themes enhancement
    #33407 Theme tags overhaul Themes enhancement
    #14310 Make template hierarchy filterable Themes enhancement
    #19627 Themes should be able to opt-in to a static front page Themes feature request
    #33472 Templating Engine Themes feature request
    #27159 Removing TinyMCE buttons to improve user experience TinyMCE enhancement
    #32678 Audit toolbar links and content Toolbar enhancement
    #24579 Add Drag’n’Drop UI to plugin and theme manual uploaders Upgrade/Install enhancement
    #33932 Filters for Plugin/Theme Update Email Notifications Upgrade/Install enhancement
    #15955 move_uploaded_file mangles non-ascii characters on Windows platforms Upload defect (bug)
    #22363 Accents in attachment filenames should be sanitized Upload defect (bug)
    #35669 Store widgets in a custom post type instead of options Widgets enhancement
    #21165 Make categories widget work with custom taxonomies Widgets enhancement
    #36532 Allow Reordering of Available Widgets Widgets enhancement
    #32417 Add new core media widget Widgets feature request
    #4280 Allow to constrain widgets being displayed on certain page types only Widgets feature request

    Tickets by Committers/Component Maintainers

    ID Summary Component Type
    #36264 Make wpList easier to contribute to Administration enhancement
    #34941 Make the main bootstrap process in ms-settings.php testable Bootstrap/Load enhancement
    #36380 Moderate Comment screen no longer displays raw content Comments defect (bug)
    #35501 Dashboard page: incorrect work of “Activity” group box bottom counters Comments defect (bug)
    #35518 Dashboard page: No “view” link for approved comment Comments defect (bug)
    #35519 Dashboard At a Glance: comment counter isn’t updated if to approve comment Comments defect (bug)
    #33717 Send Notification Email When a Comment is Approved From Moderation Comments feature request
    #35214 Custom Comment Types Comments task (blessed)
    #34391 Harden panel/section UI code by removing contents from being logically nested (read: goodbye margin-top hacks) Customize defect (bug)
    #34893 Improve Customizer setting validation model Customize enhancement
    #36175 Simplify the Customizer Image Control action buttons Customize enhancement
    #34923 Introduce basic content authorship in the Customizer Customize enhancement
    #35210 Add notification area to Customizer Customize enhancement
    #29932 There is no error reporting in the Customizer Customize enhancement
    #30937 Add Customizer transactions Customize feature request
    #34115 oEmbed not working on author page without posts Embeds enhancement
    #35567 New argument `is_embeddable` for `register_post_type()` Embeds enhancement
    #12267 Upgrade loop objects to provide identical presentational interfaces General enhancement
    #21170 JavaScript actions and filters General feature request
    #36335 Next generation: core autoloader proposal General feature request
    #33055 Support Parallel HTTP Requests in WP_Http, et al HTTP API task (blessed)
    #20491 Introduce some JavaScript i18n functions I18N enhancement
    #34114 Remove the requirement to call load_plugin_textdomain() or load_theme_textdomain() I18N enhancement
    #22229 Plurals in JavaScript I18N enhancement
    #35791 WP_Site_Query class Networks and Sites task (blessed)
    #31245 Replace alloptions with a key cache Options, Meta APIs enhancement
    #35658 Provide additional data for registered meta through register_meta() Options, Meta APIs enhancement
    #13459 Conflict between post and page slugs/permalinks when permalink setting is set to /%postname%/ Permalinks defect (bug)
    #20578 Allow users to delete a plugin without uninstalling Plugins enhancement
    #36217 WP_Post_Type class Posts, Post Types enhancement
    #36292 Rewrites: Next Generation Rewrite Rules feature request
    #32358 Add unminified jQuery to core for better debugging with SCRIPT_DEBUG enabled Script Loader feature request
    #35381 Introduce `WP_Term_Query` Taxonomy defect (bug)
    #36224 WP_Taxonomy class Taxonomy enhancement
    #18146 Add user-level timezone setting Users feature request
    #28216 Allow to register pre-instantiated widgets Widgets defect (bug)
    #35574 Add REST API JSON schema information to WP_Widget Widgets enhancement
     
  • Dominik Schilling (ocean90) 9:24 pm on April 14, 2016 Permalink |
    Tags: ,   

    WordPress 4.6: What’s on your wish list? 

    In the spirit of the existing wish list posts, I’d like know what you have for WordPress 4.6.

    • What are you most interested in seeing in WordPress 4.6 — big, or small?
    • What are your or your users’ biggest pain points?
    • What do you see as the most important UX to be solved?
    • Which existing feature should get a “version 2”?

    Look forward to hearing from you in the comments! Let’s make.wordpress.org/great-again! 😉

     

    The WordPress 4.6 kick-off chat will be next Wednesday, April 20, 2016 20:00 UTC.

     
  • Ella Iseulde Van Dorpe 8:24 pm on April 14, 2016 Permalink |
    Tags: , , , ,   

    Media Chat 

    In the regular #core-images chat this Friday, 15 April, 19:00 UTC we are planning to discuss enhancements for 4.6. So far there are four items on the agenda:

    • We are planning to add responsive images to the editor and discuss different implementation methods, e.g. saving srcset and sizes attributes to the database versus generating them on the front end. See #36475.
    • The makers of TinyMCE recently released JavaScript image tools for editing images in the browser which could replace the current server based image editor. The new editor would be quite faster, allowing you to edit and resize images before uploading them, and it would be easier to include in other scripts. This may well be a feature project over a few releases.
    • PDF preview images. See #31050.
    • Continue to improve mixed content issues on HTTPS sites. See #34945.

    If you have more ideas or tickets to discuss regarding media, please join us or leave a comment here. 🙂

     
  • Weston Ruter 12:50 am on March 22, 2016 Permalink |
    Tags: , , ,   

    Implementing Selective Refresh Support for Widgets 

    WordPress 4.5 includes a new Customizer framework called selective refresh. To recap, selective refresh is a hybrid preview mechanism that has the performance benefit of not having to refresh the entire preview window. This was previously available with JS-applied postMessage previews, but selective refresh also improves the accuracy of the previewed change while reducing the amount of code you have to write; it also just makes possible to do performant previews that would previously been practically impossible. For example, themes often include some variation of the following PHP and JavaScript to enable performant previewing of changes to the site title:

    function mytheme_customize_register( WP_Customize_Manager $wp_customize ) {
    	$wp_customize->get_option( 'blogname' )->transport = 'postMessage';
    }
    add_action( 'customize_register', 'mytheme_customize_register' );
    
    function mytheme_customize_preview_js() {
    	$handle = 'mytheme-customize-preview';
    	$src = get_template_directory_uri() . '/js/customize-preview.js';
    	$deps = array( 'customize-preview' );
    	$ver = '0.1';
    	$in_footer = true;
    	wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
    }
    add_action( 'customize_preview_init', 'mytheme_customize_preview_js' );
    
    ( function( $, api ) {
    	api( 'blogname', function( setting ) {
    		setting.bind( function( value ) {
    			$( '.site-title a' ).text( value );
    		} );
    	} );
    } ( jQuery, wp.customize ) );
    

    In 4.5, the core themes now utilize selective refresh for previewing the site title and tagline. This allows the above code to be replaced with the following PHP:

    function mytheme_customize_register( WP_Customize_Manager $wp_customize ) {
    	$wp_customize->selective_refresh->add_partial( 'blogname', array(
    		'selector' => '.site-title a',
    		'render_callback' => function() {
    			bloginfo( 'name' );
    		},
    	) );
    }
    add_action( 'customize_register', 'mytheme_customize_register' );
    

    So as you can see, not only is the amount of code more than cut in half (also eliminating the JS file altogether), it also ensures that when a site title change is previewed it will appear with all of the PHP filters applied from core and plugins: for example wptexturize will apply so that curly quotes and dashes will appear as expected. In REST API parlance, selective refresh enables the Customizer preview to show title.rendered instead of just title.raw. (For more on this change to previewing the site title and tagline, see #33738. The previous JS-based previewing is retained for an instant low-fidelity preview while the selective refresh request returns.) Selective refresh is also the mechanism used for previewing the new custom logo feature in 4.5, ensuring that the logo image is rendered re-using the image_downsize logic in PHP without having to re-implement it in JS (keeping the code DRY).

    With that recap of selective refresh out of the way, let’s turn to the focus of this post: selective refresh for widgets. When widget management was added to the Customizer in 3.9, every change to a widget required a full page refresh to preview. This resulted in a poor user experience since a full refresh can take awhile, especially on weighty pages. So selective refresh of widgets is a key usability experience improvement for widget management in the Customizer in 4.5. However, as live postMessage updates to the site title and tagline have required supporting theme code (see above), so too will theme support be required for widgets, as noted in the Selective Refresh of Widgets section from the previous post on this topic:

    Selective refresh for nav menus was enabled by default in 4.3. While some themes needed to add theme support for any dynamic aspects (such as the expanding submenus in Twenty Fifteen), generally nav menus seem to be fairly static and can be replaced in the document without needing any JS logic to be re-applied. Widgets, on the other hand, have much more variation in what they can display, since they can in fact display anything. For any widget that uses JavaScript to initialize some dynamic elements, such as a map or gallery slideshow, simply replacing the widget’s content with new content from the server will not work since the dynamic elements will not be re-initialized. Additionally, the sidebars (widget areas) in which the widgets are displayed may also have dynamic aspects associated with them, such as the Twenty Thirteen sidebar which displays widgets in a grid using Masonry. For this theme, whenever a widget is changed/added/removed/reordered, the sidebar needs to be reflowed.

    In order to allow themes to reflow sidebars and widgets to reinitialize their contents after a refresh, the selective refresh framework introduces widget-updated and sidebar-updated events. Additionally, since re-ordering widgets in a sidebar is instant by just re-ordering the elements in the DOM, some widgets with dynamically-generated iframes (such as a Twitter widget) may need to also be rebuilt, and for this reason there is a partial-content-moved event.

    For the above reasons, I believe it will be much more common for widgets (and sidebars) to need special support for selective refresh, and so I think that at least for 4.5 the selective refresh should be opt-in for widgets (and perhaps in themes for sidebars). See theme support for Twenty Thirteen and plugin support for a few widgets in Jetpack (which won’t be part of the merge). At last week’s Core dev meeting, it was suggested that we add the opt-in for widget selective refresh at RC.

    So as noted, selective refresh for widgets will be opt-in as of 4.5 RC1 (see #35855).

    What do themes and widgets need to do to opt-in for selective refresh support?

    Selective refresh will be used for previewing a widget change when both the theme and the widget itself indicate support as follows:

    Adding Theme Support

    If your theme does not do anything fancy with its sidebars (such as using Masonry to lay out widgets), then all that you need to do is add the following to your theme:

    add_theme_support( 'customize-selective-refresh-widgets' );
    

    On the other hand, if the theme is rendering a sidebar in a unique way, then to add a bit of logic to handle the changes properly. For example, as noted previously the footer area in Twenty Thirteen consists of a sidebar that is laid out using Masonry. When a widget is added, removed, or updated, the Masonry logic needs to be re-run to update the positioning of the widgets in the sidebar. The following highlighted code is what handles this:

    var widgetArea = $( '#secondary .widget-area' );
    widgetArea.masonry( {
    	itemSelector: '.widget',
    	columnWidth: columnWidth,
    	gutterWidth: 20,
    	isRTL: body.is( '.rtl' )
    } );
    
    if ( 'undefined' !== typeof wp && wp.customize && wp.customize.selectiveRefresh  ) {
    	wp.customize.selectiveRefresh.bind( 'sidebar-updated', function( sidebarPartial ) {
    		if ( 'sidebar-1' === sidebarPartial.sidebarId ) {
    			widgetArea.masonry( 'reloadItems' );
    			widgetArea.masonry( 'layout' );
    		}
    	} );
    }
    

    Note the if statement is there so the code will only run in the Customizer preview and if selective refresh is available (that is, if they are running 4.5 or later).

    Adding Widget Support

    If your widget lacks any dynamic functionality with JavaScript initialization, adding support just requires adding a customize_selective_refresh flag to the $widget_options param when constructing the WP_Widget subclass. If you are enqueueing any CSS for styling the widget, you’ll also want to enqueue this unconditionally in the Customizer preview (if is_customize_preview()) so that a widget can be added to the preview and be styled properly without doing a full page refresh. For example, note these highlighted lines in a sample widget:

    class Example_Widget extends WP_Widget {
    
    	public function __construct() {
    		parent::__construct(
    			'example',
    			__( 'Example', 'my-plugin' ),
    			array(
    				'description' => __( 'Selective refreshable widget.', 'my-plugin' ),
    				'customize_selective_refresh' => true,
    			)
    		);
    
    		// Enqueue style if widget is active (appears in a sidebar) or if in Customizer preview.
    		if ( is_active_widget( false, false, $this->id_base ) || is_customize_preview() ) {
    			add_action( 'wp_enqueue_scripts', array( $this, 'enqueue_scripts' ) );
    		}
    	}
    
    	public function enqueue_scripts() {
    		wp_enqueue_style( 'my-plugin-example-widget', plugins_url( 'example-widget.css', __FILE__ ), array(), '0.1' );
    	}
    
    	/* ... */
    }
    

    On the other hand, as with sidebars in a theme, if a widget uses JavaScript for initialization, you’ll need to add logic to make sure re-initialization happens when the widget is selectively refreshed. So in addition to the above example, you must:

    1. Enqueue any dependent JS logic if is_customize_preview() just as noted above for enqueueing any CSS stylesheet.
    2. Add a handler for partial-content-rendered selective refresh events to rebuild a widget’s dynamic elements when it is re-rendered.
    3. As needed, add a handler for partial-content-moved selective refresh events to refresh partials if any dynamic elements involve iframes that have dynamically-written documents (such as the Twitter Timeline widget). (Adding this event handler should normally not be required.)

    The Twitter Timeline widget in the Jetpack plugin is a good example for how to write these event handlers:

    jQuery( function() {
    	// Short-circuit selective refresh events if not in customizer preview or pre-4.5.
    	if ( 'undefined' === typeof wp || ! wp.customize || ! wp.customize.selectiveRefresh ) {
    		return;
    	}
    
    	// Re-load Twitter widgets when a partial is rendered.
    	wp.customize.selectiveRefresh.bind( 'partial-content-rendered', function( placement ) {
    		if ( placement.container ) {
    			twttr.widgets.load( placement.container[0] );
    		}
    	} );
    
    	// Refresh a moved partial containing a Twitter timeline iframe, since it has to be re-built.
    	wp.customize.selectiveRefresh.bind( 'partial-content-moved', function( placement ) {
    		if ( placement.container && placement.container.find( 'iframe.twitter-timeline:not([src]):first' ).length ) {
    			placement.partial.refresh();
    		}
    	} );
    } );
    

    (This is adapted from a pending PR for Jetpack.)

    Conclusion

    All core themes and core widgets will have support for selective refresh in 4.5. Now it’s up to theme and plugin authors to also add support to also start taking advantage of these drastic performance improvements for previewing widget changes.

     
    • Matthew Eppelsheimer 1:33 am on March 22, 2016 Permalink | Log in to Reply

      This is very exciting. We’re depending on the Customizer more and more, and widgets are a great fit for content management there. I’m excited to tell our clients/users about this, and how it will speed up some of their daily content management tasks.

      Excellent work Weston, and the entire Customizer component team!

    • Tada Burke 1:16 am on March 31, 2016 Permalink | Log in to Reply

      Nice work Weston! Is it too late to shrink this string? Re: customize-selective-refresh-widgets

      • Weston Ruter 2:50 am on March 31, 2016 Permalink | Log in to Reply

        @neurobotic Thanks! And yes, it is too late to shrink the string. That being said, the hope is that the need or themes to opt-in to this feature will be temporary, and that in a future release once enough themes have adopted support, that the feature can be opt-out instead of opt-in.

    • Martin Tod 8:15 am on April 3, 2016 Permalink | Log in to Reply

      Is there an event that’s triggered before the old content is removed? In order to close down the previous JavaScript that’s expecting it to be there?

      • Weston Ruter 4:39 pm on April 3, 2016 Permalink | Log in to Reply

        @mpntod The partial-content-rendered event will include a `placement` context object which has a `removedNodes` property with a reference to the old content that was just removed. So no, there is no event triggered before the replacement is done (not at the individual partial context at least. There is a render-partials-response that is triggered when the data is first received). I’d like to understand the use case for this, but en lieu of there being a core event for this, you could also override/wrap the wp.customize.selectiveRefresh.Partial.prototype.renderContent method to trigger another event before the normal logic is run.

        • Martin Tod 6:40 pm on April 3, 2016 Permalink | Log in to Reply

          @westonruter It’s a bit of an odd issue. My plug-in uses a mildly modified version of the jQuery Cycle2 script – which was crashing after the partial content re-rendering. So I mildly modified it some more and solved the problem.

          However, sometimes when other plug-ins have their own version of jQuery Cycle2, to avoid clashes, my solution has been to use their version – but this doesn’t have the fix in. So I was wanting to try to run the `destroy` command for jQuery Cycle2 before the content was removed to see if this was a possible fix.

          I’ll try to find some other solutions in the meantime!

    • mooberrydreams 3:51 pm on April 8, 2016 Permalink | Log in to Reply

      The widget in my plugin uses Javascript on the admin side, not the viewing side. I’m having trouble getting it enqueue’d when viewing in the Customizer. I’m enqueue’ing in the admin_footer hook. What am I missing?

      • Weston Ruter 3:55 pm on April 8, 2016 Permalink | Log in to Reply

        @mooberrydreams So this isn’t related to Selective Refresh. Instead of using the admin_footer hook, you should enqueue the script in admin_enqueue_scripts when the $page_hook is 'widgets.php'. This will get triggered for widgets in the Customizer.

    • jhill365 2:58 am on April 19, 2016 Permalink | Log in to Reply

      So, in the case of a widget that is being used in the customizer and being updated by javascript (for example by a returned value from the media manager window), will this fix the bug where updates to widgets performed in javascript aren’t recognized by the customizer? For example, in 4.4.2 if you have a hidden input field that is used in the Widget PHP class’ update method to hold the return value of a javascript control such as the media manager or color picker (as is a common widget practice), the customizer isn’t notified automatically of the changed field value in the way that manual updates seem to fire an ajax request to the server and notify it you’ve typed a new value into a widget’s field. I hope that makes sense.

      • Weston Ruter 4:46 am on April 19, 2016 Permalink | Log in to Reply

        @jhill365 If you want an input field change in the widget form to be picked up by the Customizer, you need to trigger a change on the input element if you manually populated the value.

        • jhill365 11:18 am on April 19, 2016 Permalink | Log in to Reply

          Thank you for replying Weston. I apologize for my ignorance here, but are you saying to hook an event handler to the onchange event of the html input element? I have been trying to figure out what event notifies the customizer that a widget value has changed for a couple days now, but I cannot find it in the documentation. I have a widget that uses the native wp media manager to let the user select an image to display, but the customizer doesn’t seem to get notified of the change when I update the input field using the value returned by the javascript (only if I manually change/type it into the field).

          • Weston Ruter 1:57 pm on April 19, 2016 Permalink | Log in to Reply

            @jhill365 That’s right. So something like this:

            $( document ).on( 'widget-added', function( e, widgetContainer ) {
            	var mediaIdInput = widgetContainer.find( 'input.media-id' );
            	widgetContainer.find( 'button.select-image' ).on( 'click', function() {
            		var mediaId;
            		// ... open editor ...
            		// ... some other callback when image is selected ...
            		// ... selected attachment id is assigned to mediaId ...
            		mediaIdInput.val( mediaId )
            		mediaIdInput.trigger( 'change' ); // <==== Key line here.
            	} );
            } );
            
            • jhill365 8:45 pm on April 19, 2016 Permalink

              Weston, I can’t thank you enough! I’ve gotten it working now.

    • peterigz 9:41 pm on April 20, 2016 Permalink | Log in to Reply

      Thanks for the work on this it”s been working great so far. I got confused about how to implement the ‘partial-content-rendered’ binding as it just wasn’t registering the bind – for some reason at that point wp.customizer.selectiveRefresh didn’t exist then I finally realised I was missing the customize-selective-refresh dependency when en-queueing the script, so for the record it should have been:

      wp_enqueue_script( 'mytheme_customizer', get_template_directory_uri() . '/assets/js/customizer.js', array( 'customize-preview', 'customize-selective-refresh' ), '20130508', true );

  • Joe McGill 12:51 pm on February 22, 2016 Permalink |
    Tags: , , ,   

    Proposal: Increase the default image compression in WordPress 

    Note: This proposal was merged to core in [36615]. Download the latest nightly build and give it a try!

    In order to improve page load performance, I propose that the default image compression setting be changed from 90 to 82 in WordPress. Let’s get into why.

    Background

    The default quality setting for resized images in WordPress has been 90 since the image_resize() function was shipped in version 2.5. This setting creates images with much larger file sizes than recommended by modern web best practices.

    Over the past several years, the importance of performance has been highlighted as users access the web globally on slower connections, and performance has even started being used by search engines to influence search results.

    Tools like Google PageSpeed Insights and WebPagetest will warn site owners if images aren’t sufficiently compressed. For example, the glossary at the bottom of the WebPagetest performance optimization page states:

    Within 10% of a photoshop quality 50 will pass, up to 50% larger will warn and anything larger than that will fail. The overall score is the percentage of image bytes that can be saved by re-compressing the images.

    Research

    With this in mind, web developer and performance advocate Dave Newton published recommendations for ImageMagick compression settings based on his research comparing various ImageMagick settings against Photoshop’s ‘high quality’ (60) setting for JPEGs. He found that an Imagick compression setting of 82 was closest to this using an objective measurement named DSSIM to compare the visual similarity between two images.

    We experimented with Dave’s settings in the RICG Responsive Images plugin during the 4.3 cycle and found that not all Dave’s suggestions can be easily applied by default in WordPress due to the memory required to process large images on shared hosts. However, changing the default image quality setting is a relatively small change that makes a big impact on file size without sacrificing much in the way of perceived image quality.

    In research released in 2014, compressed images with a DSSIM score of 0.015 were deemed acceptable to most people. In tests of several different images, I found that changing the default compression setting in WP_Image_Editor from 90 to 82 reduced image sizes by an average of ~25% with DSSIM scores ranging from 0.0014 to 0.0019 for ImageMagick and 0.0019 to 0.0023 for GD — both of which are drastically under the 0.015 threshold cited above.

    Proposal

    Given these results, I suggest making the change to 82 for the default image compression setting. You can follow the discussion on the related ticket (33642) and give feedback in the comments or in the #core-images channel on Slack.

    As a reminder, this setting only applies to the intermediate sizes that WordPress creates, and not the original files uploaded by users. For any users who need to maintain a higher image quality for intermediate sizes, the default quality can still be changed with the wp_editor_set_quality filter.

     
    • leehodson 1:26 pm on February 22, 2016 Permalink | Log in to Reply

      How about setting the default to 82 and providing an easy way for site admins to adjust the setting from within the upload screen at the time of upload and for site admins to set a default compression value in Settings > Media.

      Many site admins, editors and authors are unaware that images are compressed on upload and so few (even among developers) are aware of the wp_editor_set_quality filter; makes sense to provide a user friendly way for the quality setting to be adjusted both at time of upload and from within the media settings screen. I’d even go as far as to let those with media upload permission to rebuild their uploaded images from within the media library.

      What’s the general feeling toward this idea?

      • Eric Andrew Lewis 2:14 pm on February 22, 2016 Permalink | Log in to Reply

        I don’t think the typical end-user needs to worry about image compression levels.

        • leehodson 2:32 pm on February 22, 2016 Permalink | Log in to Reply

          They do when they can’t figure out why their beautiful high quality images of special events look fuzzy on their iPads when viewed within their websites.

          Really isn’t for us as web developers to tell people what they do and don’t need to worry about; it is for us to make it easy for people to control their websites. One extra slider in the media uploader won’t be huge distraction to authors but will make life easier for them and for site admins.

          • Samuel Wood (Otto) 4:18 pm on February 22, 2016 Permalink | Log in to Reply

            Really isn’t for us as web developers to tell people what they do and don’t need to worry about

            Actually, it is. That’s exactly your job. You don’t tell your mechanic the best way to fix your car, you don’t tell your plumber the best way to plumb. And you don’t tell your web developer the best way to develop for the web.

            “It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.” – https://wordpress.org/about/philosophy/

            • Jon Brown 4:56 pm on February 22, 2016 Permalink

              I don’t think anyone would suggest exposing the technical details to users.

              Images and image quality are deeply personal things for many bloggers and site owners though and ignoring those desires isn’t serving our users.

              IMHO, we should have always had an option for image quality vs speed, something like

              Image quality settings could be:
              [ ] High (Minimal compression/large file size, 90 old default)
              [ ] Medium (Optimized Compression/small file size, 82 new default)

              • Neither setting affects your originally uploaded image. Changing the setting will only affect newly generated thumbnails.

              Photographers could set things to “high”, everyone else would stop generating poorly compressed thumbnails.

              I find users are very strongly bipolar on this. Either they’re photo focus and want “100% quality JPEGs” or they’re speed focused and want “A’s on all the speed test suites”. Of course the first group actually wants both, but one can explain, or at least try, to explain why those are mutually exclusive options.

            • Ihor Vorotnov 5:14 pm on February 22, 2016 Permalink

              I totally agree that it’s our job develop properly. But WordPress is used by many non-devs, without dev assistance/hiring. It this case, a UI for setting this option would make sense. IMHO, it should be:

              • default option value is 82
              • a user can change this options in Settings – Media (simple input with instructional text would be sufficient)
              • a developer can override this value via `wp_editor_set_quality` filter
            • chrishoward 5:43 pm on February 22, 2016 Permalink

              There’s so many things in WP where we allow the user to make their own choice.

              The breadth of WP users goes well beyond those reliant on other developers. Many, many, many, many WP sites are one person shops, so the user is also the admin.

              They have to set things like permalinks, home page type (blog/static), use the theme customizer, post format types, widgets, menus, categories, tags, etc.

              People have had quality setting on their digital cameras for 20 years. Likewise photo editing software.

              Poor user is sitting their trying to decide if his post is an “Aside” or a “Quote” or a “Status”… so seeing an image quality option would be like seeing old friend!

              An image quality setting is not going to scare anyone – esp if you put it in words. i.e. Max, high, medium, low.

              Adding an option for image quality is hardly “a weight of technical choices”.

              “It’s our duty as developers to not treat users as idiots – even if they are.”

              The only I’d do different to Lee is I’d only have a control for it in the Media Settings.

            • Jeremy Clarke 6:01 pm on February 22, 2016 Permalink

              FWIW you guys should focus on accepting the fact that there will not be an option for this, and definitely don’t allow yourselves to waste cycles on feeling bad about it. Decisions v. Options is an ancient debate in WP and this particular setting will NOT be the one that breaks the trend.

              Opine on what you think the default should be and accept that changing it will involve either 4 lines of code or installing a tiny plugin.

            • leehodson 6:24 pm on February 22, 2016 Permalink

              The web developer’s duty is to build the site and make it as easy as possible for the site owner or his/her designated admins to use it to create and publish contenet. Control of the site belongs to the site’s owner, not me; I’m the experienced developer, not the inexperienced site owner: make it easy to use the site.

              To use the plumber example, I’d tell the plumber what I want done and give instruction on how I’d like the end product to look e.g. fit the new sink in the corner but please make sure there is enough room for me to move my elbows without hitting the wall and try to hide the pipes as best you can without leaving any pipes sticking out for me to trip over. I’m the householder, not the plumber, but I know what I want and what I don’t want: what I want is the plumber to do the work and leave me with a way to turn on the taps without need to call in a plumber each time I need to wash my hands.

              In any case, this belongs in a different discussion.

            • leehodson 6:26 pm on February 22, 2016 Permalink

              Jeremy, who says this feature isn’t up for discussion? It obviously is up for discussion. We’re looking at changing the way WordPress handles media files and we, as end users and developers, are making a reasonable suggestion. The discussion is still open.

            • Jeremy Clarke 6:37 pm on February 22, 2016 Permalink

              leehodson: What’s up for discussion is changing the default compression level. That’s what the OP was about and that’s what this conversation could potentially change.

              Nowhere in the OP did anyone ask whether there should be a setting and the reason is there won’t be. I say this as a fellow traveler who has wasted too much energy fighting for my own pet settings, and as someone with no influence over core WP and nothing to gain other than reducing the overall community drama.

            • leehodson 6:51 pm on February 22, 2016 Permalink

              Thinking about it, there is another solution: could be added to Jetpack as part of the gallery or carousel module.

              The problem with not providing a visible override setting in core is that those with image rich sites who are unknowingly accustomed to an image compression value of 90 may suddenly find their displayed images look low-res when compressed at 82. That will catch many users unaware and I can already see the headlines slating WordPress for making the change without providing a visible method to manually adjust the setting that doesn’t require a plugin (which so many equate with the mantra ‘too many plugins are bad’) or that doesn’t require a single line of code (which many users don’t expect to be forced to use).

              Really wouldn’t like to see some developers charging WP users high fees for adjusting the compression setting. We all know some will.

              The idea of changing the default compression value to 82 or between 82 and 90 is good and is one I like but without an easy way to adjust the setting I can’t see the idea being welcomed by regular end users.

        • Mike Schroder 10:32 pm on February 22, 2016 Permalink | Log in to Reply

          Completely agree. This is one of the areas where “Decisions, not Options” is pretty clear. It’s up to us to do the research (as @dnewton, @joemcgill, and more have) and make a decision that’s good for the majority of sites. Plugins can (and do) modify this value or present a UI as they would like.

      • Jon Brown 4:40 pm on February 22, 2016 Permalink | Log in to Reply

        +1 on this proposal and +10 on Lee’s additional suggestions.

        The current setting is awful for users and we should make this better all around.

        Witness the plethora of cloud based images compression services and plugins that have sprung up to do little more than fix this fundamental design flaw in WP media management. Setting up SmushIt, Krakken, EWWW, etc should be completely unnecessary and it’s become de rigeur.

        Over the years I can’t begin to count the number of users frustrated by WP’s handling on images. Granted a huge number of those don’t understand compression, image size or color space, but the frustration stems from poor defaults without transparency (ie. making it clear what compression is happening, what sizes are being created and used) and zero control over any of it.

        • Jeremy Clarke 6:07 pm on February 22, 2016 Permalink | Log in to Reply

          Adding a setting for image compression will solve pretty much none of those problems, which IMHO are related to featured images and custom sizes (which have never been well-expressed in the UI despite being critically important to authoring workflows). Compression doesn’t confused people, it’s just something people want once they learn the benefits. Turning it on by default is the solution. Once WP has aggressive compression by default a lot of those plugins will fade away as users see the diminishing returns offered by them.

          Unlike custom image sizes, which are editorially relevant (like most of the other decisions highlighted by people in these comments as examples of settings) compression levels are not relevant to how you publish posts. No one NEEDS a different compression level no matter how much they might believe they do, whereas having a custom image size that works properly as a thumbnail in X part of your theme is mandatory.

          • leehodson 6:16 pm on February 22, 2016 Permalink | Log in to Reply

            I need it. Countless others say they need it. Where do you get the idea that no one needs it? Evidence suggests otherwise.

            • Jeremy Clarke 6:25 pm on February 22, 2016 Permalink

              I don’t think you can prove you “need” it. You want it and that’s fine, lots of people feel they want it, but your site will continue to function and display correctly without it (unlike a site with messed up Custom Image Sizes).

              Also for those who “need” it 4 lines of code or a tiny plugin is not an unreasonable step. If you really need it you can install a plugin, that’s how WP works.

              It would be so boring to make a list of options in WP that people actually need but aren’t supported by core (about as interesting as the lists above of settings that ARE in core). For now I’ll leave you with this: Despite WP having a powerful and elaborate capability/role system which can be customized infinitely, there are no options to control it anywhere in core. You can’t add roles or modify the capabilities of roles at all without a plugin. You are stuck with 4 crappy roles that barely cover common use-cases of multi-author sites. Pretty much any site with more than a dozen users will need a plugin like Members or Capability Manager. This is not a bug, it’s a decision made by core to protect users from the extra complexity.

            • leehodson 6:31 pm on February 22, 2016 Permalink

              Role management is a reasonable point. WordPress core presently allows admins to perform tasks that editors, authors and subscribers can’t perform. Is there a reason that same method can’t be employed to control access to a compression value setting in Media Settings or within the media uploader? I can’t think of one.

            • Jeremy Clarke 6:40 pm on February 22, 2016 Permalink

              >Is there a reason that same method can’t be employed to control access to a compression value setting in Media Settings or within the media uploader? I can’t think of one.

              Sorry you missed my point. I wasn’t saying that role/capability management somehow complicates the question of a setting for image compress, I was just pointing out that even role/capability management has no option visibility in core, despite being a huge, complex feature set in place under the hood.

              If such an important (security/workflow/community) feature doesn’t get admin options, you can see why options like image compression are left as “plugin territory” too.

            • leehodson 6:55 pm on February 22, 2016 Permalink

              I read it a bit fast, maybe. Thanks for clearing that up. I do see what you mean though I don’t see it the same way. Might do after an internal debate with myself.

    • chrishoward 1:37 pm on February 22, 2016 Permalink | Log in to Reply

      What Lee said!

      Some sites want minimum compression, wanting their images to look their best.

      Most folks though can’t even tell.

      Looking at that owl, I reckon you can set the default much lower, and then like Lee said, provide an override in the Media settings.

    • Mark-k 1:49 pm on February 22, 2016 Permalink | Log in to Reply

      This doesn’t sound like a real research. I am not objecting but to actually test the usefulness of this change you will need actually web page to test against.

      For small images 25% reduction will not be felt by the user as the bigger factor is the latency.. Big images are many time used as the original image so there will be no change there.

      As for saving money argument, lets call it BS. I get 10GB/mo for 8$ which I can’t even get close to utilizing. I know that israel in this regard is an outliner, but still the price for byte/mo on desktop is virtually 0 and mobile is rapidly getting there all over the world.

      Again, no objection if people can not see the difference, but not sure that a surprise reduction in quality will be welcomed by site owners that will be able to notice it. If implemented this feature should be active only on new installs.

      • Ihor Vorotnov 5:27 pm on February 22, 2016 Permalink | Log in to Reply

        > and mobile is rapidly getting there all over the world

        If you’re talking about mobile traffic cost, you’re soooo wrong. I live in Ukraine, Turkey and Montenegro. All mentioned countries aren’t technical outsiders. In fact, regular internet in Ukraine is much, much, much better then in US. I have unlimited 100Mbps cable for $5/m. However, we just got 3G in 2015, it’s available only in large cities and it’s expensive. Same applies to Russia and Belarus. In Turkey, regular networks are bad and slow, but they have great 3G even in mountain villages. But still, it’s pretty expensive. In Montenegro, regular network is fine (not that good as in Ukraine, but pretty good), 3G is fine but not cheap too. Same applies to many other european countries. So, mobile bandwidth isn’t even close to being cheap. And I’m not even talking about less developed countries. Check India, for example, or Thailand, other asian countries (except China, that’s a different beast). I don’t know how things are going in Latin America, but somehow I’m sure it’s not better. All mentioned countries/regions combined are at least half of the world. So, yes, your Israeli experience is rather an exception.

        • Jeremy Clarke 6:12 pm on February 22, 2016 Permalink | Log in to Reply

          +1 What we know for sure is that decreasing bandwidth requirements has a meaningful impact in all contexts and on mobile the impact is very important for MANY users all over the place for all kinds of reasons.

        • Mark-k 11:51 am on February 23, 2016 Permalink | Log in to Reply

          You don’t design features for today, you should design features for tomorrow when they will actually be used. Changing the default in 4.5 will have no impact on images generated before that and it will take a long time for this feature to generate more then half of wordpress hoisted images on the web. So if you think that anyone around the world will be able to save any money from the introduction of the feature then I think you are very wrong.

      • Drivingralle 3:33 am on February 23, 2016 Permalink | Log in to Reply

        @Mark-k: Happy for you that you can get cheap mobile data. But even in Germany 1GB/mo can cost you around € 10,-. The networks are quite good there but still no reason to send big images.

        Right now I’m in Asia and bandwidth is a big concern here. Volume is cheap, but a lot of sites take ages to load.

        The combination of srcset and an increased compression for intermediate sizes would be a win for both cases/locations.
        In general the weight of most websites is way to high. Images are the biggest part of it. Working on that is a a really important thing.

        • Mark-k 12:01 pm on February 23, 2016 Permalink | Log in to Reply

          srcset **increases** the sizes of the images being send, it is the opposite of this feature in terms of bandwidth performance. srcset increases the size by a factor of 4 for retina displays. shaving 25% off it will end you in an increase of a factor of 3. Maybe a faster and better way to improve image bandwidth performance is to have an option to disable srcset in core so people in “developing world” (whatever that is) can out of the box help their users save bandwidth.

    • dsthedev 2:26 pm on February 22, 2016 Permalink | Log in to Reply

      This is a great idea. I think some people are missing the point here. A mere 8% reduction in quality level can yield ~25% smaller image sizes across the board (minus original) with almost no visual difference? That sounds like it would be good for everyone. Especially since adding an option in media settings would be easy enough and allow for a little more customization.

      I think it makes even more sense if you combine it with the responsive images feature recently added. Improving performance with practically no downsides?

    • Benjamin Pick 3:11 pm on February 22, 2016 Permalink | Log in to Reply

      While I support this proposal, we need to make sure that site editors/admins (!) can find out why their images become blurry. That’s why I like the idea of a media setting – this makes it clear that there is some subjective judgement involved.

      (For example, we had a client that complained that the PNGs become blurry already at the 90%-Level. This was because the typical image was technical drawings or product images with text on it, so it feels blurry much earlier than with photos. I also think of the PDF thumbnails that might get merged into core – please test if 82% would be appropriate there as well.)

      • Jeremy Clarke 6:17 pm on February 22, 2016 Permalink | Log in to Reply

        Benjamin you’re our only hope! Can you go find those images and see how they perform at 90 v. 82?

        I suspect the difference will be invisible as in the test above, and that if they get “blurred” (certainly not a description of the test above) then 90 v. 82 won’t be the reason.

        Either way, at this point it’s up to whoever thinks 82 is to low to show examples.

        • Mark-k 12:09 pm on February 23, 2016 Permalink | Log in to Reply

          Why? it is always the people that want to change things that need to justify it. 90% kinda works and maybe the difference between 90% and 82% is not big, but is it too much difference between the original and 82%? Wherever you have text it will become harder to identify, so maybe the nice owl in the example should be replace with an image of text and the difference should be tested on this kind of images.

          Then you will say that most images do not contain text, and I will agree but before a proper measurement and additional research is done you can not just say that the “difference is invisble” to everyone.

          • Helen Hou-Sandi 3:33 pm on February 23, 2016 Permalink | Log in to Reply

            The post very clearly lays out DSSIM as a proper objective measurement, existing outside research on a precise threshold, and a lot of work done by this team to quantify various outcomes as documented in a spreadsheet. The image set includes images with text, both JPG and PNG. If that is not “proper measurement and additional research”, I have a hard time believing you’re actually open to discussion.

    • jeffmcneill 3:23 pm on February 22, 2016 Permalink | Log in to Reply

      I strongly endorse this proposal. File size, besides number of files, is one of the biggest factors in a slow user experience. Yes indeed, “the biggest factor is latency” but it is latency for requests and responses, that is what is being requested is slow making it to the device, because it is big. Also, the idea that everyone has cheap bandwidth/throughput everywhere, all the time, is simply mistaken. We need ways of making WordPress more mobile-friendly (not to mention developing-country friendly), and this is an excellent proposal to do just that.

    • Aaron D. Campbell 3:46 pm on February 22, 2016 Permalink | Log in to Reply

      I’m all for this change. An average of 25% reduction in file size seems like an obvious win, especially since the visual difference between 90 and 82 is almost none.

      However, we do not need, and should not add, a setting for this. The vast majority of users not only won’t need the setting, but won’t understand it (What does an image quality of 90 vs 82 vs 60 vs 100 actually mean?). The filter (wp_editor_set_quality) is already in place for those that really want it, and a plugin could easily be created to add this setting for any users that want it.

      • dsthedev 4:26 pm on February 22, 2016 Permalink | Log in to Reply

        I don’t know, I feel like it would be pretty easy to write a simple 1 – 2 sentence description of what the setting does. Benjamin Pick provided a perfect example of somebody uploading technical drawing or images with text on them. If a user doesn’t understand the setting they will probably skip it entirely. I also don’t think we need yet another plugin for something that could be a very simple option in core. A great example of that is needing to download the “Disable Google Fonts” plugin on every site I create because wp-core forces Open Sans on everybody without providing a very simple checkbox option to not use it.

        • Aaron D. Campbell 6:06 pm on February 22, 2016 Permalink | Log in to Reply

          The problem here is two fold:

          1) If the majority of users will never use an option, then it shouldn’t be in core. We generally refer to this as the 80-20 rule of thumb. We want core to be what 80% of the people need, and plugins to cover the needs of the other 20%. I don’t even think 20% of users will need this option, much less 80%.

          2) Option overload is a real thing. Users freeze up when there are too many options, because they feel overwhelmed. Every option that goes into the WordPress admin needs to be carefully examined and an EXTREMELY good case needs to be made for it’s necessity. A single new option, then another int he next release, and another after that, and soon our options screens are overfilled and scary to an average user. “It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.” – https://wordpress.org/about/philosophy/

    • Stephane Daury (stephdau) 4:01 pm on February 22, 2016 Permalink | Log in to Reply

      Thanks for the time you put into this. I’m also in favor of looking deeper into this. Those not browsing on broadband, or those with bandwidth limits, will surely appreciate such savings, especially when thinking web scale, and WP as “25% of it”.

    • pix365 4:25 pm on February 22, 2016 Permalink | Log in to Reply

      LIke Aaron, I too am in favour of the change, Mobile data packages in Europe is quite expensive, so reducing the volume of data downloaded can only be a good move, I vote for a Option (& i am assuming it will be dropped to 82) inside the Media admin section to allow folks to override the new default with the Legacy setting (90)
      AND OR if you gave folks the ability to enter a custom value, i think most will use it responsibly, but you can bet some users will use 100%. for that reason alone a custom value field setting is probably not a good one, unless max setting was 90.

    • Aaron Jorbin 5:57 pm on February 22, 2016 Permalink | Log in to Reply

      Thanks for writing thus up.

      The proposal looks great. Let’s do it!

    • Helen Hou-Sandi 6:05 pm on February 22, 2016 Permalink | Log in to Reply

      I’m for this. Really great to see the numbers from objective measurements (DSSIM) included in this, always appreciate the thoroughness and thoughtfulness. Also really cool that this came from responsive images work, which while related, is not inherently coupled to this. Having API improvements come from feature work tends to work well for us.

      Regarding the comments here, no core UI settings for this, please. We don’t have one now and this change is, per the numbers, incredibly unlikely to be visually noticeable in the end results, so I don’t see why it requires further changes in the admin.

      Just so I’m clear on this point – this only applies to JPGs, yes? Are PNGs resized to PNGs or are they resized to JPGs? (There’s also a comment above with concerns about PNG quality loss.)

      • Joe McGill 6:37 pm on February 22, 2016 Permalink | Log in to Reply

        Good questions Helen.

        The quality setting affects both JPG and PNG files. PNGs will remain PNGs but compression in Imagick affects PNGs differently than JPGs so the file size differences aren’t as noticeable. There are a few tickets floating around track about better compression for PNGs specifically, which would be another nice addition to tackle.

    • Primoz Cigler 6:55 pm on February 22, 2016 Permalink | Log in to Reply

      Yes, do it. And no, no extra settings are needed. I even think you could set it to lower than 82, but I guess some other people here will kill me with fire 😀

      Are metadata and exif stripped also? I think it is a good idea they should be stripped by default as well. So called lossless compression.

    • Dave 7:10 pm on February 22, 2016 Permalink | Log in to Reply

      I’m all for this change, and appreciate Joe’s time in writing it up, and providing data to explain why.

      I agree with the last few comments about no UI settings in core (for all the same reasons that were already mentioned).

    • jteague 7:13 pm on February 22, 2016 Permalink | Log in to Reply

      +1 on this proposal. Our own recent tests came out at 84% optimal, but either compression percentage is fine.

    • Ansel Taft 7:53 pm on February 22, 2016 Permalink | Log in to Reply

      A great write-up, well reasoned, and an excellent tweak to WordPress. [/makeitso]

    • Gary Pendergast 11:20 pm on February 22, 2016 Permalink | Log in to Reply

      +1 on this change, nice writeup, Joe. 🙂

      -∞ on adding UI for an option, the existing filter is sufficient.

    • jtleathers 1:15 am on February 23, 2016 Permalink | Log in to Reply

      I’m all in favor of this change. It always bugs me when the current default creates smaller resolution images with larger file sizes than the original image. This change should definitely help.

    • M Asif Rahman 2:14 am on February 23, 2016 Permalink | Log in to Reply

      Agreed. Let’s do this.

      And for changing the value, we have a hook already.
      add_filter( 'jpeg_quality', create_function( '', 'return 80;' ) );

      Read more at – https://developer.wordpress.org/reference/hooks/jpeg_quality/

    • Drivingralle 3:45 am on February 23, 2016 Permalink | Log in to Reply

      +1 for this.

      I created a ticket in trac about giving developers a way to control image compression for costume image sizes per size to save even more file size. I think somehow related.
      https://core.trac.wordpress.org/ticket/29795

    • Mark Howells-Mead 8:42 am on February 23, 2016 Permalink | Log in to Reply

      +1 from me. When I make the effort to optimize content photos as precisely as possible before uploading them, WordPress’ processing always creates copies from them which are larger in file size than the originals.

      I doubt many editors or admins will take the time to pay attention to a setting in wp-admin: I think that a customization of the default setting should continue to be handled by the experienced developer, via a hook.

    • AllenAyres 8:02 pm on February 23, 2016 Permalink | Log in to Reply

      I understand I’m not a developer, but speaking for the thousands (millions?) of photographers using WP for their business-front end, it would be appreciated to give them a heads-up on the change and the way to undo it if they prefer.

      *You* may not care for image-quality vs download speed, but those who rely on the display of their work to be seen at its best do. Our life’s work is image quality, what may not be obvious to some is glaring to others.

      For those who are on slower/metered access, I’m ok if they bypass my site, it’s generally not for them in the first place.

      • Ipstenu (Mika Epstein) 12:45 am on February 24, 2016 Permalink | Log in to Reply

        I’m curious… Do you have people looking at the downsized images or the full sized? Because as I understand it, we’re only going to be changing compressions for the resized images.

        • Ryan Hellyer 8:25 am on February 24, 2016 Permalink | Log in to Reply

          I suspect it’s both. Even the “full sized” images shown on photography websites tend to be scaled down to a more reasonable number for display. And photographers tend to be very particular about their thumbnails in my experience too. I actually think the thumbnails can be even more important, as they tend to show up JPG compression more, due to their small size and people staring close at them.

          • Ipstenu (Mika Epstein) 7:55 pm on February 24, 2016 Permalink | Log in to Reply

            But isn’t the fullsized not scaled down by WP? If I upload a 3000×2000 image, it doesn’t get processed, it just gets copied.

            Thumbnails, yeah, I totally agree there. Not sure how to get the word out really.

      • Joe McGill 4:20 pm on February 24, 2016 Permalink | Log in to Reply

        Hi Allen,

        While the visual differences will be slight, I agree that we’ll want to let users with strong opinions about this sort of thing know. In fact, that’s the main reason for publicly publishing this proposal in the first place. Besides publishing information on this blog, I’d be curious to know where else you suggest we publicize this information?

        • AllenAyres 4:57 pm on February 24, 2016 Permalink | Log in to Reply

          Thank you Joe.

          To me, it would need to be published in the release notes so that those many photographers (and the developers a good percentage of the photographers pay to develop their site) would know before they update. On some hosts that update automatically it would be good to know what happened to their image quality.

          Again, what may appear slight to some is a huge change to others, and as Ryan mentioned, the resized images would be affected more (I spend a lot of time getting each image looking perfect, all the while optimizing for download speed, upload a 900×600 image, the theme resizes it to something a bit smaller to fit and then generates 1-2 thumbnails to display varying sizes throughout the site – the smaller the image the more compression affects perceived quality).

          Please don’t strip exif data either, our IP is carried in there via copyright notices, etc. I already strip out as much as possible but have seen many photographers track down theft of copyrighted images through the searches of the info they place within the exif.

          For professionals, we work/invest tremendously already to have the image display at its best, balancing that with download speed too, at least allow us a way to undo the changes made.

    • davidshq 2:02 am on February 26, 2016 Permalink | Log in to Reply

      I’m not a huge fan of this idea. I see too much deterioration in image quality. The owl looks great, but I see way too much degradation in numerous images I’ve utilized on sites in the past…

      What I would like to see is something akin to jpegMini’s technology, which reduces file size but maintains perceived image quality.

    • Todd Lahman 2:15 am on March 1, 2016 Permalink | Log in to Reply

      Not sure if this was mentioned, but this should also be applied to the jpeg_quality filter.

    • Mark Howells-Mead 8:42 am on March 31, 2016 Permalink | Log in to Reply

  • Weston Ruter 8:25 am on February 16, 2016 Permalink |
    Tags: , ,   

    Selective Refresh in the Customizer 

    Note: This proposal was merged to core in [36586]. Download the latest nightly build and give it a try!

    The Customizer is our framework for live previewing changes. However, settings edited in the Customizer get sent to the preview via the refresh transport by default, meaning that in order for a setting change to be applied, the entire preview has to reload: this refresh can be very slow and is anything but “live”. To remedy this poor user experience of a laggy preview, the Customizer allows settings to opt-in to using a postMessage transport which relies on JavaScript to preview the change instantly without doing any server-side communication at all. This provides for a great user experience.

    There is a major issue with settings using the postMessage transport, however: any logic used in PHP to render the setting in the template has to be duplicated in JavaScript. This means that the postMessage previewing logic violates the DRY (Don’t Repeat Yourself) principle, and so it is really only suitable for simple text or style changes that involve almost no logic (e.g. site title or background color). Even in this case, it is often not possible to fully re-implement the PHP logic in JS, since as in the example of #33738 there may be an unknown number of PHP filters that get applied to the setting’s value (such as the site title) when rendering the content on the server.

    What the Customizer needs is a middle-ground between refreshing the entire preview to apply changes with PHP and between applying the changes exclusively with JavaScript. The selective refresh is the solution proposed in #27355, and this post is about documenting the feature, as it was approved for core merge in 4.5. Selective refresh also appears on the proposed Customizer roadmap.

    Partial preview refreshing was first explored when Customizer widget management was being developed for the 3.9 release. It was added to the Widget Customizer plugin and described in a Make Core post. But it was decided to remove the feature in favor of having a better generalized framework for partial refreshes in a future release (which is now). In 4.3, nav menus were added to the Customizer and with this the first core implementation of selective refresh, as described in Fast previewing changes to Menus in the Customizer. (For more background, see Implementing Selective Refresh in the Customizer.)

    With the shipped example of selective refresh of nav menus in the Customizer, and an initial implementation of selective refresh for widgets, work progressed to generalize a selective framework that would support the complicated examples of nav menus and widgets, but also to support simpler use cases such as letting the server render the updated site title so that wptexturize and other filters can apply. The generalized framework has been implemented in the Customize Partial Refresh feature plugin, which also re-implements selective refresh of nav menus and introduces selective refresh of sidebars and widgets.

    To see a simple example of selective refresh, see the Site Title Smilies plugin showing wptexturize and emoji applying to site title updates in the preview:

    Note in this example that the standard postMessage updating of the site title in the header is still in place and so the change appears immediately. It gets followed, however, by the content being rendered by the partial on the server. This allows for JS to apply a quick low-fidelity preview for a setting change until the server can respond with the high-fidelity preview.

    Selective Refresh Architecture

    This plugin introduces a selective refresh framework which centers around the concept of the partial. A partial is conceptually very similar to a Customizer control. Both controls and partials are associated with one or more settings. Whereas a control appears in the pane, the partial lives in the preview. The fields in a control update automatically to reflect the values of its associated settings, and a partial refreshes in the preview when one of its settings is changed. The name “partial” is derived from  get_template_part(), which is a natural function to use in a partial’s  render_callback.

    In addition to a partial being associated with one or more settings, a partial is also registered with a jQuery selector which identifies the partial’s locations or “placements” on the page, where the rendered content appears. For example, a partial can be registered for the site title to update the header as well as the document title via:

    function my_register_blogname_partials( WP_Customize_Manager $wp_customize ) {
    
    	// Abort if selective refresh is not available.
    	if ( ! isset( $wp_customize->selective_refresh ) ) {
    		return;
    	}
    
    	$wp_customize->selective_refresh->add_partial( 'header_site_title', array(
    		'selector' => '.site-title a',
    		'settings' => array( 'blogname' ),
    		'render_callback' => function() {
    			return get_bloginfo( 'name', 'display' );
    		},
    	) );
    
    	$wp_customize->selective_refresh->add_partial( 'document_title', array(
    		'selector' => 'head > title',
    		'settings' => array( 'blogname' ),
    		'render_callback' => 'wp_get_document_title',
    	) );
    }
    add_action( 'customize_register', 'my_register_blogname_partials' );
    

    When a setting (like blogname here) is modified, each registered partial is asked on the client whether it isRelatedSetting(). If that method for a partial returns true, then the partial’s refresh() method is invoked and a request is queued up to render the partial via the requestPartial() function. Calls to this function are debounced and multiple simultaneous partials being changed will be batched together in a single Ajax request to the server.

    When the server receives a request to render partials, it will receive the list of partials as well as all of the modified settings in the Customizer. Partials need not be all registered up front: as settings support the customize_dynamic_setting_args and customize_dynamic_setting_class filters, so too partials support the customize_dynamic_partial_args and customize_dynamic_partial_class filters. These filters allow partials to be added on demand to support the partials being requested to render.

    If there is no registered partial for the request, or if the partial’s render_callback returns false, then false will be returned in the response as the content for that partial, and the default fallback() behavior in the client-side Partial object is to requestFullRefresh(). On the other hand, if the request recognizes the partial and the render_callback returns content, then this content is passed along to the Partial instance in the client and its renderContent() method then follows through to update the document with the new content.

    As noted previously, the location in the document where a partial renders its update is called a placement. A selector may match any number of elements, and so too a partial may update multiple placements. A partial’s placements in the document may each have different sets of context data associated with them. This context data is included in the partials request and is passed along to the render_callback so that the content can vary as needed, for example a widget appearing in two different sidebars would have different sidebar_id context data, which would then determine the before_widget and after_widget args used.

    Partial placements may also be nested inside other placements. For example, a Custom Menu widget is rendered as a placement which then contains another placement for a nav menu. The nav menu placement is updated independently from the parent widget placement. This being said (and this is advanced usage), a selector does not need to be supplied when registering a partial: alternatively to a top-down selector, the placement for a partial can be declared from the bottom-up by adding a data-customize-partial-id attribute to any container element. Whenever a partial is re-rendered, any nested partials will be automatically recognized. (As noted above, each placement can have a different associated context, and this is indicated by JSON object in a data-customize-partial-placement-context HTML attribute.)

    Aside: The architecture of the Infinity Scroll module in Jetpack mirrors Selective Refresh framework in several ways.

    Linking Partials to Controls

    Since each partial is associated with at least one setting, shift-clicking on the placement for a partial will attempt to focus on the related control in the pane. This was already implemented for widgets since 3.9 and recently for nav menu items as well, but now the functionality is available to partials generally.

    Selective Refresh of Widgets

    Selective refresh for nav menus was enabled by default in 4.3. While some themes needed to add theme support for any dynamic aspects (such as the expanding submenus in Twenty Fifteen), generally nav menus seem to be fairly static and can be replaced in the document without needing any JS logic to be re-applied. Widgets, on the other hand, have much more variation in what they can display, since they can in fact display anything. For any widget that uses JavaScript to initialize some dynamic elements, such as a map or gallery slideshow, simply replacing the widget’s content with new content from the server will not work since the dynamic elements will not be re-initialized. Additionally, the sidebars (widget areas) in which the widgets are displayed may also have dynamic aspects associated with them, such as the Twenty Thirteen sidebar which displays widgets in a grid using Masonry. For this theme, whenever a widget is changed/added/removed/reordered, the sidebar needs to be reflowed.

    In order to allow themes to reflow sidebars and widgets to reinitialize their contents after a refresh, the selective refresh framework introduces widget-updated and sidebar-updated events. Additionally, since re-ordering widgets in a sidebar is instant by just re-ordering the elements in the DOM, some widgets with dynamically-generated iframes (such as a Twitter widget) may need to also be rebuilt, and for this reason there is a partial-content-moved event.

    For the above reasons, I believe it will be much more common for widgets (and sidebars) to need special support for selective refresh, and so I think that at least for 4.5 the selective refresh should be opt-in for widgets (and perhaps in themes for sidebars). See theme support for Twenty Thirteen and plugin support for a few widgets in Jetpack (which won’t be part of the merge). At last week’s Core dev meeting, it was suggested that we add the opt-in for widget selective refresh at RC.

    Update: See follow-up post on Implementing Selective Refresh Support for Widgets.

    Selective Refresh API

    What follows is a list of aspects of the API that should be more commonly used. For full documentation, see the inline docs in the plugin source.

    PHP

    I suggest that Selective Refresh be added as a new Customizer component to be accessed via $wp_customize->selective_refresh which is where the methods for partials(), add_partial(), get_partial(), remove_partial(), and others would be accessed.

    New classes:

    • WP_Customize_Selective_Refresh
    • WP_Customize_Partial

    New filters:

    • customize_partial_render
    • customize_partial_render_{$partial->id}
    • customize_dynamic_partial_args
    • customize_dynamic_partial_class
    • customize_render_partials_response

    New actions:

    • customize_render_partials_before
    • customize_render_partials_after

    JS

    Namespace: wp.customize.selectiveRefresh

    New classes:

    • wp.customize.selectiveRefresh.Partial
    • wp.customize.selectiveRefresh.Placement
    • wp.customize.navMenusPreview.NavMenuInstancePartial
    • wp.customize.widgetsPreview.WidgetPartial
    • wp.customize.widgetsPreview.SidebarPartial

    New properties:

    • wp.customize.selectiveRefresh.parital (collection)
    • wp.customize.selectiveRefresh.partialConstructor

    Events (triggered on wp.customize.selectiveRefresh):

    • render-partials-response
    • partial-content-rendered
    • partial-placement-moved
    • widget-updated
    • sidebar-updated

    The Future

    If we can eliminate full-page refreshes from being the norm for the Customizer, we can start to introduce controls inline with the preview. If the entire preview does not reload, then the inline controls won’t get destroyed by the refresh with each change. For example, consider a widget control floating immediately next to the widget in the sidebar it is editing. With selective refresh, it will then also be possible to eliminate the Customizer altogether. The Customizer could be available to anyone who is logged in, with the controls being bootstrapped on demand when a user wants to edit a given element. There would be no need to navigate way from a page on the frontend to enter a unique Customizer state: the Customizer would come to the user. Any controls not relevant to being inline could remain in the Customizer pane, but it could slide in only as needed instead of appearing by default. That is to say, selective refresh makes the Customizer a much better framework for implementing frontend editing.

    Feedback

    There is just over a week until the first beta for 4.5. I’d like to get any final feedback on the feature as soon as possible before committing it to trunk. The plugin is on GitHub and the plugin directory. Feedback should be left on #27355. Note that the plugin depends on 4.5-alpha-35776 to run.

     
    • chatmandesign 3:13 pm on February 16, 2016 Permalink | Log in to Reply

      Why does this need its own API? Shouldn’t it just be done using the REST API? That would also make it easy to register AJAX-refreshable regions on the front end. This seems like a lot of duplicated effort.

      • Weston Ruter 4:41 pm on February 16, 2016 Permalink | Log in to Reply

        If your theme is making use of the REST API and it is using the WP-API JS Backbone client, then you can also use the Customizer to preview changes to those resources in a proof of concept Customize REST Resources plugin (see Bridging the Customizer and the WP REST API).

        If your theme is not already using the REST API then there is nothing about the REST API that will just automatically handle selective refresh in the Customizer preview. While the Customize REST Resources plugin does inject the Customizer state into Ajax requests to the REST API, general Ajax requests cannot get the Customizer state injected into them if they are GET requests because the Customizer requires POST. Customizer transactions (#30937) will facilitate previewing changes to any Ajax requests.

        In any case, the underlying need for selective refresh in the Customizer is for settings (resources) to be associated with arbitrary regions in the preview and to refresh those regions when an associated setting changes. There is nothing about the REST API that handles this for us.

    • Davide 'Folletto' Casali 4:29 pm on February 16, 2016 Permalink | Log in to Reply

      If we can eliminate full-page refreshes from being the norm for the Customizer, we can start to introduce controls inline with the preview. If the entire preview does not reload, then the inline controls won’t get destroyed by the refresh with each change. For example, consider a widget control floating immediately next to the widget in the sidebar it is editing. With selective refresh, it will then also be possible to eliminate the Customizer altogether. The Customizer could be available to anyone who is logged in, with the controls being bootstrapped on demand when a user wants to edit a given element. There would be no need to navigate way from a page on the frontend to enter a unique Customizer state: the Customizer would come to the user. Any controls not relevant to being inline could remain in the Customizer pane, but it could slide in only as needed instead of appearing by default. That is to say, selective refresh makes the Customizer a much better framework for implementing frontend editing.

      I think this vision is conflating two different things, namely:

      1. the design of the UI shows up
      2. the direct manipulation of content

      This is very important, because “floating controls” and “inline controls” look nice and cool, but they scale very very little. If you check the history of interfaces you’ll notice that every “floating” element over time ends up being a sidebar (or some kind of static control). The reasons are subtle, but numerous: cognitively everything always appear in the same space, there’s a clear separation content and editing, and the sidebar doesn’t cover existing parts of the content itself.

      I have the feeling that since we have the sidebar right now we want to eschew that for other UIs just because they feel “new”. I agree with that feeling, and there are many examples out there that use floating components. But you will also notice that the floating components are either very simple or very annoying to use.

      That’s why the most effective UIs out there use direct manipulation properly (which gets enabled by the selective refresh discussed here) but also have a static sidebar on the side. See all the pro and consumer tools out there: Keynote, Sketch, Word… even Photoshop, the king of floating UIs, since a few years ago docked everything to the sides! 🙂

      This to say also: nothing in having a sidebar limits the kind of direct manipulation and WYSIWYG editing we can add to the page. Nothing. 🙂

      I’d like to avoid spending time going floating to then revert back right after because it won’t scale. 😉

      So my suggestion here would be:

      1. Let’s deep dive in both direct manipulation and direct editing (i.e. typing the text on the page, dropping images, etc)
      2. Let’s also put any required UI in the sidebar, as years of work of the best direct manipulations tools out there teach us

      • Weston Ruter 4:45 pm on February 16, 2016 Permalink | Log in to Reply

        Good points. I was waving my hands about the future there, not saying how exactly it will look like, but just saying what would be made possible. Whether the editing of elements is done via a control in a sidebar, or via a floating control, or via WYSWIG direct manipulation—all of these would be possible, and they could be implemented in plugins if not in core.

    • sidati 7:39 pm on March 5, 2016 Permalink | Log in to Reply

      Hello @westonruter,
      Is there a way to get the new value of the edited control/setting inside the render_callback ?? it will be very helpful cause sometimes the render_callback may depending on the new value 😉

      • Weston Ruter 7:42 pm on March 5, 2016 Permalink | Log in to Reply

        @sidati The new value will be available by default because the preview() method would have previously been called on the related settings. In other words, if you have a partial that is associated with a blogname setting, and you make a change to this setting, then when the partial is rendered you will get the modified value if you do get_option( 'blogname' ) as opposed to the actual value stored in the database. This is the fundamental component to selective refresh working, as it isn’t useful at all if the render_callback always outputs content using the values as stored in the DB. (As then it would always return the same output, unless the setting gets saved.)

        • sidati 8:23 pm on March 5, 2016 Permalink | Log in to Reply

          I got it 🙂

        • sidati 8:24 pm on March 5, 2016 Permalink | Log in to Reply

          By the way, the `partial-content-rendered` get triggered 6 times each time, is that normal ??

          • Weston Ruter 8:57 pm on March 5, 2016 Permalink | Log in to Reply

            @sidati maybe or maybe not. How many partials do you have registered? How many elements do their selectors match, all combined? Feel free to ping me on Slack and we can look into it more deeply to see if there is a defect.

    • Ahmad Awais 1:54 am on March 11, 2016 Permalink | Log in to Reply

      Hey, @westonruter!
      The `partial` only needs to be attached to a particular setting and not control? That shift-click approach would get added automatically?

    • rmaiaco 8:11 pm on March 28, 2016 Permalink | Log in to Reply

      Hi @westonruter!

      first, congratulations for the selective refresh. The best feature of wordpress 4.5 for me. I have a question: when ‘selector’ is not found the page is reloaded. Is possible prevent this?

      Example: My previewer control ‘X’ is active and your selector is ‘body #comment’. However im in homepage and the div “#comment” not exist. So, full reload is happend.

      best regards.

      • Weston Ruter 8:21 pm on March 28, 2016 Permalink | Log in to Reply

        @rmaiaco Thanks! And yes, you can disable the fallback behavior of doing a full-page refresh when the selector is not found. In the $args passed to $wp_customize->selective_refresh->add_partial() (or the WP_Customize_Partial class constructor), just include 'fallback_refresh' => false. By default the $fallback_refresh param is true, but you can override it like so.

    • rmaiaco 8:36 pm on March 28, 2016 Permalink | Log in to Reply

      Perfect @westonruter!
      Help me a lot.

      The XWP gain a new fan 🙂

      Thanks!

    • rmaiaco 6:49 pm on April 11, 2016 Permalink | Log in to Reply

      Hi @westonruter,
      A question: I noticed that the elements that are associated with a javascript function do not work after the div recharge. I have to reload the js file again?

      Ex: A menu inside in partial reloaded div not working.

      Best regards.

    • Eric Daams 1:31 am on April 13, 2016 Permalink | Log in to Reply

      Hi @westonruter,

      I assume that if you’re aiming for PHP 5.2 compatibility, the `render_callback` function should not be an anonymous function as in your `header_site_title` example?

      Cheers,
      Eric

      • Weston Ruter 8:01 am on April 13, 2016 Permalink | Log in to Reply

        @ericdaams Yes. This is just an example which you could use in a plugin or theme. Using an anonymous function is not required by any means. It just makes the example easier to read.

    • jiggaman 9:16 pm on April 25, 2016 Permalink | Log in to Reply

      Getting what I believe is a selective refresh bug in the 4.5 that didn’t exist before…using an older theme that has been working great. There are some pre-set menu locations: primary menu being one of them. Primary menu is also special in that that when the site is re-sized it has a mobile dropdown replacement. When a menu is created that is applied to primary menu, the refresh seems to be in a loop. Disabling the menu for primary menu gets it out of the loop.

      • jiggaman 11:02 pm on April 25, 2016 Permalink | Log in to Reply

        Found the issue. There was a plugin that uses the following code:

        function extra_css() {

        echo ”;
        echo ‘#customize-control-tt_default_body, #customize-control-tt_default_heading_1, #customize-control-tt_default_heading_2, #customize-control-tt_default_heading_3, #customize-control-tt_default_heading_4, #customize-control-tt_default_heading_5, #customize-control-tt_default_heading_6 { display: none; }’;
        echo ”;

        }

        add_action(‘customize_register’, ‘extra_css’);

        Commenting out the echo statements made the issue go away with the non-stop refreshing. This did not occur prior to 4.5. So maybe I have uncovered a small bug.

  • Chris Christoff (chriscct7) 5:49 am on February 12, 2016 Permalink
    Tags: ,   

    Call for Trac Tickets and Recap of 2/5/2016 Bug Scrub 

    On Friday, February 5th at 17:00 UTC, we had our regularly scheduled bug scrub. As a reminder, for the 4.5 release, trac bug scrubs will be held weekly each Friday at 17:00 UTC. Bug scrubs are held in the #core channel of WordPress Slack.

    The Slack archive for last week’s meeting begins here: https://wordpress.slack.com/archives/core/p1454691785001716

    During the bug scrub, the following tickets were covered:

    #25247, #34722, #27272, #22198, #14393, #19627, #34521, #35630, #35692, #20419, #35737, #34887, #34996, #33045, #30352, #35624, #15448, #35736

    Today, on Friday, February 12 2016 at 17:00 UTC the bug scrub will run approximately 1 hour. Participants need not be present for the full duration, and everyone is welcome to attend.

    We’ll start with a list of pre-submitted tickets, before going to an open floor.

    If you would like to submit a ticket for consideration for the bug scrub, please comment below with the ticket number. If you have extensive knowledge of the ticket, attending or adding accompanying text which provides a brief description of each ticket, its current status, and what needs to happen for the ticket would be appreciated. Bug scrubs are a great way to get extra eyes on tickets, feedback on patches, or suggestions on future routes.

    Note: this will be the last pre-submitted tickets/open-floor style bug scrub for this release. All bug scrubs after this will focus exclusively on tickets currently milestoned for this major release in order to help expedite the betas and release candidates of the 4.5 release. Normal open-floor/pre-submitted ticket bug scrubs will resume after the stable release of 4.5.

     
  • Mike Schroder 10:22 pm on December 30, 2015 Permalink
    Tags: ,   

    WordPress 4.5: What’s on your Wishlist? 

    A few weeks ago, I put out an initial call for volunteers for 4.5.

    In the spirit of the much-commented @wonderboymusic 4.4 Wishlist post, I’d like to extend the call a bit more.

    • What are you most interested in seeing in WordPress 4.5 — big, or small?
    • What are your or your users’ biggest pain points?
    • What do you see as the most important UX or performance low-hanging fruit to be solved?

    Look forward to hearing from you in the comments!

    The WordPress 4.5 kickoff chat will be next Wednesday, January 6, 2016 16:00 UTC-5.

     
    • Rami Yushuvaev 10:23 pm on December 30, 2015 Permalink | Log in to Reply

      Unifying permission error messages – https://core.trac.wordpress.org/ticket/34521

    • Patrick Daly 10:27 pm on December 30, 2015 Permalink | Log in to Reply

      Editorial Workflow…

      https://core.trac.wordpress.org/ticket/23314 – Allow published posts to be revised without being updated immediately

      https://core.trac.wordpress.org/ticket/12706 – Custom post status bugs in the admin

      • Andrew Nacin 2:54 am on January 3, 2016 Permalink | Log in to Reply

        Both great ideas. Both require a lot of careful planning, decision-making, and implementation. Proposals welcome (from everyone).

    • Mike Schinkel 10:36 pm on December 30, 2015 Permalink | Log in to Reply

      PHP7 as base requirement? 🙂

      • Michael Beckwith 10:39 pm on December 30, 2015 Permalink | Log in to Reply

        If only

      • Matt van Andel 10:50 pm on December 30, 2015 Permalink | Log in to Reply

        I’d wholeheartedly support a bump to 5.3, though.

        • Max Foundry 10:58 pm on December 30, 2015 Permalink | Log in to Reply

          Ditto and +1

        • Jeff Farthing 11:00 pm on December 30, 2015 Permalink | Log in to Reply

          This.

        • rkoller 11:02 pm on December 30, 2015 Permalink | Log in to Reply

          hm but 5.3 as well as 5.4 are already end of life. http://php.net/supported-versions.php . Wouldn’t it be a reasonable move to only support versions with an active support or at least with provided security fixes?

          • Matt van Andel 11:42 pm on December 30, 2015 Permalink | Log in to Reply

            The issue is hosting services that hold onto old versions of php far longer than they should. At this point both 5.3 and 5.4 should be supported by almost all of them precisely because they are so old. With that in mind, I think it’s time we officially bump the requirements.

            • Sybre Waaijer 4:21 pm on December 31, 2015 Permalink

              I think if WordPress would makes this call — as it’s a dominating factor on the internet — hosting providers will be sure to update ASAP to maintain good customer support and reliability. Or create i.e. specific WordPress Hosting Packages which abide to this standard.

          • Erlend Sogge Heggen 3:33 pm on January 1, 2016 Permalink | Log in to Reply

            As a gentle nudge from WordPress’ side, I think it’d be cool if WordPress installs running on EOL PHP versions (5.2, 5.3, 5.4) would show an infobar on the wp-admin.php page, just telling users something like:

            “psst! It seems like you’re using a version of PHP which is at [“end-of-life”](exampe.com/read-more). No need to worry, your WordPress install will continue to work just fine, but you might want to ask your hosting provider if they’re planning to upgrade to a newer version of PHP soon”

        • Daniele Scasciafratte 11:26 pm on December 30, 2015 Permalink | Log in to Reply

          +1

      • Ipstenu (Mika Epstein) 11:31 pm on December 30, 2015 Permalink | Log in to Reply

        Not trolling. Is there a technical reason we need to?

        • Mike Schinkel 1:02 am on December 31, 2015 Permalink | Log in to Reply

          No real reason other than performance and ability to leverage new features like null coalescing, anonymous classes, etc.

          I know it would be a non-starter for backward compatibility though. Just wishing out loud, since he asked. I guess I was really the one trolling, but hopefully not viewed in a bad way. 🙂

          • Ipstenu (Mika Epstein) 1:45 am on December 31, 2015 Permalink | Log in to Reply

            I was legit wondering if there was a feature or such I’d missed that we need 🙂

            Backcompat aside, that’ll be your driving factor. When we have a legit need for 5.4 or 7, it’ll happen 🙂

            • Terence 12:35 pm on January 3, 2016 Permalink

              How about with PHP 7 your apps see up to 2x faster performance and 50% better memory consumption than PHP 5.6, allowing you to serve more concurrent users without adding any hardware? I should have thought that PHP 7 allowing the system to execute twice as many requests per second in comparison with the PHP 5.6, was reason enough.

            • Ipstenu (Mika Epstein) 3:28 pm on January 3, 2016 Permalink

              @pubdirltd – that’s not a feature WordPress needs. It’s one users want, and I want, but it’s in no way preventing the development of WP. Which works fine on 7. So again, if someone has a technical feature of 7 that we actually NEED, I’m all ears.

              Until then, we’re only 25% of the for million sites on the Internet. It’s a lot bigger ocean than just WP.

        • J.D. Grimes 2:27 pm on December 31, 2015 Permalink | Log in to Reply

          Yes. It allows us to more easily build OO code that can take advantage of autoloading. (Technically can be done now, but autoloading can be disabled below 5.3 so there has to be a backup plan for such cases.)

          Test and build tools and Travis CI will all be moving on. Travis already dropped support for 5.2 once and only brought it back mostly for WordPress.

          Neither of these things are necessities, but the extra burden on us all for supporting 5.2 is at some point going to surpass the burden of not supporting it. Maybe we aren’t there yet but waiting another year and a half for the number of site on 5.2 to drop to ~0 probably isn’t worth it.

        • Marcel Pol 11:17 am on January 4, 2016 Permalink | Log in to Reply

          To guard the users against security issues in PHP 5.2.
          Supporting 5.2 sends the message that is is a good idea to use it. Not supporting it anymore will make hosters upgrade their PHP and its security issues.

          • Scott Kingsley Clark 11:20 am on January 4, 2016 Permalink | Log in to Reply

            Text on Requirements page currently says:

            To run WordPress we recommend your host supports:
            PHP version 5.6 or greater
            MySQL version 5.6 or greater

            There are notes further below about support for 5.2.4+ but explicitly saying it exposes your site to security vulnerabilities.

            • summoner 11:37 pm on January 18, 2016 Permalink

              Well actually even PHP 5.5 is near its EOL so i think WP 4.5 should be able to check the server’s PHP version do the following:

              • upon WP’s installation process it should prompt the user that their server uses an EOL PHP version which technically is enough but may have security issues and the user should contact the hoster
              • when an already installed WP gets updated to WP 4.5 it should display a message with a link to detailed info. Similar to cookie notification bars. I would turn it on by default so that a very large number of WP users would contact their hosters (naturally this notification must be turned off extremly easy if the hoster just does not do anything)

              Here is why:

              • most average people will just try to install WP on their own and they will not ever read the requirements page on wordpress.org. So they will not know about security concerns of EOL PHP versions until their site gets hacked…
              • WP is the most widely used CMS and hosters are actually payed to maintain their services. Hosters who have PHP 5.2, 5.3. 5.4 installed should really have their investments payed back by now by their users so they really should be able to upgrade to at least PHP 5.6 (or even to 7) both technically and financially.

              Actually you can not sell a car if you KNOW that the safety belt is not strong enough and will be torn in case of an accident. Hosters who have only EOL PHP versions available do the exactly same thing and without some pressure they will be happy to continue that while collecting some more money from their customers.

            • summoner 12:10 am on January 19, 2016 Permalink

              Sorry, need to be some more exact:
              On upgraded installations the notification bar should be displayed even on the FRONT-END. That is why i compared it to a cookie notification bar. 😉

              I know that might sound as a no go for many of you, but that is why it should be extremly easy to turn off (ex under Settings->general). Otherwise hosters simply will not react as they did not even until now.

          • Ipstenu (Mika Epstein) 4:53 pm on January 4, 2016 Permalink | Log in to Reply

            Not supporting it anymore will make hosters upgrade their PHP and its security issues.

            I disagree. I think it’ll just make the users, not the web hosts, upset that they can’t use WP for reasons they don’t understand.

          • Jonathan Hefner 10:29 pm on January 6, 2016 Permalink | Log in to Reply

            Agreed. I also think that if it is *possible* to run WordPress on an unsupported PHP version, some hosts *will* do it, regardless of the security risks. And users will likely not know any better. And when said users are compromised, it is possible they will ignorantly blame WordPress itself.

            So +1 for bumping PHP version requirement (and even enforcing it with a version check).

        • jrf 2:48 am on January 6, 2016 Permalink | Log in to Reply

          Not so much PHP7, but a technical reason case can easily be made for moving up to PHP5.4, preferably 5.5 as that would provide access to the Intl extension which will enable much improved localization and internationalization functionality as well as better utf-8 support.

      • Sisir 8:54 am on December 31, 2015 Permalink | Log in to Reply

        +1 🙂 Although I don’t see it happening. -_-

      • askoxyz 10:58 am on December 31, 2015 Permalink | Log in to Reply

        Impossible for now, but a bump in requirements would be awesome.

      • Joost Abrahams 9:53 pm on January 5, 2016 Permalink | Log in to Reply

        As end user, non coder, small blogger, wide support for PHP is priceless. No hassle, just works.

    • Ryan Kanner 10:42 pm on December 30, 2015 Permalink | Log in to Reply

      Definitely adding orderby metadata for taxonomy -> https://core.trac.wordpress.org/ticket/34996
      Also would like to see some movement on the shortcake plugin. I think it’s pretty important for the future of shortcodes.

    • sosensible 10:43 pm on December 30, 2015 Permalink | Log in to Reply

      First, LOL Mike… I like the thought but that will be a few years before it happens.

      : : Seeing in 4.5 Notes : :

      • Shortcake plugin as part of the core.
      • Complete RESTful API

      : : Biggest Pain Points : :

      • WP_Query lacks rich relational function.

      : : UX : :

      • Any feature that runs slow is bad. Most companies who extend the page editor to the front side, outside the ADMIN are painful slow. Any speed gains in this area are big wins. While I am open in spirit we should make core perform so well those slow plugins are either dropped or fixed. 🙂
    • Dave Navarro, Jr. 10:44 pm on December 30, 2015 Permalink | Log in to Reply

      When adding new plugins and themes from the repository, I’d REALLY like to have the feature back where I can sort the search results by date, last-date-updated, number-of-installs, ratings, etc… I REALLY REALLY miss that functionality.

      If I upload a plugin or theme ZIP file and the plugin/theme already exists, instead of an error messages, can I be prompted to replace the existing plugin? I have several plugins from third-parties that I get by ZIP file.

    • J.D. Grimes 10:45 pm on December 30, 2015 Permalink | Log in to Reply

      Several tickets I’d like to see action on (no particular order):

      #31281 #34114 #33472 #25137 #27770

    • Matt van Andel 10:49 pm on December 30, 2015 Permalink | Log in to Reply

      I REALLY want to get #16031 finally taken care of. I have a very comprehensive patch uploaded as of last August that does the trick admirably. The alternative is an even more substantial refactoring of the admin screens to merge handling and redirect behavior into the WP_List_Table class(es). I’m happy to work toward the latter solution if necessary, but I think the previous patch is peachy keen as-is.

    • Howdy_McGee 10:53 pm on December 30, 2015 Permalink | Log in to Reply

      I’m a developer who, when I deploy and monitor a theme, like to keep `debug.log` on so I can continually keep any active themes in tip-top shape. My **biggest** peeve is when simple conditionals throw out general `non-object` errors from core `query.php`. There’s a pretty large list which can be found on trac but it doesn’t seem to have gotten a ton of notice ( https://core.trac.wordpress.org/ticket/29660 ).

      The biggest problem is it isn’t just one error, when one of these issues happen there’s at least 4 errors together which spam my error logs like crazy and I have to really hunt down what specifically is causing the issue in my theme. It’s a trial and error process to fix what should be non-issues which I would love to see go away.

    • Pascal Birchler 10:53 pm on December 30, 2015 Permalink | Log in to Reply

      A short list of things I’d be interested in working on:

      • Notifications API — @johnbillion mentioned this first and @rmccue is interested as well. To quote John: “I’m going to kill wp_mail() and replace it with an API.”
      • Improving support options in core: Send anonymous crash reports, search help resources from inside the admin, show videos from WordPress.tv, leveraging WordPress.org as an OAuth provider, etc.
      • Embeds template improvements
      • chriscct7 11:58 pm on December 30, 2015 Permalink | Log in to Reply

        I’d love to help out with Notifications API as well

      • Michael Beckwith 1:48 am on December 31, 2015 Permalink | Log in to Reply

        There’s already early work going on to do something similar with regards to email in BuddyPress. Very exciting.

      • Peter Wilson 4:00 am on December 31, 2015 Permalink | Log in to Reply

        I can help out on embed templates, Pascal.

      • J.D. Grimes 2:27 pm on December 31, 2015 Permalink | Log in to Reply

        +1 for notification API

      • mrjarbenne 4:59 pm on January 1, 2016 Permalink | Log in to Reply

        Has there been any thought to creating embed templates for post formats? Currently text is well supported, but post formats like video and audio create an embed with the post title only. I acknowledge the difficulty in this may be that the majority of these types of of posts are embeds from other sites (YouTube, Soundcloud, etc) which creates an embed of an embed.

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

        After having done work with notifications at Automattic, I’d be happy to help. Please feel free to ping me in Slack 🙂

    • Aaron Brazell 10:54 pm on December 30, 2015 Permalink | Log in to Reply

      Indexing of meta tables. I’d say that postmeta and usermeta (probably now tax meta) are increasingly important for complex client deliveries

    • petermolnar 10:54 pm on December 30, 2015 Permalink | Log in to Reply

      webmentions (https://wordpress.org/plugins/webmention/) as featured plugin as a future replacement for pingback.

      • dshanske 11:06 pm on December 30, 2015 Permalink | Log in to Reply

        As someone who has contributed to that plugin, made a general nuisance of myself trying to improve trackbacks and pingbacks as well to the point that people wanted to use linkbacks again….+1 if there is such an option. I’m a mediocre programmer, but I would work on such a feature plugin with a strong lead.

        • Daniele Scasciafratte 11:27 pm on December 30, 2015 Permalink | Log in to Reply

          maybe a pingback vs webmention explanation will be improve the propose to a feature plugin.

          • dshanske 12:22 am on December 31, 2015 Permalink | Log in to Reply

            A pingback is an XML-RPC request advising that another site has linked to your site. Your site then goes back and checks the accuracy of that request. The presentation of pingbacks in WordPress, quite frankly, is lacking. The […] presentation is pretty useless.

            Webmention is an update to that, using only HTTP and x-www-form-urlencoded content. (http://indiewebcamp.com/webmention-spec).

            Now part of this goes to the idea of improving Linkbacks, which have become a spammy cesspool that people do not want to play with. But it has a lot of potential.

            In practice, sites that receive webmentions look for microformats markup(or optionally other parsed elements) and use this to render a better response. The Semantic Linkbacks plugin(https://wordpress.org/plugins/semantic-linkbacks/) does this for all types of linkbacks.

    • rkoller 10:55 pm on December 30, 2015 Permalink | Log in to Reply

      Two of my biggest pain points are summed up by Jeff Eaton in the back-end part of the toast redesign article: http://responsivewebdesign.com/toast/backend/

      • The current templates are spaghetti code and could use some sanity with something like Timber/Twig
      • WordPress is badly missing the ability of structured data. You have to use Advanced Custom fields but the content is encoded only as text in the post meta table anway.
      • petermolnar 10:58 pm on December 30, 2015 Permalink | Log in to Reply

        +1 for a Twig based “official” theme.

      • davidshq 3:59 am on December 31, 2015 Permalink | Log in to Reply

        +1 for Twig
        +1 for more ACF functionality. Maybe just buy it out, if he’s willing? 🙂

      • Scott Kingsley Clark 4:55 pm on January 3, 2016 Permalink | Log in to Reply

        Structured data registered via Fields API would be a great next step, there are also plugins that let you create tables for your post type(s) and store those custom fields in a correctly typed DB column.

        • rkoller 12:40 am on January 5, 2016 Permalink | Log in to Reply

          i agree. but wouldn’t it be a reasonable move not to rely on plugins to create tables for the post types with the correctly typed DB columns for the custom fields; instead update the core db schema for wordpress? i know it would extend the scope of the fields api project. but if the fields api would take care of the proper encoding and db storage you would ensure to have a solid, stable and especially more performant foundation for the fields api as well as wordpress in general. better to have that kind of functionality in core than in a plugin?

          • Scott Kingsley Clark 5:37 pm on January 5, 2016 Permalink | Log in to Reply

            I definitely won’t be able to tackle database structures in the Fields API project, that’s far outside of the scope and there’s plenty of debate to be had that I’d rather keep out of 🙂

            Related though, I am the lead developer of the Pods Framework, a content development framework that allows you to create new / extend content types for WP. One of the options is to create a table for your custom fields which get their own DB columns correctly typed — or have a completely custom table outside of the Posts area called an Advanced Content Type.

            I know a thing or two about this, and there’s little or no inkling that the WP core team will be heading in a direction of table manipulation or db restructuring for custom fields in the near future.

            • rkoller 11:13 pm on January 5, 2016 Permalink

              yep i am aware that it is out of the scope of the fields api project; but i wanted to bring it up again in the 4.5 wishlist discussion so maybe some wp core team members might chime in and give it a second thought. cuz if all the new field types are brought in it would be a huge step in the first place but you would still have the issue jeff eaton brought up in the article with acf at the moment: “This isn’t a problem if you’re only using custom field data when a post is loaded and displayed. If you plan to use these custom fields to handle complex relationships—connecting a post to multiple authors, say—the SQL queries to handle that data will be punishingly slow.” but i will give the pods framework a try and see how things are handled there and how it goes with acf pro at the moment. thanks for the headsup. 🙂

      • Jonathan Hefner 10:33 pm on January 6, 2016 Permalink | Log in to Reply

        A huge +1 for both points. The article you linked was very insightful. Someone else in this thread mentioned #33472, which is relevant.

    • seanbennick 11:03 pm on December 30, 2015 Permalink | Log in to Reply

      Improved image management. WordPress is not just a blog anymore, so the date organization structure doesn’t work. Adding categories and maybe even tags for images would solve a lot of issues.

      • petermolnar 11:07 pm on December 30, 2015 Permalink | Log in to Reply

        You could add custom taxonomy for attachments.

        As for the filesystem layout, I’m already moving the genarated images away from the upload directory and I’d welcome this change to WordPress itself to keep the upload dir clean.

      • davidshq 3:59 am on December 31, 2015 Permalink | Log in to Reply

        +1 The Enhanced Media Library plugin is a great place to look to see some of the missing functionality.

      • vherring 5:42 am on December 31, 2015 Permalink | Log in to Reply

        My biggest wish for WordPress is some real work be done on the media library, it’s barely adequate and the management of hundreds of photos is difficult and you absolutely have to resort to a third party to manage thousands. The average blogger has that now days.

      • szabesz 7:34 am on December 31, 2015 Permalink | Log in to Reply

        +1 for this. I should also mention that storing the actual image files in one folder or in folders generated based on the month in which they were uploaded is just not enough. We should have more options, for example: images stored in folders we want to put them into. We should be able to define our own folder structure.
        Another thing is all those resized versions of the images. Other CMS’es store them in a subfolder like “_resampled” or similar. But WordPress makes a big mess by storing them alongside the original.
        And the third thing is gallery management, which is extremely basic. There is a lot of room for improvement is this area. No wonder every week a new gallery plugins is released… Developers are trying to solve it on their own way.

      • Paal Joachim Romdahl 9:48 pm on January 1, 2016 Permalink | Log in to Reply

        A big +1 to better media management!

      • MHagemeister 9:38 am on January 2, 2016 Permalink | Log in to Reply

        That’s my biggest issue with WordPress as well at the moment. I have a huge library with tons of images and the filesystem structure is a mess. Like others have already mentioned, I’d love to keep the uploads folder clean and put all resized media in a seperate “resampled” folder (or whatever it should be called)

      • taloweb 10:44 am on January 2, 2016 Permalink | Log in to Reply

        yes +1 also for me!
        A better media manager without plugins is a must now!
        A tight relation btw posts and media items and no more html insertion (by now to find where is used an image we have to use regexp on html), a robust cache sistem without resized images with size in filenames (when you change theme it is a pain), an easy way to find unused images to clear filesystem and so on…

      • danielgoze 10:08 pm on January 4, 2016 Permalink | Log in to Reply

        +1 Fully agree. Image Categories seem like a must for a site with more than 10 items in Media. Enhanced Media Library does have some great tools.
        Some Ideas I’ve had over the years:
        • Bulk edit to apply/remove image categories.
        • Possibly breakup Media into “views” of Images, Downloads & Video (in the menu rather than the pulldown filter) so that clients can find things easier.
        • Sometimes I hide images that I don’t want the client to change in the theme or a plugin, with the new site icon tool in the customizer, I wouldn’t want the client to go in and put in a much lower res file in when they feel like it, something like a checkbox for “admin only” for any images that the site relies on.
        • Crop for any size – I’ve seen the crop for thumbnail, but sometimes one size needs just a slightly different focus (example: a person is halfway cropped and if the crop started more to the left), especially now with the responsive images.
        • Other plugins already handle this, but regenerating thumbnails, renaming actual files, replacing files with a new file, and cleaning file names as a standard feature would really be appreciated.

      • htrex 11:06 am on January 5, 2016 Permalink | Log in to Reply

        +1 yes, an enhanced media library taxonomy is really needed

      • Anthony Hortin 5:05 am on January 7, 2016 Permalink | Log in to Reply

        +1 for this. Managing a large amount of images is so cumbersome and time consuming. The images library needs the ability to create folders along with being able to drag/drop images into those folders. The current Grid/List UI also needs to be fixed. There’s two completely different workflows, depening on whether you’re loooking at the Grid view or the List view and it’s makes the UI confusing. i.e. there’s multiple screens that perform the exact same function

      • Claude Martin 12:52 pm on January 7, 2016 Permalink | Log in to Reply

        +1 Media management needs improvementS. And thanks for all

    • Jeff Farthing 11:06 pm on December 30, 2015 Permalink | Log in to Reply

    • Dave Navarro, Jr. 11:08 pm on December 30, 2015 Permalink | Log in to Reply

    • Ipstenu (Mika Epstein) 11:16 pm on December 30, 2015 Permalink | Log in to Reply

    • Daniel Bachhuber 11:17 pm on December 30, 2015 Permalink | Log in to Reply

      As a co-maintainer of the Shortcake Feature Plugin, I’d like to get Official Core Direction on shortcodes and shortcode UI before we spend too much more time on it.

    • Daniele Scasciafratte 11:25 pm on December 30, 2015 Permalink | Log in to Reply

      Add get_post filter: https://core.trac.wordpress.org/ticket/12955 the patch is ready with case study and example use
      Introduce helper function for AJAX checks: https://core.trac.wordpress.org/ticket/25669 standardize the check of is an ajax request. patch ready
      Add hook for custom post.php actions: https://core.trac.wordpress.org/ticket/27056 help the plugin developers, patch ready

    • j-falk 11:27 pm on December 30, 2015 Permalink | Log in to Reply

      My wish-list:

    • Giorgos Sarigiannidis 11:29 pm on December 30, 2015 Permalink | Log in to Reply

      My list, starting from the most feasible and moving to the most controversial / impossible to happen:

      1. Better plugin management at the WP Dashboard, taking advantage of your wordpress.org favorites collection. For example, order your favorite plugins based on those that you install more often and allow batch install and activation of multiple plugins at once.

      2. Allow (and perhaps encourage) security adjustments during WP install, like setting a login url other than wp-login.php, disable XML-RPC, disable pingbacks, disable comments etc.

      3. Adding native support for content translation.

      4. Absorb CMB2 to the core.

      5. During WP install, allow us to choose our theme between twenty-whatever and underscore_s.

      6. Add “Child plugin” support, to allow overriding a plugin’s settings the same way we do it in themes, with child themes.

    • Jon Brown 11:29 pm on December 30, 2015 Permalink | Log in to Reply

      So many things… but
      #1 land the Fields API. It’s _long long long_ over due.
      #2 Finish out the REST API.
      #3 Improvements to media management (better CORE tools for organizing and managing large asset libraries).
      #4 Improved image editing and flow. I for one didn’t really like the direction Image Flow was going, but incremental improvements would be welcome.

    • andreasnrb 12:01 am on December 31, 2015 Permalink | Log in to Reply

      #1 custom comment types

    • simonrcodrington 12:29 am on December 31, 2015 Permalink | Log in to Reply

      I’m always pretty keen for additional hooks and filters in the admin area to customize the way the UI works. For example adding new hooks into the new media modal window (https://core.trac.wordpress.org/ticket/35205)

      I’m keep to chase this up (as literally it’s just a quick edit to a few template files in core).

      Love to see more hooks and filters that give me the power to change up and extend the way WordPress does stuff.

    • davetgreen 12:34 am on December 31, 2015 Permalink | Log in to Reply

      Add a ‘Last Updated’ timestamp for each and every plugin in the list of installed plugins, so that admins can see at a glance how long it has been since an update. This way they can make an informed decision as to whether the plugin needs to be replaced by an alternative or not. The security implications of reducing the number of extremely outdated plugins are obvious. 🙂

      A nice to have would be a check carried out by WordPress that alerts the user if the plugin hasn’t been updated in X time frame: possibly 2 years as per the .org repo warning.

      I plan on working on this early in 2016 as my first WP commit proposal. 🙂

    • mbrsolution 12:49 am on December 31, 2015 Permalink | Log in to Reply

      I am sure many have asked this before or it maybe included already in the next version. I would really like the ability to upload an image or photo to the profile without using a plugin, a function and or without having to sign up to gravatar under discussion -> Avatars. …..sorry for this basic request.

      Thank you all for the great work you all put in with developing WordPress…….

    • ChokDK 1:32 am on December 31, 2015 Permalink | Log in to Reply

      I wish there was some kind of help for the “pro theme makers” so adjustment of 3/3 columns spacing/width would be easy and still responsive.
      For now, they don’t dare to make it user adjusted.

      I also wish the Soundcloud pre-picture for 1/3 columns could be resizeable instead of disappearing (as it is working now)

    • Amanda Rush 1:33 am on December 31, 2015 Permalink | Log in to Reply

      I’d like to see post formats given some serious attention. I don’t think they should be left up to theme authors without any kind of guidance as to how they should be handled, ETC. I’d be willing to work on this as I use them quite frequently.

    • KARTHOST 2:10 am on December 31, 2015 Permalink | Log in to Reply

      You asked for a Wish list here it is:

      1) Finish Rest API

      2) SIMPLE SSL Set up, example:
      In Settings
      [ x ] No HTTPS
      [ ] HTTPS Admin Only
      [ ] HTTPS Entire Site

      Make it that simple for the end user.

      3) Built in SMTP to allow site owner to set up a 3rd Party SMTP service (allow SSL Port 465 as well) and disable wp-mail.php or just use wp-mail.php (you can default to wp-mail.php, but email sending should be something related with core and have a choice as to what type service to be used.
      3a) Create email template and allow end user the ability to customize the content in the default emails WordPress install sends out and the email headers.

      Thanks for all considerations

      Roy Randolph

      • J.D. Grimes 2:30 pm on December 31, 2015 Permalink | Log in to Reply

        +1 for better SSL support. It seems like a black box to me, and I’m a dev. 🙂

      • Nico 11:08 pm on January 1, 2016 Permalink | Log in to Reply

        With HTTP/2 only working over SSL I suggest people move to HTTPS only and drop http and set their servers/move hosts if necessary for it.

        There is a useful wp-config setting `define(‘FORCE_SSL_ADMIN’, true);` with that setting it would prevent insecure admin in case of a mis-configured server. This is basically your `[ ] HTTPS Admin Only`.

        As for SSL config its pretty much a server setup thing that has nothing to to with WordPress, you setup your server to server over SSL and then switch the site URLs in the WordPress config from http to https. So I see no need for WordPress to do more then its already doing.

      • thomaswm 5:14 pm on January 2, 2016 Permalink | Log in to Reply

        +1 for simple SSL support. It will become really important now that Let’s Encrypt is handing out free SSL certificates.

        https://core.trac.wordpress.org/query?status=!closed&keywords=~https

      • nathangraham 4:56 am on January 3, 2016 Permalink | Log in to Reply

        +1 for simplifying SSL set up

    • chrishoward 2:17 am on December 31, 2015 Permalink | Log in to Reply

      • Media categories. Pleeeaasse!
      • Hooks on the post listing and post editor screens for displaying instructions or other info to users. This is especially useful for custom post types. Currently I hack into the views-edit-{cpt} and edit_form_after_title hooks, but that’s not tidy.
      • More and better use of contrast and colour in the admin UI. I know minimalism is all the rage, but that doesn’t make it good UX. e.g. The post editor meta boxes could do with stronger headers as almost every thing in the post editor is black/grey on white. The visual hierarchy of WP admin varies from minimal to too subtle.
    • Ben Hansen (ubernaut) 2:19 am on December 31, 2015 Permalink | Log in to Reply

    • Mike Schinkel 2:48 am on December 31, 2015 Permalink | Log in to Reply

      Definable Image Types and associates sizes for those types.

      Rather than have all images have all sizes, frequently is is helpful to design a `’hero’` as having one set of sizes and a `featured-story` as another set of sizes and so on.

      • Andrew Nacin 11:49 pm on January 1, 2016 Permalink | Log in to Reply

        I’ve always liked this in theory, but I’m not sure how you’d auto-magically choose which image gets which treatment. (Beyond say featured image, which has its own UI.)

        I’d be more inclined to spend time to make it so WordPress creates crops only when we need them, and not on upload. We could create a thumbnail and a silver master that is a bit smaller and thus easier to work with from the original, and then generate crops when we need them. (We can even fake non-proportional crop previews using canvas or something else.) This is something we’ve talked about extensively, and notably, @mikeschroder happened to be one of the people who instigated those conversations (and who shepherded WP_Image_Editor into core).

        • heintore 3:00 pm on January 5, 2016 Permalink | Log in to Reply

          @nacin – we’re using the OTF Regenerate Thumbnails plugin extensively on our clients’ sites. It works exactly as advertised by generating images on the fly. No custom functions needed, all calls to the_post_thumbnail and other thumbnail functions are handled automatically.

          There may be plenty of reasons why this particular approach is a terrible solution for WordPress core, but I’m much preferring this plugin over how WordPress handles crops now 🙂

          https://wordpress.org/plugins/otf-regenerate-thumbnails/

      • Joe McGill 9:46 pm on January 2, 2016 Permalink | Log in to Reply

        I’ve thought about having a custom image size created when an image is added as a featured image to a specific post type. Maybe something like that could work?

      • Brad Touesnard 12:38 pm on January 7, 2016 Permalink | Log in to Reply

        +1

        #11895 is related to this and I suggested the same solution:

        > I think there is certainly a need for a “treatments” concept that is independent of size though. For example, it’s pretty common to want to crop a photo a certain way for display on a listing page (e.g. post archive page) but display the uncropped version on the detail page (e.g. single post page). I’m guessing that was the original intention of the “Apply changes to:” feature, but it never really hit the mark.

    • dryanpress 3:13 am on December 31, 2015 Permalink | Log in to Reply

      • SVG Dashicons
      • Update on direction of shortcodes in core and Shortcake
      • WP Admin Toolbar Improvements (https://core.trac.wordpress.org/ticket/32678). Proposed i10 changes look great, love increased negative space, but even fewer sites would be listed in view. A live search and list of recently updated and/or pinned sites would go a long way in moderate and large networks.
      • Native multiple authors for Posts. Co-Authors-Plus may add this in plugin territory, but subsequent integration into a theme requires complicated overriding or child theming. Giving non-developers the ability to add multiple authors on Posts, Books, Report Chapters, Music Videos, etc is important.
    • Peter Wilson 4:08 am on December 31, 2015 Permalink | Log in to Reply

      My wish list/hobby horses:

      • #35206 to control white space in menus, as a follow up to #27762 in 4.4 and later reverted.
      • #32793 to combine jQuery and jQuery migrate and reduce HTTP requests.

      Otherwise, some of the tickets around HTTP2 would be lovely to get in.

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

      1. I’d like to be able to wrap opening and closing php tags in code tags using the text editor and 2. link gallery images.

    • Marius (Clorith) 7:39 am on December 31, 2015 Permalink | Log in to Reply

      I’d love to see some kind of merge between #20578 (the option to not trigger `uninstall.php`) and #9757 (better handling of uploads when the theme/plugin exists).

      As it stands it’s painful having to change to a different theme to update a custom theme. The process was made slightly better by core remembering widgets, but you still need to change the look of your site for a period of time while uploading and re-configuring and it is a terrible user experience.

      Of course, premium themes often leverage some filters to apply updates, but imagine the sites that run old premium stuff that are avoiding updating because it’s a tedious process, and the presumably large amount of them that don’t have this filter interaction any way.

    • Rian Rietveld 7:51 am on December 31, 2015 Permalink | Log in to Reply

      The Accessibility team focusses for this release on:

      • Make the colors of the default Admin scheme conform to WCAG 2 AA (tickets are labeled #a11y-color)
      • Remove title attributes from links
      • Improve the accessibility of the customizer (for keyboard only, screen readers and for color contrast)

      Help with this is very welcome.

    • leemon 8:22 am on December 31, 2015 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/9777: Usability : add delete button to edit-tags.php
      https://core.trac.wordpress.org/ticket/20901: Taxonomy descriptions should be TinyMCE editable
      https://core.trac.wordpress.org/ticket/23421: Add sortable to taxonomy column
      https://core.trac.wordpress.org/ticket/14877: Ability to create exclusive custom taxonomies
      https://core.trac.wordpress.org/ticket/22938: Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list
      https://core.trac.wordpress.org/ticket/21165: Make categories widget work with custom taxonomies
      https://core.trac.wordpress.org/ticket/5034: Impossible to have duplicate category slugs with different parents
      https://core.trac.wordpress.org/ticket/32378: Image Uploads automatically puts “Olympus Digital Camera” as caption
      https://core.trac.wordpress.org/ticket/32101: Ability to mark plugin as unmanaged
      https://core.trac.wordpress.org/ticket/22355: Template stack – Beyond parent/child theme relationships
      https://core.trac.wordpress.org/ticket/33407: Theme tags overhaul
      https://core.trac.wordpress.org/ticket/19627: Themes should be able to opt-in to a static front page
      https://core.trac.wordpress.org/ticket/22942: Remove Post by Email
      https://core.trac.wordpress.org/ticket/22363: Accents in attachment filenames should be sanitized
      https://core.trac.wordpress.org/ticket/12718: Better structure for admin menu

    • Sisir 8:32 am on December 31, 2015 Permalink | Log in to Reply

      I would love to see my reported bugs are resolved 🙂

      1. https://core.trac.wordpress.org/ticket/24990
      2. https://core.trac.wordpress.org/ticket/35216
      3. https://core.trac.wordpress.org/ticket/32920

      I don’t have #slack account. Never got my invitation. #2 is most critical if not all 😀

    • Martin Stehle 11:09 am on December 31, 2015 Permalink | Log in to Reply

      Please make Google Fonts in the backend and Emojis available only by activated checkboxes. Both features are on by default and generates dispensable traffic.

      More about the Google Fonts issue at ticket https://core.trac.wordpress.org/ticket/26072

      • askoxyz 11:17 am on December 31, 2015 Permalink | Log in to Reply

        +1

      • petermolnar 12:23 pm on December 31, 2015 Permalink | Log in to Reply

        YES, PLEASE.
        ( And that same for EVERY feature that is addon-level, like embed )

      • Last Rose Studios 3:43 pm on January 4, 2016 Permalink | Log in to Reply

        +1 Get rid of emojis – the fact that there area bunch of plugins and how-tos on how to remove them should be a clear indication that people don’t want them. There is no reason something like that should be in the core. At the very least, make it optional (activated only by checkbox).

    • Martin Stehle 11:25 am on December 31, 2015 Permalink | Log in to Reply

      Please make tags hierarchical like categories

      • Martin Stehle 11:26 am on December 31, 2015 Permalink | Log in to Reply

        … with an backend interface like for categories 🙂

      • Andrew Nacin 11:39 pm on January 1, 2016 Permalink | Log in to Reply

        That would defeat the purpose of tags, which is for them to be flat and ad-hoc. 🙂 You can still register your own taxonomy with any attributes/flags you want.

    • Gerard Canters 12:20 pm on December 31, 2015 Permalink | Log in to Reply

      RFC:

      WP 4.3 accepted shortcodes with a tag containing a space, WP 4.4 does not. Also, you don’t get an error message or indication.
      Suggest to have add_shortcode funtion return a true result or an error-indication.
      In general should all functions return a true result or error.

    • benoitchantre 1:26 pm on December 31, 2015 Permalink | Log in to Reply

      I would like to see responsive image header and a drag and drop UI to reorder pages and custom post types.

    • Andrea Fercia 1:45 pm on December 31, 2015 Permalink | Log in to Reply

      1) Settings API: get rid of the tables and UI/accessibility improvements
      https://core.trac.wordpress.org/ticket/18801
      https://core.trac.wordpress.org/ticket/16413

      2) Re-think `$content_width`
      We’re in a “responsive era”, maybe re-think the whole idea of `$content_width` ? Some comments collected in the past months:
      https://core.trac.wordpress.org/ticket/21256#comment:25
      https://core.trac.wordpress.org/ticket/23863#comment:10
      https://github.com/Automattic/_s/issues/100#issuecomment-40746610
      https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-04-11&sort=asc#m593089

      3) Add a “typography” focus on Trac 🙂

      • Nico 11:20 pm on January 1, 2016 Permalink | Log in to Reply

        Totally agree with $content_width. I always hated that thing, even when not thinking about responsiveness.

      • robertwhitis 8:15 am on January 4, 2016 Permalink | Log in to Reply

        Along the lines of eliminating tables, the admin CSS classes need support for columns. An example would be the use of a jQuery repeater for a row of fields. There’s not really any built in support for a go-to way to handle columns currently that I am aware of.

      • Ahmad Awais 5:40 pm on January 4, 2016 Permalink | Log in to Reply

        +1 for #2.

    • tomdxw 2:21 pm on December 31, 2015 Permalink | Log in to Reply

      How about bcrypt? https://core.trac.wordpress.org/ticket/21022

      It’s a one-line change and it’ll make a huge difference to the security of 89% of WordPress sites (PHP 5.2 doesn’t support bcrypt, but PHPass falls back to using the old algorithm in that case).

    • Dave McHale 3:53 pm on December 31, 2015 Permalink | Log in to Reply

      One of the biggest complaints I hear from my users is the menu management tools in the admin. A CMS website with a moderate number of pages quickly becomes incredibly difficult to manage. An overhaul there is long overdue IMO.

      The classic widget management tools are equally frustrating to work with, but I think core is already on a path towards getting away from that screen as much as possible – so I don’t know if updates there are really worth time/attention.

      • Andrew Nacin 11:30 pm on January 1, 2016 Permalink | Log in to Reply

        I think a new exploration in menu management would require building an update as a plugin using the feature plugin model.

        Have you looked at menu management in the customizer? I feel like I prefer it. I agree it still becomes tough to work with, with a lot of pages, but have you ever used a menu-building experience that works well with a lot of pages? Actually, have you ever used a menu (as a user) with a lot of pages?

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

      My wishlist
      WP REST API

    • Scott Kingsley Clark 5:16 pm on December 31, 2015 Permalink | Log in to Reply

      I’m totally all about Fields API, there’s just a little bit more left to do and I’ll have it in a place where it’s ready for core proposal!

    • colomet 5:32 pm on December 31, 2015 Permalink | Log in to Reply

      If Photon can not refresh the pictures (in case we do changes). I preffer not to have photon and to have my own CDN.

    • colomet 5:33 pm on December 31, 2015 Permalink | Log in to Reply

      ¡ Speed
      ¡ Lower use of resources

      • Andrew Nacin 11:32 pm on January 1, 2016 Permalink | Log in to Reply

        These are nice wishes, but we realistically need concrete proposals for how to get there. For example, I pull up WordPress in KCacheGrind quite often when contributing, to identify bottlenecks and potential areas for improvement.

    • Justin Sainton 5:51 pm on December 31, 2015 Permalink | Log in to Reply

    • askoxyz 6:12 pm on December 31, 2015 Permalink | Log in to Reply

      Move WP Comment Humility (https://wordpress.org/plugins/wp-comment-humility/) to core, which moves the Comments top level menu under Posts top level menu, where it belongs now that comments are off on Pages by default.

      • Andrew Nacin 11:38 pm on January 1, 2016 Permalink | Log in to Reply

        I saw this proposal on Twitter the other day. I actually like it in theory, but:

        • It would probably be jarring/confusing for a lot of people who don’t know where their comments menu went. (This is a solvable problem, of course.)
        • If a custom post type supported comments, then what? (It could always move back. There’s of course been talk that comments should possibly be moderated per post type, but that gets annoying when all you have is posts and pages and you do use comments on pages — admittedly rare.)

        This absolutely could only be done if there was extensive usability testing with various scenarios that can back up the decision.

    • Ipstenu (Mika Epstein) 7:33 pm on December 31, 2015 Permalink | Log in to Reply

      Posts like this very one make me think that Emoji Reactions should be a thing. If we could all click an emoji +1/-1 (thumbs up/down) to vote, it would be so lovely.

      https://wordpress.org/plugins/emoji-reactions/ ? Pull that in? 😀

    • George 5:40 am on January 1, 2016 Permalink | Log in to Reply

      https://wordpress.org/plugins/custom-upload-dir/

      Add similar functionality to core.

    • luciole135 8:38 am on January 1, 2016 Permalink | Log in to Reply

      Hello,
      I hope to ask the right place unless I should not open a ticket for this?
      Some hosts including mine do not allow REWRITE RULES in the .htaccess file.
      It would be good to check before writing to it if the mod_rewrite is enabled before writing in the .htaccess because it induces 500 errors.

      • John Blackbourn 6:07 pm on January 4, 2016 Permalink | Log in to Reply

        Please open a ticket on core.trac.wordpress.org for this, with as many details as you can. The .htaccess handling code has been in WordPress for the best part of a decade, so it should be pretty stable by now, and there are lots of failsafes in place to prevent such 500 errors.

    • Ulrich 9:56 am on January 1, 2016 Permalink | Log in to Reply

      #32802: Update Masonry (v3.3.2) & imagesLoaded (v3.2.0) package
      #30797: New function for parent theme stylesheet uri
      #33407: Theme tags overhaul
      #26695 Themes: add support for multiple screenshots in themes
      #21256 New theme feature – add_theme_support( ‘content-width’, $defaults )

    • benoitchantre 1:13 pm on January 1, 2016 Permalink | Log in to Reply

    • szaqal21 1:21 pm on January 1, 2016 Permalink | Log in to Reply

      Add filter for _get_list_table() to allow using extended WP_Posts_List_Table class for edit screens, now it is hardcoded!

    • szaqal21 6:11 pm on January 1, 2016 Permalink | Log in to Reply

    • Maren-Reinecke 9:00 pm on January 1, 2016 Permalink | Log in to Reply

      1) I would very much appreciate a file manager for the media! As a photographer I have quite a lot of media and it´s not usefull to have them monthly organized…
      2) For the meta tags an opportunity to add noarchive, my old website worked with index, follow, noarchive, because I don´t want my media in google archives.

      Thanks for taking notice 🙂

      Maren

    • Paal Joachim Romdahl 9:53 pm on January 1, 2016 Permalink | Log in to Reply

      Thanks for asking Mike!

      Drag & drop of All posts/pages/categories.
      Finally getting this trac ticket feature in place: https://core.trac.wordpress.org/ticket/2702

      Additional field options in the customizer. Adjusting site title, description menu etc. As it would make simple design adjustments easier for the beginner without having to get into coding

      That’s all I can remember off the top of my heard right now!

      Happy New Year to everyone!!..:)
      What an awesome year this will become!!

    • davidperez 9:57 pm on January 1, 2016 Permalink | Log in to Reply

      Hello, Have a Button to Update everything: Plugins, Themes and Languages.

      Nice Work!

    • davidperez 10:02 pm on January 1, 2016 Permalink | Log in to Reply

      Another Idea would be Edit Taxonomies as full editor: Thumbnail, WYSIWYG Editor, …

    • christinecooper 10:39 pm on January 1, 2016 Permalink | Log in to Reply

      My wishlist for 4.5 is mainly implementing the fixes that have already been provided to numerous bug tickets.

      For example, view the following ticket:
      https://core.trac.wordpress.org/ticket/15448
      Which I outlined here:
      http://wordpress.stackexchange.com/questions/191923/sending-multipart-text-html-emails-via-wp-mail-will-likely-get-your-domain-b

      That’s only an example. There are too many tickets like these which have been laying there, with completely appropriate solutions, and no sight in adding these fixes to core.

    • luciole135 6:43 am on January 2, 2016 Permalink | Log in to Reply

      Add a third markdown text editor next to the two existing.

    • bonger 9:15 am on January 2, 2016 Permalink | Log in to Reply

      Bugs. 4.4 squashed around 600 gross. A similar drive now would be very worthwhile.

    • Frank Bueltge 1:23 pm on January 3, 2016 Permalink | Log in to Reply

      Wishs are fine, but goals are important.

      • Multisite Maintenance

      ** Like Settings API and much more equally single core.

      • Fields API
      • Notification API ( kills wp_mail() )
      • Working with priority on open bugs.
      • Relationship table, Post2Post – also about the network of Multisite
    • seanbennick 1:31 pm on January 3, 2016 Permalink | Log in to Reply

      I would also like to see Widgets that can be created once and used across multiple sidebars, footers, etc. Widget Builder – https://wordpress.org/plugins/widget-builder/ takes a decent step towards this, but I think this would be a solid addition to the core.

    • Pam Blizzard 7:45 pm on January 3, 2016 Permalink | Log in to Reply

      Please give me an option to hook and/or filter the Cheatin’ eh message. When delivering WP as a CMS, it’s too perplexing for the users and they don’t know what to do next. Give me an option to put meaningful instructions for my users on how to move forward or get help.

      • J.D. Grimes 5:01 pm on January 4, 2016 Permalink | Log in to Reply

        See #14530

        • Pam Blizzard 12:47 am on January 5, 2016 Permalink | Log in to Reply

          I respectfully disagree that it’s fixed, if the message, “Cheatin’, eh?” displays anywhere on a website that doesn’t belong to a WordPress developer.

      • John Blackbourn 6:11 pm on January 4, 2016 Permalink | Log in to Reply

        Do your users regularly see this message? If so, the root cause should be investigated because ideally no user should ever see this message.

        • Pam Blizzard 12:53 am on January 5, 2016 Permalink | Log in to Reply

          No, not regularly, but once is too much IMO. I have had clients email me from time to time upon receiving it and it’s embarrassing, when I have to explain that it’s considered “funny”. I get the joke, but they don’t. The message is not truly helpful, in any way. I know we can do better, and I’m willing to help in any way that I can.

          • Ipstenu (Mika Epstein) 5:33 pm on January 5, 2016 Permalink | Log in to Reply

            Pam, how/when/where are they seeing this?

            Becuase John’s point is that they NEVER should be able to see that. And it indicates something serious is behaving in an unexpected way 🙂 While agreeing that the message should be filterable, we still want to understand the circumstances that make it happen so we can possibly fix THAT too.

            (Of course if it’s ‘a plugin is doing something daft, we may not be able to, but it helps us understand the root cause.)

            To quote Nacin from the trac ticket:

            This warning should never be accessible via the UI. These are nothing more than sanity checks. If they can be accessed in a normal setup via the UI then that is a bug.

            So while it perhaps should be filterable, there’s an underlying bug there. That’s why the initial trac ticket was resolved with “Provide more helpful feedback than just “Cheatin’ uh?” for permission errors in wp-admin/js/customize-controls.js.”

            The bug, the part where people could legit click a link and get there, was fixed.

            Where are you running into this? What are your users doing?

            • Pam Blizzard 5:16 pm on January 6, 2016 Permalink

              I myself got it 3 days ago, when my browser hung after deleting a theme, and I hit refresh. Being experienced, I knew what it was and what the next step was. However, I’ve had 3 phone calls from clients about it in the last year, (prefer not to detail what caused it here, but can if really necessary) they just didn’t know where to go next.

              I searched Twitter, wpStackExchange and WP.org support on that term and found people posting about it within the last few months. The point is, it does appear.

              I’m trying to understand why it’s hard coded 34 times, http://bit.ly/1mGhBwp if it’s not needed, and “shouldn’t appear in the UI”

              Again, I’m willing to help out in any way I can. I’m not just kvetching, I’m here to learn and help.

          • Ipstenu (Mika Epstein) 5:21 pm on January 6, 2016 Permalink | Log in to Reply

            I myself got it 3 days ago, when my browser hung after deleting a theme, and I hit refresh.

            Yeah, that’s one of those cases where we can’t really avoid it. Let me guess, you force quit the browser and reopened with extant tabs? So WP tried to reload with an expired nonce. (Which is personally why I think this message should be filterable/customizable – unavoidable browser crashes happen. We didn’t used to have our browsers be able to reopen all tabs when restarting… Ahh the old days.)

            Can you tell us, in general terms, what the users were doing? Uploading a file, trying to use a specific plugin? I totally get that you can’t give us details 🙂 But if we can narrow down if a plugin is derping or if there’s a legit bug in WP, it helps.