From noreply at wordpress.org Fri Apr 1 00:12:27 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 00:12:27 -0000 Subject: [wp-trac] [WordPress Trac] #36391: Create a hook to handle plugin CSS? Message-ID: <054.d10f84614fb87ec58181fceb2b85db0f@wordpress.org> #36391: Create a hook to handle plugin CSS? -----------------------------+----------------------------- Reporter: CarlosRios | Owner: Type: feature request | Status: new Priority: normal | Milestone: Awaiting Review Component: Script Loader | Version: trunk Severity: normal | Keywords: Focuses: performance | -----------------------------+----------------------------- I'm not sure if this has been suggested before, but it would be really cool if there was a hook for plugins that would allow them to add their css to a css file that is generated and enqueued automatically when that hook is not empty. This would be done to prevent plugins such as Visual Composer, from loading all of their custom css in the of the page which can be bad for caching. Instead they would hook in, add their css, and then the css would be added to a single file along with all of the other css that has been hooked to it. {{{ add_filter( 'options_css', 'add_my_plugin_css' ); function add_my_plugin_css( $hooked_css ) { $bg_color = get_option( 'header_background_color' ); $hooked_css .= '#header{background-color:'.$bg_color.';}'; return $hooked_css; } }}} This code would then be hooked, sanitized, and minified, and then enqueued where it needs to be. I'd even suggest that the name of the css file could be wp-options.css or options.css -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 00:14:27 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 00:14:27 -0000 Subject: [wp-trac] [WordPress Trac] #36389: Selective refresh for widgets gets lost once `refresh` is used In-Reply-To: <056.31d17f8308b4a3c3b101ccf229595b2b@wordpress.org> References: <056.31d17f8308b4a3c3b101ccf229595b2b@wordpress.org> Message-ID: <071.ad94ec8c723ff09bf386971cbdcffcf6@wordpress.org> #36389: Selective refresh for widgets gets lost once `refresh` is used -------------------------------+------------------------------ Reporter: scamartist26 | Owner: Type: defect (bug) | Status: closed Priority: normal | Milestone: Awaiting Review Component: Customize | Version: trunk Severity: normal | Resolution: invalid Keywords: reporter-feedback | Focuses: -------------------------------+------------------------------ Comment (by scamartist26): I wanted to add a note of my findings in case this behavior is seen by others. I placed the following code in a `mu-plugins` plugin: {{{#!php WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 00:22:29 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 00:22:29 -0000 Subject: [wp-trac] [WordPress Trac] #36359: "Insert/edit link" dialog no longer shows recent posts/pages In-Reply-To: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> References: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> Message-ID: <073.233a5855246e2fd14bb6d2ea4bc2238c@wordpress.org> #36359: "Insert/edit link" dialog no longer shows recent posts/pages -------------------------------------+--------------------------------- Reporter: SergeyBiryukov | Owner: azaozz Type: defect (bug) | Status: assigned Priority: normal | Milestone: 4.5 Component: Editor | Version: trunk Severity: normal | Resolution: Keywords: has-patch needs-testing | Focuses: ui, administration -------------------------------------+--------------------------------- Comment (by azaozz): In 36359.4.patch: - Fix focusing the modal's url field on open in Safari and Chrome on Mac. That's a weird one, seems these browsers don't like to focus and select the field at the same time. Works properly in Firefox and Chrome on Windows. - Expand the modal when we pass a search string from the inline dialog. As discussed with @iseulde: we probably should remove that expand/collapse toggle. This is the "Advanced" modal now, no need for "simple" mode for it. > The search field doesn't get cleared and is still filled when I'm adding another link. I see the same behaviour in 4.4. Should we always reset it? -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 00:40:20 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 00:40:20 -0000 Subject: [wp-trac] [WordPress Trac] #36389: Selective refresh for widgets gets lost once `refresh` is used In-Reply-To: <056.31d17f8308b4a3c3b101ccf229595b2b@wordpress.org> References: <056.31d17f8308b4a3c3b101ccf229595b2b@wordpress.org> Message-ID: <071.786fea795287ac2f636d6aeb07b471b6@wordpress.org> #36389: Selective refresh for widgets gets lost once `refresh` is used -------------------------------+------------------------------ Reporter: scamartist26 | Owner: Type: defect (bug) | Status: closed Priority: normal | Milestone: Awaiting Review Component: Customize | Version: trunk Severity: normal | Resolution: invalid Keywords: reporter-feedback | Focuses: -------------------------------+------------------------------ Comment (by westonruter): @scamartist26 that's strange. I don't see how a later priority would make a difference. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 01:25:15 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 01:25:15 -0000 Subject: [wp-trac] [WordPress Trac] #36359: "Insert/edit link" dialog no longer shows recent posts/pages In-Reply-To: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> References: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> Message-ID: <073.0fa32e0a59495fe53ce053e85cb67fc7@wordpress.org> #36359: "Insert/edit link" dialog no longer shows recent posts/pages -------------------------------------+--------------------------------- Reporter: SergeyBiryukov | Owner: azaozz Type: defect (bug) | Status: assigned Priority: normal | Milestone: 4.5 Component: Editor | Version: trunk Severity: normal | Resolution: Keywords: has-patch needs-testing | Focuses: ui, administration -------------------------------------+--------------------------------- Comment (by adamsilverstein): >As discussed with @iseulde: we probably should remove that expand/collapse toggle. This is the "Advanced" modal now, no need for "simple" mode for it. That is in [attachment:36359.5.patch]: * When opening modal, always show the expanded version * Remove `Or link to existing content` text and link * Remove JS handler for expand action (no longer needed) -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 03:16:51 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 03:16:51 -0000 Subject: [wp-trac] [WordPress Trac] #36374: Audio playback fails on iOS 9.x In-Reply-To: <051.1f2508aaa816e9b02e62f1144ac52d80@wordpress.org> References: <051.1f2508aaa816e9b02e62f1144ac52d80@wordpress.org> Message-ID: <066.acfd424c4e2a3d246106c31b8f218157@wordpress.org> #36374: Audio playback fails on iOS 9.x --------------------------------+----------------------------- Reporter: Clorith | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Future Release Component: External Libraries | Version: 4.4.2 Severity: normal | Resolution: Keywords: | Focuses: javascript --------------------------------+----------------------------- Comment (by a4jp.com): I work from home and can test anything made even if it is a patch that is separate from 4.5. It would of course be nice to have this in 4.5 as sounds can't be played properly on any iOS device without getting cut off which is kind of a big problem but anything that works is okay. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 03:39:39 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 03:39:39 -0000 Subject: [wp-trac] [WordPress Trac] #36359: "Insert/edit link" dialog no longer shows recent posts/pages In-Reply-To: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> References: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> Message-ID: <073.546c30256507d8eecf5b7c3335f8a4fd@wordpress.org> #36359: "Insert/edit link" dialog no longer shows recent posts/pages -------------------------------------+--------------------------------- Reporter: SergeyBiryukov | Owner: azaozz Type: defect (bug) | Status: assigned Priority: normal | Milestone: 4.5 Component: Editor | Version: trunk Severity: normal | Resolution: Keywords: has-patch needs-testing | Focuses: ui, administration -------------------------------------+--------------------------------- Comment (by mikeschroder): On my 4.4.2, it does clear, but there's a bug where the displayed search results are from the previous search. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 04:48:13 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 04:48:13 -0000 Subject: [wp-trac] [WordPress Trac] #36392: wp_add_inline_script() breaks script dependency order when using script loader (no SCRIPT_DEBUG) In-Reply-To: <055.ec8aea20405fdc109f43505551275e13@wordpress.org> References: <055.ec8aea20405fdc109f43505551275e13@wordpress.org> Message-ID: <070.7ca49b40482141dcdf591a452e45d28c@wordpress.org> #36392: wp_add_inline_script() breaks script dependency order when using script loader (no SCRIPT_DEBUG) ---------------------------+-------------------- Reporter: westonruter | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.5 Component: Script Loader | Version: trunk Severity: normal | Resolution: Keywords: needs-patch | Focuses: ---------------------------+-------------------- Description changed by westonruter: Old description: > I've found that if an inline script is added via `wp_add_inline_script()` > for a JS file registered in a plugin, if this script has a dependency on > a core script that gets concatenated via `load-scripts.php`, the script > dependency and the inline script will erroneously get printed ''before'' > the the script tag referencing `load-scripts.php` and the script it > depends on. > > Here is a minimal test case: > https://gist.github.com/westonruter/c8968edc125fd31ae2da4171ced8c62b New description: I've found that if an inline script is added via `wp_add_inline_script()` for a JS file registered in a plugin, if this script has a dependency on a core script that gets concatenated via `load-scripts.php`, the script dependency and the inline script will erroneously get printed ''before'' the the script tag referencing `load-scripts.php` and the script it depends on. This error only occurs when `SCRIPT_DEBUG` is `false`, since this is when `load-scripts.php` is used. Here is a minimal test case: https://gist.github.com/westonruter/c8968edc125fd31ae2da4171ced8c62b `wp_add_inline_script()` introduced in #14853. -- -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 04:43:28 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 04:43:28 -0000 Subject: [wp-trac] [WordPress Trac] #36392: wp_add_inline_script() breaks script dependency order when using script loader (no SCRIPT_DEBUG) Message-ID: <055.ec8aea20405fdc109f43505551275e13@wordpress.org> #36392: wp_add_inline_script() breaks script dependency order when using script loader (no SCRIPT_DEBUG) ---------------------------+------------------------- Reporter: westonruter | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.5 Component: Script Loader | Version: trunk Severity: normal | Keywords: needs-patch Focuses: | ---------------------------+------------------------- I've found that if an inline script is added via `wp_add_inline_script()` for a JS file registered in a plugin, if this script has a dependency on a core script that gets concatenated via `load-scripts.php`, the script dependency and the inline script will erroneously get printed ''before'' the the script tag referencing `load-scripts.php` and the script it depends on. Here is a minimal test case: https://gist.github.com/westonruter/c8968edc125fd31ae2da4171ced8c62b -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 04:51:59 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 04:51:59 -0000 Subject: [wp-trac] [WordPress Trac] #14853: wp_add_inline_script() In-Reply-To: <053.371ea349d8ada5ec8aabb76d3013f6ca@wordpress.org> References: <053.371ea349d8ada5ec8aabb76d3013f6ca@wordpress.org> Message-ID: <068.ce1d9569059ef3d3cfc715d87bbc07f8@wordpress.org> #14853: wp_add_inline_script() ---------------------------------------------+------------------------- Reporter: mattwiebe | Owner: swissspidy Type: enhancement | Status: closed Priority: normal | Milestone: 4.5 Component: Script Loader | Version: 3.1 Severity: normal | Resolution: fixed Keywords: has-patch has-unit-tests commit | Focuses: ---------------------------------------------+------------------------- Comment (by westonruter): Defect: #36392 -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 05:11:57 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 05:11:57 -0000 Subject: [wp-trac] [WordPress Trac] #36359: "Insert/edit link" dialog no longer shows recent posts/pages In-Reply-To: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> References: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> Message-ID: <073.bf6b9a2c5941bd6ed7fd11ceae3cc3c3@wordpress.org> #36359: "Insert/edit link" dialog no longer shows recent posts/pages -------------------------------------+--------------------------------- Reporter: SergeyBiryukov | Owner: azaozz Type: defect (bug) | Status: assigned Priority: normal | Milestone: 4.5 Component: Editor | Version: trunk Severity: normal | Resolution: Keywords: has-patch needs-testing | Focuses: ui, administration -------------------------------------+--------------------------------- Comment (by azaozz): Replying to [comment:34 adamsilverstein]: > Remove `Or link to existing content` text and link Was thinking we could keep the text, just remove the arrow. Same as the modal being open. Also will need to remove `search_panel_visible` and the css for it. I'll refresh the patch in a min. > there's a bug where the displayed search results are from the previous search Right. Didn't realize there were so many inconsistencies in this :) -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 06:08:36 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 06:08:36 -0000 Subject: [wp-trac] [WordPress Trac] #36359: "Insert/edit link" dialog no longer shows recent posts/pages In-Reply-To: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> References: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> Message-ID: <073.6036873798ab7deedeb6f918028c3e97@wordpress.org> #36359: "Insert/edit link" dialog no longer shows recent posts/pages -------------------------------------+--------------------------------- Reporter: SergeyBiryukov | Owner: azaozz Type: defect (bug) | Status: assigned Priority: normal | Milestone: 4.5 Component: Editor | Version: trunk Severity: normal | Resolution: Keywords: has-patch needs-testing | Focuses: ui, administration -------------------------------------+--------------------------------- Comment (by azaozz): In 36359.6.patch: - Make the modal always expanded. - Remove the toggle together with the js, css and the user setting for it. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 06:38:06 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 06:38:06 -0000 Subject: [wp-trac] [WordPress Trac] #36359: "Insert/edit link" dialog no longer shows recent posts/pages In-Reply-To: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> References: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> Message-ID: <073.17fd7976debd00ca5f6cc97d76d2a0e8@wordpress.org> #36359: "Insert/edit link" dialog no longer shows recent posts/pages -------------------------------------+--------------------------------- Reporter: SergeyBiryukov | Owner: azaozz Type: defect (bug) | Status: assigned Priority: normal | Milestone: 4.5 Component: Editor | Version: trunk Severity: normal | Resolution: Keywords: has-patch needs-testing | Focuses: ui, administration -------------------------------------+--------------------------------- Comment (by azaozz): In 36359.7.patch: also always reset the search field and swap the "rivers" when reopening the modal. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 06:44:16 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 06:44:16 -0000 Subject: [wp-trac] [WordPress Trac] #36374: Audio playback fails on iOS 9.x In-Reply-To: <051.1f2508aaa816e9b02e62f1144ac52d80@wordpress.org> References: <051.1f2508aaa816e9b02e62f1144ac52d80@wordpress.org> Message-ID: <066.6433c260dd6dbc3cad28982e90ce888b@wordpress.org> #36374: Audio playback fails on iOS 9.x --------------------------------+----------------------------- Reporter: Clorith | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Future Release Component: External Libraries | Version: 4.4.2 Severity: normal | Resolution: Keywords: | Focuses: javascript --------------------------------+----------------------------- Comment (by Clorith): It's definitely too late for 4.5 I'd say, I also seem to recall there being core specific tweaks involved, possibly an idea for a 4.6-early or a 4.5.1 though. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 07:04:35 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 07:04:35 -0000 Subject: [wp-trac] [WordPress Trac] #36393: Loss of multibyte comment author names Message-ID: <050.506b582fd69286304adbef07f1e5a16b@wordpress.org> #36393: Loss of multibyte comment author names --------------------------+----------------------------- Reporter: cfinke | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Awaiting Review Component: Comments | Version: trunk Severity: normal | Keywords: Focuses: | --------------------------+----------------------------- Some multibyte comment author names can be lost during comment submission. Example: consider a comment authored by a user named `???????????????????? ??????????????????????????????????????????????????????????????????`. This name is a 258-byte string, longer than the maximum length of the `comment_author` column. `$wpdb->strip_invalid_text_for_column()` will truncate it to 255 bytes, and because each character is three bytes, the string is still "valid," albeit one character shorter. After `$wpdb->strip_invalid_text_for_column()` runs, `sanitize_text_field()` will run, which calls `wp_check_invalid_utf8()`, which will do nothing, because the string is still valid utf8. If this commenter's older sister, `A?????????????????????????????????????? ????????????????????????????????????????????????`, also tries to comment, the result is very different. This name is a 259 byte string. `$wpdb->strip_invalid_text_for_column()` will truncate it to 255 bytes, taking off one character and 1/3 of another. When `wp_check_invalid_utf8()` gets called, it will truncate the string to zero bytes out of an abundance of caution, since the string ends with something that is not valid utf8. It's clear that the commenter was not submitting invalid utf8, and the true goal of `$wpdb->strip_invalid_text_for_column()` was to ensure that the text would fit in the DB column without auto-truncation by the DB engine, so the ideal behavior should be that the string is truncated to the longest possible length that remains valid and fits within the column. One way to get around this data loss would be a wrapper around `wp_check_invalid_utf8()`. If `wp_check_invalid_utf8()` fails, chop a single byte off the end of the string and check it again, up to the point where you have checked the string without the last five bytes (as I believe that the longest a single character can be is six bytes, although I'm not positive about that and I think anything longer than four bytes is mostly theoretical). Or, fix `$wpdb->strip_invalid_text_for_column()` so that it doesn't truncate in the middle of a multibyte character. Configuration details: Tested in both WordPress 4.4.2 and trunk (4.5-RC1-37153); PHP 5.2.17 I noticed this issue in regards to commenter names, so here's the structure of my comments DB table (created in 2006, FWIW): {{{ CREATE TABLE `wp_comments` ( `comment_ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `comment_post_ID` bigint(20) unsigned NOT NULL DEFAULT '0', `comment_author` tinytext NOT NULL, `comment_author_email` varchar(100) NOT NULL DEFAULT '', `comment_author_url` varchar(200) NOT NULL DEFAULT '', `comment_author_IP` varchar(100) NOT NULL DEFAULT '', `comment_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `comment_date_gmt` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `comment_content` text NOT NULL, `comment_karma` int(11) NOT NULL DEFAULT '0', `comment_approved` varchar(20) NOT NULL DEFAULT '1', `comment_agent` varchar(255) NOT NULL DEFAULT '', `comment_type` varchar(20) NOT NULL DEFAULT '', `comment_parent` bigint(20) unsigned NOT NULL DEFAULT '0', `user_id` bigint(20) unsigned NOT NULL DEFAULT '0', PRIMARY KEY (`comment_ID`), KEY `comment_post_ID` (`comment_post_ID`), KEY `comment_approved_date_gmt` (`comment_approved`,`comment_date_gmt`), KEY `comment_date_gmt` (`comment_date_gmt`), KEY `comment_parent` (`comment_parent`), KEY `comment_author_email` (`comment_author_email`(10)) ) ENGINE=MyISAM AUTO_INCREMENT=2130254 DEFAULT CHARSET=latin1; }}} In case the strings I used as example commenter names above get mangled, here are their base64 encodings: commenter1: string(344) "776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D776D" commenter2: string(348) "Qe++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++g+++gw==" I'm attaching a POC plugin that manually walks through how the commenter name gets handled in the comment submission process (but only when the first attempt to save the comment fails and then requires the `$wpdb->strip_invalid_text_for_column()` call). -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 07:18:00 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 07:18:00 -0000 Subject: [wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal In-Reply-To: <053.bd468778dbcfa46d2ec2c3268165c76f@wordpress.org> References: <053.bd468778dbcfa46d2ec2c3268165c76f@wordpress.org> Message-ID: <068.76746957955ea04b4961218aeb60fd07@wordpress.org> #36335: Next generation: core autoloader proposal -----------------------------+----------------------------- Reporter: dnaber-de | Owner: Type: feature request | Status: new Priority: normal | Milestone: Future Release Component: General | Version: Severity: normal | Resolution: Keywords: | Focuses: -----------------------------+----------------------------- Comment (by dnaber-de): Hm, I think my expressions where a bit fuzzy. It was ''not'' my intention to say, that autoloading solves dependency management. Of course it does not. But in my opinion it is a first step in a long way to get there. If you name this more a convenience than a requirement, I'm totally fine with this :) But I'm a lazy developer, who likes to work convenient. > However, I think to make core actually "autoloadable" is a priority in that direction. Maybe you're right. But at the moment it's not clear that the core will ever be completely handled by an autoloader. At least this is what I read out of Ryan McCue's and Nacin's contributions to this discussion. Basically I fully agree with all your points. But non of them is a reason for me to stop thinking and working on a possible solution for that autoload part. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 07:23:41 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 07:23:41 -0000 Subject: [wp-trac] [WordPress Trac] #36393: Loss of multibyte comment author names In-Reply-To: <050.506b582fd69286304adbef07f1e5a16b@wordpress.org> References: <050.506b582fd69286304adbef07f1e5a16b@wordpress.org> Message-ID: <065.9b53d0be2349ae1f1986c1cdb180b1ac@wordpress.org> #36393: Loss of multibyte comment author names --------------------------+------------------------------ Reporter: cfinke | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Awaiting Review Component: Comments | Version: trunk Severity: normal | Resolution: Keywords: | Focuses: --------------------------+------------------------------ Comment (by cfinke): There might be a solution lurking in `mb_strlen()`. If `wp_check_invalid_utf8()` returns an empty string, take bytes off of the original string (up to 5 bytes) until `mb_strlen()` returns a smaller number and then try `wp_check_invalid_utf8()`. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 08:27:04 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 08:27:04 -0000 Subject: [wp-trac] [WordPress Trac] #36392: wp_add_inline_script() breaks script dependency order when using script loader (no SCRIPT_DEBUG) In-Reply-To: <055.ec8aea20405fdc109f43505551275e13@wordpress.org> References: <055.ec8aea20405fdc109f43505551275e13@wordpress.org> Message-ID: <070.24282a883535435dc99ebcfb0d020979@wordpress.org> #36392: wp_add_inline_script() breaks script dependency order when using script loader (no SCRIPT_DEBUG) ---------------------------+-------------------- Reporter: westonruter | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.5 Component: Script Loader | Version: trunk Severity: normal | Resolution: Keywords: needs-patch | Focuses: ---------------------------+-------------------- Comment (by xyulex): I want to start contributing so I might be looking at this :) -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 08:44:33 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 08:44:33 -0000 Subject: [wp-trac] [WordPress Trac] #36374: Audio playback fails on iOS 9.x In-Reply-To: <051.1f2508aaa816e9b02e62f1144ac52d80@wordpress.org> References: <051.1f2508aaa816e9b02e62f1144ac52d80@wordpress.org> Message-ID: <066.701d67359f3f539875ed2c86f6594c72@wordpress.org> #36374: Audio playback fails on iOS 9.x --------------------------------+----------------------------- Reporter: Clorith | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Future Release Component: External Libraries | Version: 4.4.2 Severity: normal | Resolution: Keywords: | Focuses: javascript --------------------------------+----------------------------- Comment (by a4jp.com): Is there any chance of a patch in the meantime, or a plugin that uses the newer version of the mediaelement file? I wish WordPress could be updated bit by bit instead of in large packaged chunks. Kind of like on Github. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 10:18:09 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 10:18:09 -0000 Subject: [wp-trac] [WordPress Trac] #36394: git-or-svn module assumes only one can be true Message-ID: <051.00a2f812acbf190159110205cf86721b@wordpress.org> #36394: git-or-svn module assumes only one can be true ------------------------------+------------------- Reporter: iseulde | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.5 Component: Build/Test Tools | Version: trunk Severity: normal | Keywords: Focuses: | ------------------------------+------------------- If both are true, it runs twice, running all the test twice at the same time and causes failures. We could allow the callback to be only run once, but better to fix upstream. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 11:24:46 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 11:24:46 -0000 Subject: [wp-trac] [WordPress Trac] #32075: Only set WP_MAX_MEMORY_LIMIT by default when its greater than memory_limit In-Reply-To: <059.d6bcdad341525426144fc1bcd894a4ef@wordpress.org> References: <059.d6bcdad341525426144fc1bcd894a4ef@wordpress.org> Message-ID: <074.805b1dd72830e3443690f59c905f2dea@wordpress.org> #32075: Only set WP_MAX_MEMORY_LIMIT by default when its greater than memory_limit ------------------------------------+----------------------------- Reporter: danielbachhuber | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Future Release Component: Bootstrap/Load | Version: 3.2 Severity: normal | Resolution: Keywords: has-patch dev-feedback | Focuses: ------------------------------------+----------------------------- Comment (by mensmaximus): I would like to throw an other aspect into the discussion. How usefull can it be to set WP_MAX_MEMORY_LIMIT to 256M by default if the allocated memory ( ini_get( 'memory_limit' ) ) is less than 256M? What would happen if a plugin developer would rely on the constants value and this value exceeds the memory allocated by the server (and restricted by the hosting company)? Imho the WP_MAX_MEMORY_LIMIT constant should never report a larger amount of memory than the maximum allocatable memory. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 11:50:16 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 11:50:16 -0000 Subject: [wp-trac] [WordPress Trac] #36392: wp_add_inline_script() breaks script dependency order when using script loader (no SCRIPT_DEBUG) In-Reply-To: <055.ec8aea20405fdc109f43505551275e13@wordpress.org> References: <055.ec8aea20405fdc109f43505551275e13@wordpress.org> Message-ID: <070.ff0bc97032fc348ee6e39003a770a16a@wordpress.org> #36392: wp_add_inline_script() breaks script dependency order when using script loader (no SCRIPT_DEBUG) ---------------------------+-------------------- Reporter: westonruter | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.5 Component: Script Loader | Version: trunk Severity: normal | Resolution: Keywords: needs-patch | Focuses: ---------------------------+-------------------- Comment (by ocean90): Attached a test in [attachment:36392.patch]. I had mentioned a similar case in [comment:ticket:14853:41] but seems like we missed the case with another dependency. cc: @swissspidy -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 12:31:31 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 12:31:31 -0000 Subject: [wp-trac] [WordPress Trac] #36395: Information in aria-label incorrect for reviews in plugin details Message-ID: <053.ac8b7040cd8b8130f7d3717d2663934f@wordpress.org> #36395: Information in aria-label incorrect for reviews in plugin details ----------------------------+----------------------------- Reporter: TacoVerdo | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Awaiting Review Component: Administration | Version: trunk Severity: normal | Keywords: Focuses: accessibility | ----------------------------+----------------------------- '''Problem description''' In the admin on the plugin install screen, you can open details for a plugin. If the plugin has reviews, they're shown in the details. When shown, the type of review and the number of reviews for the type are shown. For example a plugin that has 1300 5-star reviews will show that information. The text '5 stars' is linking to an overview page of all 5-star reviews. The link contains an {{{ aria-label }}}-attribute that contains the same information, except that the number of reviews is incorrect as it always says '1'. '''Cause''' In https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes /plugin-install.php#L588 the function {{{ number_format_i18n() }}} is used in combination with the variable {{{ %2$d }}} in the {{{ sprintf }}} which expects a digit. Since {{{ number_format_i18n() }}} returns a string, the variable will always be '1'. '''Possible solution''' By removing {{{ number_format_i18n() }}} from https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes /plugin-install.php#L590, {{{ $ratecount }}} will be a digit again, as the {{{ sprintf() }}} expects for {{{ %2$d }}}, resulting in the correct number to be displayed. Removing the formatting shouldn't negatively influence the way screenreaders read the number, so it shouldn't pose a problem. (Tested with OSX's Voice-Over) -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 12:36:22 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 12:36:22 -0000 Subject: [wp-trac] [WordPress Trac] #36395: Information in aria-label incorrect for reviews in plugin details In-Reply-To: <053.ac8b7040cd8b8130f7d3717d2663934f@wordpress.org> References: <053.ac8b7040cd8b8130f7d3717d2663934f@wordpress.org> Message-ID: <068.05dadfad32cf86a42eb469e4b5fc682b@wordpress.org> #36395: Information in aria-label incorrect for reviews in plugin details -------------------------------------+------------------------------------- Reporter: TacoVerdo | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.5 Component: Plugins | Version: trunk Severity: minor | Resolution: Keywords: has-patch commit i18n- | Focuses: accessibility, change | administration -------------------------------------+------------------------------------- Changes (by ocean90): * keywords: => has-patch commit i18n-change * focuses: accessibility => accessibility, administration * component: Administration => Plugins * severity: normal => minor * milestone: Awaiting Review => 4.5 -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 12:54:51 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 12:54:51 -0000 Subject: [wp-trac] [WordPress Trac] #36359: "Insert/edit link" dialog no longer shows recent posts/pages In-Reply-To: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> References: <058.9fb84b5223f009eea009f25bf5dcfb47@wordpress.org> Message-ID: <073.10a7404a158e45558b53ba06b0458499@wordpress.org> #36359: "Insert/edit link" dialog no longer shows recent posts/pages -------------------------------------+--------------------------------- Reporter: SergeyBiryukov | Owner: azaozz Type: defect (bug) | Status: assigned Priority: normal | Milestone: 4.5 Component: Editor | Version: trunk Severity: normal | Resolution: Keywords: has-patch needs-testing | Focuses: ui, administration -------------------------------------+--------------------------------- Comment (by adamsilverstein): Replying to [comment:38 azaozz]: > In 36359.7.patch: also always reset the search field and swap the "rivers" when reopening the modal. Looks good! Tested and this works well. I wasn't sure about cleaning out CSS in case someone used it :) Verified search field AND search results reset on re- opening modal/new link. Thanks! -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 1 12:55:05 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 01 Apr 2016 12:55:05 -0000 Subject: [wp-trac] [WordPress Trac] #35299: HTML code doesn't always show in page editor In-Reply-To: <053.ae348eb284de1fa1a41a2951d446fd00@wordpress.org> References: <053.ae348eb284de1fa1a41a2951d446fd00@wordpress.org> Message-ID: <068.b568deec3f8a2826c8635a0d2b0c6228@wordpress.org> #35299: HTML code doesn't always show in page editor --------------------------+------------------------------ Reporter: JustinBBC | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Awaiting Review Component: Editor | Version: 4.4 Severity: normal | Resolution: Keywords: | Focuses: --------------------------+------------------------------ Comment (by francbarberini): Hi Justin, I think this is not a Wordpress or Tinymce editor bug. "); thanks. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 16:59:06 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 16:59:06 -0000 Subject: [wp-trac] [WordPress Trac] #36625: Don't CAST the post meta value to CHAR in meta query In-Reply-To: <053.f1a68a929dfaa9ebfbb0e4d6b35caca9@wordpress.org> References: <053.f1a68a929dfaa9ebfbb0e4d6b35caca9@wordpress.org> Message-ID: <068.5c4532143fdf52c2aa7b3c8d27668a44@wordpress.org> #36625: Don't CAST the post meta value to CHAR in meta query -------------------------+------------------------------ Reporter: ericlewis | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Awaiting Review Component: Query | Version: 3.1 Severity: normal | Resolution: Keywords: | Focuses: -------------------------+------------------------------ Comment (by ericlewis): Replying to [comment:1 boonebgorges]: > Can we get some more technical details on how the optimizer decides whether the index can be used? The index is the column value's leftmost prefix, truncated to the index's length. The optimizer consider using the index except in some cases: * a function is applied to the index column's value in a where clause (i.e. `CHAR(postmeta.meta_value)`. * a `LIKE` clause is used on the index column with a wildcard on the left- end of the search string (i.e. `postmeta.meta_value LIKE "%erosmith"`). There may be other cases an index would not be considered for use by the optimizer, or a better general comment on when indexes are considered for use (@barry, @pento ?) > What happens when your index is 8 characters, and the `meta_value` from your `meta_query` is 12 characters? If the query is `meta_value = "Aerosmith"`, and `meta_value` has an index with an 8 character length, MySQL would use the index to figure out possible rows to touch in the actual table (the "Aerosmith" row being one of them), and rule out rows to touch in the actual table (i.e. a row with a `meta_value` of `Van Halen`) based on partial string matches. > (These are genuine questions - I don't know, and I'm having a hard time finding documentation about it.) These are great questions I'm not finding answer to in the MySQL reference either. I opened [http://bugs.mysql.com/bug.php?id=81181&thanks=4 mysql#81181] to discuss updating the reference with more detail here. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:00:21 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:00:21 -0000 Subject: [wp-trac] [WordPress Trac] #36636: allow add_editor_style() to include inline style (was: allow ADD_EDITOR_STYLE() to include inline style) In-Reply-To: <054.bcfec8e1d46f0ebfc4a8e273ae056ec5@wordpress.org> References: <054.bcfec8e1d46f0ebfc4a8e273ae056ec5@wordpress.org> Message-ID: <069.af9a9a6c4a19ad3a2841d599bc89ea19@wordpress.org> #36636: allow add_editor_style() to include inline style -------------------------+------------------------------ Reporter: selnomeria | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Awaiting Review Component: Editor | Version: 3.0 Severity: normal | Resolution: Keywords: | Focuses: -------------------------+------------------------------ Changes (by swissspidy): * type: defect (bug) => enhancement * version: => 3.0 * component: General => Editor Old description: > ADD_EDITOR_STYLE() needs to return an url of style... but it is not > always convenient for quick testing. > please, give us ability, to code inside that function, like this: > > add_editor_style( ""); > > thanks. New description: `add_editor_style()` needs to return an url of style... but it is not always convenient for quick testing. please, give us ability, to code inside that function, like this: {{{#!php add_editor_style( "" ); }}} thanks. -- -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:03:48 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:03:48 -0000 Subject: [wp-trac] [WordPress Trac] #36636: allow add_editor_style() to include inline style In-Reply-To: <054.bcfec8e1d46f0ebfc4a8e273ae056ec5@wordpress.org> References: <054.bcfec8e1d46f0ebfc4a8e273ae056ec5@wordpress.org> Message-ID: <069.032cbd7b992342207ad389ca4329198a@wordpress.org> #36636: allow add_editor_style() to include inline style -------------------------+------------------------------ Reporter: selnomeria | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Awaiting Review Component: Editor | Version: 3.0 Severity: normal | Resolution: Keywords: | Focuses: -------------------------+------------------------------ Comment (by swissspidy): `add_editor_style()` is meant for theme developers to make the editor style look more like the front-end of the site ("What you see is what you get"). This is usually done by either using a specific stylesheet in the theme or creating an `editor-style.css` file which uses `@import` to load the necessary styles. How would allowing inline styles help here? You can also debug your CSS when it's in a separate file. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:08:07 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:08:07 -0000 Subject: [wp-trac] [WordPress Trac] #36635: Issue with size_format function when value is 0 In-Reply-To: <052.1647d70c1fbd7bc7faf444ddabd84960@wordpress.org> References: <052.1647d70c1fbd7bc7faf444ddabd84960@wordpress.org> Message-ID: <067.521321adceed0a598a524a03e213c533@wordpress.org> #36635: Issue with size_format function when value is 0 --------------------------+------------------------------ Reporter: bangelov | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Awaiting Review Component: General | Version: 4.5 Severity: normal | Resolution: Keywords: | Focuses: --------------------------+------------------------------ Description changed by swissspidy: Old description: > When you invoke size_format(0) function with zero value it should return > '''0 B''' instead it returns '''false''' which is wrong. For example when > you are looping files and some of them is zero byte file it will return > false and will brake the UI if function is directly used in the view > (most cases). New description: When you invoke `size_format(0)` function with zero value it should return `0 B` instead it returns `false` which is wrong. For example when you are looping files and some of them is zero byte file it will return `false` and will break the UI if function is directly used in the view (most cases). -- -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:09:48 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:09:48 -0000 Subject: [wp-trac] [WordPress Trac] #36635: Issue with size_format function when value is 0 In-Reply-To: <052.1647d70c1fbd7bc7faf444ddabd84960@wordpress.org> References: <052.1647d70c1fbd7bc7faf444ddabd84960@wordpress.org> Message-ID: <067.375f64252de01742c63681e4f95434af@wordpress.org> #36635: Issue with size_format function when value is 0 ------------------------------------------+------------------------------ Reporter: bangelov | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Awaiting Review Component: General | Version: 2.3 Severity: normal | Resolution: Keywords: needs-patch needs-unit-tests | Focuses: ------------------------------------------+------------------------------ Changes (by swissspidy): * keywords: => needs-patch needs-unit-tests * version: 4.5 => 2.3 Comment: Seems legit to me. Will whip up a patch shortly. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:16:41 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:16:41 -0000 Subject: [wp-trac] [WordPress Trac] #36637: Inline linking inserts `_wp_link_placeholder` Message-ID: <049.3c13de6627fc69573e7a9df3c60001b1@wordpress.org> #36637: Inline linking inserts `_wp_link_placeholder` --------------------------+----------------------------- Reporter: walbo | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: Awaiting Review Component: Editor | Version: 4.5 Severity: normal | Keywords: Focuses: javascript | --------------------------+----------------------------- The text `_wp_link_placeholder` is inserted into the inline linking. To reproduce: 1. Mark some text and click the insert/edit link icon. 2. Click the insert/edit link icon once more. The text `_wp_link_placeholder` is now inserted into the input field. Sometimes you need to press the `cmd` key to get the text inserted. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:24:15 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:24:15 -0000 Subject: [wp-trac] [WordPress Trac] #36637: Inline linking inserts `_wp_link_placeholder` In-Reply-To: <049.3c13de6627fc69573e7a9df3c60001b1@wordpress.org> References: <049.3c13de6627fc69573e7a9df3c60001b1@wordpress.org> Message-ID: <064.f52399307f7de77e1ba01b3e9ea79fec@wordpress.org> #36637: Inline linking inserts `_wp_link_placeholder` --------------------------+------------------------- Reporter: walbo | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.5.2 Component: Editor | Version: 4.5 Severity: normal | Resolution: Keywords: | Focuses: javascript --------------------------+------------------------- Changes (by swissspidy): * milestone: Awaiting Review => 4.5.2 Comment: > Sometimes you need to press the `cmd` key to get the text inserted. I can definitely reproduce this when `cmd` clicking on the icon twice. Don't even have to select some text. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:37:13 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:37:13 -0000 Subject: [wp-trac] [WordPress Trac] #36637: Inline linking inserts `_wp_link_placeholder` In-Reply-To: <049.3c13de6627fc69573e7a9df3c60001b1@wordpress.org> References: <049.3c13de6627fc69573e7a9df3c60001b1@wordpress.org> Message-ID: <064.56d4bcad87438f288e668dce15d7d6f5@wordpress.org> #36637: Inline linking inserts `_wp_link_placeholder` --------------------------+------------------------- Reporter: walbo | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.5.2 Component: Editor | Version: 4.5 Severity: normal | Resolution: Keywords: has-patch | Focuses: javascript --------------------------+------------------------- Changes (by iseulde): * keywords: => has-patch -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:45:09 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:45:09 -0000 Subject: [wp-trac] [WordPress Trac] #36633: Customizer Doesn't Save Defaults in The Database for a Theme In-Reply-To: <056.79bc72026bc0a01de06d3c1b8b46ad91@wordpress.org> References: <056.79bc72026bc0a01de06d3c1b8b46ad91@wordpress.org> Message-ID: <071.5490da9334a224639ab85c62b7ddc211@wordpress.org> #36633: Customizer Doesn't Save Defaults in The Database for a Theme --------------------------------+------------------------------ Reporter: mrahmadawais | Owner: Type: enhancement | Status: reopened Priority: normal | Milestone: Awaiting Review Component: Customize | Version: trunk Severity: normal | Resolution: Keywords: dev-feedback close | Focuses: --------------------------------+------------------------------ Comment (by westonruter): @mrahmadawais thanks for explaining. Yes, I can see how this would be confusing. If this were to be fixed, the approach I'd take would be to register any settings that lack values saved in the database as `dirty` up-front. This would ensure that when the user saves the Customizer state, all of these settings would be saved. But, I'm not entirely sure that there is a change that should be made. Take, for example, `get_theme_mod()` and `get_option()`. Both of these also take a `$default` argument. If a theme uses these functions and supplies a default value, then these would indeed be duplicated with any corresponding Customizer settings that get registered. But wouldn't this be the right thing to do? If someone activates a theme and never opens the Customizer, then all of these settings wouldn't be set in the DB either. What I think themes should do instead, then, is to perhaps have a theme config array that can be re-used both in the `get_option()`/`get_theme_mod()` calls and when registering Customizer settings, to be used as the `$default` in each case. For example: {{{#!php '999-999-9999', ); add_action( 'wp_footer', function() use ( $acme_theme_defaults ) { ?>

