WordPress Trac: {4} Next Minor Release, Workflow Orientedhttps://core.trac.wordpress.org/report/4
Trac Report - {{{
#!span class="create-new-ticket button button-large button-primary"
[https://wordpress.org/support/bb-login.php?redirect_to=https://core.trac.wordpress.org/newticket Create a new ticket]
}}}
* Active tickets slated for the next minor release, workflow oriented
* Sort by component, type, summary
* Accepted tickets have an '*' appended to their owner's nameen-usWordPress Trachttps://core.trac.wordpress.org/chrome/site/your_project_logo.pnghttps://core.trac.wordpress.org/report/4
Trac v1.0.1#31428: Switch_to_blog() no longer works in Customize using Multisite.csschrisMon, 23 Feb 2015 20:09:07 GMTWed, 25 Feb 2015 16:47:57 GMT<p>
A change in /wp-includes/class-wp-customize-setting.php seems to have broken something.
</p>
<p>
Code that uses switch_to_blog() no longer gets run in customize view.
</p>
<p>
Had no problem in 4.1
</p>
csschrishttps://core.trac.wordpress.org/ticket/31428
https://core.trac.wordpress.org/ticket/31428Report#31501: Customizer Save race condition when attempting to publish too soon after updating widget form fields with multiple editswestonruterMon, 02 Mar 2015 09:23:27 GMTMon, 02 Mar 2015 09:53:39 GMT<p>
On a slow connection or if a widget update callback takes any amount of processing time complete, multiple edits to one or more form fields will have multiple simultaneous <tt>update_widget</tt> Ajax requests open at a time. The last one to return would have the winning instance data to supply for the widget form: a race condition. Before an update widget request is kicked off, any previous request should be aborted so that only the last user-submitted data is used in the form instance.
</p>
<p>
Additionally, when invoking the Customizer Save functionality, it needs to hold off on gathering up the {{customized}} data to POST to the server until the {{processing}} state is cleared-out; right now it is incorrectly obtaining the data to send before any widgets have finished processing to get their settings from the server over Ajax.
</p>
westonruterhttps://core.trac.wordpress.org/ticket/31501
https://core.trac.wordpress.org/ticket/31501Report#31484: Widgets in Customizer during theme preview fail to preview widgets with prior sidebars_widgets theme mod and fail to apply upon activationwestonruterFri, 27 Feb 2015 23:02:11 GMTTue, 03 Mar 2015 12:13:41 GMT<p>
When testing the new Theme Switcher in the Customizer, I noticed when previewing another theme that the widget controls appearing in the Widgets panel were sometimes largely appearing as inactive (partially transparent) and the widgets appearing in the Customizer preview did not correspond to the widget controls I saw in the Widgets pane. In fact, the widgets in the Panel reflected the widgets that were actually from the previously-cached widgets configuration (via <tt>retrieve_widgets()</tt> and stored in the <tt>sidebars_widgets</tt> theme mod), but the widgets appearing in the Customizer preview corresponded to the widget configuration in the currently-active theme.
</p>
<p>
The problem was introduced in WordPress 4.1, specifically in <a class="changeset" href="https://core.trac.wordpress.org/changeset/29905" title="Customizer: Only POST dirty settings to preview to improve performance.
...">r29905</a> for <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/29983" title="enhancement: Only POST dirty settings to Customizer preview to improve performance (closed: fixed)">#29983</a>, since we're no longer posting all of the settings from the Customizer pane to the preview for performance reasons: only the changed (dirty) settings get POSTed to the Preview when it is loaded.
</p>
<p>
Additionally, when attempting to activate the previous theme that had a cached widgets configuration in the <tt>sidebars_widgets</tt> theme mod, this prior configuration is not getting restored when activating the previously-active theme: the sidebar configuration from the current theme is overwriting the previous theme's configuration. I believe this is due to the <tt>old_sidebars_widgets_data</tt> not being marked as dirty, and so it is not being submitted when saving the settings.
</p>
<p>
Steps to reproduce:
</p>
<ol><li>Activate Twenty Fourteen via the Themes admin page
</li><li>Add multiple widgets to each sidebar via the Widgets admin page; let them have "2014" in their titles
</li><li>Activate Twenty Thirteen via the Themes admin page
</li><li>Add multiple widgets to each sidebar (Main Widget Area, Secondary Widget Area) via the Widgets admin page; let them have "2013" in their titles
</li><li>Try switching between Twenty Thirteen and Twenty Fourteen and note each theme's respective sidebar configurations.
</li><li>Switch back to Twenty Fourteen via the Themes admin page.
</li><li>Live-preview the Twenty Thirteen theme either via the Themes admin page, or via the new Customizer theme previewer
</li><li>Open the Widgets panel and note that the widgets listed are correctly those for Twenty Thirteen, but notice in the Preview that the widgets from Twenty Fourteen are unexpectedly showing.
</li><li>Press *Save &amp; Activate* when redirected to the frontend with the Twenty Thirteen theme active, notice that the Twenty Fourteen widgets are incorrectly shown.
</li></ol><p>
For previous issues related to widgets in the Customizer being lost during a theme switch, see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/27897" title="defect (bug): Theme preview empties sidebar on active theme (closed: fixed)">#27897</a>.
</p>
westonruterhttps://core.trac.wordpress.org/ticket/31484
https://core.trac.wordpress.org/ticket/31484Report#30802: General settings menu isn't opened.hyoseopSun, 21 Dec 2014 04:34:51 GMTFri, 20 Feb 2015 02:15:18 GMT<p>
After upgrading to 4.1, I can't open General menu in Settings. When I click General menu, the server don't reply. The file of this menu is options-general.php. And below is the path of tracing a reason.
</p>
<p>
wp-admin/options-general.php
</p>
<ul><li>356 : wp_can_install_language_pack()
</li></ul><p>
wp-admin/include/translation-install.php
</p>
<ul><li>233 : fs_connect( array( WP_CONTENT_DIR, WP_LANG_DIR ) )
</li></ul><p>
wp-admin/include/class-wp-upgrader.php
</p>
<ul><li>193 : $wp_filesystem-&gt;find_folder($dir)
</li></ul><p>
wp-admin/include/class-wp-filesystem-base.php
</p>
<ul><li>273 : search_for_folder($folder)
</li><li>293 : trailingslashit($this-&gt;cwd()); ====&gt; $this-&gt;cwd() is defined to return false always at 525 line.
</li><li>1661 : untrailingslashit( $string ) . '/';
</li><li>1667 : rtrim( $string, '/<br />' ); ====&gt; $string isn't string. It is boolean value 'false'.
</li></ul><p>
I can't find where rtrim is defined. But it is clear rtrim must have a string variable as first input. In this case, rtrim gets boolean value 'false' as $string. This makes server blocked. If I remove this function(This means skipping this.), the general settings screen is shown properly. And I don't know why a boolean value is given as a first string variable.
</p>
<p>
Why rtrim gets a boolean value as a first string variable?
If it is a root reason, how do I fix this problem?
</p>
<p>
If you want to see the problem, visit here.
<a class="ext-link" href="http://칭기즈칸.한국/"><span class="icon">​</span>http://칭기즈칸.한국/</a>
And general settings path is below.
<a class="ext-link" href="http://칭기즈칸.한국/wp-admin/options-general.php"><span class="icon">​</span>http://칭기즈칸.한국/wp-admin/options-general.php</a>
</p>
hyoseophttps://core.trac.wordpress.org/ticket/30802
https://core.trac.wordpress.org/ticket/30802Report