WordPress Trac: {29} Open Tickets with patches from youhttps://core.trac.wordpress.org/report/29
Trac Report - {{{
#!span class="create-new-ticket button button-large button-primary"
[https://login.wordpress.org/?redirect_to=https://core.trac.wordpress.org/newticket Create a new ticket]
}}}
This report highlights any tickets which the current user has added patches on, yet the ticket remains open.
By default, it shows tickets for the current user, however, you may define it via the URL as such: http://core.trac.wordpress.org/report/29?USER=dd32
Coloured rows are those where the ticket has been marked as needing a patch.en-usWordPress Trachttps://core.trac.wordpress.org/chrome/site/your_project_logo.pnghttps://core.trac.wordpress.org/report/29
Trac v1.0.1#37705: Remove unnecessary parts of WP_HTTP which remainThu, 18 Aug 2016 04:29:19 GMT<p>
After Requests was merged in WordPress 4.6, WP_HTTP now wraps it with a few of the previous classes remaining for compatibility.
</p>
<p>
Some of these have significant code left in them which is no longer used, and we've still got the entire cURL and Streams WP_HTTP request classes in core.
</p>
<p>
We should be able to remove a large percentage of these without too much issue.
</p>
<p>
There's a chance that some developers have been using these classes directly, especially as a number of items were marked as public (due to how it was developed).
</p>
<p>
I'd like to take the hardline approach and rip everything not needed out early, and restore compatibility shims where needed if it turns out developers were using things directly (incorrectly).
</p>
https://core.trac.wordpress.org/ticket/37705
https://core.trac.wordpress.org/ticket/37705Report#21602: redirect_canonical can lead to infinite loop on index navigation if site url is not all lower caseSat, 09 Jan 2016 08:47:23 GMT<p>
The function redirect_canonical in wp-includes/canonical.php (WordPress 3.4.1) on line 406 and 422 makes the following check:
</p>
<pre class="wiki">if ( !$redirect_url || $redirect_url == $requested_url )
return false;
</pre><p>
This ensures that it does not attempt to redirect you to the page you requested in the first place. However this function is not case sensitive so if the redirect URL is in a different case than the requested URL then the user can enter an infinite redirect loop. (For example if the Site Address (URL) of the site is set to be in all upper case.)
</p>
<p>
This function should do a case-insensitive string comparison since domain names are case-insensitive.
</p>
<p>
The issue only appears to happen with certain plugins installed (ShareThis and PilotPress both led to this issue,) I haven't figured out yet why it's only an issue with certain plugins but it should still be fixed in WordPress to make the proper string comparison.
</p>
https://core.trac.wordpress.org/ticket/21602
https://core.trac.wordpress.org/ticket/21602Report#27365: Upgrader bulk_upgrade() functions do not return the correct dataFri, 23 Oct 2015 08:14:49 GMT<p>
In the bulk_upgrade() function of Language_Pack_Upgrader, Plugin_Upgrader, and Theme_Upgrader the values returned are not set properly, resulting in very poor feedback from the function on success or failure.
</p>
<p>
For instance, take the following code sample from Plugin_Upgrader:
</p>
<div class="code"><pre><span class="x">$result = $this-&gt;run( array(
'package' =&gt; $r-&gt;package,
'destination' =&gt; WP_PLUGIN_DIR,
'clear_destination' =&gt; true,
'clear_working' =&gt; true,
'is_multi' =&gt; true,
'hook_extra' =&gt; array(
'plugin' =&gt; $plugin
)
) );
$results[$plugin] = $this-&gt;result;
</span></pre></div><p>
Notice how the result is stored in the <tt>$result</tt> variable yet the <tt>$results</tt> variable, which is used as the return value, stores the <tt>$this-&gt;result</tt> variable. While the <tt>$this-&gt;result</tt> variable does contain some data, it's not very relevant as a return value for these functions. This issue causes a loss of most, if not all error feedback (I have yet to test every possible combination of result possibilities) and fails to provide any useful success condition responses. In most of my test cases, this issue results in each package having a response value of <tt>null</tt>.
</p>
<p>
This same issue can be found in the Language_Pack_Upgrader and Theme_Upgrader classes.
</p>
<p>
My solution is to simply change <tt>$this-&gt;result</tt> to <tt>$result</tt> as found in the supplied patch and as shown below:
</p>
<div class="code"><pre><span class="x">$results[$plugin] = $result;
</span></pre></div>https://core.trac.wordpress.org/ticket/27365
https://core.trac.wordpress.org/ticket/27365Report#15101: Update Message Reduces User Orientation reg. WordPress VersionTue, 16 Jun 2015 04:57:30 GMT<p>
This is a usability issue many customers are telling me: When there is a WordPress update message, the current version is not prominent any longer.
</p>
<p>
Normally the current version is displayed in the admin's footer. If there is a (very promintent "on top") update message, this version information get's hidden in footer as well.
</p>
<p>
The only place where a user can find the current version is in some dashboard widget. That location is hard to find. And that location is hard to describe on the phone, e.g. in support.
</p>
<p>
I suggest to restore the current version display in the footer, because a footer is very easy to find and to describe by phone.
</p>
<p>
Additionally the update message on top should display the current version number as well. Something Like There is a new version available, you're currently running (should be 65%-70% of the width in english text of a 1024 width screen (970 or so viewport size) to allow this to be translated w/o consuming too much of the screen real estate).
</p>
https://core.trac.wordpress.org/ticket/15101
https://core.trac.wordpress.org/ticket/15101Report#31270: Unexpected slugs for same-title different-parents term creationMon, 09 Feb 2015 03:42:46 GMT<p>
When creating a new term which matches an existing terms name, it uses that slugs slug as the slug prefix, which can result in an unexpected term slug.
</p>
<p>
For example, take this:
</p>
<pre class="wiki">Foo (slug: foo)
- Bar (slug: foo-bar)
</pre><p>
If we now create a root level "Bar" term, it'll get a slug of <tt>foo-bar-2</tt>, when one would expect it to receive <tt>bar</tt> since no conflicting slug exists.
</p>
<p>
This is related directly to <a class="changeset" href="https://core.trac.wordpress.org/changeset/28733" title="In `wp_insert_term()`, when no slug is provided, check for an existing ...">[28733]</a> / <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/17689" title="defect (bug): Terms should not be sanitized inside term_exists() (closed: fixed)">#17689</a>.
</p>
<p>
Unit test attached showing behaviour.
</p>
https://core.trac.wordpress.org/ticket/31270
https://core.trac.wordpress.org/ticket/31270Report#14477: get_pages with child_of only works with uninterrupted hierarchiesThu, 27 Nov 2014 02:49:41 GMT<p>
I have a page X with several children and grandchildren. Some of the grandchildren have a certain meta key and value. I now want to fetch all pages under page X that have this meta key. After reading the documentation of <em>get_pages</em>, I expected this to work with a single call of <em>get_pages</em>.
</p>
<p>
But if I use get_pages like this:
</p>
<pre class="wiki">get_pages('child_of=X&amp;meta_key=A&amp;meta_value=B');
</pre><p>
it returns no pages at all (hierarchical=0 has no effect). It seems that's because <em>child_of</em> triggers a call of <em>get_page_children</em> which only returns uninterrupted hierarchies. Since the query returns only some grandchildren and no direct descendants, the function fails. IMHO, that's a bug.
</p>
https://core.trac.wordpress.org/ticket/14477
https://core.trac.wordpress.org/ticket/14477Report#25840: Feature Request: WP_ACCESSIBLE_HOSTS as optionFri, 08 Nov 2013 02:36:05 GMT<p>
Currently WP_ACCESSIBLE_HOSTS is defined as a constant. It would be great if this is a wordpress option (or something equivalent) so you can change it at runtime. If you have a multisite installation and need to add domains to the whitelist you must reload the whole installation to enable them. Writing a simple plugin for this is also not possible since constants can not be redefined.
</p>
<p>
My suggestion:
1) Store a site_option for mutlisites. This should contain a general whitelist for all blogs
2) Store a option per blog to contain additional whitelists for this single blog
3) Make it configurable via the admin interface (single textbox to enter the domains)
4) In the block_request function (<a class="ext-link" href="https://github.com/WordPress/WordPress/blob/master/wp-includes/class-http.php#L507"><span class="icon">​</span>https://github.com/WordPress/WordPress/blob/master/wp-includes/class-http.php#L507</a>) the 2 options should be merged and handled like the constant
</p>
<p>
This way you could manage the whitelist at runtime.
</p>
<p>
What do you think about this?
</p>
<p>
Chris
</p>
https://core.trac.wordpress.org/ticket/25840
https://core.trac.wordpress.org/ticket/25840Report#25692: Update /info/ API endpointsMon, 28 Oct 2013 04:16:18 GMT<p>
The <tt>/info/</tt> API endpoints need to be updated to use JSON encoding.
</p>
<p>
Previously: <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/25311" title="task (blessed): Replace PHP-serialized data with JSON in api.wordpress.org (closed: fixed)">#25311</a>
</p>
https://core.trac.wordpress.org/ticket/25692
https://core.trac.wordpress.org/ticket/25692Report#22840: Uploading an existing plugin saves the zip in media libraryFri, 13 Sep 2013 07:10:32 GMT<p>
Action: Install the same plugin twice.
</p>
<p>
Expected behavior: Second time, plugin should fail and not install.
</p>
<p>
Actual Behavior: Install fails, but the plugin's .zip shows in the Media Library. (Shows in Site <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/1" title="defect (bug): Handle https:// when manipulating 'home' (closed: fixed)">#1</a> on Multisite)
</p>
<p>
This <em>is not</em> a 3.5 regression, same things happens in 3.4.2
</p>
https://core.trac.wordpress.org/ticket/22840
https://core.trac.wordpress.org/ticket/22840Report#23845: Install new theme via FTP failedFri, 06 Sep 2013 05:28:22 GMT<p>
New theme installation via FTP has failed when we specified custom FTP_BASE folder. If we try this theme installation , wordpress shows error message: "Unable to locate WordPress theme directory". This was because search_for_folder method do not respect FTP_BASE setting and allows to walking on parent directories. All solutions I found in google is ugly hacks who only mask the problem but does not resolved it
I attached patch example who resolve this problem. I hope is useful and will help to repair this bug.
</p>
https://core.trac.wordpress.org/ticket/23845
https://core.trac.wordpress.org/ticket/23845Report#14401: Unable to locate WordPress Content directory (wp-content).Tue, 20 Aug 2013 07:34:12 GMT<p>
Hi, I encounter this message on one server during plugin install: "Unable to locate WordPress Content directory (wp-content)."
</p>
<p>
PHP Version 5.2.0-8+etch1
</p>
<p>
Another info from Core Control plugin:
</p>
<p>
Direct Not Available
</p>
<p>
SSH2 Not Available
</p>
<p>
PHP FTP Extension Available
</p>
<p>
PHP FTP Sockets Available
</p>
<p>
ABSPATH: /home/www/domain.eu/subdomains/www/
</p>
<p>
WP_CONTENT_DIR /home/www/domain.eu/subdomains/www/wp-content
WP_PLUGIN_DIR /home/www/domain.eu/subdomains/www/wp-content/plugins
</p>
<p>
DOCUMENT_ROOT (from phpinfo) /home/www/domain.eu/subdomains/www
</p>
<p>
I tried some hacks in wp-config.php, but I was not successfull.
</p>
<p>
When I tried ftpsockets, following error appears:
</p>
<p>
Warning: socket_last_error() expects parameter 1 to be resource, null given in /home/www/domain.eu/subdomains/www/wp-admin/includes/class-ftp-sockets.php on line 59
</p>
<p>
When I tried direct, following error appears:
</p>
<p>
Downloading install package from <a class="ext-link" href="http://downloads.wordpress.org/plugin/wp-memory-usage.zip"><span class="icon">​</span>http://downloads.wordpress.org/plugin/wp-memory-usage.zip</a>…
</p>
<p>
Unpacking the package
</p>
<p>
Could not create directory. /home/www/domain.eu/subdomains/www/wp-content/upgrade/wp-memory-usage.tmp
</p>
https://core.trac.wordpress.org/ticket/14401
https://core.trac.wordpress.org/ticket/14401Report#20652: Install plugins with FTP upload, virtual subdomain, bad base dir?Thu, 10 May 2012 12:47:45 GMT<p>
Hi anybody!
I have problem with install plugins with FTP module in WP.
</p>
<p>
Everything show as OK, but plugin directory is bad. I have subdomain
</p>
<p>
sub.something.com - this is virtual subdomain from mod_rewrite
</p>
<p>
dirs are
</p>
<p>
/www/something.com/something.com<br />
/www/something.com/sub.something.com - here is WP installation, subdomain is virtual from rewrite in httpd.conf
</p>
<p>
After install - WP say everything OK - but one thing is bad.<br />
Upload is in bad directory - plugin I can found in<br />
/www/something.com/something.com/plugins<br />
no in /www/something.com/sub.something.com/plugins<br />
</p>
<p>
Is here some way to fix it automatticaly or I can must edit config and basedir of ftp? Why is here this bug?
</p>
<p>
Thank you !
</p>
<p>
Pavel
</p>
https://core.trac.wordpress.org/ticket/20652
https://core.trac.wordpress.org/ticket/20652Report#18289: Direct link to plugin installation should have admin chromeWed, 05 Oct 2011 13:52:30 GMT<p>
We should be able to provide a direct link to the page to install a plugin, based on the plugin's slug. This does it: wp-admin/plugin-install.php?tab=plugin-information&amp;plugin=log-deprecated-notices. However, there's no admin chrome, no real indication which site you're on, and no name of the plugin.
</p>
<p>
If we're not loading that page inside an iframe request, it needs the admin around it, as well as a heading. Probably new styling too.
</p>
<p>
This would serve as a replacement for <a class="ext-link" href="http://coveredwebservices.com/wp-plugin-install/"><span class="icon">​</span>Jaquith's bookmarklet</a>, which broke in 3.2 (frame busting), as well as allow us to integrate a link on extend/plugins for plugin installation. Related, <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/16923" title="task (blessed): &#34;Install from URL&#34; for themes and plugins (closed: wontfix)">#16923</a>, which is now closed.
</p>
https://core.trac.wordpress.org/ticket/18289
https://core.trac.wordpress.org/ticket/18289Report#18322: The Road to Magic Quotes SanitySun, 02 Oct 2011 04:21:46 GMT<p>
For back compat reasons, wp_magic_quotes() performs addslashes() on GPCS data. This is a pain, especially given that some core API expects slashes and some doesn't. In hopes of someday losing the automatic GPCS slashing, let's introduce a flag to turn off the slashing as well as slash and unslash functions that consult the flag. If slashing is on, these functions add and strip slashes. If slashing is off, they return data unchanged. Plugin authors can start using these functions and testing their code with GPCS slashing turned off and on. Eventually, GPCS slashing would default to off and all calls to the slash and unslash functions could be removed from core.
</p>
https://core.trac.wordpress.org/ticket/18322
https://core.trac.wordpress.org/ticket/18322Report#18738: Improving cron spawning and other non-blocking HTTP requestsSat, 24 Sep 2011 06:11:16 GMT<p>
The order of preference for transport methods in the HTTP API is cURL, streams, fsockopen. However cURL and streams cannot perform non-blocking requests, but fsockopen can. Therefore, fsockopen should be the highest priority transport method for non-blocking HTTP requests.
</p>
<p>
Here's an example. I have a script at <tt>http://ctftw.com/sleep.php</tt> which sleeps for 5 seconds.
</p>
<pre class="wiki">$start = microtime( true );
wp_remote_get( 'http://ctftw.com/sleep.php', array(
'blocking' =&gt; false
) );
$end = microtime( true );
var_dump( $end - $start );
</pre><p>
When the cURL or streams transports are used, this request blocks the page for 5 seconds (the default request timeout is 5 seconds).
</p>
<p>
Let's disable the cURL and streams transports (leaving only fsockopen) and try again:
</p>
<pre class="wiki">add_filter( 'use_curl_transport', '__return_false' );
add_filter( 'use_streams_transport', '__return_false' );
$start = microtime( true );
wp_remote_get( 'http://ctftw.com/sleep.php', array(
'blocking' =&gt; false
) );
$end = microtime( true );
var_dump( $end - $start );
</pre><p>
This request does not block the page because fsockopen returns immediately after sending the request.
</p>
<h2 id="CronSpawning">Cron Spawning</h2>
<p>
This is a benefit to core because it improves the cron spawner (and can potentially fix <a class="reopened ticket" href="https://core.trac.wordpress.org/ticket/8923" title="defect (bug): cron timeout is too short (reopened)">#8923</a>). The cron spawner uses a timeout of 0.01 seconds and a non-blocking request, but actually takes longer than 0.01 seconds.
</p>
<p>
Example:
</p>
<pre class="wiki">$cron_url = get_option( 'siteurl' ) . '/wp-cron.php?doing_wp_cron';
$start = microtime( true );
wp_remote_post( $cron_url, array(
'timeout' =&gt; 0.01,
'blocking' =&gt; false
) );
$end = microtime( true );
var_dump( $end - $start );
</pre><p>
This request takes around 1.1 seconds on the three servers I've tested it on.
</p>
<p>
Let's disable cURL and streams again (leaving only fsockopen) and see what we get:
</p>
<pre class="wiki">add_filter( 'use_curl_transport', '__return_false' );
add_filter( 'use_streams_transport', '__return_false' );
$cron_url = get_option( 'siteurl' ) . '/wp-cron.php?doing_wp_cron';
$start = microtime( true );
wp_remote_post( $cron_url, array(
'timeout' =&gt; 0.01,
'blocking' =&gt; false
) );
$end = microtime( true );
var_dump( $end - $start );
</pre><p>
On each of my three servers I see a time of around 0.001 seconds.
</p>
<p>
We can therefore improve the cron spawner by setting fsockopen as the preferred transport method for non-blocking HTTP requests.
</p>
<p>
In an attempt to address <a class="reopened ticket" href="https://core.trac.wordpress.org/ticket/8923" title="defect (bug): cron timeout is too short (reopened)">#8923</a>, we can change the cron request timeout to 1 second. If fsockopen is used, the request is lightning fast at ~0.001 seconds. If it's not available and the HTTP API falls back to cURL or streams then it takes ~1.1 second, which is the same time it takes currently. (Hopefully that makes sense.)
</p>
<p>
Patch coming up for those who want to test it.
</p>
https://core.trac.wordpress.org/ticket/18738
https://core.trac.wordpress.org/ticket/18738Report#16216: Hide core updater if running an svn checkoutTue, 19 Apr 2011 05:29:35 GMT<p>
The logic with this patch is if you are running an svn checkout, do not display the core updater code and instead display a reminder.
</p>
https://core.trac.wordpress.org/ticket/16216
https://core.trac.wordpress.org/ticket/16216Report#16979: Extra hooks needed in comment processSat, 16 Apr 2011 03:46:36 GMT<p>
I'm running into a few commenting issues whilst building a plugin with a custom post type..
</p>
<ul><li>Duplicate comment check's cannot be bypassed
</li><li>Empty comments are not allowed (In this case, the comment body is empty whilst a set of custom fields acting as metadata are set, meaning, the plugin wants to accept that comment)
</li><li>being able to override the wp_die() in the commenting process would be useful (Currently: Duplicate comments, User not logged in, and not all fields filled in will cause this)
</li></ul><p>
One potential solution would be to move <a class="ext-link" href="http://core.trac.wordpress.org/browser/trunk/wp-comments-post.php#L55"><span class="icon">​</span>lines 55-84</a> from <tt>wp-comments-post.php</tt> to functions hooked to <tt>preprocess_comment</tt>
</p>
https://core.trac.wordpress.org/ticket/16979
https://core.trac.wordpress.org/ticket/16979Report#16156: update-core is oblivious to api.wp.org being unreachableMon, 04 Apr 2011 07:12:56 GMT<p>
A server running 3.0.4 had trouble reaching *.wordpress.org for some unknown reason. (This wasn't during the brief api.wp.org outage, and it worked otherwise.)
</p>
<p>
Problem is, update-core was completely oblivious to this. It's even worse when running 3.1, because the 'Check Again' button will refresh the page and tell you we last checked for updates *just now*.
</p>
<p>
Try Again or Check Again should reflect that the API is unreachable when this can be determined. Claiming that we checked for updates is also really lame, so we should see if the transient tells us how long it's been since the last one.
</p>
<p>
Side note, the plugin install et al. HTTP error messages are rather cryptic, and we should also make those more user friendly.
</p>
https://core.trac.wordpress.org/ticket/16156
https://core.trac.wordpress.org/ticket/16156Report#16895: wp_list_pluck cannot be used with arrays of referencesSat, 19 Mar 2011 11:49:26 GMT<p>
Example code:
</p>
<pre class="wiki">$one = array('num' =&gt; 1);
$two = array('num' =&gt; 2);
$input = array( &amp;$one, &amp;$two );
$nums = wp_list_pluck($input, 'num');
var_dump($nums, $input);
</pre><p>
Example output:
</p>
<pre class="wiki">array
0 =&gt; &amp;int 1
1 =&gt; &amp;int 2
array
0 =&gt; &amp;int 1
1 =&gt; &amp;int 2
</pre><p>
Expected output:
</p>
<pre class="wiki">array
0 =&gt; int 1
1 =&gt; int 2
array
0 =&gt; &amp;
array
'num' =&gt; int 1
1 =&gt; &amp;
array
'num' =&gt; int 2
</pre><p>
This is caused by wp_list_pluck using the same variable name for the input array, and then overwriting it for the return.
</p>
<p>
One such real life example, is $wp_query-&gt;comments
</p>
<p>
See patch
</p>
https://core.trac.wordpress.org/ticket/16895
https://core.trac.wordpress.org/ticket/16895Report#13041: Canonical redirection will redirect a non-exitant page to a post.Sun, 18 Apr 2010 06:15:14 GMT<p>
Following on from <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/12601" title="defect (bug): Post_type + non-existant object + Canonical (closed: fixed)">#12601</a>
</p>
<p>
Canonical redirection will kick in for <a class="ext-link" href="http://localhost/wordpress-commit/apage/something"><span class="icon">​</span>http://localhost/wordpress-commit/apage/something</a> and redirect it to <a class="ext-link" href="http://localhost/wordpress-commit/2010/02/13/something-else/"><span class="icon">​</span>http://localhost/wordpress-commit/2010/02/13/something-else/</a>
</p>
<p>
<a class="closed ticket" href="https://core.trac.wordpress.org/ticket/12601" title="defect (bug): Post_type + non-existant object + Canonical (closed: fixed)">#12601</a> limited redirect_guess_404_permalink() to only searching in the same post_type if one was provided, for posts and pages however, which are builtin, these vars are not set.
</p>
<p>
I'm attaching a patch which will prevent a Page -&gt; Post redirection, but not the other way around. - this patch was originally added to the other ticket.
</p>
https://core.trac.wordpress.org/ticket/13041
https://core.trac.wordpress.org/ticket/13041Report#12456: Canonical URL redirect issue with post_id/postname permalink structureFri, 05 Mar 2010 12:01:27 GMT<p>
The issue:
</p>
<p>
Using /%post_id%/%postname%/ as permalink structure,
Most canonical redirects work fine, except:
</p>
<p>
domain.com/post_id/ brings you to the post but does not redirect to the canonical domain.com/post_id/postname/
</p>
<p>
Additional info:
</p>
<p>
The above permalink structure conforms to best practice as described in the codex:
<a class="ext-link" href="http://codex.wordpress.org/Using_Permalinks#Structure_Tags"><span class="icon">​</span>http://codex.wordpress.org/Using_Permalinks#Structure_Tags</a>
</p>
<p>
Therefore I figured this was a bug, given the attention given to redirecting to the canonical url "So to avoid confusing search engines and to consolidate your rankings for your content, there should only be one URL for a resource."
<a class="ext-link" href="http://markjaquith.wordpress.com/2007/09/25/wordpress-23-canonical-urls/"><span class="icon">​</span>http://markjaquith.wordpress.com/2007/09/25/wordpress-23-canonical-urls/</a>
</p>
https://core.trac.wordpress.org/ticket/12456
https://core.trac.wordpress.org/ticket/12456Report#11623: review options list and update sanitize_option()Sat, 26 Dec 2009 01:24:37 GMT<p>
A lot of options have been added since 2.0.5, and as a result, not all of them have been added to <tt>sanitize_option()</tt>
</p>
<p>
Ideally, Options which are to be (int) or absint() should have a filter applied to them here.
</p>
<p>
Attached patch is for the first option thats brought this up, 'start_of_week' which is tested to be int in some function uses, ignored elsewhere.
</p>
<p>
I've set this to security as its preventive security..
</p>
https://core.trac.wordpress.org/ticket/11623
https://core.trac.wordpress.org/ticket/11623Report#10786: Implementation of %my_taxonomy% in permastructs is incompleteFri, 18 Sep 2009 01:57:39 GMT<p>
The <tt>register_taxonomy()</tt> function includes a call to <tt>add_rewrite_tag()</tt> which should allow for a site's permastruct to include a %my_taxonomy% tag just like you can include a %category% tag or a %tag% tag, however this implementation is incomplete and doesn't work.
</p>
<p>
Example:
</p>
<p>
<tt>register_taxonomy('genre','post');</tt>
</p>
<p>
should allow you to create a permastruct (from the Settings-&gt;Permalinks screen) which includes %genre% in it.
</p>
<p>
The problem is that <tt>get_permalink()</tt> doesn't check for custom taxonomies and the replacement of %genre% with your post's genre in the permalink doesn't happen.
</p>
<p>
Patch upcoming.
</p>
https://core.trac.wordpress.org/ticket/10786
https://core.trac.wordpress.org/ticket/10786Report#6778: Detect when the config will cause infinite loopSun, 16 Aug 2009 12:00:19 GMT<p>
Behavior:
</p>
<p>
If you put in <a class="ext-link" href="http://www.domain.com"><span class="icon">​</span>http://www.domain.com</a> in the "Wordpress Address" setting, then Wordpress will automatically do a redirect from <a class="ext-link" href="http://domain.com"><span class="icon">​</span>http://domain.com</a> to <a class="ext-link" href="http://www.domain.com"><span class="icon">​</span>http://www.domain.com</a>. Many hosting packages allow the user to deal with www and non-www versions of their domain. This will cause an infinite redirect loop if, for example, the "Wordpress Address" is set to <a class="ext-link" href="http://www.domain.com"><span class="icon">​</span>http://www.domain.com</a> and the hosting setting is set remove the www from the domain address-- to redirect <a class="ext-link" href="http://www.domain.com"><span class="icon">​</span>http://www.domain.com</a> to <a class="ext-link" href="http://domain.com"><span class="icon">​</span>http://domain.com</a>.
</p>
<p>
Expected behavior:
</p>
<p>
When setting the "Wordpress Address" setting, it should detect if the canocical code will cause an infinite redirect loop and warn/correct the mistake
</p>
https://core.trac.wordpress.org/ticket/6778
https://core.trac.wordpress.org/ticket/6778Report#10535: _wp_filter_build_unique_id issues with the first time a filter is hooked by a classSun, 02 Aug 2009 12:55:46 GMT<p>
Ref <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/8723" title="defect (bug): Instances of same class that call variable hook first generate same ... (closed: fixed)">#8723</a>
</p>
<p>
The first time _wp_filter_build_unique_id is used to generate an ID the ID returned is different to the second time it is called. This presents a problem if the first ID is used when adding a filter which then needs to be removed later in the app flow... as the IDs don't match the filter is unremovable.
</p>
<p>
One workaround proposed is to set a wp_filter_id property before add the filter, and this will cause _wp_filter_build_unique_id to bypass the problem code and effectively forces the "unique" ID which is generated... this workaround feels unpoetic. ;)
</p>
https://core.trac.wordpress.org/ticket/10535
https://core.trac.wordpress.org/ticket/10535Report#7795: Activate and Deactivate Theme hooksThu, 18 Dec 2008 12:50:03 GMT<p>
Currently, there is no standard way of checking whether of theme is activated, deactivated and uninstalled. Plugins have this capability and themes should also have the same to ensure that both share similar functionality.
</p>
https://core.trac.wordpress.org/ticket/7795
https://core.trac.wordpress.org/ticket/7795Report#38931: `update_option()` race condition with non-autoloaded optionsThu, 24 Nov 2016 13:32:41 GMT<p>
Starting back in <a class="changeset" href="https://core.trac.wordpress.org/changeset/25664" title="When queries fail in option functions, bail before setting cache.
...">[25664]</a> there's a race condition with object caches where <tt>get_option()</tt> will return a value, but <tt>update_option()</tt> will refuse to update it.
This is kind-of-related to <tt>alloptions</tt>, but affects non-autoloaded options (which are not in <tt>alloptions</tt>, but in their own cache).
</p>
<p>
Consider the following scenario:
</p>
<pre class="wiki">Process 1: Fetch option_a. Fills local cache.
Process 2: Update option_a.
Process 1: Delete option_a.
Process 2: Update DB.
Process 1: Delete from DB. Delete from remote cache.
Process 2: Update remote cache.
...
Process 5: Fetch option_a. Fills local cache from remote cache.
Process 5: Update option_a. FAIL. DB doesn't have option. abort. cache not updated.
...
(repeat process 5 above many times)
Process 10: Get option_a (Still the value that Process 2 set in cache, even though it's not in the DB)
Process 10: Update option_a (Doing the same as Process 5 now). FAIL.
</pre><p>
Seems very racey and unlikely, but I've seen it happen on WordPress.org at least twice in the last few weeks when we update Jetpack (which makes heavy usage of the options table, and is loaded on most WordPress.org requests).
</p>
<p>
When it happens, <tt>get_option()</tt> will continue to return a stale value from the cache that no longer exists in the DB and <tt>update_option()</tt> will fail to update the option as long as it exists in cache.
If a plugin is performing an operation to update the stale option often, it can cause a huge load spike on the database server of never-ending failing <tt>UPDATE</tt> queries.
The only way to 'fix' it is to create the DB row manually, or flush the object cache key.
</p>
<p>
The patch attached attempts to perform an <tt>add_option()</tt> in the case of the <tt>update_option()</tt> DB query failing.
This isn't exactly a new behaviour for options - <tt>add_option()</tt> will effectively perform an <tt>update_option()</tt> in the event the option you're trying to add already exists (through it using <tt>INSERT .. ON DUPLICATE KEY UPDATE..</tt>), doing it in reverse doesn't seem that out of the question.
</p>
https://core.trac.wordpress.org/ticket/38931
https://core.trac.wordpress.org/ticket/38931Report#38328: Lost Password email construction - two links should be one.Mon, 17 Oct 2016 03:46:46 GMT<p>
The generic lost password email is poorly constructed. It states "...password be reset for the following account" and then echoes the home URL of the Wordpress site, leading many users unfamiliar with Wordpress to click this link rather than the more cryptic-looking longer (correct!) password-reset link.
</p>
<p>
Surely the 'account' should just state the 'Site name' with no link to the home_url. Or if it's important to give the home_url, why not clearly separate the two different links:
</p>
<p>
Account homepage: {network_home_url}
Reset your password: {network_site_url("wp-login.php?action=rp&amp;key=$key&amp;login="}
</p>
https://core.trac.wordpress.org/ticket/38328
https://core.trac.wordpress.org/ticket/38328Report#38243: Attempting to create a term with invalid UTF8 characters creates a blank termThu, 06 Oct 2016 13:53:23 GMT<p>
Attempting to insert a term which contains invalid UTF8 characters will incorrectly create a term in the database with a blank name &amp; slug. This happens as we check that the term name &amp; slug is provided, but fail to check after sanitizing the term.
</p>
<p>
In the scenario that I've run into, something similar to this happens:
</p>
<pre class="wiki">$term_name = urldecode( "360%BF" ); // Invalid UTF8 character
wp_insert_term( $term_name, 'my_taxonomy' );
</pre><p>
What this causes is
</p>
<ul><li>the checks on <tt>$name</tt> to pass
</li><li>it then hits <tt>sanitize_term()</tt> and after passing through <tt>sanitize_text_field()</tt> and then <tt>wp_check_invalid_utf8()</tt> the <tt>name</tt> field of the term is set to an empty string.
</li><li><tt>wp_insert_term()</tt> then takes this empty name and creates an equally empty slug from it.
</li><li><tt>wp_insert_term()</tt> then calls <tt>get_terms( array( 'name' =&gt; '' ) )</tt> and needlessly &amp; badly loads up all 60,000 terms into memory of the custom taxonomy
</li><li><tt>wp_insert_term()</tt> then see's an empty slug and ultimates settles on a setting the slug to the numeric ID of the term somehow
</li><li><tt>wp_insert_term()</tt> finally inserts a term with a numeric slug and empty <tt>name</tt> field
</li></ul><p>
I think at a minimum, we should verify that the term name is still valid after term sanitisation. See patch for that.
</p>
https://core.trac.wordpress.org/ticket/38243
https://core.trac.wordpress.org/ticket/38243Report#36426: WP Admin memory limit not increasing to base limit by defaultFri, 19 Aug 2016 04:45:01 GMT<p>
We have 2 constants that can be set in wp-config.php (and by using filters, afaik), for example:
</p>
<div class="code"><pre><span class="x">define( 'WP_MEMORY_LIMIT', '512M' ); // increases WP base (front-end) limit
define( 'WP_MAX_MEMORY_LIMIT', '512M'); // increases WP admin (back-end) limit
</span></pre></div><p>
The former isn't really known, which you can Google to find out. People usually only use the first constant.
If the 2nd constant (WP_MAX_MEMORY_LIMIT) is not set, it defaults to 256M. WP_MEMORY_LIMIT can be higher than that though, so we could safely increase WP_MAX_MEMORY_LIMIT to match WP_MEMORY_LIMIT if WP_MEMORY_LIMIT is higher and WP_MAX_MEMORY_LIMIT is not set manually to a lower (than WP_MEMORY_LIMIT) value.
</p>
<p>
What I mean in coding terms:
</p>
<pre class="wiki">if(!isset(WP_MAX_MEMORY_LIMIT) &amp;&amp; isset(WP_MEMORY_LIMIT)){
if(WP_MEMORY_LIMIT&gt;DEFAULT_WP_MAX_MEMORY_LIMIT){
//NOTE to the line above: this requires parsing the actual value in these constants as the strings can be like: 512M, 1G etc.; the DEFAULT_WP_MAX_MEMORY_LIMIT is a thing I came up with, currently the default admin memory limit is 256M
define( 'WP_MAX_MEMORY_LIMIT', WP_MEMORY_LIMIT);
}
}
</pre><p>
All these values can be checked with the Bulletproof Security plugin, under BPS Security -&gt; System Info.
Side note: imho WP_MAX_MEMORY_LIMIT should be renamed to something like WP_ADMIN_MEMORY_LIMIT, but that's another issue.
</p>
https://core.trac.wordpress.org/ticket/36426
https://core.trac.wordpress.org/ticket/36426Report#35983: Better support for "singular" endpointsSun, 28 Feb 2016 04:47:54 GMT<p>
WP_Rewrite endpoints are currently geared towards endpoints that capture content after it, for example, <tt>/feed/FEED_TYPE/</tt>.
</p>
<p>
Quite often we instead want to create an endpoint which is instead <tt>/embed/</tt> or <tt>/faq/</tt> we don't need to capture an optional bit of data after it.
</p>
<p>
Currently endpoints can operate in either mode, if you specify and endpoint of <tt>test-endpoint</tt> then both <tt>/endpoint-name/</tt> and <tt>/endpoint-name/data-passed/</tt> will work.
The problem comes when testing for the existence of that endpoint in the query.
An endpoint which passes data is easy to check <tt>if ( get_query_var('endpoint-name') )</tt>, an endpoint which doesn't - not so easy <tt>global $wp_query; if ( isset( $wp_query-&gt;query_var['single-endpoint'] ) )</tt>.
</p>
<p>
Something that would be easier, and nicer for developers using the rewrite endpoint is to instead match the endpoint name itself:
Currently the rewrite rule would look like this:
</p>
<pre class="wiki">([^/]+)/endpoint-name(/(.*))?/?$ =&gt; index.php?name=$1&amp;endpoint-name=$3
</pre><p>
What would be great, is if we can do instead:
</p>
<pre class="wiki">add_endpoint( 'single-endpoint', ... );
([^/]+)/(single-endpoint)/?$ =&gt; index.php?name=$1&amp;single-endpoint=$2
</pre><p>
Which if used in conjunction with <tt>add_endpoint()</tt>'s 3rd parameter allowing us to specify a custom query_var:
</p>
<pre class="wiki">add_endpoint( 'endpoint-name', ..., 'special_query' );
add_endpoint( 'another-endpoint-name', ..., 'special_query' );
Rules:
([^/]+)/(endpoint-name)/?$ =&gt; index.php?name=$1&amp;special_query=$2
([^/]+)/(another-endpoint-name)/?$ =&gt; index.php?name=$1&amp;special_query=$2
</pre><p>
this would then allow us to use <tt>if ( get_query_var( 'special_query' ) )</tt> or <tt>if ( get_query_var( 'single-endpoint' ) ) </tt> in the case of the first example.
</p>
<p>
Attached is an implementation which upgrades the 3rd parameter (<tt>$query_var</tt>) to an array to support this. It's a super-rough patch, but appears to work. Does anyone else feel that this is worthwhile supporting?
</p>
https://core.trac.wordpress.org/ticket/35983
https://core.trac.wordpress.org/ticket/35983Report#35554: De-emphasis WordPress Version in the adminThu, 21 Jan 2016 09:55:10 GMT<p>
Currently WordPress is very proud of the version it's running - but version strings are not exactly the most important piece of information to a regular user.
I'd like to bring it back to displaying only the major version (ie. <tt>Version 4.4</tt>, not <tt>Version 4.4.1</tt>).
</p>
<p>
A few of us have kicked the idea around over the years, and making the version number less specific as we move towards faster point releases really makes a lot of sense.
</p>
<p>
There's two options which could be taken:
</p>
<ol><li>Simply bring it back to x.y (<tt>Version 4.4</tt>). <a class="attachment" href="https://core.trac.wordpress.org/attachment/ticket/35554/major.minor.diff" title="Attachment 'major.minor.diff' in Ticket #35554">attachment:major.minor.diff</a><a class="trac-rawlink" href="https://core.trac.wordpress.org/raw-attachment/ticket/35554/major.minor.diff" title="Download">​</a>
</li><li>Remove it entirely, including the <tt>You are running WordPress x.y.z running Theme X theme.</tt> message in the at-a-glance widget. <a class="attachment" href="https://core.trac.wordpress.org/attachment/ticket/35554/remove-all-version-mentions.diff" title="Attachment 'remove-all-version-mentions.diff' in Ticket #35554">attachment:remove-all-version-mentions.diff</a><a class="trac-rawlink" href="https://core.trac.wordpress.org/raw-attachment/ticket/35554/remove-all-version-mentions.diff" title="Download">​</a>
</li></ol><p>
The second option is a harder-line approach, but removes information that most users have no need to see most of the time. They'll still see update nags when a new version comes out (Well, except for the million or more of sites which choose to enable automatic updates for major versions too) and the version string will always be available on the update screen where it's useful.
</p>
https://core.trac.wordpress.org/ticket/35554
https://core.trac.wordpress.org/ticket/35554Report#33053: download_url() includes query string in temporary filenamesTue, 21 Jul 2015 09:09:28 GMT<p>
When installing a theme update, I encountered an error traced back to the update file exceeding the Windows path\filename length limit. It turned out the root cause of this was that the download URL contained a query string with access key information, which was also being included in the filename of the temporary file created by $tmpfname = wp_tempnam($url); in the download_url() function.
</p>
<p>
In my case, for example, download URL was:
</p>
<p>
<a class="ext-link" href="https://s3.amazonaws.com/marketplace-downloads.envato.com/files/140862862/enfold.zip?AWSAccessKeyId=*******************&amp;Expires=1437422162&amp;Signature=*****************-***********%3D&amp;response-content-disposition=attachment%3B+filename%3Dthemeforest-4519990-enfold-responsive-multipurpose-theme-wordpress_theme.zip"><span class="icon">​</span>https://s3.amazonaws.com/marketplace-downloads.envato.com/files/140862862/enfold.zip?AWSAccessKeyId=*******************&amp;Expires=1437422162&amp;Signature=*****************-***********%3D&amp;response-content-disposition=attachment%3B+filename%3Dthemeforest-4519990-enfold-responsive-multipurpose-theme-wordpress_theme.zip</a>
</p>
<p>
which resulted in a temporary file called:
</p>
<p>
enfold.zipAWSAccessKeyId<strong></strong><strong></strong><strong></strong><strong></strong><strong>*Expires1437422162Signature</strong><strong></strong><strong></strong><strong></strong><strong>*-</strong><strong></strong><strong></strong>*-3Dresponse-content-dispositionattachment-3B-filename-3Dthemeforest-4519990-enfold-responsive-multipurpose-theme-wordpress_theme.tmp
</p>
<p>
rather than the expected enfold.zip
</p>
<p>
I would suggest that downloaded files should probably exclude any query string from the URL as the simplest method of resolving this issue, but will leave that to development team.
</p>
https://core.trac.wordpress.org/ticket/33053
https://core.trac.wordpress.org/ticket/33053Report#32774: Improve WP_Filesystem::dirlist() format consistencyWed, 24 Jun 2015 07:06:16 GMT<p>
At present the return values of dirlist() between the various methods are scattered between several different formats
</p>
<table class="wiki">
<tr><td>Field</td><td>Direct</td><td>FTP Ext</td><td>FTP Sockets</td><td>SSH2
</td></tr><tr><td>name</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes
</td></tr><tr><td>perms</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes
</td></tr><tr><td>permsn</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes
</td></tr><tr><td>number</td><td><tt>false</tt></td><td>Yes</td><td>Yes</td><td><tt>false</tt>
</td></tr><tr><td>owner</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes
</td></tr><tr><td>group</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes
</td></tr><tr><td>size</td><td>Yes</td><td>Yes</td><td>Yes or <tt>&lt;DIR&gt;</tt></td><td>Yes
</td></tr><tr><td>lastmodunix</td><td>Unix Timestamp</td><td>No</td><td>No</td><td>Unix Timestamp
</td></tr><tr><td>lastmod</td><td><tt>Nov 15</tt></td><td>No</td><td>No</td><td><tt>Nov 15</tt>
</td></tr><tr><td>time</td><td><tt>02:12:48</tt></td><td>Unix Timestamp</td><td>Unix Timestamp</td><td><tt>02:12:48</tt>
</td></tr><tr><td>year</td><td>No</td><td>Maybe</td><td>Maybe</td><td>No
</td></tr><tr><td>month</td><td>No</td><td><tt>Nov</tt></td><td><tt>Nov</tt></td><td>No
</td></tr><tr><td>day</td><td>No</td><td><tt>15</tt></td><td><tt>15</tt></td><td>No
</td></tr><tr><td>hour</td><td>No</td><td><tt>02</tt></td><td><tt>02</tt></td><td>No
</td></tr><tr><td>minute</td><td>No</td><td><tt>12</tt></td><td><tt>12</tt></td><td>No
</td></tr><tr><td>type</td><td><tt>d</tt> or <tt>f</tt></td><td><tt>d</tt>, <tt>f</tt>, or <tt>l</tt></td><td><tt>d</tt>, <tt>f</tt>, or <tt>l</tt></td><td><tt>d</tt> or <tt>f</tt>
</td></tr><tr><td>isdir</td><td>No</td><td>Yes</td><td>Yes</td><td>No
</td></tr><tr><td>islink</td><td>No</td><td>Yes</td><td>Yes</td><td>No
</td></tr></table>
<p>
If the FTP Server was Windows, it'd complicate it further by not returning certain fields, using different data in them, or getting confused and not returning any data.
</p>
<p>
The attached patch boils it down to a consistent result of <tt>[ 'filename.ext' =&gt; [...], ...]</tt> with the nested arrays of:
</p>
<table class="wiki">
<tr><td>Field</td><td>Value
</td></tr><tr><td>name</td><td>Filename
</td></tr><tr><td>time</td><td>Unix Timestamp of last modified
</td></tr><tr><td>size</td><td>File size or false for Directories
</td></tr><tr><td>type</td><td><tt>d</tt>, <tt>f</tt>, or <tt>l</tt> for Directory, File, or Link respectively
</td></tr><tr><td>perms</td><td>A formatted human-readable <tt>drwxr-xr-x</tt>
</td></tr><tr><td>permsn</td><td>A octal as string <tt>'0755'</tt> for Back-compat purposes
</td></tr><tr><td>owner</td><td>Owner ID or name
</td></tr><tr><td>group</td><td>Group ID or name
</td></tr><tr><td>files</td><td>If it's a recursive directory lookup, a nested array of files
</td></tr></table>
<p>
A number of these are only got back-compat or to match the FTP output - most of these fields are not used by WordPress at all - Specifically <tt>group</tt>, <tt>owner</tt>, <tt>perms</tt>, <tt>permsn</tt>, and <tt>time</tt> are ignored 100% by WordPress (along with a lot of the methods)
Changing this has some back-compat issues for any plugins doing anything special with the fields - however they've had to work around the fields returning random content already, so this shouldn't be a huge issue (or they were already broken)
</p>
https://core.trac.wordpress.org/ticket/32774
https://core.trac.wordpress.org/ticket/32774Report#32452: Cache optimizationsThu, 21 May 2015 03:13:54 GMT<p>
Hi,
</p>
<p>
I've recently been making some custom modifications to wordpress core that reduce the resource load on our object-caching system.
I cannot see any drawbacks to these modifications, but I have to defer to the wp-core development team on this one and therefore assume I've missed something.
I want to know if there is anything I overlooked while making these modifications.
If there are no drawbacks, then perhaps the changes could be rolled into wp-core officially (and then I won't have svn showing files as modified all the time)
</p>
<p>
Explanation: (broken down into sections)
1) I noticed a huge amount of 'extra' queries to the object-cache.
Many of them originating from calls to wp_load_alloptions()
I believe with my modifications wp_load_alloptions() only needs to be called in one place instead of many, and that is within the definition of the object-cache itself.
</p>
<p>
2) I've also reduced redundant queries by changing the assumption that a key doesn't exist to a key does exist. Check the cache for the key first instead of checking the 'negative' cache for the key first.
</p>
<p>
3) Some minor fixes in options.php
</p>
<hr />
<hr />
<hr />
<p>
All file changes (from svn diff) available at this link:
<a class="ext-link" href="http://pastebin.com/5vPGCCt7"><span class="icon">​</span>http://pastebin.com/5vPGCCt7</a>
</p>
https://core.trac.wordpress.org/ticket/32452
https://core.trac.wordpress.org/ticket/32452Report#29204: SimplePie error with fetch_feed()Mon, 09 Mar 2015 05:37:04 GMT<p>
There seems to be a bug in SimplePie that raises the following notice every time an RSS Feed Dashboard widget is added to the Dashboard.
</p>
<pre class="wiki">call_user_func_array() expects parameter 1 to be a valid callback, non-static method WP_Feed_Cache::create() should not be called statically on line 215 in file /path/to/wp-includes/SimplePie/Registry.php
</pre><p>
Calling <tt>fetch_feed()</tt> is the best way to raise it. I'm using 'blackbox-debug-bar' plugin to capture the notices.
</p>
<p>
Examples to reproduce the error:
</p>
<p>
Install and use <a class="ext-link" href="https://wordpress.org/plugins/dashboard-feed-widget/"><span class="icon">​</span>Dashboard Feed Widget</a>
</p>
<p>
or follow one of the tuts below.
</p>
<p>
<a class="ext-link" href="http://adamscottcreative.com/add-your-own-news-feed-to-wordpress-dashboard/"><span class="icon">​</span>http://adamscottcreative.com/add-your-own-news-feed-to-wordpress-dashboard/</a>
</p>
<p>
<a class="ext-link" href="http://samglover.net/build-your-own-wordpress-dashboard-widget-for-any-rss-feed/"><span class="icon">​</span>http://samglover.net/build-your-own-wordpress-dashboard-widget-for-any-rss-feed/</a>
</p>
<p>
I suspect the reason we don't see it when "WordPress News" is displayed is because the fetch_feed() runs via ajax and does not get captured in the current screen.
</p>
https://core.trac.wordpress.org/ticket/29204
https://core.trac.wordpress.org/ticket/29204Report#26802: WordPress FTP component fails to update core on IIS7+Sat, 18 Jan 2014 05:38:19 GMT<p>
Update fails with this error : Could not copy file.: wp-admin/update-core.php
</p>
<p>
Steps to reproduce :
</p>
<ul><li>Clean install of Windows 2012R2 in a virtual machine
</li><li>PHP version 5.4.23 installed, configured, and tested as per Microsoft Instructions
</li><li>Granted FTP user full control of entire web root
</li><li>Granted web server user read access to web root
</li><li>Verified the ability to connect with a remote FTP client, create a folder, upload a file, delete the file, delete the folder
</li><li>Installed wordpress 3.7.1
</li><li>Logged into wordpress admin, clicked on 3.8 upgrade link
</li><li>prompted for FTP credentials, supplied same credentials as in my test above
</li><li>wordpress update failed with the following message
</li></ul><pre class="wiki">Downloading update from https://wordpress.org/wordpress-3.8-new-bundled.zip…
Unpacking the update…
Verifying the unpacked files…
Preparing to install the latest version…
Enabling Maintenance mode…
Copying the required files…
Disabling Maintenance mode…
Could not copy file.: wp-admin/update-core.php
Installation Failed
</pre><p>
I then verified that the update could be done manually via an FTP client
</p>
<ul><li>Manually downloaded wordpress-3.8-new-bundled.zip form wordpress.org
</li><li>Manually unzipped into temporary directory
</li><li>Manually uploaded contents of entire zip file to server
</li><li>ran wp-admin/update-core.php
</li><li>Updated the database as prompted
</li></ul><p>
Wordpress successfully updated to 3.8 using this manual FTP upload method. The only difference is that I used my own FTP client (Filezilla) instead of the wordpress FTP component.
</p>
<p>
I think its fair to say at this point that there is a potential bug in the FTP component which manifests itself on IIS servers.
</p>
<p>
WWW, FTP, and PHP Log files are available upon request.
</p>
https://core.trac.wordpress.org/ticket/26802
https://core.trac.wordpress.org/ticket/26802Report#25741: Broken WP_Filesystem methodsMon, 28 Oct 2013 03:18:22 GMT<p>
The following methods of WP_Filesystem do not work as intended, as they're called with absolute paths, and fail to find those absolute paths within the relative paths returned from the listing functions:
</p>
<ul><li>WP_Filesystem_FTPext
<ul><li>owner()
</li><li>getchmod()
</li><li>group()
</li></ul></li><li>WP_Filesystem_ftpsockets
<ul><li>owner()
</li><li>getchmod()
</li><li>group()
</li></ul></li></ul><p>
It's worth noting that the following FTP methods are available but don't actually hit the filesystem, and are just there to match the <tt>WP_Filesystem_Direct</tt> methods:
</p>
<ul><li>is_readable()
</li><li>is_writable()
</li><li>atime()
</li><li>touch()
</li></ul><p>
Attached is a patch I had locally from during 3.7 development, not thoughly tested, I believe WP_Filesystem_FTPext::owner() at least needs extra work.
The patch also removes the above methods from the FTP classes and relies upon the <tt>WP_Filesystem_Base</tt> versions - as a result, the is_writable() and is_readable() methods changed to assume things are readable/writable.
</p>
https://core.trac.wordpress.org/ticket/25741
https://core.trac.wordpress.org/ticket/25741Report#16808: Insufficient permissions for custom post type management and custom role/capsFri, 09 Aug 2013 07:07:48 GMT<p>
I asked a question over at <a class="ext-link" href="http://wordpress.stackexchange.com/questions/11508/permission-error-on-custom-post-type-add-new-action"><span class="icon">​</span>StackExchange</a> about this. Went into their chat room to talk to a few people and came to the conclusion I need to post this ticket.
</p>
<p>
---
</p>
<p>
When accessing an admin page located at post-new.php with a custom post type on a user that's in a custom role that has the available permission to "Add New", you get "You do not have sufficient permissions to access this page."
</p>
<pre class="wiki"> $post_caps = array( 'delete_post' =&gt; 'argus_admin', );
$visitor_caps = $post_caps;
$visitor_caps = array_merge( $visitor_caps, array(
'edit_post' =&gt; 'argus_visitors',
'read_post' =&gt; 'argus_visitors',
'edit_posts' =&gt; 'argus_visitors',
'edit_others_posts' =&gt; 'argus_visitors',
'publish_posts' =&gt; 'argus_visitors',
'read_private_posts' =&gt; 'argus_visitors',
));
$v_args = array(
'labels' =&gt; array (
'name' =&gt; 'Visitors',
'singular_name' =&gt; 'Visitor',
'add_new_item' =&gt; 'Register New Visitor',
),
'public' =&gt; true,
'publicly_queryable' =&gt; false,
'exclude_from_search' =&gt; true,
'show_ui' =&gt; true,
'show_in_menu' =&gt; 'argus',
//'show_in_menu' =&gt; false,
'hiearchical' =&gt; false,
'supports' =&gt; array( '' ),
'capabilities' =&gt; $visitor_caps,
'register_meta_box_cb' =&gt; array ( &amp;$this, '_wp_visitor_meta_box_cb' ),
);
register_post_type( 'visitor', $v_args );
</pre><p>
I've tested it with 3.0.4 and it worked flawlessly. However, when in 3.1, it doesn't want to work.
</p>
https://core.trac.wordpress.org/ticket/16808
https://core.trac.wordpress.org/ticket/16808Report#22239: wp_ob_end_flush_all() tries to destroy non-destroyable output buffersSun, 21 Oct 2012 03:27:28 GMT<p>
<tt>wp_ob_end_flush_all()</tt> currently tries to flush &amp; destroy every PHP Output buffer that is enabled on the current installation.
However, not every type of PHP Output buffer can be destroyed, which will cause a PHP Notice when attempts to do so are made.
An example of this is PHP extensions such as New Relic, or PHP output buffers created with the <tt>$erase</tt> flag set to false in <tt>ob_start()</tt>
</p>
<p>
An example is when New Relic is installed on a host, also <a class="ext-link" href="https://newrelic.com/docs/php/php-agent-faq#rum-obclean"><span class="icon">​</span>see New Relics FAQ entry</a> on the issue.
</p>
<pre class="wiki">( ! ) Notice: ob_end_flush(): failed to send buffer of New Relic auto-RUM (1) in ../trunk/wp-includes/functions.php on line 2641
Call Stack
# Time Memory Function Location
1 0.8510 4328360 shutdown_action_hook( ) ../load.php:0
2 0.8510 4328440 do_action( ) ../load.php:556
3 0.8510 4329856 call_user_func_array ( ) ../plugin.php:406
4 0.8510 4329888 wp_ob_end_flush_all( ) ../plugin.php:406
5 0.8511 4330064 ob_end_flush ( ) ../functions.php:2641
</pre><p>
Somewhat similar to <a class="new ticket" href="https://core.trac.wordpress.org/ticket/18239" title="defect (bug): wp_ob_end_flush_all() hangs the output buffering, during plugin ... (new)">#18239</a>
I'm not sure of what the ideal solution for this would be for WordPress, but wanted to record the issue being known.
</p>
https://core.trac.wordpress.org/ticket/22239
https://core.trac.wordpress.org/ticket/22239Report#18385: Canonical redirections not suited for Queries with multiple query vars and "pretty permalinks" in generalFri, 12 Aug 2011 09:05:57 GMT<p>
When the Canonical code was originally written, it served it's purpose quite well. However, over the years the number of Query vars which can be used to access content via has increased, and so have the number of archive views. This has lead to increased complexity in the Taxonomy canonical code which has needlessly caused bugs.
</p>
<p>
What I'm proposing, is that it might be time to lay to rest the current <tt>if.. elseif.. elseif..</tt> style checks, It's not possible for 1 if branch to handle every single access point without duplicating another branch.
</p>
<p>
As a result, I've put a half-finished together alternate version of Canonical, It's based on tallying up which query vars have been used/accounted for and removing any duplicates.. It's certainly not the best, but it's fairing better with the unit tests so far.
</p>
<pre class="wiki">Unit Testing: http://unit-tests.trac.wordpress.org/browser/wp-testcase/test_includes_canonical.php
Before: FF.......FFFF..FFF.....F......FFFFFF.F....F.....FF....FF...
After: FF...........FFF..................FF..................F....
</pre><p>
It's a work in progress, but it's worth considering IMO.
</p>
<p>
Attaching a diff, and the full file (since the diff is going to be rather unreadable in some sections)
</p>
https://core.trac.wordpress.org/ticket/18385
https://core.trac.wordpress.org/ticket/18385Report#16858: Usage of HTTP_HOST in the administrationThu, 24 Mar 2011 11:09:47 GMT<p>
In some files like wp-admin/includes/class-wp-list-table.php (there are more files I think), some links are created by using the HTTP_HOST variable.
</p>
<p>
It's better to use the defined wordpress URL to create those links.
</p>
<p>
In our case, we have a wordpress running behind a Squid cache. When you check for HTTP_HOST you get the *real* HOST and not the one with the Squid server.
</p>
<p>
To bypass the problem, I added in the main config.php a line like this :
</p>
<pre class="wiki">$_SERVER['HTTP_HOST'] = 'www.my-visible-http-host.com';
</pre><p>
Without this setting and in our case, some links in the admin (next, previous page, re-ordering...) where pointing to the wrong server.
</p>
https://core.trac.wordpress.org/ticket/16858
https://core.trac.wordpress.org/ticket/16858Report#4280: Allow to constrain widgets being displayed on certain page types onlyWed, 25 Jun 2008 02:26:37 GMT<p>
The only real added value of the Sidebar Modules (SBM) plugin right now is the possibility to customize, which widgets are to be displayed on which pages (setting at Sidebar Modules/&lt;Module&gt;/Module's Options/Display On).
</p>
<p>
With this you are able to highly customize your sidebars even down to a single post's page.
It might also make sense to define sidebars per category a post is in.
</p>
<p>
However, it makes the most sense to have different sidebars on the Homepage, different static pages and posts pages.
</p>
https://core.trac.wordpress.org/ticket/4280
https://core.trac.wordpress.org/ticket/4280Report#39038: Add support for non-split shared terms to singular term capabilitiesSat, 03 Dec 2016 04:59:03 GMT<p>
As reported in <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/35614" title="enhancement: Cannot check capabilities on single taxonomy terms (closed: fixed)">#35614</a> by @kevinB, the <tt>edit_term</tt>, <tt>delete_term</tt> and <tt>assign_term</tt> singular capabilities only pass the <tt>term_id</tt> and not the <tt>taxonomy</tt>. For compat with installations where shared terms aren't split, we should specify the taxonomy, or trigger splitting.
</p>
<blockquote class="citation">
<p>
As implemented in 4.7 RC, these meta capability checks accept a term_id with no taxonomy specified. This is an issue for legacy installations that have term_id != term_taxonomy_id. Taxonomy determination is now slated to fall to WP_Term::get_instance(), which will try to disambiguate but may return WP_Error.
An obvious option would to require the additional taxonomy argument following term_id. This would cause a fourth item in the $args array passed into the 'map_meta_cap' filter - a break with tradition, but not a problem for API-compliant plugins in my view.
</p>
</blockquote>
https://core.trac.wordpress.org/ticket/39038
https://core.trac.wordpress.org/ticket/39038Report#38700: REST API: Cannot send an empty or no-op comment updateTue, 08 Nov 2016 22:36:02 GMT<p>
Sending a POST/PUT/PATCH request to <tt>/wp/v2/comments/:id</tt> fails if the update is empty, or if the comment data is the same as what's currently stored in the database.
</p>
<p>
This is due to a <a href="https://core.trac.wordpress.org/browser/trunk/src/wp-includes/comment.php?rev=39153&amp;marks=2204,2222#L2191">quirk</a> of <tt>wp_update_comment</tt>: it returns the number of rows updated by <tt>$wpdb-&gt;update</tt>, which may be zero. However, zero is <a href="https://core.trac.wordpress.org/browser/trunk/src/wp-includes/comment.php?rev=39153&amp;marks=2146,2151#L2128">also used</a> as the return value for an error condition. The API should differentiate between these two states.
</p>
<p>
For any other object type, sending a "null update" via the API is successful.
</p>
https://core.trac.wordpress.org/ticket/38700
https://core.trac.wordpress.org/ticket/38700Report