You should give us a call!

add_setting( 'acme_phone_number', array( 'type' => 'theme_mod', 'default' => $acme_theme_defaults['phone_number'], ) ); $wp_customize->add_control( 'acme_phone_number', array( 'type' => 'text', ) ); } ); }}} -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:46:41 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:46:41 -0000 Subject: [wp-trac] [WordPress Trac] #32941: Customizer changes to input field values after clicking Save not recorded In-Reply-To: <053.b4c5ec32fe2dd55b0edf9162d09f2872@wordpress.org> References: <053.b4c5ec32fe2dd55b0edf9162d09f2872@wordpress.org> Message-ID: <068.efb75e75630c068de59412170c09cfb1@wordpress.org> #32941: Customizer changes to input field values after clicking Save not recorded --------------------------+------------------------- Reporter: mb5324897 | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.6 Component: Customize | Version: 4.2.2 Severity: normal | Resolution: Keywords: needs-patch | Focuses: javascript --------------------------+------------------------- Comment (by chandrapatel): Hi @westonruter, Okay. Now I understood why we can't keep the Save button enabled. Thanks. I have added `fieldset` element as child of form and then applied disabled attribute to this element which disabled all controls. I have also check whether `disabled` state enabled or not for `fieldset`. If it enabled then only I remove `disabled` state from `fieldset`. I have uploaded new patch `32941.1.patch`. But I noticed some bad behavior for color picker and drag/drop widgets. To see this behavior add `sleep(30)` code at line #1032 in `save()` method in `wp-includes/class-wp-customize-manager.php`. Then use and check behavior of color picker and drag/drop widgets. Another alternative solution is, We disable only `Save & Publish` button. User can change settings during ajax request in-progress and we set flag if any settings changed and once ajax request complete then we check if flag set then we enable `Save & Publish`. So user can save their settings again. If flag not set then `save` button in disabled mode. Please let me know your suggestion. Regards -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 17:51:37 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 17:51:37 -0000 Subject: [wp-trac] [WordPress Trac] #36637: Inline linking inserts `_wp_link_placeholder` In-Reply-To: <049.3c13de6627fc69573e7a9df3c60001b1@wordpress.org> References: <049.3c13de6627fc69573e7a9df3c60001b1@wordpress.org> Message-ID: <064.674b52be35616543ac2a26c2c899ef26@wordpress.org> #36637: Inline linking inserts `_wp_link_placeholder` --------------------------+------------------------- Reporter: walbo | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.5.2 Component: Editor | Version: 4.5 Severity: normal | Resolution: Keywords: has-patch | Focuses: javascript --------------------------+------------------------- Comment (by azaozz): This is mostly "cosmetic", but annoying nevertheless. Of course it will create a link with href of `_wp_link_placeholder` if the user clicks on the Apply button, but that would happen for any text entered in the URL field. Been wondering if we should change that behaviour when the text is obviously not an URL. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 18:08:19 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 18:08:19 -0000 Subject: [wp-trac] [WordPress Trac] #32941: Customizer changes to input field values after clicking Save not recorded In-Reply-To: <053.b4c5ec32fe2dd55b0edf9162d09f2872@wordpress.org> References: <053.b4c5ec32fe2dd55b0edf9162d09f2872@wordpress.org> Message-ID: <068.fefab5dd59a4879e8067afa776213491@wordpress.org> #32941: Customizer changes to input field values after clicking Save not recorded --------------------------+------------------------- Reporter: mb5324897 | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.6 Component: Customize | Version: 4.2.2 Severity: normal | Resolution: Keywords: needs-patch | Focuses: javascript --------------------------+------------------------- Comment (by westonruter): Replying to [comment:6 chandrapatel]: > Another alternative solution is, We disable only `Save & Publish` button. User can change settings during ajax request in-progress and we set flag if any settings changed and once ajax request complete then we check if flag set then we enable `Save & Publish`. So user can save their settings again. If flag not set then `save` button in disabled mode. That's a good idea. After the successful save response comes back, if any `change` events triggered on `wp.customize` during the save request, then the `saved` state should be reset to `false` instead of being `true`, and any of the settings that were modified during the save request should not have their `_dirty` state reset to `false`. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 18:14:27 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 18:14:27 -0000 Subject: [wp-trac] [WordPress Trac] #36160: Comment content ul elements have no style in the Comment List Table or Moderate Comment screen In-Reply-To: <055.4e33f6b688888f3c432e6a21851284ad@wordpress.org> References: <055.4e33f6b688888f3c432e6a21851284ad@wordpress.org> Message-ID: <070.0ea476a968d3b55f3fc53248448c8ce2@wordpress.org> #36160: Comment content ul elements have no style in the Comment List Table or Moderate Comment screen --------------------------+----------------------------- Reporter: rachelbaker | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.6 Component: Comments | Version: Severity: normal | Resolution: Keywords: has-patch | Focuses: administration --------------------------+----------------------------- Comment (by rachelbaker): In [attachment:36160.3.patch] I applied the same `ul` style rules from [attachment:36160-2.patch] to the Moderate Comment screen as well. Screenshots: Before: [[Image(https://cldup.com/abfSUdWRj_-1200x1200.png)]] After: [[Image(https://cldup.com/DmFWjfyi_U.png)]] -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 18:29:05 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 18:29:05 -0000 Subject: [wp-trac] [WordPress Trac] #36638: Detect broken URLs in the editor Message-ID: <051.22cf4dbe73cfc18c2351d7379b8c55e3@wordpress.org> #36638: Detect broken URLs in the editor -------------------------+----------------------------- Reporter: iseulde | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Awaiting Review Component: Editor | Version: Severity: normal | Keywords: Focuses: | -------------------------+----------------------------- Chatted a bit with @azaozz. We could detect broken URLs in the editor when the user adds one by sending a request to the server and then doing a HEAD request and check the response code. If it's 4xx, we could mark the bad link in the editor and if the user clicks on it show the toolbar with a message. This is to prevent accidental user mistakes (wrong copy/paste, entering query by accident...) Another thing we could do is warn for mixed content. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 18:38:13 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 18:38:13 -0000 Subject: [wp-trac] [WordPress Trac] #35433: Walker_Comment::comment calls comment_text which forces the comment to be re-queried rather than use $comments variable cache In-Reply-To: <053.44c4a7833db40b3ab7155005db05e501@wordpress.org> References: <053.44c4a7833db40b3ab7155005db05e501@wordpress.org> Message-ID: <068.48d793525aa90d0743b50b199c23f8e6@wordpress.org> #35433: Walker_Comment::comment calls comment_text which forces the comment to be re-queried rather than use $comments variable cache -------------------------------------+------------------ Reporter: pcfreak30 | Owner: Type: defect (bug) | Status: new Priority: normal | Milestone: 4.6 Component: Comments | Version: 3.7 Severity: normal | Resolution: Keywords: has-patch needs-testing | Focuses: -------------------------------------+------------------ Changes (by rachelbaker): * milestone: Future Release => 4.6 -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 18:39:10 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 18:39:10 -0000 Subject: [wp-trac] [WordPress Trac] #36393: Loss of multibyte comment author names In-Reply-To: <050.506b582fd69286304adbef07f1e5a16b@wordpress.org> References: <050.506b582fd69286304adbef07f1e5a16b@wordpress.org> Message-ID: <065.73c150da1d4de39374a4260862eb95ce@wordpress.org> #36393: Loss of multibyte comment author names --------------------------+--------------------- Reporter: cfinke | Owner: Type: defect (bug) | Status: closed Priority: normal | Milestone: 4.5 Component: Comments | Version: Severity: normal | Resolution: fixed Keywords: close | Focuses: --------------------------+--------------------- Changes (by rachelbaker): * status: new => closed * resolution: => fixed * milestone: Awaiting Review => 4.5 -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 18:45:45 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 18:45:45 -0000 Subject: [wp-trac] [WordPress Trac] #36636: allow add_editor_style() to include inline style In-Reply-To: <054.bcfec8e1d46f0ebfc4a8e273ae056ec5@wordpress.org> References: <054.bcfec8e1d46f0ebfc4a8e273ae056ec5@wordpress.org> Message-ID: <069.eff71ab151f87b4c9f1bac81dc31aa7d@wordpress.org> #36636: allow add_editor_style() to include inline style -------------------------+------------------------------ Reporter: selnomeria | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Awaiting Review Component: Editor | Version: 3.0 Severity: normal | Resolution: Keywords: | Focuses: -------------------------+------------------------------ Comment (by jcastaneda): If you really are looking to add inline styles there is also the function `wp_add_inline_style()`: https://developer.wordpress.org/reference/functions/wp_add_inline_style/ -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 18:46:23 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 18:46:23 -0000 Subject: [wp-trac] [WordPress Trac] #36638: Detect broken URLs in the editor In-Reply-To: <051.22cf4dbe73cfc18c2351d7379b8c55e3@wordpress.org> References: <051.22cf4dbe73cfc18c2351d7379b8c55e3@wordpress.org> Message-ID: <066.1c84369bb9cd62bea4fb0930306e4cb5@wordpress.org> #36638: Detect broken URLs in the editor -------------------------+------------------ Reporter: iseulde | Owner: Type: enhancement | Status: new Priority: normal | Milestone: 4.6 Component: Editor | Version: Severity: normal | Resolution: Keywords: | Focuses: -------------------------+------------------ Changes (by azaozz): * milestone: Awaiting Review => 4.6 Comment: This is the logical next step for enhancing how we handle link (and URLs in general) in the editor. Something like "spellcheck for URLs" :) I'm hoping we will have time to implement it in this cycle, or at least start. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 18:55:09 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 18:55:09 -0000 Subject: [wp-trac] [WordPress Trac] #22237: Add keyboard shortcuts for collapse/expand, panel-back, and close to the Customizer In-Reply-To: <056.03ec3b46a1b3e8cc564791961083eeff@wordpress.org> References: <056.03ec3b46a1b3e8cc564791961083eeff@wordpress.org> Message-ID: <071.5487866f5f022be4160e3cce2c472c7c@wordpress.org> #22237: Add keyboard shortcuts for collapse/expand, panel-back, and close to the Customizer -------------------------------------+------------------------------------- Reporter: designsimply | Owner: celloexpressions Type: enhancement | Status: reviewing Priority: normal | Milestone: 4.6 Component: Customize | Version: 3.4 Severity: normal | Resolution: Keywords: good-first-bug has- | Focuses: accessibility, patch | javascript -------------------------------------+------------------------------------- Changes (by westonruter): * keywords: good-first-bug has-patch commit => good-first-bug has-patch * owner: westonruter => celloexpressions Comment: @celloexpressions take a look at my new patch [attachment:22237.2.diff] . What do you think about also recognizing Esc when a widget or nav menu item is expanded? This adds support for that and also improves parity between the controls for nav menu items and widgets. I noticed the former lacked the same interface as the latter. -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 19:10:21 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 19:10:21 -0000 Subject: [wp-trac] [WordPress Trac] #36637: Inline linking inserts `_wp_link_placeholder` In-Reply-To: <049.3c13de6627fc69573e7a9df3c60001b1@wordpress.org> References: <049.3c13de6627fc69573e7a9df3c60001b1@wordpress.org> Message-ID: <064.d75095498f98b5d2c742cb1dbf3b1954@wordpress.org> #36637: Inline linking inserts `_wp_link_placeholder` --------------------------+------------------------- Reporter: walbo | Owner: azaozz Type: defect (bug) | Status: closed Priority: normal | Milestone: 4.5.2 Component: Editor | Version: 4.5 Severity: normal | Resolution: fixed Keywords: has-patch | Focuses: javascript --------------------------+------------------------- Changes (by azaozz): * owner: => azaozz * status: new => closed * resolution: => fixed Comment: In [changeset:"37301"]: {{{ #!CommitTicketReference repository="" revision="37301" TinyMCE: prevent showing the placeholder URL when adding a link and clicking more than once on the Insert Link button. Props iseulde. Fixes #36637 for trunk. }}} -- Ticket URL: WordPress Trac WordPress publishing platform From noreply at wordpress.org Fri Apr 22 19:05:34 2016 From: noreply at wordpress.org (WordPress Trac) Date: Fri, 22 Apr 2016 19:05:34 -0000 Subject: [wp-trac] [WordPress Trac] #34391: Harden panel/section UI code by removing contents from being logically nested (read: goodbye margin-top hacks) In-Reply-To: <055.4d5cea31c9a31c17cdfb7b98baccd3c3@wordpress.org> References: <055.4d5cea31c9a31c17cdfb7b98baccd3c3@wordpress.org> Message-ID: <070.b48008ec9caa6350a9f5391c0e35805a@wordpress.org> #34391: Harden panel/section UI code by removing contents from being logically nested (read: goodbye margin-top hacks) ------------------------------+-------------------------------------------- Reporter: westonruter | Owner: delawski Type: defect (bug) | Status: assigned Priority: normal | Milestone: 4.6 Component: Customize | Version: 4.0 Severity: normal | Resolution: Keywords: needs-patch | Focuses: ui, accessibility, javascript 4.6-early | ------------------------------+-------------------------------------------- Comment (by delawski): I have worked on the issue today: * fixed issues related to focusing on controls (particularly when shift- clicking on widgets in the preview) * fixed bugs in Themes section. I still have to test new panel/section UI on various browsers/devices and clean up the CSS. The progress on this ticket is tracked in the following PR: https://github.com/xwp/wordpress-develop/pull/150 Today I've also checked two free themes (''Zerif Lite'' and ''Sydney'') and how they work with the new UI. The only major issue I've noticed was with ''Zerif Lite''. In short, here's the issue: ''Zerif'' prepends its own special {{{
  • }}} element to ''any'' {{{