Stars,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
3,28821,Admin page registered with add_menu_page() allows access through wrong URls and hightlights wrong top level menu item,,Administration,3.9.1,normal,normal,,defect (bug),new,dev-feedback,2014-07-10T21:05:19Z,2019-06-04T19:26:10Z,"'''Steps to reproduce:'''
* Add a top level admin menu page (with the plugin provided below).
* Access the new top level admin menu via the menu item (bottom of menu)
* Try to access it via one of the following URLs
{{{
http://example.com/wp-admin/options-general.php?page=trac
http://example.com/wp-admin/tools.php?page=trac
http://example.com/wp-admin/admin.php?page=trac
http://example.com/wp-admin/edit-comments.php?page=trac
http://example.com/wp-admin/edit.php?post_type=page&page=trac
http://example.com/wp-admin/upload.php?page=trac
http://example.com/wp-admin/edit.php?page=trac
http://example.com/wp-admin/index.php?page=trac
... etc ...
// Sub menu items that have the same behavior
http://vagrant.local/wp/wp-admin/plugin-install.php?page=trac
http://vagrant.local/wp/wp-admin/themes.php?page=custom-header&page=trac
http://vagrant.local/wp/wp-admin/themes.php?post-new.php?post_type=page&page=trac
... etc ...
}}}
'''Bug description:''' Every of the above links will (falsely) work and bring you to the registered page. The top level menu item will be hightlighted while the sub menu item does not exist.
The following URls will work (with above bug) as well, but ''not'' highlight any menu item:
{{{
http://example.com/wp-admin/edit-tags.php?taxonomy=post_tag&page=trac
http://example.com/wp-admin/edit-tags.php?taxonomy=category&page=trac
}}}
I would not really consider this a ''""feature""''.
----
'''Test Plugin'''
{{{
Hello Trac!
}}}
and the js for my input fields, loading the color picker:
{{{
(function( $ ) {
// Add Color Picker to all inputs that have 'color-field' class
$(function() {
$('.color-field').each(function(){
$(this).wpColorPicker();
});
});
})( jQuery );
}}}
With WordPress 4.4.2 everything worked like a charm (I even did a reverse from 4.5 to 4.4.2 to be sure of it) and now with the 4.5 version, the color picker doesn't show up on my fields...
I didn't found anybody having the same issue.
Have a nice day
David THOMAS
",anou
1,35785,"Concatenating ""wp-post-new-reload=true"" with URL repeatedly",,Administration,,normal,normal,,defect (bug),new,,2016-02-09T18:33:12Z,2019-06-04T19:34:27Z,"Concatenating ""wp-post-new-reload=true"" with URL repeatedly when a meta box has required field and user click on ""Publish"" button without filling it properly:
http://screencast-o-matic.com/watch/cDnQFFhRcR
",codename065
,31593,Conflict of custom post type menu and add_utility_page,,Administration,4.1.1,normal,normal,,defect (bug),new,,2015-03-11T07:00:51Z,2023-11-13T18:56:31Z,"I installed a plugin that register_post_type with menu_position 80. Thereafter, I installed a plugin to add a menu by add_utility_page. Then the menu of menu_position 80 is disappeared.
Where I examined, I think there is a problem with the count up of `$_wp_last_utility_menu`, but is this correct specification?
This is the sample code.
{{{
function test_add_utility_page() {
add_utility_page(
'test_utility_page',
'test_utility_page',
'edit_posts',
'test_utility_page',
'__return_false'
);
}
add_action( 'admin_menu', 'test_add_utility_page' );
function test_register_post_type() {
register_post_type( 'test_post_type', array(
'labels' => array(
'name' => 'test_post_type',
),
'public' => true,
'menu_position' => 80,
) );
}
add_action( 'init', 'test_register_post_type' );
}}}",inc2734
11,26050,Continual Admin Page POST (HeartBeats?) Can Cause SQL Connection Issues,,Administration,3.6,normal,normal,,defect (bug),new,,2013-11-15T19:14:10Z,2019-06-04T19:24:36Z,"The admin pages (/wp-admin/widget.php, /wp-admin/index.php, etc..) will continually POST to admin-ajax.php ever 2.5-3 min. If multiple admin pages are open for long periods of time(ex. over night) the SQL Connections associated with the POSTs will begin to progressively have longer sleep times. I have seen MYSQL Connecitons Sleep upwards of 45 seconds from these POSTs.
This ultimately cause my Server/Account to be shutdown by my host due to the long sleep time taking up connections for no reason.
I wouldn't expect the Connections to progressively sleep longer. I was surprised to find that the pages were Sending POSTs even when they were not being used(before I knew about the heartbeat api).
Is this the expected experience/results? Should there be a sleep setting on these POSTs to stop after a given time frame? Or can all of these be rolled into 1 POST?
To Reproduce:
Open up the following in their own tabs: /wp-admin/widgets.php, /wp-admin/index.php, /wp-admin/theme.php, /wp-admin/theme-edit.php, /wp-admin/plugins.php, /wp-admin/post.php
Verify they are making post requests ever 2.5-3min, I use Tamper Data add-on for firefox, but fiddler or any other http collector will do.
In MYSQL watch the connections by using the command: show full processlist;
run the SQL command as soon as you see the POST occur in tamper data or fiddler. Notice the Sleep and time is 0 for the POST request. you might not see it in the process list at first since it is so quick.
Once POSTs are occuring ever few min and MySQL is setup to view processes/connections leave the pages open over night.
Then test again in the morning by viewing the processlist once you see a POST submitted. It usually easiest to see when post are submitted around the same time. You will notice the sleep time has increased and you will also notice that the response times for the POSTs have increased.
I reproduced this on twenty-thirteen theme with all plugins deactivated and using firefox.",optimized-marketing.com
11,26575,Dashboard widgets should be able to specify a min-width at which they span two columns,,Administration,3.8,normal,normal,,defect (bug),new,,2013-12-12T19:34:01Z,2019-06-04T19:24:39Z,"Some dashboard widgets [http://imtheirwebguy.com/dont-hit-update-just-yet-wp-3-8-overhauls-ui-breaks-dashboard-widgets/ don't do well in skinny columns]. Maybe we should let them specify a min-width. If breached, they could span two columns. Certainly would be useful for stats/traffic widgets.",markjaquith
,32655,Don't save screen options (table column) in post edit page and maybe other pages,,Administration,4.1,normal,normal,,defect (bug),new,,2015-06-15T23:53:53Z,2019-06-04T19:29:27Z,"I fixed it so...
wp-includes/user.php
row 364
{{{
if ( $user->has_prop( $option ) )
$result = $user->get( $option );
elseif ( $user->has_prop( $prefix . $option ) )
$result = $user->get( $prefix . $option );
else
$result = false;
----
//todo bag user options delete this
// if ( $user->has_prop( $prefix . $option ) ) // Blog specific
// $result = $user->get( $prefix . $option );
// elseif ( $user->has_prop( $option ) ) // User specific and cross-blog
// $result = $user->get( $option );
// else
// $result = false;
}}}
",Juriy
5,27162,Don't store admin messages in transients,,Administration,3.0,low,normal,,defect (bug),new,,2014-02-20T02:52:23Z,2019-06-04T19:42:03Z,"The settings errors API (`add_settings_error`/`get_settings_errors`) in core uses transients to store messages across requests. Unfortunately, this is a misuse of transients, as [http://journal.ryanmccue.info/296/youre-using-transients-wrong/ transients are not guaranteed to exist] for any length of time.
I've noticed this issue appear in two separate scenarios:
* When flushing the cache (after a deploy, e.g.): If you happen to flush the object cache between a `add_settings_error` call and the next page load, the message will disappear forever
* When disabling caching for testing purposes, the error will never be set/read (depending on how you disable it)
----
There's a few options I can see to fix this:
* Store them in options/usermeta: This keeps all the logic on the backend, but causes potentially costly writes to the database
* Store them in cookies (session data): This avoids the database write, but means we have to send extra data via the HTTP server, which might be filtering cookies (inbound and outbound). It also means we need to set a hash using a secret key to avoid allowing users to edit their cookies.",rmccue
,32097,Extra margin in `post_submit_meta_box()` on non-public post types,,Administration,4.2,normal,normal,,defect (bug),new,,2015-04-24T06:04:39Z,2019-06-04T19:28:37Z,"If you're editing a published or scheduled post in a post type registered with `public => false`, there's now some extra space above ""Status.""",dlh
,27543,Flyout submenu items can be hidden on Windows touch devices,,Administration,3.8,normal,normal,,defect (bug),new,,2014-03-27T06:08:29Z,2019-06-04T19:25:19Z,"Spin out of #26482, specifically comment 5 and the related screenshot.
The fly out submenus are broken on Surface. The patch in #26482 fixes that issue for iOS, but we should circle back and fix it for Surface.",samuelsidler
3,32233,Improve escaping in /wp-admin/includes/template.php,,Administration,4.3,normal,normal,,defect (bug),new,has-patch,2015-05-02T07:28:44Z,2019-06-04T19:28:46Z,"It was brought to my attention that various output in /wp-admin/includes/template.php is missing proper escaping. This includes titles for settings sections and fields, inline Thickbox JS, and various translatable strings (the translations for which might accidentally or intentionally include problematic content).
This patch adds various escaping functions where needed.
",McGuive7
2,31000,Multiple calls to settings_errors() result in duplicate display of notices,,Administration,3.9,normal,normal,,defect (bug),new,,2015-01-13T09:07:28Z,2019-06-04T19:27:33Z,"`settings_errors()` is called by default on options pages and numerous plugins and themes whose pages aren't under the options submenu will also call it.
Good, maybe even great, as so many have obviously adopted to using this.
The issue arises when, for instance, a plugin uses a call to `settings_errors()` hooked into `admin_notices` to display their notices across all pages. In that case, their message will be displayed twice on any pages also calling `settings_errors()`.
Now a plugin can check if they are on an options page and - knowing that the messages will be displayed there anyhow - forgo the call to `settings_errors( 'my-messages' )` there. But there is no way for a plugin to test if another theme/plugin outside of the options pages is also making the `settings_errors()` call.
I would suggest unsetting any messages which are displayed from within the settings_errors() call to avoid duplicate messages ever being shown.
",jrf
1,28273,Multisite sites without a path redirect to signup page,chriscct7,Administration,3.9,normal,normal,,defect (bug),reviewing,has-patch,2014-05-15T21:52:36Z,2019-06-04T19:25:38Z,"From https://wordpress.org/support/topic/after-update-to-39-one-sub-site-directs-to-wp-signupphpnew?replies=4&view=all
Pre 3.9, WordPress would treat an empty 'path' variable for the site as a /
As of 3.9, this is no longer the case, and a blank path will act as if the site does not exist.
It's a simple fix in the admin section, but this is a regression from 3.8",Ipstenu
2,35505,Navigation tabs styling inconsistencies,,Administration,4.4.1,normal,normal,,defect (bug),new,,2016-01-17T23:07:58Z,2019-06-04T19:33:58Z,"This is a follow-up to #34214.
Still an issue at max-screen width 600px (mobile).",Cybr
3,19085,Removing First Submenu Page in Admin Menu breaks URL for Menu Page,,Administration,3.1,normal,normal,,defect (bug),new,has-patch,2011-10-29T18:44:19Z,2019-06-04T19:22:46Z,"If you attempt to remove the Post Type Submenu Page in the Admin it breaks the Menu Page URL; it causes the Menu Page URL to be the same as the new first Submenu Page URL:
[[Image(http://screenshots.newclarity.net/skitched-20111029-142108.png)]]
Here is a simple class you can drop into the theme's `functions.php` file to experience this bug. This example is a minimum to trigger the error ''(I simplified the `register_post_type()` call so the example code would have fewer lines):''
{{{
'Test CPT',
'show_ui' => true,
));
}
static function parent_file( $parent_file ) {
remove_submenu_page( 'edit.php?post_type=test-cpt',
'edit.php?post_type=test-cpt' );
return $parent_file;
}
}
Trigger_Admin_Menu_Bug::on_load();
}}}
I'd provide a patch but the admin menu code is more complex than I can fully understand. Maybe the person who originally wrote it could fix it?
Note: Sadly, this is a blocker for one of my client projects. The client wants the admin menus simplified to reduce the conceptual load on their end users because we are adding many other submenu pages. Plus I've traced through the core WP code with a debugger for many hours looking for hooks that would allow me to get around this issue, but there simply are no hooks where it would be needed to hack a fix for this.",mikeschinkel
2,35339,Settings > Reading > Front Page Displays > Front Page and Posts Page Select Length of Text,,Administration,4.4,normal,normal,,defect (bug),new,,2016-01-07T00:59:05Z,2019-06-04T19:33:48Z,"When choosing the Front Page and Posts Page within Reading Settings, if you have really long post or page titles, these are not truncated, leading to a pretty bad looking Settings page.
Screenshot:
[[Image(http://slimbobwp.com/wp-content/uploads/2016/01/reading-settings-select-text-length.png)]]
This is further implicated if moving a column based admin as is discussed as having potential here: #16413
Expected output would be a limitation on the number of characters, what that limit should be is open for debate.",robertwhitis
4,35182,Site icon URLs don't respect SSL in admin,,Administration,4.4,normal,normal,,defect (bug),new,dev-feedback,2015-12-21T12:14:56Z,2019-06-04T19:33:29Z,"It appears that the following check in `wp_get_attachment_url()`:
{{{#!php
if ( is_ssl() && ! is_admin() && 'wp-login.php' !== $GLOBALS['pagenow'] ) {
$url = set_url_scheme( $url );
}
}}}
prevents `get_site_icon_url()` from using SSL for serving the icon links in the head, which results in non-HTTPS icon URLs on all admin pages:
[[Image(http://kaspars.net/wp-content/uploads/2015/12/site-icon-url-https.png)]]
",kasparsd
3,22623,"Some string tweaks - duplicity, context, mistake",,Administration,3.0,normal,normal,,defect (bug),new,has-patch,2012-11-28T20:56:41Z,2021-11-15T20:57:01Z,"1) String ""Path"" has a little different meaning for TinyMCE (HTML position) and Multisite list sites column (subdirectory address). Can we have a context?
2) When you click ""Deactivate"" action link bellow any site (in Multisite admin), site is marked as ""Deleted"" instead of ""Deactivated""? You can ""Activate"" deleted site? Strange...
3) We have strings ""No results found."" (twice) and ""No matches found."" One string would be better instead of three similar strings?
4) String ""Show header text with your image."" is not accurate. You can show header text without header image.",pavelevap
,35793,Something Wrong with UI in Administration,,Administration,,normal,normal,,defect (bug),new,reporter-feedback,2016-02-10T02:26:04Z,2019-06-04T19:34:33Z,"I'm using 4.4.2 now. And I think that there's something wrong with the UI in administration page.
Look at the sidebar in the image.
I have tried to remove the cache, it works. But it looks as the image shows working after viewing some pages.
",zjhzxhz
4,31691,Taxonomies registered to Attachments post type don't show in media modal if public = false but show_ui = true.,,Administration,4.1.1,normal,normal,,defect (bug),new,,2015-03-19T11:00:37Z,2019-06-04T19:28:16Z,"If you register a taxonomy for the `attachment` post type with the parameters:
{{{
public => false,
show_ui => true
}}}
If correctly shows the UI meta box when viewing the old-style edit media page.
However, if doesn't show fields in the edit media modal.
If you set `public` to true then it does show.
The media modal should check the `show_ui` value to determine wether taxonomy fields should be shown in the attachment media modal.",husobj
1,36933,TinyMCE failing when using ModPagespeed,,Administration,4.5.2,normal,normal,,defect (bug),new,,2016-05-24T15:07:41Z,2019-06-04T19:38:18Z,"TinyMCE Stops working correctly When using ModPagespeed module.
TypeError: wp.svgPainter is undefined
I needed to edit this file to fix the issue:
/wp-admin/js/svg-painter.js
",franmaWp
1,27514,Weird focus/color behavior on touch devices (like iOS),,Administration,,normal,normal,,defect (bug),new,,2014-03-25T16:50:00Z,2019-06-04T19:25:12Z,"Using an iOS device, when you scroll and click on the sidebar, you can get buggy color behavior in the sidebar. Apparently Android works too.
STR:
* Open the admin interface on iOS
* Touch to open the menu
* Touch to navigate to the Comments screen
* Touch to open the menu again
* Touch ""Posts"" to open the sub menu
At this point, I have three highlighted items: Dashboard, Posts, and Comments. In other scenarios, I can get sub menu items (like ""All Posts"") to be highlighted as well, mostly from scrolling up and down a bit.
Screenshot of the worst case scenario attached (four highlighted things).",samuelsidler
7,27776,WordPress API timeouts should be cached to avoid slowing down the admin,,Administration,3.3,normal,normal,,defect (bug),new,,2014-04-12T16:23:04Z,2019-06-04T19:25:25Z,"The admin does several calls to the WordPress API, such as from the wp_check_browser_version function. These calls don't cache timeouts, which means if the API is consistently timing out the admin is slow on every load as all of these calls must timeout before the page can load.
I propose we cache timeouts using transients, for a day.
This behavior has been present since at least 3.3 and is still the behavior on trunk.",brandon.wamboldt
1,36663,"Wordpress 4.5 Query Strings Replacing ""."" with ""_""",,Administration,4.5,normal,normal,,defect (bug),new,reporter-feedback,2016-04-25T17:07:37Z,2019-06-04T19:37:19Z,"As of Wordpress 4.5, any query strings using a ""."" will get converted to a ""_"". While i understand that PHP doesn't support a period in a query string value, there are instances where query strings with periods are used by JavaScript and need to be retained. For example, the Webtrends analytics platform uses periods in most of their analytics query string values. For example, they use ""wt.mc_id"", ""wt.z_mce"", and ""wt.dl"".
It appears that changes to 'wp-includes/canonical.php' in 4.5 cause these periods to be visually and functionally converted to underscores when the pages loads. Interestingly, this only happens on pages and not posts.
Can we get the functionality put back the way it was so that the periods are retained, as this update will break Webtrends functionality, as well as any site using JavaScript that expects a period in a query string value?",michael.bucklin
,27804,bug when updating after domain change settings,,Administration,3.8.2,normal,normal,,defect (bug),new,dev-feedback,2014-04-14T22:07:08Z,2019-06-04T19:25:28Z,"I have found the following bug that affects for sure wordpress 3.8.2 and the latest 3.8.3.
I have noticed this bug when I changed my domain settings:
WordPress Address (URL) and Site Address (URL) from a domain say www.mydomain.org to www.mydomain.com.
In the admin panel, when I get notified of new updates to be installed, installation of wordprewss, plugins and themes seems successful but is not performed.
After a bit of banging my head on the problem, for curiosity decided to switch back to www.mydomain.org and all updates were installed!
It's a bit annoying doing this procedure for every new updates.
Can anybody reproduce this?",robomotic
1,30300,setUserSetting js function only removes first unwanted character,,Administration,2.7,normal,normal,,defect (bug),new,dev-feedback,2014-11-09T17:08:15Z,2019-06-04T19:26:58Z,"The function comments of the function setUserSetting in `wp-includes/js/utils.js` says the following: ""Both name and value must be only ASCII letters, numbers or underscore (...)"". The function removes the unwanted characters with the js `replace` function, in the current code, it only removes the first occurrence of an unwanted character. This is solved by adding the `g` modifier to the replace regex. See the attached patch.
How to reproduce:
* Open your browsers console while you are logged in to your WordPress installation.
* Run the following command: `setUserSetting('test--', 'bad-value-')` (note that the - character is not allowed)
* The console will return `""test-""` (not `""test""` as expected).
* Run `getUserSetting('test-')`.
* The console returns `""badvalue-""` (not `""badvalue""` as expected).
* You may want to delete the setting by executing `deleteUserSetting('test-')`. ",TV productions
2,30855,wp_get_update_data() calls are not pluggable,,Administration,4.1,normal,normal,,defect (bug),new,,2014-12-28T21:06:10Z,2019-06-04T19:27:21Z,"Up to 4.1 I was able to disable core, themes and plugin updates and related HTTP traffic.
https://github.com/szepeviktor/wordpress-plugin-construction/blob/7b64d0ca4981b163b2f08adbe14a5b5238800bd8/mu-disable-updates/disable-updates.php
In 4.1 new wp_get_update_data() calls are much like hardcoded than pluggable, I wasn't able to disable them all. Especially not the ones in wp-admin/menu.php
https://github.com/WordPress/WordPress/blob/master/wp-admin/menu.php#L33-L34
https://github.com/WordPress/WordPress/blob/master/wp-admin/menu.php#L183-L187
Could you make wp_get_update_data() calls pluggable? Or give me an advise to disable them?
My current workaround is to fiddle with the transients:
https://github.com/szepeviktor/wordpress-plugin-construction/blob/master/mu-disable-updates/disable-updates.php#L98
Thank you!
",szepe.viktor
4,36527,Add a 'wp-' prefix to ALL admin classes to prevent CSS conflicts,,Administration,,normal,normal,,enhancement,new,,2016-04-14T12:37:34Z,2019-06-04T19:36:44Z,"Long story short, in any front end editors, which WP itself seems to be moving towards with the Customizer, there are lots of admin elements that are not prefixed and can quickly begin to conflict. Some examples are .button, .textarea, etc. I'd love to see all admin classes add a prefix of `.wp-`",mrpritchett
1,25616,Add a content length filter to wp_dashboard_recent_drafts(),,Administration,,normal,normal,,enhancement,new,dev-feedback,2013-10-17T01:41:34Z,2019-06-04T19:24:26Z,It would be nice to be able to change the length of the recent drafts content via a filter. The fixed value of 10 is too short for character count based users.,tenpura
4,37219,Admin menu with admin_url function,,Administration,,normal,normal,,enhancement,new,has-patch,2016-06-29T06:13:05Z,2019-06-04T19:39:25Z,I think that options in menu should have admin_url function. For example I want add custom param (?lang=de). I can use admin_url filter but this not work in menu items,sebastian.pisula
1,32507,Admin notices remove styling of lists,,Administration,4.2.2,normal,normal,,enhancement,new,,2015-05-27T15:50:35Z,2019-06-04T19:29:00Z,"Create an admin notice which contains an unordered or odered list and you will see that the list has no bullets or numbers.
This is because the notice inherit `list-style-type:none`. ",sciamannikoo
2,26960,Audit extraneous HTML/CSS for the admin menu,,Administration,,low,normal,,enhancement,new,has-patch,2014-01-30T05:56:16Z,2019-06-04T19:41:55Z,"In working on #18380, I've noticed quite a bit of cruft that has built up over time, some of it directly related to the split between colors and structure. For example, the .wp-menu-arrow is no longer visible in the 3.8 redesign, but the HTML and CSS remain. Once #18380 and #26669 are complete, we should take a closer look at this.",helen
,17704,Automatically enqueue necessary scripts when custom meta boxes are used,,Administration,,normal,normal,,enhancement,new,needs-refresh,2011-06-06T05:53:43Z,2019-06-04T19:22:32Z,"Right now if you add_meta_box() to a custom page, like using add_submenu_page() and then calling do_meta_boxes(), the screen options and post box JS don't work automagically. They should.",mitchoyoshitaka
3,19691,Cannot modify admin messages for /wp-admin/edit.php,,Administration,3.3,normal,normal,,enhancement,new,dev-feedback,2011-12-30T02:10:01Z,2019-06-04T19:22:50Z,"The admin console messages output on line `264` of WordPress 3.3's file `/wp-admin/edit.php` are not filterable. This causes problems when added row actions need to HTTP GET from to WordPress to modify a post and then display an appropriate message complete with a revert link ''(like the ""Trash"" link does.)''
An example use-case could be for a custom post type used for both quotes and invoices where a row action might be ''""Convert Quote to Invoice""'' where you'd want a message and link displayed at the top of the admin after similar to this:
- ''Quote #{$post_id} converted to Invoice. __Revert__''
Currently the only way to accomplish this is to pick hooks before and after the messages are output and use PHP's output buffering; clearly not a ''""best practice""'' approach.
In order to address this I'm proposing an '''`'admin_messages'`''' filter hook to run just before the messages are output:
{{{
$messages = apply_filters( 'admin_messages', $messages );
}}}
However, since messages are output in numerous locations in the WordPress admin it seemed best to add the hook in every location where messages are output, which is what my patch does. Thus a hook can look at `$pagenow` or `get_current_screen()` to decide it is needs to do anything.
Also while searching for places in the admin code that echo messages I found `$messages` are sometimes an array of HTML where the entire array is echoed and other times the $messages are an array with an index passed via `$_GET` and only one message will be displayed. For those cases I created another hook '''`'admin_message'`''' ''(note that this hook name is singular)'':
{{{
$message = apply_filters( 'admin_message', $message, $messages, $_GET['message'] );
}}}
I really only found a specific need for `/wp-admin/edit.php` today, but it seemed that it would be better for consistency if all messages were made hook filterable. That's why I created a larger patch when all my use-case needs is one new line.
Looking forward to your feedback.
",mikeschinkel
2,32815,Color schemes silently disabled in source checkout of core,,Administration,4.3,normal,normal,,enhancement,new,,2015-06-28T13:52:08Z,2019-06-04T19:30:04Z,"When using development version of WordPress the admin color scheme feature is silently disabled. There is a check in code for -src in version.
This is highly confusing from developer experience perspective.
It would make sense to me if there were:
- message in profile, informing that color schemes are being disabled
- short explanation inline for the reasons check is being made",Rarst
3,37578,Dashboard Recent Activity widget - new filters to manipulate output,,Administration,4.6,normal,normal,,enhancement,new,has-patch,2016-08-05T01:41:43Z,2021-03-23T05:25:04Z,"It is currently not possible to manipulate the recent post activity dashboard widget. Output is built using `wp_dashboard_recent_posts()`. 2 filters could be introduced for the parameters for future and recent posts.
This would allow easy interaction with the parameters array, for instance increasing the amount of posts shown, changing order, post status, CSS ID etc - would definitely make it more useful!
I realise that there is a filter `dashboard_recent_posts_query_args` inside the`wp_dashboard_recent_posts()` function (used to build the queries, useful for switching post type etc), but there is currently no way to interact with the calls to this function.",Jonnyauk
,30177,Eliminate deprecated pointers,,Administration,,normal,normal,,enhancement,new,dev-feedback,2014-10-29T17:19:33Z,2019-06-04T19:26:56Z,"While working on #30158 @nacin suggested that we eliminate the now irrelevant pointers (anything before 3.9). Initially I followed the existing convention: blanking, but leaving, the internal pointer method.
@nacin also mentioned that we should eventually removing those blanked methods and that they were only left behind because we hadn't considered the full ramifications of straight removing them. I spent a few brain cycles on exactly that these past several hours and below are my findings.
**Option The First:**
We can completely remove these methods with no negative impact whatsoever. Reason: The pointer class is Final and cannot be extended (so there are no inheritance concerns) and these static methods themselves are completely useless in isolation. There is no reasonable explanation for a person ever calling these methods directly, and calling remove_action() on them does not depend on their existence, either.
**Option The Second:**
We remove the methods and register a new `get_deprecated_pointers()` method to be used in tandem with a `__callStatic()` magic method in order to inform the fringiest fringe-case developer that they've done something abhorrently wrong (in the most polite way possible).
My vote is for Option 1 because I can't fathom a world in which someone would have a productive reason to statically call one of these pointer methods in isolation. Option 2 gives us a new list to maintain fairly unnecessarily and succeeds in adding more lines of code than it removes.
I've provided patches for each option so all that is left is for someone else to weigh in with their opinions.
@jjj likes option 2
@aaroncampbell likes option 1",rzen
1,14097,Idea for placeholder text,,Administration,,normal,normal,,enhancement,new,,2010-06-26T06:28:25Z,2019-06-04T19:21:56Z,"Placeholder text has a fatal flaw, in my mind: once the field is focused, that placeholder text is gone. This can be confusing, especially if you tabbed into that field or it was selected by default. You can actually use placeholder text instead of labels, for a minimalistic form layout, but only if you correct this flaw.
So here's a potential solution:
http://txfx.net/files/wordpress/labels/
It uses HTML 5's {{{placeholder}}} attribute (newest Safari and Chrome support it), with a jQuery plugin to handle that support for other browsers.
Thoughts?",markjaquith
4,35133,Make the admin menu more flexible in width,,Administration,4.4,normal,normal,,enhancement,new,,2015-12-17T14:06:31Z,2019-06-04T19:33:21Z,"Two years ago the admin menu was increased by width by 10 pixels, #25918. More and more strings gets translated, which causes the menu to be too small:
[[Image(https://dl.dropboxusercontent.com/u/23348/WP/Schermafbeelding%202015-12-17%20om%2014.33.42.png)]]
I would suggest to make the menu variable in width, so it can take the space needed for translated menu items.",ChantalC
1,29312,No recommended nonce refresh functionality in Heartbeat.,,Administration,3.6,normal,normal,,enhancement,new,dev-feedback,2014-08-22T07:49:19Z,2019-06-04T19:26:31Z,"Oddly enough it seems there isn't an obvious way to refresh nonces that may be needed on the page after heartbeat-api login dialog. For example, go to wordpress plugins listing page, notice the activate, deactivate links all have a nonce part in the request.
In a second tab, log out of the site, and go back to plugin listing page.
After awhile, the page realizes it's not logged in, and pops up a log in screen. Log in, and click an ""activate"" or ""deactivate"" button.
Notice it gives the nonce-failure message, ""are you sure you want to do this""? Because the previous session's nonces don't work. Why does Wordpress not know to refresh these nonces? I thought new nonces would be sent back as a heartbeat-ajax, but it looks like there isn't an ajax request with the login screen.
It seems $(document).on('heartbeat-nonces-expired') can be used to detect when this situation happens, but it happens many times after login successful, is not just triggered once.",programmin
1,32194,Post Locked Notification Dialog is not Responsive,,Administration,3.6,normal,normal,,enhancement,new,has-patch,2015-04-29T21:38:27Z,2019-06-04T19:28:44Z,"When notification dialogs were introduced in r23661, they were only designed for larger screens.",iandunn
2,27996,Show/Hide Postbox doesn't work if dynamically added,,Administration,3.9,normal,normal,,enhancement,new,has-patch,2014-04-23T17:23:23Z,2019-06-04T19:25:33Z,"If you have a plugin which adds a metabox to the page at runtime, the ""handlediv"" button which shows/hides the contents of that metabox doesn't work.
To fix it, the code (on line 12 of postbox.js and also in postbox.min.js) should change from:
{{{
$('.postbox h3, .postbox .handlediv').bind('click.postboxes', function() {
}}}
To:
{{{
$(document).on('click.postboxes', '.postbox h3, .postbox .handlediv', function() {
}}}
P.S. I have tried to submit a patch in the past but my entire computer had a meltdown and scattered files from here to Mordor to the Shire because I have no idea how to do it properly. This after spending a couple weeks reading up on how to it properly. So, unfortunately, I am not able to submit a patch due to the incredibly difficult-for-me-to-understand SVN system. My Apologies.",johnstonphilip
1,34799,Tell admin-post.php to check for $_REQUEST['action2'] ?,,Administration,4.4,normal,normal,,enhancement,new,,2015-11-27T10:05:55Z,2019-06-04T19:33:11Z,"In plugin development, we can handle POST requests through the `admin-post.php` file. This file is looking after an input with a name of `action` so we can register a custom hook to handle the POST request.
After looking at the WP_List_Table, the bulk ""select"" '''top''' tag has a name attribute of `action`. So for custom development, the form where the list table fit can easily point to `admin-post.php` and we can handle the bulk POST request through a custom hook and it works.
But here is the issue, if users use the ""select"" '''bottom''' tag for their bulk action, it won't work because the bottom select tag has a name attribute of `action2`. So if a POST request to `admin-post.php`, we can no longer listen to a custom hook to manipulate the request and its data.
So I'm asking if it will be ok to update the `admin-post.php` file to check after a `$_REQUEST['action2']` as well?",jlambe
5,31006,Use classes instead of setting and directly animating background colors in JS,,Administration,,normal,minor,,enhancement,new,,2015-01-14T05:32:10Z,2019-06-04T19:27:37Z,"Directly setting hex values in JS doesn't tell us much about what the color is being used for, whereas setting a class name is much more semantic. Also, jQuery UI can animate color changes when using addClass/removeClass/toggleClass/switchClass - no need to use .animate() directly and do things like getting background colors of surrounding elements.
This is very tightly related to #25060 and blocks it. I am working on it.",helen
1,36426,WP Admin memory limit not increasing to base limit by default,,Administration,4.6,normal,normal,,enhancement,new,has-patch,2016-04-06T12:54:54Z,2019-06-04T19:35:53Z,"We have 2 constants that can be set in wp-config.php (and by using filters, afaik), for example:
{{{#!php
define( 'WP_MEMORY_LIMIT', '512M' ); // increases WP base (front-end) limit
define( 'WP_MAX_MEMORY_LIMIT', '512M'); // increases WP admin (back-end) limit
}}}
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.
What I mean in coding terms:
{{{
if(!isset(WP_MAX_MEMORY_LIMIT) && isset(WP_MEMORY_LIMIT)){
if(WP_MEMORY_LIMIT>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);
}
}
}}}
All these values can be checked with the Bulletproof Security plugin, under BPS Security -> System Info.
Side note: imho WP_MAX_MEMORY_LIMIT should be renamed to something like WP_ADMIN_MEMORY_LIMIT, but that's another issue.
",eclare
2,21171,jQuery Events for Metaboxes,,Administration,,normal,minor,,enhancement,new,,2012-07-05T21:35:47Z,2019-06-04T19:23:09Z,"Currently, when a plugin adds a metabox with complex objects (like TinyMCE, Maps, CodeMirror etc) care must be taken to refresh the objects when the elements are moved (including hidden/shown).
After some digging, I've found that this seems to works in most cases:
{{{
var context = ""#custom_meta_box_id"";
$( '#adv-settings' ).on( 'click', context + '-hide, ', refresh );
$( context ).on( 'click', '.hndle, .handlediv', refresh );
$('.meta-box-sortables').bind( ""sortstop"", refresh );
}}}
which isn't terrible, but seems fragile if core changes in the future, and there should just be a better way :-)
Two ideas from dev chat are triggering custom events or the (coming soon) ""js actions"" which would be more robust (like php actions).",WraithKenny
1,35205,Add additional hooks to the 'attachment-info' template to customise output,,Administration,4.4.2,normal,normal,,feature request,new,,2015-12-22T23:05:31Z,2019-06-04T19:33:34Z,"Hey guys,
I've been working on several sites for clients and one thing that keeps coming up is the need to customise the 'attachment info' screen when viewing media items in the fancy media modal.
[[Image(http://drive.google.com/uc?export=view&id=0BxFkQxv15MkfUWJNUnBMb3gxa00)]]
You can see that the screen shows the attachment info at the top, followed additional info below (for example the file name, file type, uploaded date at the top followed by editable fields below such as title, caption etc)
All of this is defined in `/wp-includes/media-template.php` and pretty much hard coded, looking for the upload type and then displaying fields.
There is already an [https://codex.wordpress.org/Plugin_API/Filter_Reference/attachment_fields_to_edit 'attachment_fields_to_edit'] action but what that does is allow you at add fields to the ''bottom of the existing fields'' as such.
[[Image(http://drive.google.com/uc?export=view&id=0BxFkQxv15MkfSUVhby1pQm9Mc3M)]]
I would propose a few new hooks be created inside `media-template.php` starting from line 338. This is the start of the `attachment-info` panel and it's here a few actions would be helpful.
For example a client wanted to see all of their different image sizes in the attachment screen so they could easily copy them. Currently this can only be done by editing core directly (which is a terrible idea).
[[Image(http://drive.google.com/uc?id=0BxFkQxv15Mkfd2dwdXRkMm93SHM)]]
Since the media modal is built dynamically with Ajax if we add hooks here developers will be able to access the media object (which contains the URL, title, id and other info). So the flexibility will be really neat.
I'm more than happy to look into this but I'd be really keep to get feedback from you guys just in case I am missing something critical (because I don't know why there is a lack of hooks here for development)
I'm thinking of adding just basic hooks like
```do_action('media-attachment-info-start')```
Cheers
",simonrcodrington
2,28324,Add primary and secondary color definitions to admin color schemes and add function to retrieve color scheme info,,Administration,3.8,normal,normal,,feature request,new,reporter-feedback,2014-05-21T14:31:36Z,2019-06-04T19:25:50Z,"I'd like to be able to implement a user's selected admin color scheme into my plugin admin UI design but, at this point in time, using wp_admin_css_color() to register a color scheme only asks for an array of colors and then depends on a stylesheet to use said colors so there's no way for me to, at the very least, detect a primary and secondary color to use in my design.
From what I can tell, most color schemes have what they consider to be the primary and secondary color, and they use those colors for primary buttons and admin menu links and such, but there's no way for someone else to detect those color values.
It would also be nice if there was a function to retrieve the color scheme info. Perhaps something like this:
{{{
function get_user_admin_color() {
global $_wp_admin_css_colors;
if ( ( $user_admin_color = get_user_option( 'admin_color' ) )
&& isset( $_wp_admin_css_colors[ $user_admin_color ] ) ) {
return $_wp_admin_css_colors[ $user_admin_color ];
}
return false;
}
}}}
But the big request is changes to the wp_admin_css_color() function so, at the very least, a primary and secondary color can be defined and stored in $_wp_admin_css_colors. Perhaps something like this?
{{{
function wp_admin_css_color( $key, $name, $url, $colors = array(), $icons = array(), $primary_color = NULL, $secondary_color = NULL ) {
global $_wp_admin_css_colors;
// If a primary color is not defined, use first color from $colors array
if ( ! isset( $primary_color ) && count( $colors ) >= 1 )
$primary_color = $colors[0];
// If a secondary color is not defined, use second color from $colors array
if ( ! isset( $secondary_color ) && count( $colors ) >= 2 )
$secondary_color = $colors[1];
if ( ! isset( $_wp_admin_css_colors ) )
$_wp_admin_css_colors = array();
$_wp_admin_css_colors[$key] = (object) array(
'name' => $name,
'url' => $url,
'primary_color' => $primary_color,
'secondary_color => $secondary_color,
'colors' => $colors,
'icon_colors' => $icons,
);
}
}}}
",bamadesigner
1,29386,Autosave message should disappear when the next autosave happens,,Autosave,,normal,normal,,defect (bug),new,has-patch,2014-08-26T21:17:58Z,2019-06-04T19:26:37Z,"An autosave overwrites the previous autosave, so the message is no longer relevant. It will just display the same content as the current editor.",iseulde
4,32912,Autosaves are generated every other preview if post is unchanged,,Autosave,4.3,normal,normal,,defect (bug),new,,2015-07-07T22:30:03Z,2019-06-04T19:30:34Z,"I'm trying to work with revisioned post meta and noticed an interesting quirk in core today that I'd categorize as ""unexpected behavior."" While this probably wouldn't come up very often, I think it can cause a bit of a headache when it does.
To replicate:
1. Create a new post, give it a title, and publish it.
2. Once the screen reloads, click ""Preview Changes"". Don't make any changes to the post.
* In loading the preview, WordPress created an autosave of this post
3. Return to the WordPress Admin and click ""Preview Changes"" again without making any changes.
* In loading the preview, WordPress deleted the autosave it created in step 2
Every other preview will add an autosave and every other one will delete it. If at any point you do change the post, the autosave won't get deleted.
In the code, what appears to be happening is, `wp_create_post_autosave()` checks to see if an autosave exists. If it does, the code checks to see if the autosave is different from the post, and if so, it deletes the autosave. If an autosave doesn't exist, the function then creates one (using `_wp_put_post_revision()`) -- *without checking to see if the post has changed*. It seems to me that there should be an intermediate function, e.g. `_wp_maybe_put_post_revision()`, which would check to see if the post has changed, and only then call `_wp_put_post_revision()`.
This probably isn't a big deal, because it requires someone to attempt to preview (twice) without making changes. However, it's still a bug and it might come up in other ways.
Verified in trunk and 4.2.2.",mboynes
1,36479,Improve autosave in the browser,,Autosave,,normal,normal,,defect (bug),new,,2016-04-11T14:55:10Z,2019-06-04T19:36:24Z,"Several improvements that can make this quite better:
- Try to better detect when a restore may be needed.
- Make in-browser autosaves a ""higher priority"" than remote/server autosaves. The in-browser content is fresher. If both are available, prefer/emphasis the in-browser data.
- Add some subtle, always present UI for restoring a post from in-browser autosave. This should (probably) be only available before the users start typing.
- Consider adding the in-browser data to the revisions or display a preview/diff with the current data in some other way.
",azaozz
6,11049,Page Preview does not autosave page template,nacin*,Autosave,2.8.4,normal,normal,,defect (bug),accepted,dev-feedback,2009-10-30T21:19:34Z,2019-06-04T19:21:39Z,"When editing a published page, if you change the page template and then click Preview, the preview does not show the new template choice. ",janeforshort
,24552,Taking over a locked post does not always load the most recent revision,,Autosave,3.6,normal,major,,defect (bug),new,,2013-06-10T10:33:44Z,2019-06-04T19:24:06Z,"Steps to reproduce:
1. Open up a post for editing, and make some changes to it. Do not save the changes.
2. Open up the same post for editing using a different user account (in a different browser![1]) and click the 'Take over' button when you get the post lock modal.
3. Note that the post that loads is not the most recent autosave of the post, but equally importantly you are not shown the message stating this.
4. Reload the editing screen and you'll be presented with the ""There is an autosave of this post that is more recent than the version below."" message.
Related: #23697
----
![1] The simplest way to do this is to use an Incognito browser window (and [http://wordpress.org/plugins/user-switching/ User Switching]) so you can be logged in as two accounts simultaneously. ",johnbillion
1,24865,Allow plugins to hook into autosave and include field data from the autosave with the package.,,Autosave,,normal,normal,,enhancement,new,needs-refresh,2013-07-28T22:55:43Z,2019-06-04T19:24:10Z,"== Why? ==
Autosaves currently only save ""blessed"" data (post_title and post_description?). Plugin authors may want to add their own data in the autosave package so if they hook into `save_post` they can handle/save that data as needed.
== How this works ==
Metaboxes are generated with an id already on the page. So what we do is add an extra parameter to the `add_meta_box()` function (`do_autosave` bool) so that when a plugin uses add_meta_box() they can set that flag.
We set a javascript object that contains the ids of the metaboxes that have had that flag set and then `wp.autosave.getPostData` in `autosave.js` has been modified to loop through the metaboxes matching those ids and return the fields in those metaboxes as an object attached to the data param.
Added a new jquery plugin (serializefullarray) as it will handle nested pseudo arrays set as the ""name"" values in inputs (i.e. somedata[one][two]) and create proper objects from them. ",nerrad
1,22601,Make post content autosave work more generically,,Autosave,,normal,normal,,enhancement,new,,2012-11-27T04:00:31Z,2019-06-04T19:23:41Z,"The JS for autosave/AYS looks for the contents of `#post #content`. While we should fix the other JS issue related to targeting `#content` in #22600, it seems that autosave/AYS should be looking for the textarea (or whatever type of input) with the name of content instead, since having that data in the form will save to the post content. That way, if somebody does choose to use a different ID but the right input name, the autosave benefits will kick in.
Discovered while working on #22491.",helen
4,17376,Multisite Subfolders and bunk /wp-admin areas,,Bootstrap/Load,,normal,normal,,defect (bug),new,needs-unit-tests,2011-05-11T15:07:38Z,2021-06-24T18:50:17Z,"On a multisite installation with subfolders, navigating to:
www.mysite.com/i-dont-exist/wp-admin
loads a dashboard and maintains the i-dont-exist in the url. That part exists if i navigate to themes and/or plugin pages. However, I'm actually altering the base site.
This can be quite confusing if someone makes a typo in a sitename and they end up changing the base site (like happened to us) :(",MadtownLems
2,23088,"Multisite, Subdomains and www",,Bootstrap/Load,3.0,normal,normal,,defect (bug),new,has-patch,2012-12-30T20:05:33Z,2019-06-04T19:23:47Z,"I installed a WordPress Multisite network (in subdomain mode) on Zend's PHPCloud.com.
Zend does not provide an IP address, recommending a CNAME instead. CNAME records are not allowed on the root of a domain, so they recommend using the www subdomain, with a redirect from the root domain to www.
This site can NEVER be accessed on the naked domain; it will always be accessed via the www subdomain.
So, I setup wildcard DNS for *.mydomain.com, then created a network on www.mydomain.com. Then, I went to a non-existant subdomain on my network, nonexistant.mydomain.com, and WordPress redirected to www.mydomain.com/wp-signup.php?new=nonexistantwwwmydomaincom.
The correct behavior is to redirect to www.mydomain.com/wp-signup.php?new=nonexistant
The fix for this is in wp-includes/ms-settings.php, replace line 89 with:
{{{
$site_domain = preg_replace( '|^www\.|', '', $current_site->domain );
$destination = 'http://' . $current_site->domain . $current_site->path . 'wp-signup.php?new=' . str_replace( '.' . $site_domain, '', $domain );
}}}
Also, on the registration page at the bottom it says:
""The site you were looking for, http://nonexistant.www.mydomain.com/ does not exist, but you can create it now!""
The fix is in ms-blogs.php, line 53:
{{{
$url = preg_replace( '|^([^\.]+://)(?:www\.)?|', '$1' . $blogname . '.', $url );
}}}",jkhoffman
2,19487,Remove useless calls to set_time_limit(),westi,Bootstrap/Load,1.5,normal,normal,,defect (bug),new,has-patch,2011-12-09T14:53:08Z,2019-06-04T19:22:47Z,"Calls to set_time_limit() were introduced in http://core.trac.wordpress.org/changeset/1812 and have remained in core ever since. The call occurs in code that makes network connections and is designed to allow time for the network calls to complete before the script execution stops.
But set_time_limit() won't take network time into account, so it actually will not do what it seems designed to do. From php docs:
The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running.
Further, calls to set_time_limit() can cause unexpected results in code that relies on any functions that call set_time_limit(). For example, if some code (in a cron job, say) sets the time limit to 0 (unlimited) because it knows it needs some time complete, then a subsequent call to a function that resets the time limit will halt the long-running execution once the new limit has been reached. Also from php docs:
When called, set_time_limit() restarts the timeout counter from zero. In other words, if the timeout is the default 30 seconds, and 25 seconds into script execution a call such as set_time_limit(20) is made, the script will run for a total of 45 seconds before timing out.
Since the call to set_time_limit() does not here do anything useful, it should be removed.",dllh
7,28364,WordPress Entry Points (wp-load.php occurrences),,Bootstrap/Load,3.9.1,normal,normal,,defect (bug),new,,2014-05-26T12:16:56Z,2019-06-04T19:25:53Z,"I was looking for entry point by searching for wp-load.php for plugin refactoring. I mean conditionally use require().
1. There are easy to identify entry points like admin-ajax.php but there are no defines e.g in async-upload.php, wp-loging.php or wp-comments-post.php
2. wp-trackback.php uses a strange way to detect the core `if (empty($wp))`
3. xmlrpc.php uses alone `include()` all others `require()`
4. How to distinguish between admin.php and admin-post.php?
=== Proposal ===
- There should be a uniform way requiring wp-load.
- All entry point should be distinguished by '''different''' defines
== List of entry points and ways to detect them ==
1. frontend: wp-blog-header.php:12 {{{!is_admin()}}}
1. admin GET request: wp-admin/admin.php:30 {{{is_admin()}}}
1. admin POST request: wp-admin/admin-post.php:15 {{{is_admin()}}}
1. admin upload: wp-admin/async-upload.php:16 {{{@$_SERVER['SCRIPT_FILENAME'] === ABSPATH . 'wp-admin/async-upload.php'}}}
1. AJAX call: wp-admin/admin-ajax.php:20 {{{defined('DOING_AJAX') && DOING_AJAX}}}
1. WordPress cron webserver/CLI: wp-cron.php:26 {{{defined('DOING_CRON') && DOING_CRON}}} {{{php_sapi_name() === 'cli'}}}
1. XML-RPC protocol: xmlrpc.php:29 {{{defined('XMLRPC_REQUEST') && XMLRPC_REQUEST}}}
=== Frontend low priority ===
1. wp-comments-post.php:16 {{{@$_SERVER['SCRIPT_FILENAME'] === ABSPATH . 'wp-comments-post.php'}}}
1. wp-trackback.php:12 {{{1 === get_query_var('tb')}}}
=== Dashboard low priority ===
1. wp-login.php:12
1. wp-signup.php:4
1. wp-activate.php:12
1. wp-mail.php:11
=== Exclude from profiling ===
1. wp-links-opml.php:15
1. wp-includes/ms-files.php:12
1. wp-includes/js/tinymce/wp-mce-help.php:9
1. wp-admin/install.php:36
1. wp-admin/install-helper.php:39
1. wp-admin/upgrade.php:18
1. wp-admin/maint/repair.php:10
1. wp-admin/moderation.php:10
Total: '''21 entry points''' as of version 3.9.1
[https://github.com/szepeviktor/WPHW/blob/master/wp-entry-points.md from WPHW]
",szepe.viktor
,13554,WordPress MU canonical link redirect failure,markjaquith,Bootstrap/Load,2.9.2,normal,normal,,defect (bug),reopened,,2010-05-26T16:30:37Z,2019-11-19T17:04:05Z,"This problem manifests itself in Wordpress '''MU''' 2.9.2, but '''not''' in Wordpress 2.9.2.
In the MU install where blogs are subdirectories, canonical redirects work correctly for the subdirectory blogs, but not for pages on the root blog.
For example, [http://silverwarethief.com/essays/] is a sub-blog in the wordpress MU install. If you alter that link to [http://www.silverwarethief.com/essays/] wordpress MU will correctly redirect the browser to the canonical url.
However, this does not work with pages on the root blog. [http://silverwarethief.com/about/] is a page on the root blog. If you go to that link, you will correctly find yourself at the ""About"" page. If you then alter the link to [http://www.silverwarethief.com/about/] you will be redirected to the main page of the root blog, not the ""About"" page.
I have seen this behavior manifested on more than one MU install.
",rundi
18,22325,Abstract GPCS away from the superglobals,,Bootstrap/Load,,normal,normal,,enhancement,new,dev-feedback,2012-10-30T21:15:41Z,2019-06-04T19:23:39Z,"As discussed at #wpcs, it looks like we want to move away from directly using the GPCS superglobals. This gives us a way to handle slashing backwards compatibility moving forward.
This is still a heap of versions away, but this is a way to keep any notes central.",rmccue
4,13874,"Add package argument to ""_deprecated_function"" function",chriscct7,Bootstrap/Load,,normal,normal,,enhancement,assigned,has-patch,2010-06-13T23:48:37Z,2019-06-04T19:21:54Z,"Got to thinking it would be nice if plugins could use the _deprecated_ API by passing a ""$package"" argument to separate themselves from WP core, and so this patch was born.
",johnjamesjacoby
5,26806,Add support for custom SHORTINIT handlers,,Bootstrap/Load,3.8,normal,normal,,enhancement,new,dev-feedback,2014-01-10T14:30:43Z,2019-06-04T19:24:57Z,"I'm building ajax caching for a plugin and need a handler to '''conditionally''' determine whether to continue loading WP (based on whether a cached version exists).
Example handler file: https://gist.github.com/mgibbs189/8345521
The `SHORTINIT` constant along with `wp-load.php` isn't an option because it forces WP to exit early.
Drop-ins like advanced-cache.php, object-cache.php, or db.php won't work because only 1 plugin at a time can use them. I need for my caching to work in combination with these other plugins (e.g. W3 Total Cache)",mgibbs189
2,34189,Add warning about changing $table_prefix for existing database,,Bootstrap/Load,4.4,normal,normal,,enhancement,new,has-patch,2015-10-07T10:50:06Z,2019-06-04T19:32:46Z,"When changing the $table_prefix for an existing database, it is not sufficient to rename the tables. You also have to change several values in at least two tables. In my case, changing prefix from ""wp_"" to ""bbj_wp_"" this involved at least the following SQL:
UPDATE bbj_wp_options
SET option_name = 'bbj_wp_user_roles'
WHERE option_name = 'wp_user_roles';
UPDATE bbj_wp_usermeta
SET meta_key = 'bbj_wp_user_level'
WHERE meta_key = 'wp_user_level';
UPDATE bbj_wp_usermeta
SET meta_key = 'bbj_wp_capabilities'
WHERE meta_key = 'wp_capabilities';
The attached patch adds a warning to the generated wp-config.php file about this. There is much room for improvement here, including giving detailed information on what needs to be changed or even re-writingthe particular misfeature that stores tables names in other tables. The patch is intended as a stop-gap 'til such improvements are made. Hopefully this will prevent others from chasing down the same wildly unexpected behavior should they decide to change $table_prefix
",bjerke-johannessen
3,21521,Audit use of set_time_limit(),,Bootstrap/Load,3.4.1,normal,normal,,enhancement,new,dev-feedback,2012-08-08T17:28:21Z,2019-06-04T19:23:14Z,Core calls this half a dozen times. The call in wp_get_http() interferes with unit tests. Unit tests will terminate 60 seconds after wp_get_http() is called. Let's justify each use of set_time_limit() and remove what we can.,ryan
,33034,Refactor SCRIPT_FILENAME ending with php.cgi check in load.php,,Bootstrap/Load,4.3,normal,normal,,enhancement,new,,2015-07-18T13:40:53Z,2019-06-04T19:31:23Z,I found the original check pretty confusing :),wildpeat
5,31839,Setting error reporting level for wp_debug_mode,,Bootstrap/Load,4.1.1,normal,normal,,enhancement,new,dev-feedback,2015-04-01T16:25:34Z,2023-12-12T20:27:56Z,"Since PHP 5.4.0 `E_STRICT` errors appear as part of `E_ALL` and headers cannot be sent sometimes - stuff that can lead to a whole set of problems. For me, they are useless and annoying - but for others they can be useful.
I just want the possibility to set the `error_reporting` level used in `wp_debug_mode()`. I have applied a small patch to `load.php` as shown below.
I have defined a `WP_DEBUG_LEVEL` constant in `wp-config.php` like so: `define( 'WP_DEBUG_LEVEL', E_ALL & ~E_STRICT );` because I do not want to see the `E_STRICT` warnings.
Afterwards I modified the `wp_debug_mode` function like so:
{{{
#!php
function wp_debug_mode() {
if ( WP_DEBUG ) {
if( !defined( WP_DEBUG_LEVEL ) )
define( 'WP_DEBUG_LEVEL' , E_ALL) ;
error_reporting( WP_DEBUG_LEVEL );
if ( WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 1 );
elseif ( null !== WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 0 );
if ( WP_DEBUG_LOG ) {
ini_set( 'log_errors', 1 );
ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );
}
} else {
error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
}
if ( defined( 'XMLRPC_REQUEST' ) )
ini_set( 'display_errors', 0 );
}
}}}
Here's the [https://gist.github.com/AlexandruIfrim/8e3626f27344f8f28a87 gist] of it.",aifrim
2,33740,Create a new API to standardize application tracing,,Bootstrap/Load,4.4,normal,normal,,feature request,new,reporter-feedback,2015-09-05T13:10:31Z,2019-06-04T19:32:32Z,"Having read #30934 and #28319, I think it's best if I raise a new requirement.
My proposal isn't about logging, it's related to problem determination tracing; the ability to dynamically activate trace logic to help someone to track down a problem.
I have been using my own solution ( a plugin called oik-bwtrace ) for a while now.
There are two dormant APIs that I need to make available at all times, even when tracing is not activated.
Since these functions are currently not available by default I've had to be careful where I use them. To circumvent the problem of trying to use an API which doesn't exist, many of my plugins have dependencies on a base plugin which supplies the dormant APIs.
Life would be a lot simpler if WordPress came with a set of dormant functions which I can rely on to exist.
This proposal is for two trace APIs. It could easily be extended to support logging.
The dormant APIs have the same basic structure
{{{
function dormant_api( easy to use parameters ) {
global $api_set_active;
if ( $api_set_active ) {
lazy_api( easy to use parameters );
}
}
}}}
In this example $api_set_active is just a boolean.
It's set to true when the API logic is activated, false otherwise.
To cater for different levels of tracing ( or logging ) we can either implement the test in the dormant API, or pass it to the lazy_api().
This solution is different from 'pluggable'.
The dormant APIs need to exist, from very early on.
The lazy APIs are provided by implementing plugins and should be implemented as pluggable.
The two APIs I really do need are currently called bw_trace2() and bw_backtrace().
I've attached the latest version of my shared library file that defines these APIs and the constants they use.
Assuming that these APIs will be required to trace WordPress core logic I feel that they need to have been defined early on in wp-settings.php
I therefore propose a new file called dormant.php which can, if the developer so wishes, be included in wp-config.php but would otherwise be loaded in wp-settings.php before load.php.
Note: It's the implementing plugin's responsibility to know when it's safe to do things.
In my implementation of a hook for the 'all' action I've used multiple strategies which involve loading my APIs in wp-config.php before wp-settings.php, using a Must-Use plugin to be able to record most hooks, but requiring a custom db.php to be able to capture everything. I can't do it before db.php since add_action()'s not available until then.
",bobbingwide
2,32452,Cache optimizations,,Cache API,4.1,normal,normal,,defect (bug),new,,2015-05-20T23:54:50Z,2019-06-04T19:28:59Z,"Hi,
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)
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.
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.
3) Some minor fixes in options.php
---- removed untrailingslashit on line#109 // function does not yet exist if called from within functions.php
---- added ! $result == 0 line#288 // if a database update effects zero rows the cache should still be updated
---- pre-emptively negatively cache (into notoptions) the just deleted option line#477
All file changes (from svn diff) available at this link:
http://pastebin.com/5vPGCCt7",Relevad
1,32848,Null values for Update Options does not reset in $all_options,,Cache API,4.2.2,normal,normal,,defect (bug),new,needs-unit-tests,2015-06-30T22:04:47Z,2019-06-04T19:30:18Z,"This is a fun, extremely niche case.
We were using the Settings API to save out options for a plugin when we came across a really frustrating scenario. Half the time our setting was returning values that were not accurate to the setting that was stored in the database and in cache.
Come to find, the value being returned from wp_load_alloptions was incorrect while every other instance was correct. In our case, these values were in the database, memcache, and the single value in wp-object-cache.
On [https://core.trac.wordpress.org/browser/tags/4.2.2/src/wp-includes/option.php#L319 ""line 319 of option.php""], we're using isset to check the value in the array. This returns false if the value is NULL. This leads to all kinds of sadness.
I would propose we instead use `array_key_exists` here to ensure we're getting true if the key is present in the array at all. ",MikeNGarrett
4,23290,"When using switch_to_blog() with a persistent object cache that lacks wp_cache_switch_to_blog() support, non-persistent groups are not maintained",,Cache API,3.0,low,normal,,defect (bug),new,needs-unit-tests,2013-01-25T05:28:44Z,2019-06-04T19:41:33Z,"If you're using a persistent object cache that lacks the new `wp_cache_switch_to_blog()` support, WordPress core `else`s into a complete cache clobbering branch. It is smart about grabbing the global groups and re-adding those after `wp_cache_init()` is called, but it doesn't do the same for non-persistent groups. Those are a hardcoded array. So if you call `switch_to_blog()`, you would lose any custom-added non-persistent groups.",markjaquith
,31520,wp_cache_get generates fatal error,,Cache API,4.1.1,normal,normal,,defect (bug),new,reporter-feedback,2015-03-04T08:47:40Z,2019-06-04T19:28:04Z," There are timing issues in WP where some code in plugins, specifically wp super cache, make called to wp_cache_get before $wp_object_cache is initiated.
This generates a fatal error in php and can often send apache crashing.
This only occurs n wp_cache_get() and it seems as if the easiest solution is to check to see if $wp_object_cache is actually initaited and/or an object before calling its get() function.
… at /var/sentora/hostdata/zadmin/public_html/freemaal_in/wp-includes/
cache.php (113)
…at /var/sentora/hostdata/zadmin/public_html/freemaal_in/wp-includes/
option.php (54)
…/public_html/freemaal_in/wp-content/plugins/wp-super-cache/
wp-cache-phase2.php (255)",jatingupta2k
,23327,Cache incrementors for get_bookmarks(),,Cache API,3.5.1,low,normal,,enhancement,new,has-patch,2013-01-30T18:24:08Z,2022-01-18T13:48:04Z,"Make use of a caching incrementor and store queries in individual cache buckets to avoid memory exhaustion.
Pattern this after #23167, which does the same thing for get_pages().
See #23173 for an explanation of the motivation behind this.",ryan
1,20388,?cpage=N URLs do not have canonical redirection,,Canonical,,normal,normal,,defect (bug),new,has-patch,2012-04-07T05:43:02Z,2019-06-04T19:22:58Z,?cpage=N URLs aren't redirected to their pretty URL counterparts. They should be.,markjaquith
,17661,Appending date & author based query vars to a permalink overrides the permalink,,Canonical,3.1,normal,normal,,defect (bug),new,needs-unit-tests,2011-06-02T11:05:05Z,2019-06-04T19:22:31Z,"Some canonical code branches are not properly accounting for extra query variables being specified via the url.
For example, these url's are not handled properly:
{{{
/2008/?author=1 redirects to /author/admin/
/author/admin/?year=2008 redirects to /year/2008/
/category/uncategorized/?year=2008 redirects to /2008/
}}}
This happens with most date based branches, as once a higher priority canonical rule is hit, the permalink component is ignored.
The canonical code includes a branch to add any ""forgotten"" `$_GET` variables back onto the url, however this doesn't help when it's the rewritten variables are being lost.",dd32
,36355,Article URL redirects no longer working,,Canonical,4.0,normal,normal,,defect (bug),new,,2016-03-28T15:20:39Z,2019-06-04T19:35:41Z,"On multiple sites, we have started using article URLs with the post ID in them. Historically, this has allowed WordPress to find the post and do a 301 redirect when the slug, date, or other parts of the URL path changed.
For example, Permalink - %year%/%vertical%/%category%/%postname%-%post_id%/
All of these URLs should redirect us to this article: http://variety.com/2016/tv/news/the-loud-house-premiere-date-video-nickelodeon-1201740128/
http://variety.com/2015/tv-news/news/the-loud-house-premiere-date-video-nickelodeon-1201740128/
http://variety.com/2015/tv-news/news/test-url-slug-1201740128/
http://variety.com/the-loud-house-premiere-date-video-nickelodeon-1201740128/
http://variety.com/2016/the-loud-house-premiere-date-video-nickelodeon-1201740128/
While the first 2 examples work correctly, the last 2 URLs land on 404 page inspite of correct %pagename%-%post_id% combination.
If we have Permalink - %year%/%vertical%/%category%/%postname%/
The last 2 structure work correctly and reach correct article page. For example - http://hollywoodlife.com/2016/03/28/lip-sync-battle-the-walking-dead-sasha-vs-maggie-video/
http://hollywoodlife.com/lip-sync-battle-the-walking-dead-sasha-vs-maggie-video/
http://hollywoodlife.com/2013/lip-sync-battle-the-walking-dead-sasha-vs-maggie-video/
Since we have a correct %postname%-%post_id% combination in the first Permalink structure URL, we should be able to reach the correct article page in the last 2 examples there too.
",archanamandhare
2,34800,Canonical 301 redirects go to request origin instead of site_url,,Canonical,4.3.1,normal,normal,,defect (bug),new,reporter-feedback,2015-11-27T11:48:52Z,2019-06-04T19:33:12Z,"I have a problem with canonical redirect using a CDN setup.
Let's say we have an origin server at `origin.example.com`, and the CDN at `www.example.com`.
When I request `https://www.example.com/page-x`, it redirects me to `https://origin.example.com/page-x/` instead of `https://www.example.com/page-x/`, altough both `site_url` and `home_url` are set to `https://www.example.com`.
I suspect that Wordpress doesn't use `site_url` when composing the redirect URL, it's just using the request URL with a trailing slash added (which is in fact `https://origin.example.com/page-x` as the CDN translates the request).
The expected behaviour would be to either:
* use the correct absolute URL in the header, like `Location: + `
* use a relative URL, like `Location: `
I also checked the Redirection plugin, which returns relative URLs in the 301 redirects, and those work fine with my setup.
Thanks for looking into this!
Sevcsik
",sevcsik
1,22879,Canonical Link Missing on Front Page,,Canonical,3.4.2,normal,normal,,defect (bug),new,,2012-12-12T11:03:05Z,2019-06-04T19:23:43Z,"Canonical links are provided for posts, so if someone links to /2012/12/my-post/?whatever then Google will know it is a duplicate of /2012/12/my-post/
But if someone links to /?whatever there is no canonical address.",miqrogroove
,36873,"Canonical redirect code does opposite of comment, breaks script when home_url starts with https",,Canonical,4.5.2,normal,normal,,defect (bug),new,,2016-05-18T03:43:01Z,2019-06-04T19:37:46Z,"The comment on line 444 in wp-includes/canonical.php says that it only changes the host if it's adding or removing ""www."". It changes the host to lowercase if capitalization is the only difference or if the change is NOT adding or removing ""www."". Either the comment or the code should be changed.
This is causing a problem when I try to run the script below. If the home url (used on line 176) is ""https://www.example.com/"", then the host is removed and redirect url changes to ""https:///"". This makes the parse_url call on line 69 return false and end processing.
I believe this is why the script fails. There's a lot of code here. Apologies if I have it wrong.
Here's the script:
define('WP_USE_THEMES', true);
require_once('/var/www/html/wp-blog-header.php');
I can workaround the bug by explicitly setting some server variables before calling that code:
$_SERVER = array (
'REQUEST_URI' => '/',
'HTTPS' => 'on',
'HTTP_HOST' => 'www.example.com',
);",thasmin
,14201,"Canonical redirect kicks in in case of category/tag base containing other chars then a-z, 0-9, _ and -",,Canonical,,normal,normal,,defect (bug),new,close,2010-07-05T09:03:39Z,2019-06-04T19:21:57Z,"'''Expected behaviour'''
Whatever the category base is, if we go to a properly formed category pretty permalink, canonical redirects shouldn't kick in.
'''Actual behaviour'''
If the category base is non-ASCII (for example: баба), the canonical redirect tries to redirect to the same URL. The redirect sanitizer removes the category base from the URL, because it is non-ASCII and redirects to {{{//category-name/}}}. This prevents endless redirects and usually results in 404.
'''Why does it happen?'''
Category base is always used verbatim. It can't be URL-encoded, because the percent signs will be interpreted as permalink variables. Because of that the generated urls will be always in the form: {{{/баба//}}}.
The contents of {{{$_SERVER['REQUEST_URI']}}} are always URL-encoded, so the requested URI is: {{{/%D0%B1%D0%B0%D0%B1%D0%B0//}}}.
Canonical redirect functionality assumes the requested URL would be the same as the generated term URL and since they are different tries to redirect.
'''Solutions'''
The easiest one is to assume that if we had come to the right category page without any get variables, we don't need the logic for redirecting to the canonical category page. This is valid statement, because that logic relies only on removing get arguments.
The only disadvantage with that solution is that doesn't solve the more general problem of discrepancies between generated and requested URLs. But for now it will do a good job.",nbachiyski
,13041,Canonical redirection will redirect a non-exitant page to a post.,dd32,Canonical,3.0,normal,normal,,defect (bug),reviewing,has-patch,2010-04-18T06:14:20Z,2019-06-04T19:21:48Z,"Following on from #12601
Canonical redirection will kick in for http://localhost/wordpress-commit/apage/something and redirect it to http://localhost/wordpress-commit/2010/02/13/something-else/
#12601 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.
I'm attaching a patch which will prevent a Page -> Post redirection, but not the other way around. - this patch was originally added to the other ticket.",dd32
,37505,Filtering pagination when the pagenumber doesn't exist.,,Canonical,4.5.3,normal,normal,,defect (bug),new,,2016-07-29T05:10:50Z,2019-06-04T19:40:25Z,"Hello :).
`WP_Query::page` or `$GLOBALS['page']` or `get_query_var( 'page' );` will return whatever value is set by the visitor on a non-paginated page or post.
On a paginated page/post, it will 301 redirect the visitor to the first page, this is OK.
'''An example, on a post or page without pagination:'''
The output of the page will be incorrect, specifically on these two parts (both Title and Canonical URL show pagination).
URL: `http://example.com/2016/07/29/hello-world/123/`
{{{
Hello world! – Page 123 – Example.com
...
...
}}}
This is a major concern for SEO, as it will output duplicated pages.
Abusers could mark otherwise good pages as duplicated by simply linking to a non-existing non-paginated page.
'''My suggestion:'''
Check against `$GLOBALS['multipage']` (or `$GLOBALS['numpages']`) prior to creating the above output.
",Cybr
1,23602,"Incorrect canonical redirect if p=123 query argument present in ""paged"" archives",,Canonical,3.5,normal,normal,,defect (bug),new,needs-unit-tests,2013-02-25T08:34:19Z,2019-06-04T19:23:57Z,"URLs that include `page/n` AND `p=n` query variable, such as:
http://example.com/page/3/?p=123
will issue a 301 redirect to the homepage. This is being reported as incorrect behaviour in Google Webmaster Tools, because:
The target URL does not exist and your server is not returning a 404 (file not found) error.
Your server is redirecting requests for a non-existent page, instead of returning a 404 response code. This creates a poor experience for searchers and search engines.
A fix would be to strip the `p=` query variable and redirect to the paged archive.
From:
http://example.com/page/3/?p=123
to:
http://example.com/page/3/
",kasparsd
3,35847,Issue with blog roll pagination on static frontpage,,Canonical,4.4.2,normal,major,,defect (bug),new,,2016-02-17T02:00:09Z,2019-06-04T19:34:46Z,"This is a follow-up to #35344.
Still having this problem on 4.4.2 with or without [https://core.trac.wordpress.org/attachment/ticket/35344/35344.2.diff 35344.2.diff] applied.
The query.php in 4.4.2 is way too different to apply [https://core.trac.wordpress.org/attachment/ticket/35344/35344.diff 35344.diff].
In my case this bug only affects the blog roll on a static front page, and instead of redirecting to the homepage it strips the page number from the URL and tries to load sitename.com/page/ which, in turn, returns a 404.
The same page, unset from being the frontpage, works fine.",finomeno
12,35689,Pagination issue on front page after 4.4.1 update,,Canonical,4.4.1,normal,normal,,defect (bug),reviewing,,2016-02-01T14:36:06Z,2019-06-04T19:34:14Z,"This is a spinoff of the remainder of #35344. See ticket:35344#comment:60 and on.
> It seems to be that the remaining issues being experienced is this scenario, which is sounding like a combination of #35482 and this ticket.
> * Static page on front, no posts page defined
> * `query_posts()` or `$wp_query = new WP_Query()` used within the template to display the first page of posts
> * /page/2/ would then load page 2 of the posts index with no static page in sight.
> The problem I face, is that /page/2/ should NOT be the archive of posts, it should be the second page of the static home page (You can paginate posts/pages using the tag in your content).
",samuelsidler
2,16133,"Pagination issue with tag ""rss""",,Canonical,3.0,normal,normal,,defect (bug),new,dev-feedback,2011-01-07T09:39:10Z,2019-06-04T19:22:09Z,"When posts use ""RSS"" as a tag, and the /tag/rss/ page has more posts than it is set to display on one single page, the link to page 2:
/tag/rss/page/2/
is redirected to:
/category/page/2/
Tested on Paolo Belcastro test WordPress.org :
http://test.belcastro.com/tag/rss/
Running 3.1-RC2-17229 with only Debug Bar plugin activated
This is not theme related, same behaviour with TwentyTen or Thematic on this install.",paolal
2,21700,Problem obtaining the Feed of an archive of tag “RSS”,,Canonical,3.4.1,normal,normal,,defect (bug),new,,2012-08-27T10:40:33Z,2019-06-04T19:23:18Z,"I'm using RSS as a tag for some of my blog posts, and I was using them without any problem.
'''myblog.com/tag/rss/'''
But I've just realised that Google Webmaster Tools gives me some related errors.
The issue is this: when trying to retrieve the feed of this tag, from
'''myblog.com/tag/rss/feed/'''
it gets redirected to
'''myblog.com/tag/feed/'''
And this gives an error.",xavivars
1,30905,Theme Preview - Not working preview when front page setting,stevenkword,Canonical,4.1,normal,normal,,defect (bug),assigned,,2015-01-05T09:24:15Z,2019-06-04T19:27:22Z,"I'm sorry if there are already ticket for same problem.
Preview is not working well (not live preview/customizer).
Is this a bug? or specification?
Steps to reproduce:
1. Settings to '''Front page'''(anyting page) and select the '''A static page''' of Front page displays of Reading of Settings.
2. Access the Themes screen of Appearance with Editor(Editor already have capability to switch_themes).
3. Click to the '''preview button''' of per not activated themes.
Tested in: Google Chrome 39.0.2171.95 m
And I think this happen is affect to following.
{{{
wp-includes/canonical.php line 48 - 54
}}}
Theme preview is not have post ID. But that it become to have post ID after the Front page settings.
And I have tentatively avoiding the problem in this way.
{{{
function test_redirect_canonical( $redirect_url , $requested_url ) {
if( get_query_var( 'preview' ) && !empty( $_GET['template'] ) && !empty( $_GET['stylesheet'] ) && !empty( $_GET['preview_iframe'] ) ) {
if( current_user_can( 'switch_themes' ) ) {
$redirect_url = false;
}
}
return $redirect_url;
}
add_filter( 'redirect_canonical' , 'test_redirect_canonical' , 10 , 2 );
}}}",gqevu6bsiz
12,10690,WordPress does not support non-ascii characters in the domain name,markjaquith,Canonical,2.8.4,normal,normal,,defect (bug),reopened,needs-unit-tests,2009-08-26T18:26:13Z,2019-06-04T19:21:34Z,"WordPress' clean_url() strips out most characters, which are non-ascii for security reasons. This is causing problems, if you want to run a WordPress blog on a domain containing non-ascii-characters (e.g. müller.com), because WordPress generates wrong URLs on redirects.",paddya
,20386,"Year permalinks ""win"" against category permalinks",,Canonical,,normal,normal,,defect (bug),new,needs-unit-tests,2012-04-07T05:20:55Z,2019-06-04T19:22:56Z,"We need to decide whether category permalinks should take priority over year permalinks.
e.g. /2008/?category_name=cat-a
Should that stay the same, or redirect to:
/category/cat-a/?year=2008
We have a unit test which is failing.",markjaquith
,30631,posts_per_page causing infinite duplicate content,,Canonical,4.0.1,normal,normal,,defect (bug),new,,2014-12-08T20:05:26Z,2019-06-04T19:27:15Z,"While using the posts_per_page in the pre_get_posts, if you set it to -1. It will output all the posts. The issue is that if you use this with the main query on a taxonomy archive page, then it will create unlimited number of subpages with all the same content as the main page :
taxonomy-1/
taxonomy-1/page/2/
taxonomy-1/page/3/
...
taxonomy-1/page/500/
etc...
It is probably not really the expected behavior...
",firebird75
6,37115,recent canonical change is giving an infinite 301 redirect loop,,Canonical,4.4.2,normal,normal,,defect (bug),new,dev-feedback,2016-06-16T16:26:39Z,2019-06-04T19:39:05Z,"Hello,
For 4.5.2 in canonical.php line 175, in prior versions there was an elseif condition which was removed. Can you please add it back?
&& isset($wp_query->queried_object) &&
For example, when we have akamai injecting GET parameters to our home page, it just goes in an infinite 301 loop due to line 175 now evaluating TRUE when in the past it would evaluate as FALSE, and we'd like that back.
Please and thank you awesome wordpress team!",solomon123br
1,35794,redirect_canonical doesn't strip off custom feed endings,,Canonical,3.9,normal,normal,,defect (bug),new,,2016-02-10T13:54:41Z,2019-06-04T19:34:38Z,"The pattern used for matching URL's with feed endings (e.g. /feed/atom/) isn't matching any custom defined feeds. For example, if you add 'json' as a new type of feed, the redirect_canonical function adds up the feed ending to the current request URL.
This is caused by fixed regular expressions used to match such feed URL's. These regular expressions should be generated using the $wp_rewrite->feeds variable:
{{{#!php
$feedssubpattern = implode('|', array_map(function($val) { return preg_quote($val, '#'); }, $wp_rewrite->feeds));
$pattern = '#/(comments/?)?(' . $feedssubpattern . ')(/+)?$#';
}}}",huyby
2,31300,redirect_canonical returns too early,,Canonical,,normal,normal,,defect (bug),new,dev-feedback,2015-02-11T17:00:31Z,2019-12-06T10:01:04Z,"If `$redirect_url` is not set or is not equal to `$requested_url` then `redirect_canonical()` returns early and does not trigger the `redirect_canonical` filter. This prevents plugins from being able to alter the canonical URL.
This bug was partially addressed in #8975 (it still returned early when the redirect and requested URL are the same), but this was reverted in #11700 without any indication as to why.
The attached patch ensures the filter triggers even when the `$redirect_url` is not set or is the same as `$requested_url`.",stephenharris
3,20902,redirect_canonical() on using permalink: Not all $_GET being redirected,chriscct7,Canonical,3.4,normal,normal,,defect (bug),reviewing,has-patch,2012-06-11T09:30:08Z,2019-06-04T19:23:06Z,"Using permalink, I suppose that all query_var entered manually on URL or using $_GET will be redirected to proper permalink. Apparently not all being redirected at all. AFAIC:
1. /?post_format=image : should be redirected to /type/image/
2. /?pagename=blog : should be redirected to /blog/
3. /?author_name=admin : should be redirected to /author/admin/
Unfortunately, they are not.
It can be done by filtering redirect_canonical() but it will be better if it's being done by default as we can see that /?category_name=cat will be redirected to /category/cat/",arieputranto
,18385,"Canonical redirections not suited for Queries with multiple query vars and ""pretty permalinks"" in general",,Canonical,3.2,normal,normal,,enhancement,new,dev-feedback,2011-08-12T09:05:03Z,2019-06-04T19:22:40Z,"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.
What I'm proposing, is that it might be time to lay to rest the current `if.. elseif.. elseif..` style checks, It's not possible for 1 if branch to handle every single access point without duplicating another branch.
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.
{{{
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....
}}}
It's a work in progress, but it's worth considering IMO.
Attaching a diff, and the full file (since the diff is going to be rather unreadable in some sections)",dd32
1,20283,Create new variable or function in $wp_query object to get canonical URL of any site's page,,Canonical,3.3.1,normal,normal,,enhancement,new,dev-feedback,2012-03-22T14:42:36Z,2019-06-04T19:22:53Z,"For the sake of Search Engine Optimization it's recommended to set canonical URL inside tag in any site's page. Incorrect URL can exist in search engine index. For example: http://example.com?some_param=some_val&cat=3,4. URL points to categories with id equals 3 and 4, but we have another unnecessary parameter 'some_param'. It's malicious! We must set canonical URL to http://example.com?cat=3,4.
So It's advance to have canonical URL generated some way. I propose to set function or variable inside WP_Query class to retrieve canonical URL to any opened page.
In WP_Query we have variable WP_Query::query which consists of all necessary parameters for that propose. But we must use $wp_rewrites also.
Any thoughts?
",egorpromo
,10543,Incorrect (non-UTF-8) character handling in tag's name and slug,westi*,Charset,2.8.2,normal,normal,,defect (bug),accepted,needs-unit-tests,2009-08-04T05:26:11Z,2019-06-04T19:21:33Z,"Incorrect (non-UTF-8) character tag's name and slug are handled in different way: name is truncated on 1st such character, and in slug they are just removed (no truncation). WP should handle both in the same way - drop invalid characters, instead of truncation.
I found this issue recently. One of the Polish programs for adding posts to the Wordpresses does not encode tags in UTF-8 - it left them in ISO-8859-2. I notified author of this bug. Unfortunately there are many copies around, so it may take a long time before everyone upgrade.",sirzooro
1,35144,Sorting Greek characters,,Charset,4.4,normal,normal,,defect (bug),new,,2015-12-17T21:52:15Z,2019-06-04T19:33:24Z,"There's an abnormal behaviour in alphabetically sorted lists containing terms in Greek. The expected order would be Latin characters on top, then Greek; two consecutive lists. However, the Greek list is actually further split into two other lists, one with terms starting with an upper case character and the other with terms starting with lower case. So it's Latin Aa-Zz, then Greek Α-Ω, then Greek α-ω. A real-world example is a tag cloud. See this for example: [http://www.tastefull.gr/tagcloud]",beerallica
1,25693,blog_charset should be checked for null values,,Charset,3.8,normal,major,,defect (bug),new,,2013-10-25T04:10:29Z,2019-06-04T19:24:29Z,"We've encountered an error wherein a blog in a multisite network's `blog_charset` was nuked. This led to posts entered from the editor (visual and text) having random bits eaten. This was particularly pronounced when using text copied from Word documents. This is related to #23688, I think.
It seems as though PHP 5.4 makes some weird assumptions when you have a blank/null charset. Suggest we check for null values and fall back to, say, UTF-8 if none is found.
@grantlandram, @dkotter and I found this one under duress.",ZaMoose
3,34631,Extra compat for mbstring: mb_strpos(),,Charset,4.4,normal,normal,,enhancement,new,has-patch,2015-11-09T12:00:50Z,2019-06-04T19:33:04Z,"Hello,
I noticed a missing compat function within compat.php, regarding mb_strpos.
The use of this function within a plugin will result in a fatal error if the server doesn't support mbstring.
So I made a function that will take over the function if it does not exist.
I also implemented debugging errors based on PHP 5.5 source: https://github.com/php/php-src/blob/PHP-5.5/ext/standard/string.c#L1824
{{{#!php
if ( ! function_exists( 'mb_strpos' ) ) {
function mb_strpos( $haystack, $needle, $offset = 0, $encoding = null ) {
return _mb_strpos( $haystack, $needle, $offset, $encoding );
}
}
/*
* Only understands UTF-8 and 8bit. All other character sets will be treated as 8bit.
* For $encoding === UTF-8, the $str input is expected to be a valid UTF-8 byte sequence.
* The behavior of this function for invalid inputs is PHP compliant.
*/
if ( ! function_exists( '_mb_strpos' ) ) {
function _mb_strpos( $haystack, $needle, $offset = 0, $encoding = null ) {
if ( null === $encoding ) {
$encoding = get_option( 'blog_charset' );
}
// The solution below works only for UTF-8,
// so in case of a different charset just use built-in strpos()
if ( ! in_array( $encoding, array( 'utf8', 'utf-8', 'UTF8', 'UTF-8' ) ) ) {
return $offset === 0 ? strpos( $haystack, $needle ) : strpos( $haystack, $needle, $offset );
}
$haystack_len = mb_strlen( $haystack );
if ( $offset < (int) 0 || $offset > $haystack_len ) {
trigger_error( 'mb_strpos(): Offset not contained in string', E_USER_WARNING );
return false;
}
if ( !is_string( $needle ) ) {
$needle = (string) $needle;
if ( !is_string( $needle ) ) {
trigger_error( 'mb_strpos(): Array to string conversion', E_USER_WARNING );
return false;
}
}
if ( empty( $needle ) ) {
trigger_error( 'mb_strpos(): Empty needle', E_USER_WARNING );
return false;
}
// Slice off the offset
$haystack_sub = mb_substr( $haystack, $offset );
if ( _wp_can_use_pcre_u() ) {
// Use the regex unicode support to separate the UTF-8 characters into an array
preg_match_all( ""/./us"", $haystack, $match_h );
preg_match_all( ""/$needle/us"", $haystack_sub, $match_n );
$pos = key( array_intersect( $match_h[0], $match_n[0] ) );
if ( empty( $pos ) ) {
return false;
}
return (int) $pos;
}
$regex = '/(
[\x00-\x7F] # single-byte sequences 0xxxxxxx
| [\xC2-\xDF][\x80-\xBF] # double-byte sequences 110xxxxx 10xxxxxx
| \xE0[\xA0-\xBF][\x80-\xBF] # triple-byte sequences 1110xxxx 10xxxxxx * 2
| [\xE1-\xEC][\x80-\xBF]{2}
| \xED[\x80-\x9F][\x80-\xBF]
| [\xEE-\xEF][\x80-\xBF]{2}
| \xF0[\x90-\xBF][\x80-\xBF]{2} # four-byte sequences 11110xxx 10xxxxxx * 3
| [\xF1-\xF3][\x80-\xBF]{3}
| \xF4[\x80-\x8F][\x80-\xBF]{2}
)/x';
/**
* Place haystack into array
*/
$match_h = array( '' ); // Start with 1 element instead of 0 since the first thing we do is pop
do {
// We had some string left over from the last round, but we counted it in that last round.
array_pop( $match_h );
// Split by UTF-8 character, limit to 1000 characters (last array element will contain the rest of the string)
$pieces = preg_split( $regex, $haystack, 1000, PREG_SPLIT_DELIM_CAPTURE | PREG_SPLIT_NO_EMPTY );
$match_h = array_merge( $match_h, $pieces );
} while ( count( $pieces ) > 1 && $haystack = array_pop( $pieces ) ); // If there's anything left over, repeat the loop.
/**
* Place haystack offset into array
*/
$match_hs = array( '' ); // Start with 1 element instead of 0 since the first thing we do is pop
do {
// We had some string left over from the last round, but we counted it in that last round.
array_pop( $match_hs );
// Split by UTF-8 character, limit to 1000 characters (last array element will contain the rest of the string)
$pieces = preg_split( $regex, $haystack_sub, 1000, PREG_SPLIT_DELIM_CAPTURE | PREG_SPLIT_NO_EMPTY );
$match_hs = array_merge( $match_hs, $pieces );
} while ( count( $pieces ) > 1 && $haystack_sub = array_pop( $pieces ) ); // If there's anything left over, repeat the loop.
/**
* Put needle into array
*/
$match_n = array( '' ); // Start with 1 element instead of 0 since the first thing we do is pop
do {
// We had some string left over from the last round, but we counted it in that last round.
array_pop( $match_n );
// Split by UTF-8 character, limit to 1000 characters (last array element will contain the rest of the string)
$pieces = preg_split( $regex, $needle, 1000, PREG_SPLIT_DELIM_CAPTURE | PREG_SPLIT_NO_EMPTY );
$match_n = array_merge( $match_n, $pieces );
} while ( count( $pieces ) > 1 && $needle = array_pop( $pieces ) ); // If there's anything left over, repeat the loop.
/**
* Compute match of haystack offset with needle
* If passed, find the array key number within the full haystack.
*/
$pos = in_array( $match_n[0], $match_hs ) ? key( array_intersect( $match_h, $match_n ) ) : '';
if ( empty( $pos ) ) {
return false;
}
return (int) $pos;
}
}
}}}
`if ( ! function_exists( '_mb_strpos' ) ) {` could probably be removed since it could be a core function.
To test this, I've used the following lines of code:
{{{#!php
var_dump( _mb_strpos( '象形指事', '指', 0 ) ); // 2
var_dump( _mb_strpos( '象形指事', '指', 1 ) ); // 2
var_dump( _mb_strpos( '象形指事', '指', 2 ) ); // 2
var_dump( _mb_strpos( '象形指事', '指', 3 ) ); // false
var_dump( _mb_strpos( '象形指事', '指', -1 ) ); // false WARNING
var_dump( _mb_strpos( '象形指事', '指', 4 ) ); // false
var_dump( _mb_strpos( '象形指事', '指', 5 ) ); // false WARNING
echo PHP_EOL.PHP_EOL;
var_dump( mb_strpos( '象形指事', '指', 0 ) ); // 2
var_dump( mb_strpos( '象形指事', '指', 1 ) ); // 2
var_dump( mb_strpos( '象形指事', '指', 2 ) ); // 2
var_dump( mb_strpos( '象形指事', '指', 3 ) ); // false
var_dump( mb_strpos( '象形指事', '指', -1 ) ); // false WARNING
var_dump( mb_strpos( '象形指事', '指', 4 ) ); // false
var_dump( mb_strpos( '象形指事', '指', 5 ) ); // false WARNING
}}}
Feel free to contribute your thoughts :) Thanks!",Cybr
1,32917,Tests_DB_Charset tests don't fully cover wpdb::strip_invalid_text_for_column(),,Charset,4.2,normal,normal,,enhancement,new,needs-unit-tests,2015-07-08T00:20:27Z,2019-06-04T19:30:40Z,"Related / previously:
* #32351
* #32308
* #32127
* #21212
`Tests_DB_Charset` includes a data provider that feeds various charsets into its `wpdb::strip_invalid_text()` test, but not for its `wpdb::strip_invalid_text_for_column()` test, which means it's not being tested fully. It should be.",johnbillion
4,30909,Allow passing ID for comment_form container and title,,Comments,,normal,normal,,defect (bug),new,dev-feedback,2015-01-05T13:01:56Z,2019-06-04T19:27:27Z,"Right now, there's a `div` hardcoded with `#respond` and a `h3` hardcoded with `reply-title`. These make it hard for the comment form to be used on archive pages, as they assume the comment form is only ever output on single pages.
(There are other IDs output in the form, however these are controllable through `id_form` and `id_submit`)",rmccue
1,32299,Cancel comment reply link broken in AJAX call,,Comments,2.7,normal,normal,,defect (bug),new,,2015-05-08T01:23:46Z,2019-06-04T19:28:51Z,"related #31333 and both of that & this could arguably be a dupe of #31100 but there case appears to be a server config issue, not using `cancel_comment_reply_link()` or `get_comment_link()` with AJAX.
`cancel_comment_reply_link()` has the same issue as `get_comment_link()` has (#31333) which is that it relies on `$_SERVER['REQUEST_URI']` not the actual post permalink for the post's URL.
",Shelob9
1,35075,Comment cache ignores custom query vars,boonebgorges,Comments,,normal,normal,,defect (bug),assigned,has-patch,2015-12-14T14:41:42Z,2020-03-06T01:08:10Z,"It's currently very possible to add custom query vars to the get_comments function, for themes and plugins to extend. A problem occurs, however, if the function is being used and a custom query var is being used, but no standard ones are changing. This is because it caches the first query, and every subsequent query is then assumed to be the same since custom query vars are ignored.
I first thought about just using the entire query_vars array for caching, but decided there's probably a reason this wasn't done. So instead I decided it would make the most sense to make a filter for the cache keys so a plugin/theme can add its own keys that should be considered for caching.",jason_the_adams
1,12363,Comment permalink wrong when only listing one comment type,wonderboymusic,Comments,3.0,normal,normal,,defect (bug),assigned,dev-feedback,2010-02-24T14:31:51Z,2019-06-04T19:21:46Z,"If you pass the `type` parameter to `wp_list_comments()` (for example, to show comments only and no pings), then comment permalinks can easily use the wrong page number as they expect there to be pings included. This is apparent after leaving a comment and WordPress attempts to redirect back to your new comment.
At first I was thinking you could tell WordPress that you're filtering to a type and it could compensate when determining the page number, but then I realized perhaps it'd just be better for `wp_list_comments()` to check if there were 0 comments returned for the query and if so, see if there are any of that type of comment available. If so, then we know we're on too high of a page number and can instead display the highest existing page. Then again this introduces SEO issues.
Ideas on what to do are welcome.",Viper007Bond
3,36409,Comments number is wrong,,Comments,,normal,normal,,defect (bug),new,needs-unit-tests,2016-04-04T14:21:26Z,2019-06-04T19:35:47Z,"Hi,
the comment number return the number of approved comments, this means all approved comments even those are replies to unapproved comments, for example if a user post comment and people replied to it, then the admin decide to hide this parent comment by disapproving it, the comment number will decrease only by one and keeping counting the hidden replies
So there are two option to fix that :
1. Hold/Disapprove all children when disapproving the parent.
2. Recalculate the comment number and excluding comments has an unapproved parent.
Regards,
Sidati",sidati
2,35862,Comments screen: audit all the background color animations,,Comments,3.8,normal,normal,,defect (bug),new,,2016-02-18T17:26:13Z,2019-06-04T19:34:53Z,"Noticed some weird behavior, to reproduce: go in the Comments screen (in the ""All"" view), and mark as spam or move to the trash an '''approved''' comment. The comment row background will quickly ""flash"" to red and then the comment row will disappear.
Do the same on an '''unapproved''' comment: no red flash.
There are also other cases where this happens, seems all related to pending comments. By the way, the JavaScript animations still run and the background is animated behind the scenes. It just can't be seen because the pending comment row background color is now set on the `th` and `td` elements that hide the change on the `tr` background. Looks like this JavaScript part wasn't updated after the CSS changes in WordPress 3.8.
There are also other old things that missed to be updated, for example at some point JavaScript still uses `#FFFFE0`. This was the background color used for unapproved comments in WordPress 3.7 but they use `#FEF7F1` since 3.8.
I'd propose two options:
1. Fix the animations :)
2. Get rid of them. Apparently, not so many users have complained about the (partial) lack of color animations in the last 2 years
I'd lean toward the second option. There are several lines of JavaScript in `edit-comments.js` and `wp-lists.js` that could be removed, they are hard to maintain and being a bit old code they also violate the separation of structure, presentation and behavior principle. Yes, the JS could be refactored and maybe use a more modern approach but for, I'd say, a very little benefit.
So before any patch attempt, this would need a decision. Any thoughts more than welcome.
In the screenshot below, the red flash on pending comments, how it used to be on WordPress 3.7
[[Image(https://cldup.com/Ml9laEw1jQ.png)]]",afercia
10,34106,Comments should have real permalinks,,Comments,,normal,normal,,defect (bug),new,,2015-10-01T04:41:21Z,2019-06-04T19:32:37Z,"The closest think we have to comment permalinks are links like this:
`example.com/my-post/comment-page-3/#comment-123`
This is very fragile:
* comment-page-x is sometimes optional, as when oldest comments are displayed first, and `my-post/comments-page-1/` is the same as `my-post/`
* If you change the number of comments per page, the link is no longer correct
* URL fragments (the stuff after `#`) are client-side only. Remember hashbangs? https://www.w3.org/blog/2011/05/hash-uris/
* Pagination URLs are ugly and should not be used for canonical purposes
I propose something along the following lines:
* `example.com/comment/123` rewrites to `example.com/?comment_id=123`
* `WP_Query` will translate `comment_id` into the proper values for `p` and `cpage`
* `redirect_canonical()` will send you to `example.com/my-post/comment-page-3/#comment-123`
Comment pagination settings can change at any time, and permalinks will continue to work.",boonebgorges
1,26596,Edit comments from wpAdmin don't process well radio button fields,,Comments,2.7,normal,normal,,defect (bug),new,has-patch,2013-12-13T08:38:04Z,2019-06-04T19:24:43Z,"I'm filtering for 'wp_comment_reply' to add a custom radio button selector in the wpAdmin comments.
Then the ajax request don't send this field value, always send the last one, checked or not.
wp-admin/js/edit-comments.js process all INPUT fields as a text (except type button)
I attach the patch to allow radio buttons but doesn't works for checkbox.",corretge
3,35651,No longer any consistent way to add content to bottom of comments form,,Comments,4.4,normal,normal,,defect (bug),new,dev-feedback,2016-01-28T22:12:22Z,2019-08-19T01:44:25Z,"In #34731, there was a discussion on whether `comment_notes_after` should be directly after the comment form (now at the top by default), or at the bottom above the submit form (as the documentation described).
The decision was to change the documentation.
However, this now leaves no consistent way for themes/plugins to add content to the bottom of the form, above the submit button. Using `comment_notes_after` was a popular method to add notes like terms and conditios, or a subscribe checkbox etc, and consistent with the old documentation. All of these themes/plugins that relied on the positioning in the documentation will now have this output in the wrong place in the form.
`comment_form_after_fields` isn't an alternative since it only applies when the user is logged out.",smerriman
3,11248,Paged wp_list_comments() should always output something,boonebgorges,Comments,2.9,normal,normal,,defect (bug),assigned,has-patch,2009-11-24T06:00:23Z,2019-06-04T19:21:40Z,"Enable comment paging on your blog and visit `http://yourblog.com/a/single/post/comment-page-999999/`. Note no comments will be displayed.
There's situations where the comment form will redirect you back to the wrong page (for example if you mess with the type parameter and exclude pings). The Walker should detect if there's no comments to be displayed on the requested page and if that's the case, then display the latest page that actually has comments.",Viper007Bond
9,22301,Performance problem with Recent Comments widget,,Comments,2.8,normal,normal,,defect (bug),new,has-patch,2012-10-29T06:07:14Z,2019-06-04T19:23:37Z,"When a comment is posted (or the status of a comment changes), the `widget_recent_comments`cache item is invalidated, which the Recent Comments widget uses to populate the widget content. On the next widget display, it will call `get_comments()` to repopulate the cache.
The problem occurs when you have a very large number of comments, the MySQL query will use the `(comment_approved, comment_date_gmt)` index, but if MySQL has to scan too many rows in an index, it'll switch to table scan instead. As the `comment_approved` column is mostly the same value, this will almost always happen. This is compounded by the query occurring on every page load until the cache is re-populated - if the query takes 60 seconds to run, there could potentially be hundreds of instances of the same query running.
So, we need a solution that either hides or eliminates how slow this query can be, and only runs it (at most) once per new comment.
After discussing this with @matt, we have a couple of ideas:
1. Move this query to a `wp_schedule_single_event()` call, which has the bonus of ensuring only one is scheduled at any given time. The downside is that it may cause the cache to be outdated on a low traffic site.
2. Keep a queue of recent comments in cache, and push a new one onto the queue when posted. This avoids the query entirely, but there would be a race condition if two comments were posted at nearly the same time - one of them could be left out of the queue entirely.",pento
,22261,Recent comments widget makes additional queries when pagination is enabled,,Comments,,normal,normal,,defect (bug),new,,2012-10-23T14:19:59Z,2019-06-04T19:23:35Z,A continuation of #15400.,nacin
5,35805,Reverse page order in wp_list_comments() with newest comments first,boonebgorges,Comments,4.4.2,normal,normal,,defect (bug),reviewing,needs-unit-tests,2016-02-12T00:21:26Z,2019-06-04T19:34:45Z,"Hey there,
since wp 4.4 there were lots of bugs in the wp_list_comments()-function. Some of them are already fixed, now I found another one.
If you change the comments order from default (oldest first) to newest first, the page order is wrong (reverse page order).
== Example ==
You have 4 pages by sending following param you get these pages:
{{{
page=1 -> 4
page=2 -> 3
page=3 -> 2
page=4 -> 1
}}}
== How I call this function ==
Inside the post-loop I'm calling:
{{{#!php
}}}
And comments-content.php has following part:
{{{#!php
$cpaged, // Variable defined before, default: 1
'per_page' => 2
) );
?>
}}}
PS: In ticketing system the version 4.4.2 is not available :-)",Ninos Ego
9,31188,Very slow query in comments_template -> get_comments -> WP_Comment_Query->query,boonebgorges,Comments,4.1,normal,normal,,defect (bug),assigned,,2015-01-31T02:01:45Z,2019-06-04T19:27:50Z,"In my quest to improve performance of core Wordpress functionality (see #31071, #31072, and #31171), I'm back with another optimization that is quite significant for large WP installations with lots of comments on some posts.
The query in question:
{{{
# Query_time: 25.314234 Lock_time: 0.000074 Rows_sent: 10 Rows_examined: 699220
SET timestamp=1422666393;
SELECT wp_comments.* FROM wp_comments WHERE comment_post_ID = '87814' AND comment_approved = '1' ORDER BY comment_date_gmt DESC LIMIT 10;
}}}
As you can see, 25s is not great to say the least. The query isn't using an optimized index, which I've now created, at which point it started running in milliseconds.
The index is as follows:
{{{
CREATE INDEX `comment_post_ID_approved_date_gmt` ON `wp_comments`(`comment_post_ID`, `comment_approved`, `comment_date_gmt`);
}}}
I've verified the performance improvements using SQL_NO_CACHE as well as EXPLAIN.
The post in question here had over 3000 comments, which isn't uncommon on our site (androidpolice.com).
Interestingly, MySQL queries using a different strategy internally which isn't nearly this slow for posts with fewer comments. But at some point, it switches it up because it thinks it's better, and things go sour.",archon810
2,36885,"When one uses custom callback function for comment list, ""Reply"" link would not show",,Comments,,normal,normal,,defect (bug),new,reporter-feedback,2016-05-19T00:59:34Z,2019-06-04T19:37:59Z,"It took too much time, but found the issue here in wp-includes/comments-template.php in
get_comment_reply_link function. The OR conditions are likely to be true I imagine in many combination of situations although I am not too sure what combination causes bad things to happen.
{{{
if ( 0 == $args['depth'] || $args['max_depth'] <= $args['depth'] ) {
return;
}
}}}
Well and good to check this, but why would the reply as well as login link disappear if any of it is true? Sorry if I am not getting this as I should. ",remedy17
4,34110,WordPress Trackback Bug when Comment Pagination is Enabled,,Comments,,normal,normal,,defect (bug),new,needs-unit-tests,2015-10-01T11:40:36Z,2019-06-04T19:32:40Z,"Hi, I just find a comment bug with wordpress which I think is there for a ling site, may be since v2.7+ but never actually fixed.
'''Bug Details/ Reproduce process'''
Inside your theme while fetching your comments after
{{{
have_comments()
}}}
try to fetch comments only by using
{{{
wp_list_comments( array( ""type"" => ""comment"") )
}}}
and then below check if trackback exists and if they do print the trackbacks separately using
{{{
wp_list_comments( array( ""type"" => ""pings"") )
}}}
Now add a bunch of comments on any of your blog post which also have some trackbacks. Add more than 60 - 70 comments on that post. and from settings enable comment pagination option. So that comments get divided into several comment pages. If you are thinking this is never going to happen in real life, let me tell you I have blog posts which has more than 2.500 comments in it and none of them are spam comments.
Now, after you enable the comment pagination, visit your blog page link i.e. example.com/some-post/ and you will see the trackbacks below your comments as it should show up now start navigation through your comment pagination, you will see the following -
Trackback is showing on the normal blog post link
Trackbacks also showing for /comment-page-1/
But when you will move further from comment page 1 you will only see the heading i.e. Trackback or whatever you have set, but not the actual trackbacks. This problem is also present in genesis theme, earlier I though it was a genesis bug but while developing a non genesis wordpress there I understood that it is actually a wordpress core bug.",isaumya
1,28314,cancel_comment_reply_link() is unflexible - respond_id & post check,,Comments,3.9.1,normal,major,,defect (bug),new,has-patch,2014-05-20T13:03:57Z,2019-06-04T19:25:49Z,"There are two found problems with the function
{{{
cancel_comment_reply_link()
}}}
1. You cannot define a custom respond id like #respond-POSTID. The respond id (#respond) is hardcoded. So the anchor is not working anymore, if you use a custom respond_id in your theme.
2. If you include the comments on the blogs page (loop) you have comment areas as much as posts. Now you answer to a comment of a specific comment (for example: http://example.com/blog/?replytocom=210#respond-821). This is working fine, just that the cancel_comment_reply_link() is going active for all posts and shows a cancel message under each comment area. It should check for the specific comment area/post and return the message just for the affected comment area/post.
If you want I can create a patch for this two bugs :-)
Best regards,
Ninos",Ninos Ego
2,13473,comment_status should be set to default_comment_status when commentstatusdiv is removed,westi,Comments,,normal,normal,,defect (bug),reopened,,2010-05-20T23:36:24Z,2019-06-04T19:21:51Z,"When the Comment Status box is removed from the Add/Edit Post screens, posts should be created with the comment_status set to the value of the default_comment_status option.
-----
I had hidden the Comment Status box via:
remove_meta_box('commentstatusdiv','post','normal');
and made sure that default_comment_status was set to open:
update_option('default_comment_status', 'open');
After adding a new post it displayed ""Comments Off"" when I was assuming that it should have honored the value of default_comment_status.",jimmcq
4,37103,get_comments_number_text() should not replace '%' in post title,,Comments,4.2,normal,normal,,defect (bug),new,has-patch,2016-06-14T20:06:02Z,2019-06-04T19:38:56Z,"Background: #13651
1. Create a post titled ""Hello % world"".
2. Add a couple of comments.
3. `comments_popup_link()` will produce the following output:
{{{
2 Comments on Hello 2 world!
}}}
Note ""Hello 2 world!"" instead of ""Hello % world!"", due to `get_comments_number_text()` treating `%` as a comments number.
Reproduced with 4.5.2 and Twenty Sixteen. Technically introduced in [31388].",SergeyBiryukov
2,11734,trackback_rdf() for IDN (xn--) Domains produces invalid HTML,,Comments,3.1,normal,normal,,defect (bug),new,has-patch,2010-01-06T01:10:55Z,2019-06-04T19:21:42Z,"Hello
The trackback_rdf() function from wp-includes/comment-template.php wraps the ""..."" output inside """" HTML comments, probably to be safe as not all Browsers understand them.
When using Wordpress 2.9.1 on a site with an international domain name [1] that contains special characters like German ""Umlauts"" like äöü, this domain name is written as e.g. xn--tst-qla.de for täst.de.
Now the output of trackback_rdf() suddenly gets a ""--"" which is the SGML/HTML comment separator mark [2]. Firefox 3.5.6 e.g. sees this as the end of the comment and therefore shows the final ""-->"" as text to the user.
As the whole RDF tag is supposed to be invisible for the user, it's a bug in Wordpress :-(
Here is an real world example output:
{{{
}}}
So, two/three issues:
- wpautop should also ignore double object tags, and html comments
- wptexturize should ignore html comments",Denis-de-Bernardy
3,15918,wpautop() breaks inline tags on the same line as block tags,dunno,Formatting,3.0.3,normal,normal,,defect (bug),new,,2010-12-20T16:01:31Z,2019-06-04T19:43:17Z,"Hi guys! I've got latest WP installation (3.0.3) and found strange bug in posts parser.
Create article with following HTML:
{{{
but who cares. All seems to be OK.
Create article with following HTML:
{{{
}}}
Browser will get:
{{{
}}}
Now isn't that cool? But check what is even cooler!
Create article with following HTML:
{{{
}}}
Browser will get:
{{{
NO IT’S BUGGY AS HELL
}}}
Wow! Say hello to invalid markup and rendering problems! Auto-closing of tags turned off. No matter of the settings I still get this nice messed up html. WYSIWYG turned off also.",retrib
1,11678,wpautop() fails on uppercase closing tags,,Formatting,2.9,normal,normal,,defect (bug),new,dev-feedback,2009-12-31T11:26:11Z,2019-06-04T19:42:47Z,"To reproduce, in a post enter:
{{{
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
}}}
View the post (source) and you get:
{{{
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
}}}
Because I (incorrectly) entered an uppercase closing tag, wpautop() thinks there is no closing tag so adds a , which then often renders as a double
tag. Close if this is not a bug, though I thought it may be good to do some sanitizing or something on uppercase tags.
",joehoyle
8,27733,wpautop(): \s in regex destroys some UTF-8 characters,,Formatting,0.71,normal,major,,defect (bug),new,needs-unit-tests,2014-04-09T09:17:39Z,2022-01-18T13:48:21Z,"\s in preg_replace() incorrectly targets some UTF-8 characters.
'''Steps to reproduce:'''
1. Create a post with
{{{
ム
new line
}}}
as a content.
2. It will be output as
{{{
� \n
}}}
'''Solution:'''
Use [\r\n\t ] rather than \s.",tenpura
,34592,wptexturize interprets apostrophe at end of word as closing single quote,,Formatting,4.3,normal,normal,,defect (bug),new,,2015-11-05T11:07:35Z,2019-06-04T19:53:30Z,"In the example
`Let's meet at Chris' place`
wptexturize interprets the first special character as an apostrophe and the second special character as a closing curly single quote.
In English, the result is `’` regardless. However, some localization files use closing curly single quotes that differ from apostrophes.",floffimedia
,29913,wptexturize should handle broken HTML consistently,,Formatting,1.5,normal,minor,,defect (bug),new,needs-unit-tests,2014-10-10T00:38:40Z,2019-06-04T19:46:35Z,"Spunoff from ticket:29557#comment:93 because it's not that important.
When encountering broken HTML, `wptexturize()` should match web browser behavior, without getting too complicated. This bug is for:
1. unclosed comments: `
paragraph testitalic
normal
paragraph
paragraph
paragraph
line
paragraph
paragraph
paragraph
Honor
this whitespace
paragraph
paragraph
paragraph
text
}}}
=== Output
{{{
paragraph
paragraph test
italic
normal
paragraph
paragraph
paragraph
line
paragraph
paragraph
paragraph
Honor
this whitespace
paragraph
paragraph
paragraph
text
}}}",stefanrz
,26868,"Function 'make_clickable()' doesn't make hyperlinks from explicit URLs using the `mailto:`, `tel:` and other schemes that do not start with `//`",,Formatting,3.8,normal,normal,,enhancement,new,needs-unit-tests,2014-01-18T16:00:14Z,2019-06-04T19:45:21Z,"Function `make_clickable()` tries to recognise URLs and convert these into clickable hyperlinks. The function is by default configured as a filter for comment text.
Unfortunately, the function assumes that all explicitly declared URLs begin with the string `//` after the scheme and colon parts which is not the case for the `mailto:`, `tel:` and many other schemes. Such URLs could usefully be made clickable, especially for use on smartphones and tablets.
This also leads to inconsistencies between explicitly and implicitly declared URLs. For example, the string `myemail@mydomain.com` is converted into a clickable hyperlink whilst the string `mailto:myemail@mydomain.com` is not.
By contrast, the TinyMCE post editor correctly and automatically makes both implicit and explicit `mailto:` links clickable but does nothing with `tel:`.
For reference, the syntax of URLs is defined by http://tools.ietf.org/html/std66, the `mailto:` scheme by http://tools.ietf.org/html/rfc6068 and that for `tel:` by http://tools.ietf.org/html/rfc3966.
As #16892 has illustrated, parsing URLs can be hard. The use of `wp_allowed_protocols()` may help in detecting which strings we wish to make clickable.
Found whilst testing #22946.",mdgl
1,24225,Improve regular expressions when matching attributes,miqrogroove,Formatting,3.6,normal,normal,,enhancement,assigned,needs-unit-tests,2013-04-29T15:37:56Z,2019-06-04T19:44:41Z,"When working with HTML attributes in various functions we use something like `[\'""](.+?)[\'""]` to match the attribute value. Although not used much in attribute values, such an approach breaks when a single or double quote is intentionally part of the value:
* `attr=""val'ue""`
* `attr='val""ue'`
Some of these are new 3.6 functions, mostly around media.",kovshenin
2,30531,Make wptexturize the last filter before output,azaozz,Formatting,,normal,normal,,enhancement,assigned,,2014-11-27T20:30:22Z,2019-06-04T19:46:52Z,"This will allow it to be simplified/refactored and run faster.
Advantages:
- Not looking at shortcodes as it will run after do_shortcode(). That will make it less complex and faster. This also avoids all edge cases with shortcodes.
- Better detection/handling of quotes around `
` tags as it will run after wpautop(). Also, preg_split() will split the text in more chunks which will be easier to process.
Disadvantage: the `no_texturize_shortcodes` filter will stop working.
",azaozz
8,26759,New Generic Sanitize Functions for Core,,Formatting,3.8,normal,normal,,enhancement,new,dev-feedback,2014-01-02T17:54:48Z,2019-06-04T19:45:16Z,"Core currently supplies a number of sanitize functions:
{{{
sanitize_email()
sanitize_file_name()
sanitize_html_class()
sanitize_key()
sanitize_meta()
sanitize_mime_type()
sanitize_option()
sanitize_sql_orderby()
sanitize_post_field()
sanitize_text_field()
sanitize_title()
sanitize_title_for_query()
sanitize_title_with_dashes()
sanitize_user()
}}}
They all sanitize by usage, not by data type.
As such, I (and I suspect others) wind up using these to escape things they weren't initially meant for -- for the sake of brevity, and it's just quicker and leads to tidier code.
I believe it could result in better and simpler sanitizing if we were to include sanitize-by-format functions in core. For example,
{{{
wp_sanitize_numeric( $raw ); // [\d]
wp_sanitize_numeric_float( $raw ); // [\d\.,] allowing both commas and periods as decimal indicator and thousands seperator
wp_sanitize_hex( $raw ); // [\da-f] case-insensitive
wp_sanitize_alphanumeric( $raw ); // [\da-z] case-insensitive
wp_sanitize_letters( $raw ); // [a-z] case-insensitive
wp_sanitize( $raw, $regex ); // uses passed in regex to determine what to strip.
}}}
The specific functions to use are up for discussion. I'm just hoping to make it simpler for users to sanitize data by expected type.
As a side note, this will let folks use `wp_sanitize_numeric()` to sanitize integers larger than `PHP_INT_MAX` -- which tumblr and twitter IDs often happen to be for imports and feeds and the like (as casting to `(int)` isn't a good idea).",georgestephanis
1,22330,Optimize regexes to remove protocol from URL,,Formatting,3.4.2,normal,normal,,enhancement,new,needs-unit-tests,2012-10-31T09:30:48Z,2019-06-04T19:44:10Z,"Regexes used to chop off the protocol of a URL should be anchored to the start of the string.
1. The regex fails faster and thus avoid useless work. No need to look further down the URL for strings like `""http://""`.
2. The regex should not alter any URLs that might be contained in the query string.",GeertDD
2,22402,Stripping non-alphanumeric multi-byte characters from slugs,,Formatting,,normal,normal,,enhancement,new,dev-feedback,2012-11-10T05:07:10Z,2019-06-04T19:44:12Z,"`sanitize_title_with_dashes()` strips non-alphanumeric characters from a title to create a slug. Unfortunately it only strips ASCII non-alphanumeric characters. Apart from a few exceptions, all multi-byte characters are preserved. This means all non-Western (and plenty of Western) non-alphanumeric characters end up in the slug as they're treated just like any other multi-byte character.
As an example, here are some common non-alphanumeric Chinese characters which would ideally be stripped from slugs, but are not:
* 。 (U+3002, Ideographic Full Stop, %E3%80%82)
* , (U+FF0C, Fullwidth Comma, %EF%BC%8C)
* ! (U+FF01, Fullwidth Exclamation Mark, %EF%BC%81)
* : (U+FF1A, Fullwidth Colon, %EF%BC%9A)
* 《 (U+300A, Left Double Angle Bracket, %E3%80%8A)
* 》 (U+300B, Right Double Angle Bracket, %E3%80%8B)
Obviously it would be impractical to make a list of ''all'' the non-ASCII characters we want to strip from slugs. The list would be gigantic.
So the question is, would it be possible to use Unicode ranges to blacklist (or whitelist) whole ranges of characters to be stripped from (or preserved in) slugs? Is this practical or even desirable?
Or would it make more sense to continue using a list of just the most common multi-byte characters to be stripped?
The latter makes a whole lot more sense, but the former is a more complete solution.
Thoughts?",johnbillion
,12084,allow preserving HTML in the_excerpt (specify allowed tags for strip_tags in wp_trim_excerpt),,Formatting,3.0,normal,normal,,enhancement,new,has-patch,2010-01-29T22:36:40Z,2019-06-04T19:42:50Z,"Right now, `wp_trim_excerpt` is destructive. You can filter it, but once tags are stripped, you can't get them back without recreating the excerpt from the raw input. It would be nice if theme developers had an option to preserve at least some of the HTML formatting when using excerpts as post teasers (see #9260). ",sillybean
7,25856,debug of wpautop function with Unit Tests,,Formatting,3.8,normal,normal,,enhancement,new,,2013-11-07T03:04:23Z,2019-06-04T19:45:03Z,"== Cleanup / Refactor of wpautop function ==
Upon review of the WordPress Trac needs-unit-test filter I saw that the wpautop function was needing both cleanup and unit tests. I have created a comprehensive test suite for the function that covers in my opinion the full breadth of use cases for the function. During this process I have been working on modifying the wpautop function to resolve out open defects and remove ''fix'' code that was placed to resolve an issue without resolving the underlying cause of the error.
I've attached the following files for support of the changes.
''autop-20622.out'' --> OUTPUT from running the unit tests against current code base (revision 20622)
''autop-diff.out'' --> OUTPUT from running the unit test against modififed wpautop function as given in the diff.
''Autop.diff'' --> diff of changes made to the Autop test class :: Unit Tests
''formatting.diff'' --> diff of changes made to the formatting.php function file :: wpautop changes
''As a note I've added a trim call to the end of wpautop as it was always appending a new line, which I did not think was needed. This causes a good amount of test cases to fail as the expected output is not containing the additional new line given by current implementation.''
----
== Enhancements / Fixes to wpautop function ==
1. Corrected core logic to identify when double new lines wrap open or close block element tags due to nested block level elements. Original Logic adds \n\n before open tags and \n\n after close tags which allows for output of
TEXT that is not correct, and had several patches implemented to attempt to fix.
*Fixes :: Formatting of Lists, Nested Lists, orphaned
tags
2. Added logic to not add tags after comments
3. Added logic to not convert \n for svg, math, style, select or script codes
4. Added logic to not format audio, video or object elements. This is implemented as the elements are in-line but can contain block level content for displaying in browsers that don't support the HTML5 elements.
5. case insensitive recognition of block tags
6. inclusion of variable re-naming as outlined in #25516
----
== Overview of Tickets reviewed and covered by the Unit Tests ==
Ticket : Current Status : Summary
#6877 : Closed : large posts causes empty return
#3476 : Closed : Improper formatting of Object elements, additional and no ending
#3669 : Closed : Don't insert
tags inside of block elements that only contain inline elements/text
#6809 : Closed : wpautop correctly handles auto
of basic text
#11024 : Closed : Incorrect handling of div tags with nested inline tags
#1305 : Closed : Handling of blocks>
#1706 : Closed :
tags with attributes introduce additional
#2285 : Closed : Strip excessive in content
#2813 : Closed : elements added instead of
#3007 : Closed : Spacing of text in block elments reveals improper handling of nested elements
#3035 : Closed : Extra tags introduced in Object tags.
#3238 : Closed : Dangling
tags, no closing
#3621 : Closed : Don't format new lines in Script and Object tags
#3854 : Closed : Don't format new lines in Script and Style tags
#3935 : Closed (wf) : Erroneous
tags added to the content '''has fix'''
#3952 : Closed : Don't autop hr tags
#5250 : OPEN : incorrect handling of lists + nested Lists '''has fix'''
#7937 : Closed : incorrect handling of inline tags
#7988 : Closed (wf) : incorrect handling of nested tags '''has fix'''
#8644 : Closed : HTML5 block elements
#10033 : OPEN : autop does not handle Comments '''has fix''' *also contains wptexturize details that I am not sure are fully closed out.
#11257 : Closed : autop errors out on large content
#11678 : OPEN : autop does not recognize upper tags '''has fix'''
#13340 : OPEN : nested MATH tag handling '''has fix'''
#2833 : OPEN : No formating Style and Script tags '''has fix'''
#4298 : Accepted : handling of tags with attributes on new lines '''fix already existed'''
#3833 : OPEN : incorrect
tags in block elements (explicitly blockquote) '''has fix'''
#6041 : Closed : incorrect handling of DL lists and DT,DD elements
#9437 : OPEN : dont modify SVG content '''has fix'''
#10247 : Closed : no new lines in Video, Audio, Source
#4857 : OPEN : incorrect autop logic '''has fix'''
#15918 : OPEN : incorrect handling of nested tags '''has fix'''
#16456 : Closed : input is not block level
#3054 : Closed : input is not block level
#16790 : Reviewing : functional specifications '''can close'''
#18534 : Closed : noscript are block level
#20444 : OPEN : Single line handling (nested block level issue) '''has fix'''
#18136 : OPEN : extra tags being added due to white space '''has fix'''
#23135 : OPEN : block element filter '''close as won't fix'''
#18807 : Closed : samp is not block level
#25516 : OPEN : variable name changes '''changes included'''
#9305 : Closed : handling of empty content
#6218 : Closed : handling of empty content
#11947 : Closed : no formating of select options '''has fix'''
#12335 : Closed : HTML5 Block Elements
== Tickets concerning ShortCode handling ==
Ticket : Current Status
#12061 : OPEN
#6984 : OPEN
#21689 : OPEN
#24085 : OPEN
#24846 : OPEN
''Currently the wpautop function does not concern itself with shortcodes. I suggest that 12061 remain open as a future enhancement and that other tickets can be closed referending 12061 unless there is issues with '''shortcode_unatop''' or other functions used.''
== Tickets Reviewed but Ignored/ Not Tested/ Duplicate ==
'''Ticket''' : '''Current Status''' : '''Summary'''
#11249 : Closed : standalone function
#10490 : Closed : Duplicate of #10082
#9218 : Closed : Duplicate of #4298
#19934 : Closed : Duplicate of #16456
#18330 : Rejected : Enhancement
#18514 : Rejected : Enhancement
#23858 : Closed : Duplicate of #18807
#23375 : Closed : Duplicate of #18807
",mdbitz
1,34390,Gallery - images order,,Gallery,4.3.1,normal,normal,,defect (bug),new,,2015-10-21T16:55:11Z,2019-06-04T19:52:47Z,"I already asked here, but nobody answered:
https://wordpress.org/support/topic/media-manager-shuffle-images-all-the-time?replies=10
Seems as it is a bug, or oversight because you maybe dont test this real life scenario case. I know now what triggers this problem, did not know when asked in this topic.
Some short info:
- Have this problem in 1-2 years.
- Installed new and clean Wordpress (to exclude my code lines or plugins)
- Default theme, no plugins, no custom code in functions.php, no custom code in wp-config.php, .htaccess.
How to trigger problem:
- Add new post.
- Open media manager and insert many images (In my case was it 280 images uploaded at once. I make multiple galleries on separate subpages to reduce page load). But for your test you can have maybe 100 images uploaded in this post, not so important.
- When uploading finished you will see that all images are sorted in perfect order.
- Just for clean test close modal box and open it again Add Media and chose Create Gallery.
- Images are still sorted in perfect order.
- Go to the first image media manager uploded in this batch. In my case as it was clean installation it was image first at the bottom (but you get it).
- Now comes part how you trigger glitch/bug.
- If you mark first uploaded image and hold Shift arrow on keyboard, and if you CLICK ONLY ONCE at last image you want in your gallery, sorting in gallery (backend and frontend) is still perfect and OK.
- But, if you hold Shift key and keep clicking on row after row (to be able to see number of images in gallery at the bottom bar ""#No selected""), then problems comes and seems as JS code is confused and shuffle many images.
- Problem will be visible in next modal window where you chose gallery settings, in post self and on the front.
Shift and click on last image wished in gallery = perfect order.
Shift and click several time around before you decide what to mark = shuffled images.
[[Image(http://s7.postimg.org/4o50g6cpn/2015_10_21_184256.jpg)]]
[[Image(http://s17.postimg.org/t0c4blrin/2015_10_21_184859.jpg)]]
[[Image(http://s9.postimg.org/4msb88s9r/2015_10_21_185039.jpg)]]",Stagger Lee
3,13425,Image Gallery of Private Post is publicly displayed,,Gallery,3.0,normal,normal,,defect (bug),reopened,dev-feedback,2010-05-17T20:12:20Z,2019-06-04T19:42:59Z,"Might have been forgotten only, I just ran over this inconsistency while beta-testing:
'''Description:'''
The Image Gallery of a Private Post is displayed (in another post via the Shorttag with id parameter) whereas, when clicking on the images to go to the attachment page, you get a 404 not found.
'''Example:'''
[http://hakre.wordpress.com/2010/05/17/cui-utils-rev2/#more-1184 Post with Gallery][[BR]]
[http://hakre.wordpress.com/2010/05/17/cui-utils-gnu-tools-fur-windows-32-with-a-simple-setup/gnu-win-cui-util-00-setup/ Attachment of that Gallery]
'''Steps to reproduce'''
Create a new Post, set a title and the Status to private.
Save as Draft.
Preview it, to get the ID easily from URL.
Upload a Bunch of Images.
Insert the Gallery Shorttag inside that Post Body.
Publish the Post.
Create a second new Post
Give it a Title and Insert the Gallery Shortcode with the ID from the last Post.
Publish.
View.
Copy the URL.
Open another Browser so to have a new User-Session.
Visit that URL.
'''Expected Behaviour'''
You should not see a gallery.
'''Behaviour'''
You see a gallery.
When clicking on a gallery link you get a 404 page.
'''Feedback'''
I see an inconsitency here but have no Idea how to deal with it.
So either the gallery should not be found as well (not found as in 404 but in this case: not output) or the attachment pages should be able to call as well.
Related: #11697",hakre
1,37157,Photo galleries are displaying EVERY photo in library (and related issues).,,Gallery,4.5.2,normal,normal,,defect (bug),new,,2016-06-23T03:21:21Z,2019-06-04T19:59:42Z,"
'''ISSUE 1.)'''
* With WordPress Permalinks set to ""Post Name"", any photo gallery that has been added to a page displays EVERY photo in the media library.
For example if you've added a gallery of 3 photos, 3 thumbnails are displayed on the page, but entering the gallery will allow you to click ""next"" to view every photo that has been uploaded to the WordPress site.
This has been tested in a fresh install of WordPress (version 4.5.3) and with the themes Twenty Thirteen through Twenty Sixteen.
In this case WordPress Permalink settings have been set to ""Post Name"". If Permalinks are instead set to ""Plain"" (the default) this does not seem to be a problem. I have not tested out other Permalink settings to see if they work.
An internet search brings up two discussions related to this issue which do not appear to have been properly resolved:
* https://wordpress.org/support/topic/gallery-showing-all-images-in-media-library?replies=12
* https://wordpress.org/support/topic/gallery-showing-all-images-in-media-library-1?replies=4
'''ISSUE 2.)'''
* Single photos added to a page are no longer viewable within a gallery.
If you've added a single photo (not a gallery) to a page that also contains a gallery, and if that single photo is also part of the gallery's thumbnail group, it is longer a part of the actually gallery. You can no longer view that image by entering the gallery even though it is shown in the gallery's thumbnails.
In this case the single photo is set to ""link to attachment page"". Permalinks are set to ""Post Name"".
'''ISSUE 3.)'''
* Single photos added to a page have incorrect attachment link by default. In this case Permalinks are set to ""Post Name"".
If you add a single photo to a page and leave the default ""link to attachment page"" set, the link is incorrect; it is missing the page name in it's path. If you then go back to edit the page again and look at the details of the photo, you can see that it has changed to ""link to custom URL"" but is still showing the same incorrect link. Changing this back again to ""link to attachment page"" corrects the link by adding the page name to the path.
I have not tested this with other Permalink settings.
'''ISSUE 4.)'''
There seems to be a problem with galleries not displaying all photos when certain other pages are in the ""trash"".
For example, after deleting a page titled ""try"" which contained the image ""cake"", another page would not display ""cake"" within a photo gallery.
Clicking on the ""cake"" thumbnail in the photo galley opened the attachment page ""try__trashed/cake/"" and would not slide to the next photo. Clicking on any of the other thumbnails in the gallery would work, but would never slide to ""cake"".
",webtechmailbag
1,36269,WordPress 4.4.2 Gallery Ordering,,Gallery,4.4.2,normal,normal,,defect (bug),new,reporter-feedback,2016-03-17T16:01:00Z,2019-06-04T19:56:16Z,There seems to be an issue with the ordering functionality in the latest version of WordPress. Wordpress seems to ignore/misunderstand gallery image order.,aj@…
4,29023,Galleries: add pagination option,,Gallery,3.9.1,normal,normal,,enhancement,new,,2014-07-25T08:28:03Z,2019-06-04T19:46:13Z,"Galleries are great, but if you add a lot of images to a single gallery the page will take a while to load.
I think it would be nice to add a new option, maybe just a new gallery shortcode parameter at first, that would allow post authors to define a number of images per page, thus breaking galleries into different pages, much like we do with [https://codex.wordpress.org/Function_Reference/wp_link_pages single post pagination] today.
",jeherve
1,34396,Gallery shortcode : make image captions relative to the current gallery,,Gallery,3.5,normal,normal,,enhancement,new,,2015-10-22T12:57:02Z,2019-06-04T19:52:58Z,"In the media frame, the ""Caption"" field is used to set a caption for images. But this field has several other effects that are not always intended by the website author.
* Changes to this field are saved on the database (in the excerpt field of the attachment post) as soon as the field is unfocused : no preview is possible, changes are put online directly. Changes are still applied even if ""Update"" button is not clicked.
* For single image insertion, caption is saved in the post content, inside the [caption] shortcode. But for multiple images, caption is saved globally, not inside the [gallery] shortcode.
* When modifying a gallery, changing the caption field right under the image also updates the caption field on the right panel, and saves it globally when the focus is moved. So even when the ""Update gallery"" button is not clicked, the changes are still saved in the database, but they are not reflected in the editor until the page is reloaded.
* When an image is use in several galleries, updating the caption associated with this image in one gallery also updates the caption on the other gallery. This is very different from the behavior of other fields displayed on the right panel (columns, link to, size) that change only the current gallery.
* Modifying the caption field is the attachment details edition view or in the media library grid view will change the caption used for this image in a gallery.",Fab1en
,37409,Broken & illogic conditional check in wp_get_document_title(),,General,4.5.3,normal,normal,,defect (bug),new,,2016-07-19T11:53:24Z,2019-06-04T20:00:19Z,"
{{{
/*
* If we're on the blog page that is not the homepage or
* a single post of any post type, use the post title.
*/
} elseif( is_home() || is_singular() ) {
$title = the_title_attribute('echo=0');
}}}
should be changed to:
{{{
/*
* If we're on the blog page that is not the homepage or
* a single post of any post type, use the post title.
*/
} elseif( !is_home() || is_singular() ) {
$title = the_title_attribute('echo=0');
}}}
For now it does not lead to wrong title because the previous condition is_front_page() is catching this before it throws out a wrong title but it should be fixed before it leads to issues when someone decided to do some changes on wp_get_document_title().
You can reproduce a possible error with commenting the condition is_front_page() in wp_get_document_title(). Than visit a frontpage with multiple blog posts. You will see that the wp_get_document_title() will return than the title of the first blog post and not the site title as expected.
",ReneHermi
3,30613,Check the return value of wp_json_encode(),,General,4.1,normal,normal,,defect (bug),new,has-patch,2014-12-06T10:08:13Z,2019-06-04T19:47:01Z,"It's possible for `wp_json_encode()` to return `false`, same as `json_encode()`. Everywhere in core, this will cause either invalid JS to be produced, or invalid JSON to be returned to an ajax call.
We need to sanity check the return value, and switch `false` for an appropriate response.
This ticket is branched from discussion in #28786.",pento
,28563,Dashicons transition,,General,3.9.1,normal,normal,,defect (bug),new,,2014-06-17T12:03:47Z,2019-06-04T19:45:54Z,"In /wp-includes/css/dashicons.css there is:
{{{
.dashicons,
.dashicons-before:before {
display: inline-block;
width: 20px;
height: 20px;
font-size: 20px;
line-height: 1;
font-family: ""dashicons"";
text-decoration: inherit;
font-weight: normal;
font-style: normal;
vertical-align: top;
text-align: center;
-webkit-transition: color .1s ease-in 0;
transition: color .1s ease-in 0;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
}}}
The `-webkit-transition: color .1s ease-in 0; transition: color .1s ease-in 0;` part should be removed because it's not related to what this block of code is supposed to do. There can be another CSS class like `.dashicons-animation-color { -webkit-transition: color .1s ease-in 0; transition: color .1s ease-in 0; }` for that.
Some plugins and themes may want some kind of animation on icons, not necessarily color animation though but most don't want animations. They have to overwrite this to `transition: none;` in most cases now.
This project did it OK, they have perfect classes in their CSS file: http://fortawesome.github.io/Font-Awesome/",Looimaster
,33344,"Do not force draggable elements on touch devices, stop using touch-punch.js",,General,,normal,normal,,defect (bug),new,,2015-08-11T22:07:01Z,2019-06-04T19:50:32Z,"Having draggable elements on touch screen devices doesn't work well in most cases. It interferes with the standard scrolling, dragging an element off the page doesn't scroll it either. Examples: Menus, Widgets, Dashboard (rearranging the layout), Customizer => Menus and Widgets, etc. This is especially bad on Android as drag/drop is disabled for iOS in several places.
",azaozz
,59163,"Fatal error: Cannot declare class WP_Metadata_Lazyloader, because the name is already in use in /home1/tarotcardco/public_html/wp-includes/class-wp-metadata-lazyloader.php on line 32",,General,,normal,normal,,defect (bug),reopened,,2023-08-22T07:45:57Z,2023-08-22T11:24:59Z,i can not login to backend how to fix this error,ashwiniravipatil
,32392,HTML entities in Pingback notifications?,,General,,normal,normal,,defect (bug),new,,2015-05-14T12:35:30Z,2019-06-04T19:49:15Z,"Pingback email notification contains following part:
{{{
Comment: […] some text […]
}}}
But HTML entities are ugly and when I searched for older notifications, I found that there was `[...]` sometimes before.",pavelevap
,30922,"Link Manager: Doesn't support relative URLs for ""Image Address""",,General,4.1,normal,normal,,defect (bug),new,,2015-01-06T00:24:56Z,2019-06-04T19:47:21Z,"For links, the ""Edit Link"" page allows be to put in any of
* {{{http://blog.hartwork.org/__images/gentoo3-150x30.png}}}
* {{{https://blog.hartwork.org/__images/gentoo3-150x30.png}}}
* {{{/__images/gentoo3-150x30.png}}}
for a working image URL but
* it mis-corrects {{{__images/gentoo3-150x30.png}}} to {{{http://__images/gentoo3-150x30.png}}} and
* setting it to {{{//blog.hartwork.org/__images/gentoo3-150x30.png}}} remains untouched but results in broken final URL {{{http://blog.hartwork.org//blog.hartwork.org/__images/gentoo3-150x30.png}}} on the blog itself (which is unexpected).
Without patching code, what are my options?
This behaviour is actually not new in 4.1 btw.",hartwork
2,31778,Opening the collapsed admin menu doesn't close toolbar submenus,,General,,normal,normal,,defect (bug),new,,2015-03-26T20:31:38Z,2019-06-04T19:48:36Z,"On a narrow touch device, toolbar dropdowns only open one at a time, but opening the admin menu does not close any dropdowns and is shown behind any open dropdowns, making it impossible to get to any of the higher items. This is particularly bad because you can't always close the submenu (see #29906). Opening the admin menu should close any other toolbar dropdowns - it's fine to continue to have toolbar dropdowns open over the admin menu if it's already open.",helen
3,31725,Protect against jQuery being downgraded by poorly coded plugins and themes,,General,,normal,normal,,defect (bug),new,,2015-03-22T10:15:09Z,2019-06-04T19:48:29Z,"I'm sick to death of plugins and themes that replace core's jQuery with their own version or link to Google's CDN but without matching version numbers, or hardcode an additional version that overwrites `jQuery`. It causes so many headaches.
I'm willing, at this point, to consider drastic measures. How can core protect against this?",markjaquith
10,36946,Provide `id` properties on core objects,,General,,normal,normal,,defect (bug),new,,2016-05-26T00:22:39Z,2019-06-04T19:58:44Z,"In #36717, `WP_Site` and `WP_Network` will get magic getters/setters so that `id` and other more properly named properties can be used.
We should standardize on `id` rather than `ID` for core objects where it makes sense.
Current primary IDs for objects are:
* `WP_Comment` -> `comment_ID`
* `WP_Post` -> `ID`
* `WP_Term` -> `term_id`
* `WP_User` -> `ID`
* `WP_Widget` -> `id`
* `WP_Screen` -> `id`
`WP_User` is somewhat unique because the property was `id` and then deprecated in [18504] in favor of `ID`. We should be able to un-deprecate this.",jeremyfelt
3,33308,Responsive list tables don't handle primary columns that are not the first non-checkbox one,,General,4.3,normal,normal,,defect (bug),new,,2015-08-08T02:11:05Z,2019-06-04T19:50:28Z,"In #25408, we introduced the concept of a primary column for list tables, which is where row actions are placed and the column that appears in the small screen responsive view (see #32395). However, due to the way the toggled columns are handled, any non-checkbox columns before the primary one still appear before the primary, which does not look good. See attached screenshot for an example of defining the ""name"" column for users as the primary instead of username.",helen
5,54759,"Shortcodes are not working in page templates in the new ""Beta"" editor",,General,,normal,normal,,defect (bug),reopened,,2022-01-07T09:08:11Z,2022-11-04T17:21:01Z,"The shortcode block does not transform the shortcodes in the page template of the new ""beta"" editor (located at Appearance > Editor (beta)) of the full site editing when the shortcode is added to the ""content"" area, not into the ""Header"" or ""Footer"". (It works fine from these two.)
For testing I created a new plugin which only contains the following code:
{{{#!php
Editor
3. Click on the WordPress icon at the left site
4. Select Templates > Page
5. Add a new shortcode block above Post title (https://imgur.com/5lFPgtE)
6. Write this code there: {{{[note]test[/note]}}}
7. Save the template
8. Create a new page
9. Add a new shortcode block and write the same shortcode there (https://imgur.com/5lFPgtE)
10. Save the page and check it
You’ll see the {{{[note]test[/note]}}} code is displayed above the post title, but the yellow block shows correctly up below.
https://imgur.com/orEyhvI
I've also opened a post in the alpha-beta forums:
https://wordpress.org/support/topic/shortcodes-are-not-working-in-page-templates/
",nextend_ramona
1,33112,Suppress calls to ini_set in core,,General,,normal,normal,,defect (bug),new,,2015-07-24T14:24:43Z,2019-12-30T23:39:03Z,"On many shared hosts, the PHP function `ini_set` is disabled for security reasons. Calls to the function when it is disabled generate a warning that is usually not shown to the user because `display_errors` is configured as such. However, this event is still logged and for high traffic sites, this can create a ton of events.
You can suppress warnings from this function by prepending an `@` symbol to the beginning of each call. We are already doing this in many places in core.
By running `grep -r ""[^@]ini_set"" .` in the root of a WordPress installation, all occurrences will be located.
In addition, the following command can be run in the root to patch all occurrences by prepending with an `@` symbol.
{{{
find . -type f -exec sed -i 's/@*ini_set/@ini_set/g' {} \;
}}}
This searches the current directory for all occurrences of `ini_set` with zero-or-more occurrences of `@` prepended. This is an idempotent command in that it should produce the same results if run many times. It could be made part of a build preparation process to clean occurrences of `ini_set` without suppression.
I will be attaching a patch that makes these changes!
Thanks!",mdwheele
4,35154,The admin_url filter might break ajaxurl usage,,General,,normal,normal,,defect (bug),new,reporter-feedback,2015-12-18T12:46:04Z,2019-06-04T19:54:22Z,"`ajaxurl` is a javascript global generated basically as
{{{
var ajaxurl = '';
}}}
`admin_url()` results get filtered by `admin_url`, which might add query arguments into `ajaxurl`, or at least modify it on a substantial way.
We have several instances where we assume that `ajaxurl` will be an URL without query arguments, like this one:
{{{
// wp-admin\js\tags-box.js 179
ajaxurl + '?action=ajax-tag-search&tax=' + tax,
}}}
That assumption might be completely wrong.
I am attaching a list of places where we define `ajax_url` and a list of places where we assume it is a clean, query-arguments-free URL. Note that those lists might not be complete, although I greped against WordPress trunk.
As a solution idea, we might want to create a javascript version of `add_query_arg()` and use it extensively.",jadpm
,28801,Walker::walk makes an incorrect assumption if $top_level_elements is empty.,,General,3.8,normal,normal,,defect (bug),new,needs-unit-tests,2014-07-09T16:02:56Z,2019-06-04T19:46:05Z,"A colleague of mine was generating a sidebar sub-navigation for one of his projects. The subnavigation contained second-level and third-level navigation elements.
The problem my colleague was having was that occasionally third-level elements would not be nested underneath their parent element (also in the list of elements) on some pages.
My colleague was calling wp_list_pages with an array of page IDs that he wanted to render in the sub-navigation, wp_list_pages then turned the list of page IDs into a list of Page objects, and it sorted the page objects by their 'menu_order' attribute; the third-level navigational elements all had their 'menu_order' set to 0, whereas the second-level navigational elements all had 'menu_order' set to something more than 0 - causing the third-level elements to be the first elements in the list.
wp_list_pages later made a call to Walker::walk, passing along that list of pages. Here is a relevant code snippet from Walker::walk:
{{{
/*
* When none of the elements is top level.
* Assume the first one must be root of the sub elements.
*/
if ( empty($top_level_elements) ) {
$first = array_slice( $elements, 0, 1 );
$root = $first[0];
$top_level_elements = array();
$children_elements = array();
foreach ( $elements as $e) {
if ( $root->$parent_field == $e->$parent_field )
$top_level_elements[] = $e;
else
$children_elements[ $e->$parent_field ][] = $e;
}
}
}}}
'''The bug is this code's assumption that the first item in $elements is a suitable root-element for the entire list''' (sentence emboldened for anybody not wanting to read the wall of text). wp_list_pages ordered our list by 'menu_order' which put our 3rd-level elements at the top of the list - causing a 3rd-level element to be treated as the navigation's root.
I wrote up a quick fix for this (I'm not sure if it's the best fix, I'm not overly experienced in Wordpress), and for our project we'll use wp_list_pages with a custom walker class that implements my fix.
Here is the patch of my fix:
{{{
Index: public_html/wp-includes/class-wp-walker.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- public_html/wp-includes/class-wp-walker.php (date 1404915904000)
+++ public_html/wp-includes/class-wp-walker.php (revision )
@@ -217,12 +217,34 @@
/*
* When none of the elements is top level.
- * Assume the first one must be root of the sub elements.
+ * ~~Assume the first one must be root of the sub elements.~~ Disregard - RJ CGIT 2014-07-09
+ *
+ * ----------
+ *
+ * Modified by Rob Jackson, Castlegate IT; 2014-07-09:
+ * Do not assume the first element is root, instead loop through the elements
+ * until we find one whose parent is _not_ in the list of elements. If that fails,
+ * just fall back to the default behaviour of using the first element.
*/
if ( empty($top_level_elements) ) {
+ $root = false;
+ $element_ids = array_map(function($element){ return $element->ID; }, $elements);
+ foreach($elements as $element)
+ {
+ if (!in_array($element->post_parent, $element_ids))
+ {
+ $root = $element;
+ break;
+ }
+ }
+ unset($element);
+
+ if ($root === false)
+ {
- $first = array_slice( $elements, 0, 1 );
- $root = $first[0];
+ $first = array_slice( $elements, 0, 1 );
+ $root = $first[0];
+ }
$top_level_elements = array();
$children_elements = array();
}}}
Kind regards,
Rob
",rob-castlegate
1,33929,Wrong data type for several variables holding a wpdb query result,boonebgorges,General,,normal,normal,,defect (bug),assigned,needs-unit-tests,2015-09-19T16:27:25Z,2019-06-04T19:51:38Z,"Just like in #32876, there are several situations where the result of `$wpdb->get_var()` is used as is (which is a `string`), and yet data type is said to be `int`. The individual situations include `apply_filters()` calls, function return values, and class properties, i.e., only ''non-local'' usage.
Please find the attached patch that takes care of that.
In one case I also adapted two conditionals using a former-`string/null`-now-`int`-value.",tfrommen
1,35466,`add_filter()` errors when `spl_object_hash()` not exists,,General,4.4.1,normal,normal,,defect (bug),new,,2016-01-15T05:06:37Z,2019-06-04T19:54:52Z,"`add_filter()` will errors when the following conditions are met.
1. `$function_to_add` is Closure
2. `spl_object_hash` function not exists
For example:
{{{
add_filter( 'template_include', function($args){
return $args;
},90 );
}}}",yaquawa
1,34392,"calling update_option(""siteurl"", $newval) can overwrite it with an instance of WP_Error.",,General,4.3.1,normal,normal,,defect (bug),new,,2015-10-21T17:41:50Z,2019-06-04T19:52:53Z,"Hello,
under admittedly somewhat obscure circumstances a call to
update_option(""siteurl"", ...) can overwrite its value with an instance of
WP_Error class.
When being updated `siteurl` is subject to some additional checks in
`sanitize_option()` function, and the bug is due its handling of WP_Error's.
In particular the code at
https://github.com/WordPress/WordPress/blob/4.3.1/wp-includes/formatting.php#L3609-L3612:
- overwrites the `$value` variable with result of the call to
`$wpdb->strip_invalid_text_for_column()` -
- will only create the `$error` variable if the WP_Error received from the call
to `$wpdb->strip_invalid_text_for_column()` contains the optional error
message
If `$wpdb->strip_invalid_text_for_column()` returns an instance of WP_Error
without an error message we end up with `$value` containing a WP_Error instance
but empty `$error` variable.
Then the check at
https://github.com/WordPress/WordPress/blob/4.3.1/wp-includes/formatting.php#L3720
fails due to empty `$error`, and the WP_Error `$value` propagates upwards as the
return result of `sanitize_option()`, to be written into the database. As most
places trust get_option(""siteurl"") to return a string rather than an object this
results in fatal errors as WP_Error can't be converted to a string.
In the specific case I observed, the WP_Error instance without an error message
was originating from `wpdb::get_table_charset()` function -
https://github.com/WordPress/WordPress/blob/4.3.1/wp-includes/wp-db.php#L2306-L2308. From
what I gather `wpdb::strip_invalid_text_for_column()` needs to know the database
charset for the database column to determine valid input, this will eventually
call out to `wpdb::get_table_charset()` and if the query in that function fails
for some reason the resulting WP_Error propagates all the way up to
`sanitize_option()`.
As this was tracked down retrospectively I don't know what exact conditions
allowed the query in `wpdb::get_table_charset()` to fail while allowing any
subsequent queries to succeed, however it can be reproduced with a test case at
https://gist.github.com/pbogdan/9827a8f2358cf9e8ca71
I have not reviewed the logic for other options handled by `sanitize_option()`
but it's possible some of them could be affected if they use the same logic for
dealing with WP_Error's - which relies on the WP_Error having the optional error
message.
I might be bit slow to respond but let me know if there is any additional
information I can provide.
Thanks,
Piotr
",pbogdan
2,36499,"featured image, image upload",,General,4.5,normal,normal,,defect (bug),new,reporter-feedback,2016-04-13T01:35:59Z,2019-06-04T19:57:19Z,"Using Avada theme with WP4.5, many elements have broken since WP4.5 update.
Including:
Slidedeck Slider shows ini_set errors and load.php errors
Fusion Slider - stuck at spinning wheel trying to load slides
Featured Images for blog posts not showing
Add Media into post or page (images wont load to select from)
Surprised this update has affected just about all my sites (about 200) which updated automatically. Now I am trying to revert them all to 4.4x
How did you guys drop the ball this time?",diskmandotnet
,22530,garbage query strings on URLs are not sanitized or removed,,General,3.4.2,normal,normal,,defect (bug),reopened,reporter-feedback,2012-11-21T15:52:50Z,2019-06-04T19:44:14Z,"Here is an interesting problem I ran into, a bug / feature that appears to be used by malicious people to cause Google to see your site as full of duplicate content.
If you visit a wordpress site, and add a garbage query string to the end of the URL, that garbage gets carried forward. Example:
yourblog.here/page/2?ssdlfkjsdlkfjsdfs
When you scroll down, the ""previous"" and ""next"" links will automatically carry that query string forward.
Normally, this would not be a big issue. However, some people appear intent on specifically creating these sorts of links to wordpress sites, and Googlebot is finding those links on remote sites. Those links are followed, and then the ""previous - next"" situation perpetuates the problem through every page on the site. If you have 1000 posts, at 10 per page, Google just indexed 100 duplicate content pages.
So the bug is the following:
Passed query strings need to be sanitized, and junk removed - there is no reason to pass it on. In the case of a junk passed string, there should be an http 301 or 302 reply and the user / bot redirected to the proper page without the query string.
Further, query strings should not be perpetuated forward through the ""previous - next"" links on the pages unless they are relevant to that page change. As an example, a valid search string might be worth moving forward with. Other passed items may not be worth carrying forward.
Potentially, any unsanitized input accepted in a query is a vector for other attacks. Having that query carry forward is a real issue. As an example, full select * from queries are not accepted and not dealt with, and perpetuated forward. No, they are not currently actually causing anything to happen, but a failure to sanitize these inputs suggests a vector for a future attack, such as an input overflow or similar.",rawalex
1,33498,get_home_path does not stripslashes $_SERVER['SCRIPT_FILENAME'] before using it,,General,4.3,normal,normal,,defect (bug),new,needs-unit-tests,2015-08-21T20:41:38Z,2019-06-04T19:50:58Z,"Hello WordPress support,
I'm running WordPress on Windows through Webmatrix and IIS Express 8.5 and FastCGI.
This function has a bug that appears only on windows due to its different path formatting and causes the web.config to not be writable on PHP 5.5 (error from` DOMDocument::load`).
WordPress runs `addslashes` on all `$_SERVER`/`$_GET`/`$_POST` variables which places a burden to remember to stripslashes before using any variable from it.
The `get_home_path()` function does not do this before using `$_SERVER['SCRIPT_FILENAME']`. This doesn't cause a problem on Linux because the path format is not modified by `addslashes`, so it works by coincidence.
But on Windows, this causes the path to have double slashes (example: `C:\\inetpub\\wordpress`). Then it is passed to trailingslashit which gives a weird result:
`C:\\inetpub\\wordpress\`
(apologies, trac is messing up the slashes)
Now, PHP on windows is very tolerant of such paths, but some APIs such as `DOMDocument::load` (test on PHP 5.5) returns an error and logs that it wasn't able to open the file. This is used by WordPress to save the web.config file when it detects IIS.
I have attached a patch that fixes this against WordPress 4.3, but I have seen this in 4.2 as well (didn't test with older).",handsomejack201
,31711,is_front_page flag affected by frontpage ID and page Title strange conflict,,General,3.1,normal,normal,,defect (bug),new,has-patch,2015-03-20T14:04:03Z,2019-06-04T19:48:24Z,"I want to report a strange bug. The ''is_front_page'' flag has incorrect value in cases like described below:
Front page in Settings / Reading is set to a static page: http://i.imgur.com/DzrbOVM.png
This ''Sample Page'' ID is 2
If you visit any other page, all is fine. For example the ''Lorem ipsum'' page: http://i.imgur.com/n5M0x8R.png
However, if you change title of this page to be the same as ID of a frontpage - in my case ''2'', then the ''is_front_page'' flag changes value to incorrect: http://i.imgur.com/KCa1JYo.png
It happens for titles like: 2, 02, 000002. Basically always if (int)$page_title == $front_page_id
The wrong ''is_front_page'' flag may affect themes/plugins which use it.
It's quite rare for the bug to take effect, but it happens, as I got a report from a user of my theme.",m_i_n
1,59252,is_front_page returns false when a static blog page has been set.,,General,2.5,normal,normal,,defect (bug),reopened,,2023-08-31T07:51:12Z,2023-11-03T21:21:16Z,"Hi
I have a question. I do not know if this is a bug or not, but the behaviour of the is_front_page() function is bit ackward.
If no static homepage has been set and you call on the home page the function is_front_page() it returns true. If you call is_home() it also retruns true.
However the moment you set a static blog page (not home page) that same call for is_front_page on the home page returns false, but is_home() still returns true.
Is this a bug? It does not seem consistent to me as there is no static home page set why does is_front_page() return true when no static blog page has been set and return false the moment a static blog page is set.
What has the static blog page set in the reading settings to do with the is_front_page() function?
Can somebody please explain this to me as it does not make sense given the description of is_front_page() function?
Thank you
see image
[[Image(https://share.getcloudapp.com/4guXkxZy)]]
**STEPS TO CREATE THE SAME RESULTS!**
Tested with wp 6.4 latest trunk build clean wordpress. 20-21 theme and php 8.0.x
just add this code to the index.php
{{{#!php
this is home.';
if ( is_front_page() ) echo '---------------> this is frontpage.';
?>
}}}
see image below where i added the php code
[[Image(https://share.getcloudapp.com/lluXB459)]]
The complete altered index.php of the 20-21 theme below
{{{#!php
this is home.';
if ( is_front_page() ) echo '---------------> this is frontpage.';
?>
'list',
'title_li' => '',
'echo' => 0,
'hierarchical' => true,
'depth' => 2,
'taxonomy' => 'my_taxonomy',
'orderby' => 'count',
'order' => 'DESC',
'show_option_none' => ''
);
$args['child_of'] = $current_term->term_id;
}}}
it return only
{{{
Subterm 1.1.1
}}}
Problem is that
{{{
'orderby' => 'count',
'order' => 'DESC',
}}}
when i put it out, it works as expected
BTW IMO wp_list_categories() need some bigger rewrite - it is probably the oldest code in WP :-). No filters, strange classes etc. especially comparing to similar wp_nav_menu. E.g. there is no class to parent LI (and it is often need to change e.g. for Bootstrap), nor any action or filter, the only way are some non-trivial preg_match on the full results or replacing the whole Walker, what is not optimal for forward and plugin compatibility ",thomask
2,31200,wp_redirect Missing Body - Causes Performance Issues,,General,4.1,normal,normal,,defect (bug),new,,2015-02-01T18:56:15Z,2019-06-04T19:47:42Z,"When I changed my site over to a new setup using nginx and Varnish, I noticed some performance issues when doing things like submitting a comment, activating plugins, etc.
I narrowed it down to a problem with wp_redirect not providing a body, and thus nginx does not provide a content length. This causes Varnish to hang, waiting for a body, until it hits a time out (which by default is 5 seconds). This makes any action that involves a redirect take a minimum of 5 seconds (or whatever the time out is set to).
Adding some output to wp_redirect immediately solved the problem for me.
Even though this may relate to a specific nginx/Varnish setup, the HTTP standards also say you should always include some kind of output in the body. Nginx + php-fpm does not do this by default, and given that this is an increasingly common stack it would be useful if it conformed to standards.
The issue can also be sidestepped by adding:
{{{
header( ""Content-Length: 0"" );
}}}
However, this does not conform to RFC specs.
See: http://www.ietf.org/rfc/rfc2616.txt under 10.3.2 and 10.3.3
HTTP 301:
The new permanent URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
HTTP 302:
The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).",tripsis
,34028,wp_safe_redirect can return admin_url() when get_admin_url() is used,aaroncampbell,General,,normal,normal,,defect (bug),reopened,needs-unit-tests,2015-09-25T20:47:48Z,2019-06-04T19:51:49Z,"Setup your site like this:
WordPress Address (URL): http://yourdomain.tld/ (without www)
Site Address (URL): http://www.yourdomain.tld/ (with www)
Example code (yes I know it's stupid code, but it's a working proof-of-concept):
{{{
My div1
My div2
';
echo $str.' '.wpautop($str);
}}}
Produces this output as seen in the page source:
{{{
My div1
My div2
My div1
My div2
}}}
I.e. unbalanced
{{{
}}}
and wrong layout.
",opajaap
,34853,A helper method should be created to centralize which extensions are used for images.,,General,4.4,normal,normal,,enhancement,new,has-patch,2015-12-06T08:44:31Z,2019-06-04T19:53:56Z,"In keeping with the helper methods introduced in `3.6` for audio/media extensions retrieval, the retrieval of image extensions should similarly be wrapped in a filterable method. Currently all places where this information is needed appear to simply define their own array and use that -- very un-DRY.",dan.rossiter
5,32192,Add HTML attribute builder helper function,,General,4.2.1,normal,normal,,enhancement,new,has-patch,2015-04-29T20:01:30Z,2019-06-04T19:49:00Z,"I've seen (and wrote) a lot of plugins which manually build out each HTML attribute as a loop, escaping each value and then removing any attribute that has no value. Wouldn't it be nice if there was a function that does all that for you?
This patch introduces a new function {{{html_attributes}}} which accepts an array and builds out a string of attributes whilst sanitising the values and removing any empty attributes.
I've also updated any uses in core removing the logic and using the function instead. There's probably a few instances still left to update, but this is a good start.",paulwilde
4,34487,"Add a new conditional tag for the ""Posts Page""",,General,4.4,normal,normal,,enhancement,new,has-patch,2015-10-29T19:22:45Z,2019-06-04T19:53:19Z,"Currently, there's no conditional tag to determine whether the current page is the ""Posts Page"", set under Settings->Reading. The codex (https://codex.wordpress.org/Conditional_Tags#The_Blog_Page) describes a way to combine is_home() and is_front_page(), but I propose that we instead add a new conditional tag to deal with this.
Naming the function is a little tricky. Unfortunately, the name ""is_posts_page"" is taken in query.php, so I created a patch that adds ""is_blog_page"". It returns true on the ""posts page"", and false everywhere else.
I've run across this issue in real world projects a couple of times and though it would be a good addition to WordPress. The patch adds this to query.php because is_home() and is_front_page also live there.",roytanck
3,32316,Caps: Pass cap being checked to the 'user_has_cap' filter,,General,3.5.1,normal,normal,,enhancement,new,,2015-05-08T19:19:41Z,2019-06-04T19:49:10Z,"Is there a reason why we don't pass the cap being checked from `current_user_can()` to the `'user_has_cap'` filter?
It would make things way easier for plugins to do checks.",r-a-y
5,32249,Create extendable base classes of WP_Customize_* so that the rest of WordPress can benefit for its API,,General,4.2.1,normal,normal,,enhancement,new,,2015-05-04T17:03:41Z,2019-06-04T19:49:06Z,"This is a grand plan ticket so bare with me here, but I think it has the potential of changing a lot of WordPress for the better.
The Customiser holds a lot of logic for handling form fields that the rest of WordPress could take advantage of. I propose we abstract out these classes so that there's a base class that other parts of WordPress could extend. This would basically be the first step in order to create a consistent API for creating meta box fields (See #), and (eventually) a front-facing API for adding custom fields to taxonomy pages once term meta is in core.
This could also be used to update all of the Setting screens away from tables and having all of those fields registered in the same consistent way as well adding/removing widget & user fields and because the base classes would be a public API plugin developers could extend it and use it for front-end forms and such.
Here's a breakdown of the current structure, and what I'd suggest for abstracting things out:
- {{{WP_Customize_Control}}} holds a lot of logic for rendering form controls that could be used elsewhere inside WordPress for outputting fields by creating a {{{WP_Form_Control}}} class which {{{WP_Customize_Control}}} would extend.
- {{{WP_Customize_Setting}}} holds the logic for saving the values of these controls, so this could be abstracted into {{{WP_Form_Setting}}} and then {{{WP_Customize_Setting}}} extends this base class and holds customiser specific logic (mainly just adding theme_mod as an option).
- {{{WP_Customize_Manager}}} handles the bulk of the front-facing API of adding/getting/removing sections, panels, controls and registering the default controls associated with the customizer. This could extend a {{{WP_Form_Manager}}} class that would handle the majority of this code. {{{WP_Customize_Manager}}} would then simply handle customizer specific things such as panels and creating all of the default objects.
- {{{WP_Customize_Panel}}} and {{{WP_Customize_Section}}} seem to repeat the same code twice except for how each renders the HTML. A separate {{{WP_Form_Group}}} class would be created that moves most of this repetitive code away.
Once the abstraction has happened separate classes could be created that handles object specific areas of the admin (post types, taxonomies, settings, etc).
Advantages:
- As people begin to learn how the customiser API works, once the other parts of WordPress move over to use the same API everything is consistent and easy to pick up. Once you understand how to add fields to the customiser, you automatically know how to do the same everywhere else in WordPress. That currently isn't the case as everything is different.
- Once a control type is added to WordPress core (say for example a WYSIWYG editor) all of WordPress could take advantage of that control. There already seems to be some interest in adding several more control types into the customiser (See [http://wptavern.com/redux-and-kirki-frameworks-join-forces-to-provide-better-support-for-the-wordpress-customizer here]).
- This would give the opportunity to update all of the Setting screens away from tables (See #16413).
- This would pave the way to an API to add fields to post meta boxes, one of the most wanted features by the majority of developers.
- The customiser is moving forward faster than the rest of WordPress. If everything else shared the same API then everything would benefit.
- Although I haven't really digged into the Javascript side of the Customiser I'm going to assume that if everything were to use this API then some of the Customiser code could also be abstracted out so things like conditional display logic could be possible elsewhere inside the admin.
Disadvantages:
- This could potentially create a lot of classes in the long run. I'm not sure if this is a disadvantage as such, but it's at least noteworthy.
If there's any interest in taking things in this direction (oh please let there be), I'd be interesting in helping drive this thing forward. It would be nice to get the base classes complete in 4.3 (maybe its too late now?) so that 4.4 could then begin to take advantage by beginning to move each part of WordPress (release by release) over to the new API whilst adjusting the existing API to still work for backwards compatibility.",paulwilde
3,32469,Create wp-include/views directory,,General,,normal,normal,,enhancement,new,,2015-05-23T02:03:02Z,2019-06-04T19:49:16Z,"HTML/JS/CSS is currently combined with PHP code. So, this is bad practice.
I realize that this is currently used in the entire WordPress code base. Excepting themes, which are loaded on the front-end. Most of the view code is displayed on the admin I believe.
Having views part of the PHP increases the function or method size and is confusing since some parts are evaluated after some parts of the view is displayed, so to process what the code is doing, you need to comprehend both the HTML output along with the PHP execution.
Furthermore, doing this should allow for customizing even the hardcoded view code in functions and methods.
I also propose a helper function that pulls in the views from wp-includes that could probably be extended later to include the current theme file matching the view file name.
While **ABSPATH . 'wp-includes/views/{filename}.php'** would be simple, it wouldn't allow future modifications without again modifying all of the view paths. It should be done once and allow for the future modification of accepting another location for changing the views. ",jacobsantos
,31010,Frontend / Admin specifications for AJAX,,General,4.2,normal,normal,,enhancement,new,,2015-01-14T14:25:34Z,2019-06-04T19:47:31Z,"I recently ran into an issue, not sure where this belongs exactly. If you load posts in Twenty Fifteen via AJAX (by detecting pagination clicks) the images will be narrower, take a look:
http://cl.ly/image/2M15133q2U1D
This happens because when an image is shown, somewhere down the line the image_constrain_size_for_editor() function is called which is in media.php. If a context is not given it uses is_admin() to detect where the request is from.
The problem is that admin-ajax.php is always considered to be in the admin, since it technically is. However, the AJAX request comes from the front-end and the response is used on the front end as well. Here is one method to get around this problem:
{{{
$posts = new WP_Query( $query_vars );
add_filter( 'editor_max_image_size', 'my_image_size_override' );
if( ! $posts->have_posts() ) {
get_template_part( 'content', 'none' );
}
else {
while ( $posts->have_posts() ) {
$posts->the_post();
get_template_part( 'content', get_post_format() );
}
}
remove_filter( 'editor_max_image_size', 'my_image_size_override' );
}}}
This could also be addressed by providing a parameter that is passed to admin-ajax. Just as action is used to transfer the action, another parameter could be added to indicate the origin. I'm not a huge AJAX expert and I'm not sure if this causes any security issues so I am refraining from adding any patches. Aside from the security issue I assume this would affect a lot of functions.
",danielpataki
2,28774,Hooking into wp_ajax_upload_attachment,,General,4.0,normal,normal,,enhancement,new,dev-feedback,2014-07-07T15:20:25Z,2019-06-04T19:46:04Z,"If you want to do something before/after an attachment has been uploaded - or replace the upload function entirely -- there doesn't seem to be a way to do that:
For other `wp_ajax_* calls`, you can unhook them and then hook in your own. This doesn't work for `wp_ajax_upload_attachment` because it ends up getting called directly from async-upload.php.
If we replace the direct call with another set of `do_action/add_action` (like admin-ajax has) you can now hook into upload like the other ajax actions.
See the proposed patch.",jshreve
3,30798,Ideas for improvements to to wp_die() usages,,General,,normal,normal,,enhancement,new,dev-feedback,2014-12-20T19:34:16Z,2019-06-04T19:47:06Z,"When a visitor to or a user of a WordPress powered site encounters a `wp_die()` message (traditionally handled by the `_default_wp_die_handler()` function) it is (likely intentionally) a very jarring experience. Having `wp_die()` produce human readable results is the least amount of assistance we could possibly provide when a not-completely-unanticipated event occurs, and I think in many instances we can provide a more positive experience.
Of our current 230 approximate usages, 33 appear to be `Cheatin’; uh?`'s which, while cute and full of personality, aren't particularly helpful to the innocent user who encounters them, nor are they stern enough to deflect any guilty parties from continuing to seek out unauthorized access.
The remaining 200 approximate usages typically drop an authorized user into a limbo state where their only option is going back in their browser history and hope their drafted content isn't bungled or lost. Maybe tucking some of these requests behind ajax actions would reduce that redirection? Or maybe enabling themes to have a template hierarchy for handling various error messages would be more user friendly?
I don't have a real improvement plan, and don't feel wholly qualified to solve this issue for the entire WordPress community, rather I'm hoping this ticket can foster some discussion about improving this trusted, though somewhat antiquated, piece of WordPress core.",johnjamesjacoby
1,28643,Improve the wp_die experience,,General,3.9.1,normal,normal,,enhancement,new,,2014-06-26T09:20:26Z,2019-06-04T19:45:59Z,"Improve the wp_die experience passing an 'action' argument (possibly as a variable) that will let a user to better recognize which 'action' is executing the wp_die function.
This would be let a user improve better the wordpress wp_die page such as adding specific content or action buttons.
The most wp_die calls, inside wordpress core, pass only a message string, without any reference about action that wordpress has executed before.",virgodesign
4,31559,Meta boxes should have before/after hooks,,General,,normal,normal,,enhancement,new,dev-feedback,2015-03-07T20:38:33Z,2019-06-04T19:47:58Z,"Currently there is no way to hook into an existing metabox. If I wanted to modify the featured image metabox (add a checkbox or something), I'd have to unregister the metabox, and re-register w/ my own callback. This is not good for compatibility w/ other plugins, etc.
I propose before_callback and after_callback hooks for metaboxes.
Basically, we'd replace this:
{{{
echo '
\n"";
}}}
",jtsternberg
3,32558,More compact handling of the filter bar on small screens,,General,,normal,normal,,enhancement,new,,2015-06-03T01:50:09Z,2019-06-04T19:49:22Z,"The ""filter bar"" takes up a lot of vertical space on narrow screens and ends up becoming a point of focus when it is more typically secondary navigation. It's used for theme install, plugin install, and both views of the media library. For themes, it is especially bad because the search input separates the feature filter toggle from the filter controls themselves.
Screenshot:
[[Image(http://s.hyhs.me/baAS/image.png)]]",helen
,31206,Move AJAX action parameters out of the method body and into the declaration.,,General,4.2,normal,normal,,enhancement,new,dev-feedback,2015-02-01T23:09:49Z,2019-06-04T19:47:45Z,"`admin-ajax.php` has several methods that require an `$action` parameter, then immediately set that parameter in the body of the method to the desired string if it's not set, which seems a bit counter-intuitive.
I propose removing the conditional check completely (since it's not checking for a value, just the presence) and move the desired string into the method declaration as a default value.",morganestes
1,36120,Move wp_*_link() functions into wp-includes,,General,,normal,normal,,enhancement,new,dev-feedback,2016-03-05T14:51:04Z,2019-06-04T19:55:44Z,"The following link functions live in `wp-admin/includes/bookmark.php`:
* `wp_insert_link()`
* `wp_delete_link()`
* `wp_update_link()`
I would like to propose that these three functions be moved into `wp-includes/bookmark.php` so that they are available on any request, and not just requests inside `wp-admin`.
It would also be necessary to move the `wp_set_link_cats()` so that it is available inside the `wp_insert_link()` function.
Other similar functions live in `wp-includes` already, such as `wp_insert_post()`, `wp_insert_commet()`, etc. This change would allow links to work in the same way as those other content types.",JPry
,31211,New function for link-category intersection,,General,4.1,normal,normal,,enhancement,new,,2015-02-02T14:29:55Z,2019-06-04T19:47:49Z,"Maybe passed to wp-includes/bookmark.php...
{{{
function link_cat_intersect($input, $args=array() ){
/*
$input (string) - Comma separated list of link-category ID-s to find common links.
$args (array) - $args for get_bookmarks() function http://codex.wordpress.org/Function_Reference/get_bookmarks
Defaults:
$args = array(
'orderby' => 'name',
'order' => 'ASC',
'limit' => -1,
'category' => '',
'category_name' => '',
'hide_invisible' => 1,
'show_updated' => 0,
'include' => '',
'exclude' => '',
'search' => '' );
Example:
$links = link_cat_intersect('65,75',array('include' => '8' ));
Get the common links of link categories 65 and 75, then add the link with id 8 to result.
Return Values http://codex.wordpress.org/Function_Reference/get_bookmarks
(array)
List of bookmark row objects. Each bookmark object may contain the following: 'link_id', 'link_url', 'link_name', 'link_image', 'link_target', 'link_category', 'link_description', 'link_visible', 'link_owner', 'link_rating', 'link_updated', 'link_rel', 'link_notes', 'link_rss'
*/
$input = explode(',',$input);
$input = array_unique($input); // remove duplicates
if( count($input)==1 ){
return new WP_Error( 'broke', __( ""One id is not enough..."", ""my_textdomain"" ) );
}
$keys=$input;
$input = array_combine($keys, array_values($input));
// get the link ids
foreach($input as $cat_id => $posts){
$objects = get_objects_in_term($input[$cat_id],'link_category');
if( is_wp_error( $objects ) ) {
echo $objects->get_error_message().' !link_category_id: '.$cat_id;
return false;
}else{
$input[$cat_id]= $objects;
}
}
// thx to Shackrock and outis http://stackoverflow.com/a/8198111
function recursive($inarray,$result){
foreach ($inarray as $inkey => $inval) {
if ( is_array($inval) ) {
$result = recursive($inval, $result);
} else {
$result[] = $inval;
}
}
return $result;
};
$intersect = function($array){
foreach(array_count_values(recursive( $array, array() )) as $key => $value ){
if( $value == count($array) ){ // intersect
$result[] = $key;
}
}
return $result;
};
$result = $intersect($input);
if( !isset($args['include']) || $args['include']=='' ){
$args['include'] = implode(',',$result);
}else if( isset($args['include']) && $args['include'] != '' ){
$args['include'] = explode(',',$args['include']);
$args['include'] = array_merge($args['include'],$result);
$args['include'] = implode(',',$args['include']);
}
$result = get_bookmarks($args);
if( count($result) == 0 ){
return new WP_Error( 'broke', __( ""No posts in the intersection..."", ""my_textdomain"" ) );
}else{
return $result;
}
}
}}}
",krabat1
4,27122,Optimization for PHP FPM,,General,3.8,normal,normal,,enhancement,new,dev-feedback,2014-02-13T22:59:21Z,2019-06-04T19:45:25Z,"This patch make {{{ wp_ob_end_flush_all }}} calling {{{ fastcgi_finish_request }}} instead of {{{ ob_end_flush }}} when php-fpm is used.
{{{ fastcgi_finish_request }}} flush the buffers '''and''' close the connection. This tweak increases page speed.
It also allows to run heavy tasks such as sending mail, writing logs or making complex calculations after the end of the request without slowing down the whole page load.
Symfony uses this tweak too, see this PR FOR further details: https://github.com/symfony/symfony/issues/1180",dunglas
1,27957,Revisit the Tag/Category Converter mention on the Tools Page,,General,3.9,normal,normal,,enhancement,new,,2014-04-21T18:59:04Z,2019-06-04T19:45:42Z,"Core's tools.php page specifically calls attention to the ""Categories and Tags Converter"" plugin.
I'd suggest eliminating reference to this completely.
It looks to be a relic from years ago that just kind of came along for the ride, and doesn't really have a place in modern Core. I think it's a perfect example of functionality that falls into 'Plugin Territory' - which, luckily, is how it's currently implemented. There are also a large number of similar, more well-maintained plugins that can accomplish this and more for a larger number of taxonomies.
If it's decided that the reference should stay, then I believe the logic surrounding the output needs to be modified, more along the lines of this psuedocode:
(As currently, if a user can Manage Terms, they're instructed to go install a plugin, even if they may lack that capability.)
{{{
if ( current_user_can($cats->cap->manage_terms) || current_user_can($tags->cap->manage_terms) ) {
if ( $tag_category_converter_is_installed //TODO: this check ) {
// provide link for actually using it. TODO: this link
} else {
if ( current_user_can( 'install_plugins') ) {
?>
Categories and Tags Converter available from the Import screen.'), 'import.php' ); ?>
$function_to_add, 'accepted_args' => $accepted_args);
unset( $merged_filters[ $tag ] );
return true;
}
}}}
I've just made `$idx` explicit and for obvious retrocompatibility reasons this have to be at the end.
Why we should do this small change? Well, this will help a lot and will enable a full use of anonymous functions:
{{{
#!php
add_action('init', function(){ /* some code */ }, 10, 0, 'plugin_domain');
add_action('the_title', function($t){ return $t; }, 10, 0, 'plugin_domain');
}}}
Please notice that I've used the domain name as the `$idx`, therefore we can:
{{{
#!php
remove_action('init', 'plugin_domain');
}}}
It would be easier and more efficient if we all follow the convention of set `$idx = $domain_name`, hence if anyone want to remove a specific hook introduced by some plugin, doesn't need to read the code to know it.
Also, if we use anonymous functions instead of named, the namespace pollution will decrease by a lot and performance should increase (it doesn't even have to calculate the `$idx`).
It will also enable the override of specific hook. Today we need to remove the hook we want to override and add another one, because we cannot redifine a named function. However, with this change all we have to do is:
{{{#!php
add_action('init', function(){ /* new code */ }, 10, 0, 'plugin_to_override');
}}}
A syntactical sugar will be great:
{{{#!php
function new_add_action($hook, $idx, $callback, $priority = 10, $args_count = 1) {
return add_filter($hook, $callback, $priority, $args_count, $idx);
}
}}}
I don't know what the name should be yet, but introducing it is a good compromise between retrocompatibility and good API; in years the first version should be deprecated... Something like that.
All in all, a really small change can simplify a good amount of things.
I don't really know if this is the correct way to propose this change, but I still haven't found the equivalent of git's pull request on SVN, sorry for that `^^""`",Iazel
2,29972,Split pagination calculations and HTML in paginate_links,,General,4.0,normal,normal,,enhancement,new,has-patch,2014-10-15T04:22:28Z,2019-06-04T19:46:40Z,"The current implementation of paginate_links has a number of issues. It has been improved significantly in the latest version, however there is still room for more improvements.
Currently, the function forces you to use the HTML as it has been returned. If you want to add a class onto something, there is no easy way to do it - you're stuck with the defaults as they are hard-coded.
The first step towards fixing this is to split the pagination calculations from the HTML. Sort out what's going to go where, and then go and build the HTML and return it.
My reasoning is below, take a look and see what you think. I'm not necessarily advocating my particular fix, but I believe at the very least it needs some discussion.
This change will make it easier to create features such as custom classes for elements, and will make the code easier to read and maintain.
Also this is my first time creating a ticket on WordPress Trac, so go easy :)
'''Return raw array data'''
If you want to write your own completely custom HTML, you currently have to either copy+paste the function and modify it to suit your needs, or write a whole new one from scratch. The function should be able to return an array containing these values for each pagination item:
- type (next/prev/dots/page)
- link (where the item links to)
- text (the text to be displayed within the link)
- active (so you can apply your own active class)
This allows for more flexible use of the function within the template.
'''Customize the default output'''
Sometimes, you might just want to add an extra class to an item or two. Now, you could add these features to the current code, but the section for the active element is split from the normal elements which means you'd have to duplicate code to do it.
'''Change the currently selected page element'''
I've added a new arg 'link_current' so you can change the default element of the selected page to an A tag instead of the SPAN. I needed this for our specific design, but thought other people might find it useful as well.",dylanj
,36417,Unit tests for functions.php's maybe_unserialize,,General,2.0,normal,normal,,enhancement,new,,2016-04-05T00:36:50Z,2019-06-04T19:56:56Z,Unit tests for maybe_unseriaze,tloureiro
3,30325,WP List Table: allow filtering view switcher modes,,General,4.0,normal,normal,,enhancement,new,has-patch,2014-11-12T19:21:48Z,2019-06-04T19:46:51Z,"I suggest the view mode switcher for post/media/site list views should be filterable, so it's possible to:
* add additional, custom view modes (especially for custom post types)
* filter available view modes
* remove view modes completely (effectively removing the switcher from HTML)
This would allow developers to customise the switcher for different custom post types. At the moment, this is impossible - and in some cases the switcher may make no sense or have no effect at all, if a specific mode isn't implemented.
",ragulka
3,33837,We should avoid Superglobals when possible,wonderboymusic,General,,normal,normal,,enhancement,assigned,dev-feedback,2015-09-11T19:53:44Z,2019-06-04T19:51:22Z,"We can probably add some helper functions that complete common tasks around Superglobal access
Examples of accessing here:
https://codeclimate.com/github/WordPress/WordPress/wp-admin/edit-comments.php
Something like `wp_verify_action( $action )` could replace the many instances of things like:
`isset( $_REQUEST['action'] ) && 'upload-attachment' == $_REQUEST['action']`
Without having to architect something like `Symfony/HttpFoundation`, we can make accessing them more rare.",wonderboymusic
,23454,_deprecated_function Messages,chriscct7,General,3.5,normal,normal,,enhancement,assigned,has-patch,2013-02-12T11:20:39Z,2019-06-04T19:44:32Z,"Unlike ''_deprecated_file'' and ''_deprecated_argument'', the ''_deprecated_function'' function has no option to append a message to the triggered notice.
I propose adding this to make it consistant with the other 2 functions. Patch to follow.",mikejolley
5,27286,create menu page for custom post types,,General,3.8,normal,normal,,enhancement,new,dev-feedback,2014-03-05T21:13:20Z,2019-06-04T19:45:30Z,"Currently, there are dedicated functions for adding new items to a top-level navigation item, such as `add_posts_page`, `add_media_page`, `add_links_page`, and so on. These all act as a wrapper for the `add_submenu_page`. However, there is no dedicated function for custom post types. I am proposing to add a new function called `add_post_type_page` that works in the same way. It's basically a copy of `add_posts_page` with an additional parameter for the registered CPT.",norcross
2,24284,is_multi_author() should query by specific post type and status,,General,,normal,normal,,enhancement,new,needs-unit-tests,2013-05-08T08:18:58Z,2019-06-04T19:44:43Z,"Current is_multi_author() function only checks by the 'post' post-type and 'publish' post-status..
I think the function should be able to query by custom-post-type and custom-post-status",alex-ye
,31005,wp_send_json(): Filtering of $response prior to passing it to wp_json_encode().,,General,4.1,normal,normal,,enhancement,new,,2015-01-13T22:35:08Z,2019-06-04T19:47:28Z,"It would be nice if wp_send_json() allowed $response to be filtered prior to passing it to wp_json_encode() and echo'ing the resulting JSON.
I'm working with a theme that uses wp_send_json() while responding to AJAX requests. I'd like to modify/customize the response content, however, without modifying the theme itself (which doesn't appear to have other hooks that could be used).
wp_send_json() seems to be a convenient and reasonable place to perform such filtering, but doesn't already appear to support this as of 4.1.",ap.0
5,33252,Add a Faster SHORTINIT-like admin-ajax Alternative,,General,4.2.3,normal,normal,,feature request,new,,2015-08-04T03:34:47Z,2019-06-04T19:50:21Z,"The existing `admin-ajax.php` is slow because it loads the whole Core.
Even though that's useful, this makes `admin-ajax.php` slow to use in front-end scenarios where you need fast responses.
Some code snippets exist that circumvent this by creating their own ajax handlers that utilize the SHORTINIT constant. Although these solutions would require you to load `wp-load.php` yourself which is not advised. E.g. https://coderwall.com/p/of7y2q/faster-ajax-for-wordpress from 2012
I'd like to propose a feature request for an `admin-ajax.php` likehandler that:
* doesn't load the whole core,
* loads only some essential functions similar to the functionality given by SHORTINIT
Implementation suggestion: The best way to implement this in my opinion is to create 2 new action hooks `wp_ajax_shortinit_{action}` and `wp_ajax_shortinit_nopriv_{action}` that behaves identically with `wp_ajax_{action}` and `wp_ajax_nopriv_{action}` except that the SHORTINIT-like environment is implemented.",bfintal
,32528,Create a new search_form_content hook in get_search_form(),,General,4.3,normal,normal,,feature request,new,,2015-05-29T16:22:28Z,2019-06-04T19:49:21Z,"The only viable method for creating a custom search form in a plugin or theme is to replace the entire default search form.
This runs the risk of introducing possible security issues should a patch be issued in the default search form. More importantly it means more potential deviation from ""the WordPress standard"".
Instead of requiring developers to recreate a new feature that mimics the HTML that get_search_form() provides, consider adding a new filter that allows developers to easily add HTML elements to the search form.
The current general-template.php get_search_form() snippet:
{{{
if ( 'html5' == $format ) {
$form = '';
} else {
$form = '';
}
}}}
Allow developers to easily insert additional input elements between the search input and submit elements:
{{{
if ( 'html5' == $format ) {
$form = '';
} else {
$form = '';
}
}}}
There are a number of ways to implement this, including the possibility of passing in the initial label + input fields HTML as a parameter to the filter.
The general idea is to keep the form HTML and submit HTML intact to ensure maximum functionality/compatibility with the core search feature.
As long as the hook processor does not impart too much overhead, this may be a viable feature to keep more control over the search form and simplify/eliminate many custom searchform.php files that only need to add an extra input element such as ""select a category"" to further refine the search mechanism.
",charlestonsw
5,60229,HTML API: Introduce HTML Templating,,HTML API,trunk,normal,normal,,enhancement,new,dev-feedback,2024-01-11T03:41:51Z,2024-03-07T17:03:47Z,"WordPress relies on developers remembering to perform proper escaping when building HTML strings. There's no mechanism to ensure that output HTML is safe. This patch introduces `WP_HTML_Template::render( $template, $args )` to do just that.
{{{#!php
"">
"">
%url>
HTML,
array( 'url' => 'https://s.wp.com/i/atat.png?w=640&h=480&alt=""atat>atst""' ),
);
}}}
outputs
{{{
https://s.wp.com/i/atat.png?w=640&h=480&alt="atat>atst"
}}}
This proposed templating syntax uses closing tags containing invalid tag names, so-called ""funky comments,"" as placeholders, because they are converted to HTML comments in the DOM and because there is near universal existing support for them in all browsers, and because the syntax cannot be nested. The `%` at the front indicates that the value for the placeholder should come from the args array with a key named according to what follows the `%`.
This proposal does not yet consider nested HTML, or ""raw"" HTML. It currently escapes all content. It would be great if the templating engine can properly and safely handle HTML passed into it without risking unintentional exposure, but there must also be some way to communicate that a value inside is already escaped //and that its safety is maintained//.
By relying on the HTML API, this templating only supports replacement of values //inside// HTML attributes or in plaintext (`#text`) nodes. It's not possible to inject HTML tags (unless nested support can be safely added), comments, or other HTML syntax.",dmsnell
2,34796,Facing an issue when using wp_remote_get with streams (non-blocking mode),rmccue*,HTTP API,4.3.1,normal,normal,,defect (bug),accepted,reporter-feedback,2015-11-26T22:45:06Z,2019-06-04T19:53:49Z,"On some hosting providers (like wpengine.com) I've encountered an issue when using wp_remote_get with streams (non-blocking mode) which on the other hand uses PHP native functions stream_socket_client, stream_context_create and stream_set_blocking. The issue is that HTTP request (non-blocking) never succeed, it just hangs/stuck on the initial call of stream_socket_client and neither errors or exception are generated. I've investigated the issue deeper and it seems that many people over the Internet have it. The issue can be resolved after invoking stream_socket_client we put usleep(5000) and then stream_set_blocking($handler, 0). It seems that the initial time for stream_socket_client is not enough and that's why it needs more time in order to process the HTTP request.
PHP Bugtracker
https://bugs.php.net/bug.php?id=64803
WordPress 4.3.1
PHP 5.5
Is it possible to add additinal parameter on wp_remote_get or if there is any other way to achieve setting usleep parameter will help us to precisely configure HTTP requests.
I am adding patch file",bangelov
6,34053,HTTP API (Curl backend) inappropriately sends Content-Length header on POST requests made through a proxy server CONNECT,,HTTP API,4.3.1,normal,normal,,defect (bug),new,,2015-09-28T08:47:00Z,2019-06-04T19:51:56Z,"When WordPress is configured to communicate with the outside world through a HTTP proxy server, using
{{{
define('WP_PROXY_HOST', 'some-proxy-server');
define('WP_PROXY_PORT', '3128');
}}}
in '''wp-config.php''', HTTP POST requests that are over HTTPS, and pass through the proxy server, get a Content-Length header inserted in the CONNECT request, instead of in the headers of the POST request made inside the HTTPS tunnel.
On certain proxy servers configured to parse requests strictly, they will reject this outer CONNECT request with a HTTP 400 Bad Request, as the Content-Length header should not be there(?)
Here is an HTTP POST request and response, going via a HTTPS CONNECT request (in this case a request for Google's Recaptcha through the Contact Form 7 plugin) behind a BlueCoat proxy server configured with tolerant-request-parsing off:
{{{
CONNECT www.google.com:443 HTTP/1.1
Host: www.google.com:443
User-Agent: WordPress/4.3.1; https://staging.testvalley.hants.sch.uk
Proxy-Connection: Keep-Alive
Accept-Encoding: deflate;q=1.0, compress;q=0.5, gzip;q=0.5
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 1052
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: close
Connection: close
Content-Length: 513
invalid_request: Your request could not be processed. Request could not be handled
}}}
To demonstrate this is not a plugin issue, a similar request (a check for core updates by clicking 'Check again' on the Updates page in WP-Admin) that is also affected:
{{{
CONNECT api.wordpress.org:443 HTTP/1.1
Host: api.wordpress.org:443
User-Agent: WordPress/4.3.1; https://staging.testvalley.hants.sch.uk
Proxy-Connection: Keep-Alive
Accept-Encoding: deflate;q=1.0, compress;q=0.5, gzip;q=0.5
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 193
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: close
Connection: close
Content-Length: 513
invalid_request: Your request could not be processed. Request could not be handled
}}}
HTTP (not HTTPS) requests, including POST, proceed fine through the proxy. HTTPS GET requests also work correctly.
This seems to be an issue that derives from where '''includes/class-http.php''' injects the Content-Length header before dispatching the request to the chosen HTTP backend. This header injection does not cause issues with a HTTP POST request, but in the case of an HTTPS POST request going through the proxy, the Content-Length header ends up in the HTTPS CONNECT request to the proxy, rather than the actual request to the server that is wrapped inside the established tunnel.
Commenting out lines 273 and 274 of '''includes/class-http.php''' causes the above two requests to succeed.
",petertvs
2,37705,Remove unnecessary parts of WP_HTTP which remain,,HTTP API,,normal,normal,,defect (bug),new,has-patch,2016-08-18T04:07:10Z,2019-06-04T20:01:04Z,"After Requests was merged in WordPress 4.6, WP_HTTP now wraps it with a few of the previous classes remaining for compatibility.
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.
We should be able to remove a large percentage of these without too much issue.
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).
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).",dd32
2,32932,WP_Http::request hangs on badly behaving servers,,HTTP API,,normal,normal,,defect (bug),new,,2015-07-09T00:52:56Z,2022-06-02T14:07:31Z,"Some plugin includes a call to ""fetch_feed( 'https://wpml.org/feed/' )"" which takes 300 seconds to complete. The whole backend hangs during this rending of the dashboard widget.
Tracing the problem down reveals, that the function WP_Http::request has a problem with the response from the server.
The server does answer the HTTP/1.0 request with an HTTP/1.1 response and 300 seconds timeout:
{{{
$ openssl s_client -connect wpml.org:443
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES128-SHA
Session-ID: 45...30
Session-ID-ctx:
Master-Key: 68...4F
Key-Arg : None
Start Time: 1436367230
Timeout : 300 (sec)
---
GET /feed/ HTTP/1.0
Host: wpml.org
HTTP/1.1 302 Found
...
[300 seconds to wait until the server closes the connection]
}}}
The WP_Http::request function does not handle this case correctly.
It located in this part of the code:
{{{
$header_length = 0;
while ( ! feof( $handle ) && $keep_reading ) {
$block = fread( $handle, $block_size );
$strResponse .= $block;
if ( ! $bodyStarted && strpos( $strResponse, ...
$header_length = strpos( $strResponse, ...
$bodyStarted = true;
}
$keep_reading = ( ! $bodyStarted || !...
}
}}}
fread() waits the default 10s timeout and returns nothing (after the initial two reads). The repeats 30 times accumulating to 300 seconds.
{{{
Count Avg.Time Tot.Time Name (linenumbers differ from the original)
1 301.201028 301.201028 wp-includes/class-http.php:889
1 0.595707 0.595707 -> 1065
1 0.000048 0.000048 -> 1067
1 0.000008 0.000008 -> 1075
1 0.000007 0.000007 -> 1084
1 0.000006 0.000006 -> 1131
32 0.000033 0.001070 -> 1134
32 9.386880 300.380167 -> 1136
1 0.000025 0.000025 -> 1145
1 0.000030 0.000030 -> 1148
1 0.000109 0.000109 -> 1153
}}}
The obvious solution is to stop reading if nothing is returned.
{{{
$header_length = 0;
while ( ! feof( $handle ) && $keep_reading ) {
$block = fread( $handle, $block_size );
$strResponse .= $block;
if ( ! $bodyStarted && strpos( $strResponse, ...
$header_length = strpos( $strResponse, ...
$bodyStarted = true;
}
$keep_reading = ( ! $bodyStarted || !...
+ if(strlen($block) === 0) break;
}
}}}
This solves the problem for the badly behaving servers (in this case the one from the plugin).
(From #meta1104",Lutz Donnerhacke
,37614,"WP_PROXY_BYPASS_HOSTS has no effect inside curl transport, if http_proxy or https_proxy is set on the system",,HTTP API,,normal,normal,,defect (bug),new,,2016-08-09T13:20:22Z,2019-06-04T20:00:40Z,"OS: Debian Squeeze
PHP Version tested: 5.3.29
Will try to provide results from newer distros later today.
--
In case server hosting website has environmental settings for proxy, it's not possible to skip using it even for addresses that should be bypassed.
Let's take for example that printenv returns following:
{{{
http_proxy=http://proxy.com:8080
https_proxy=http://proxy.com::8080
}}}
In this case, if we execute `wp_remote_get` (with domain that should be bypassed via WP_PROXY_BYPASS_HOSTS) it will still use system variable http_proxy in curl transport.
I think that wp_remote_get should explicitely set `curl_setopt($handle, CURLOPT_PROXY, null);`, if proxy is disabled inside wordpress or url SHOULD be bypassed.",fliespl
1,29619,Make WP_HTTP_BLOCK_EXTERNAL more easy to use,,HTTP API,2.8,normal,normal,,enhancement,new,dev-feedback,2014-09-10T17:46:54Z,2019-06-04T19:46:22Z,"Currently when defining WP_HTTP_BLOCK_EXTERNAL it blocks all requests which would mean that WordPress itself becomes unusable because it then will also blocks it own requests to WordPress.org. Also oEmbeds stop working because they can't get their data.
My idea is to make an if statement like the localhost check to allow those requests. I do get that this constant is mainly for local development but would be great to have a easy way to have a semi locked down installation. So I'm curious what you guys think about this.",markoheijnen
1,29390,add filter for get_date_from_gmt(),,I18N,1.2,normal,normal,,defect (bug),new,has-patch,2014-08-27T08:53:24Z,2019-06-04T20:08:52Z,"Please add filter for i18n date`s in get_date_from_gmt();
Buddypress use this function in admin section for display posts time, and we can't change dates via i18n and filters for Persian dates (Jalali Calendar).
get_date_from_gmt() is located in wp-includes/formatting.php
Thank you",zakrot
,12477,Search with special characters and similar terms,nbachiyski,I18N,,normal,normal,,feature request,new,dev-feedback,2010-03-02T17:42:46Z,2019-06-04T20:01:58Z,"I did:Tried searching for terms Metis and Métis
I saw:Those two searches turned up different sets of results.
I expected:The same set of search results, or at least everything when
I searched for Metis.
Can search be smarter when special characters are involved?",mrroundhill
1,23482,Fix improper use of comment_exists() in some importers,maxpagels,Import,,normal,normal,,defect (bug),assigned,has-patch,2013-02-15T18:49:18Z,2019-06-04T20:05:02Z,"Background: #20494
DotClear Importer and TextPattern Importer treat the returned comment post ID as a comment ID: [[BR]]
http://plugins.trac.wordpress.org/browser/dotclear-importer/trunk/dotclear-importer.php#L416 [[BR]]
http://plugins.trac.wordpress.org/browser/textpattern-importer/trunk/textpattern-importer.php#L429",SergeyBiryukov
5,16445,Fix incompatibilities with IDs greater than 2^31,,Import,3.1,normal,normal,,defect (bug),new,,2011-02-03T01:03:24Z,2019-06-04T20:02:33Z,"For various reasons, things go bad when you get a post ID greater than 2^31^. When we're importing content and there's an existing ID, I suggest we ignore it if possible if it's too big.
Tumblr2WordPress for example maintains the Tumblr IDs and causes problems in WordPress.",Viper007Bond
,31581,Images-Links broken after import from wordpress.xml in WordPress 4.1.1,,Import,4.1.1,normal,normal,,defect (bug),new,,2015-03-10T10:33:19Z,2019-06-04T20:11:51Z,"In XML:
<...""Fotolia_65968659_S-300x205.jpg""...>
After Import the Image-File is created as
Fotolia_65968659_S-300x206.jpg
but the img-src still is ...300x205.jpg.
The same happend to Fotolia_66268596_S-300x199.jpg. The Filename was changed to ...300x200.jpg, the link did´n change.
Seems to be a rounding-issue when recalculating Image-Sizes.",WulfP
2,21859,Import blog and media library is not working,,Import,3.4,normal,normal,,defect (bug),new,,2012-09-10T08:02:25Z,2019-06-04T20:03:47Z,"Hi,
I have problems (due to hosting php timeout) to import all my blog at once.
I tried doing it by months, but it's also not working. Blog posts are imported, but nothing of the media library is imported.
I can describe too what happens when trying to import everything at once. I've just 200 photos and every 90 secs the connection is reseted trying to import them. If you try to retry using browser, photos begin to duplicate, or triplicate, or more...
After all this, then you finish, there is no attachments related to their post.
I've tried importing by months, which would not spend more than 60 secs importing photos, but then the photos are not imported.
Please, fix the import/export by months or by splitting files every 10 post (or configurable).
I would suggest too to allow any mechanism to import photos first, doing it in groups of 20 (or by configuration) and later, after that, importing post and attaching files to each post.
I set it as critical as moving a blog it's impossible without a huge amount of work.
I could try to help debugging if needed.
Version 3.4.1 is also affected.
Thanks and regards",don_ousian
3,30887,Imported media relies on GUID for download,,Import,,normal,normal,,defect (bug),new,,2015-01-02T21:44:05Z,2019-06-04T20:10:23Z,"When importing media with the importer plugin, the GUID is used as the URL for downloading the files. If there is more than two levels of sites you're importing between this creates an issue with flow.
In example, say you have three sites:
http://siteone.com (Original WP install)
http://sitetwo.com
http://sitethree.com
Exporting from http://siteone.com and importing on http://sitetwo.com the files will be downloaded from http://siteone.com.
However, if you export from http://sitetwo.com and import into http://sitethree.com, without changing the GUID, the files will be downloaded from http://siteone.com
In most cases http://siteone.com would be nonexistent or unreachable at this point, thus the media items cannot be imported.
Note that wp_get_attachment_url had this same defect ([ticket:7622])",pathartl
,19764,Invalid JSON in custom fields meta value after export,,Import,3.3,normal,normal,,defect (bug),new,,2012-01-06T17:13:07Z,2019-06-04T20:03:07Z,"Hey there,
I exported a working copy of my online WordPress site to a local copy and noticed that the code gets changed; The backslash is removed which causes the json format to be invalide.
Original code in the custom fields meta
{{{
{""videos"":{""0"":""""}}
}}}
Becomes in the local site after import
{{{
{""videos"":{""0"":""""}}
}}}
",abdessamad idrissi
1,34112,Library broken after import XML,,Import,,normal,normal,,defect (bug),new,,2015-10-01T12:15:55Z,2019-06-04T20:16:44Z,"Hello, after exporting an XML file to a blog and after import this XML in a empty Wordpress installation (to a new URL), the result is often a broken Library: it's missing thumbs, as you can see here:
http://s1380.photobucket.com/user/New254/media/wp-track--library-broken-01_zpskslxbc7t.jpg.html
But if I clic on empty thumb, the media is ok and appear also on the website. As you can see here, after clicking empty thumb, the media is here:
http://i1380.photobucket.com/albums/ah198/New254/wp-track--library-broken-02_zpsdos6akx8.jpg
After many days of research and try tips found on the forums, plugin tests... I finally found the ultimate plugin that repair the problem:
https://wordpress.org/plugins/fix-my-posts/
The subject is vast on the Internet if you search ""wordpress broken library after moving"" or ""wordpress plugin repair library""... so i think that there is a problem in the core of WordPress, missing a function ""regenerate library"" or ""repair library"".
",Newzic
,12885,LiveJournal importer uses GMT date/time as local date/time,,Import,,normal,normal,,defect (bug),new,has-patch,2010-04-07T02:07:25Z,2019-06-04T20:02:01Z,"The LiveJournal importer takes a comment's date/timestamp, which is in GMT, and inserts it into the database as the comment's local date/timestamp. In my timezone (U.S. Central, DST), a comment posted at 12:00pm local time (5:00pm GMT) will be imported to the database as having been posted at 5:00pm local time (10:00pm GMT).
I've attached a patch that I've successfully tested on Wordpress 2.9.2, and it appears to be easily ported to trunk. One caveat: it appears that there are two timezone settings in the Wordpress database (timezone_string and gmt_offset), but as my database has no value for gmt_offset, I don't know if I need to account for that, nor can I test that.",kurtmckee
2,16147,"MT Importer truncates double vertical spaces, munging paragraphs together",,Import,3.2.1,normal,normal,,defect (bug),reopened,,2011-01-07T22:25:47Z,2019-06-04T20:02:27Z,"Movable Type 3.x-era exports don't use '''
''' tags. Like TinyMCE (and WordPress), a '''
''' in final rendered code is represented by two '''\n'''s in a row.
The importer strips out double '''\n'''s and replaces with a single '''\n'''. This causes paragraphs to lose their distinction upon import.
It does this because the '''$line''' variable was created by '''$line = $this->fgets($handle)''' (line 339). Then '''$line = trim($line)''' (line 340) strips out several characters, including '''\n'''.
Lines 455 and 456 add back the '''\n''' ''except'' on blank lines:
{{{
if( !empty($line) )
$line .= ""\n"";
}}}
So if a '''$line''' was nothing but a '''\n''', it's stripped by the '''trim''' function and becomes a 0 character line. Then the '''if( !empty($line) )''' declines to add back a '''\n'''.
Somehow this needs to be altered so that successive '''\n'''s aren't stripped. Otherwise paragraphs get vertically munged together.",novasource
2,18602,"Media Library imported, but all items Unattached",,Import,3.2,normal,normal,,defect (bug),new,reporter-feedback,2011-09-06T10:10:18Z,2019-06-04T20:02:51Z,"Export XML file from one site, import into another site. By checking ""Download and import file attachments"", files from wp-content/uploads are downloaded correctly to the new site, and added to Media Library. However all items in the Media Library are now ""Unattached"", and for example posts using [gallery] are broken on the new site. ",awallin
1,34845,Serialized custom fields are ignored on import,,Import,,normal,normal,,defect (bug),new,,2015-12-04T13:56:30Z,2019-06-04T20:18:44Z,"Hi guys,
we would like to report a bug related with .xml file import. Data from our builder are stored in $items table. Post meta values entry are made with below code:
{{{
$new = wp_slash( $items );
update_post_meta( $post_id, 'mfn-page-items', $new );
}}}
And in accordance to your documentation https://codex.wordpress.org/Function_Reference/update_post_meta#Character_Escaping, we use ""wp_slash"" function. Table with data is saving and reading properly. The problem is when we export .xml file with Tools > Export and when we try to import data with built-in Tools > Import > WordPress option, serialised table is ignored and we get empty field.
We attach test, exported .xml file so you can check it yourself.
We would be grateful if you can have a look on it.
Thanks!",muffingroup
,33371,Undefined Indexes for Movable Type and TypePad Importer.,westi*,Import,,normal,normal,,defect (bug),accepted,reporter-feedback,2015-08-14T08:25:25Z,2019-12-06T05:07:37Z,"Display notice in ""Assign Authors"" ( WP_DEBUG = true ) .
{{{
Notice: Undefined index: upload_type in movabletype-importer/movabletype-importer.php on line 233
Notice: Undefined index: id in movabletype-importer/movabletype-importer.php on line 248
}}}",mt8.biz
1,22082,WordPress Import Tool loses the complete category hierarchical structure,,Import,3.4.2,normal,normal,,defect (bug),new,,2012-10-03T01:53:05Z,2019-06-04T20:03:54Z,"I have exported from my local laptop wordpress installation the posts I had. They have the following structure with categories:
{{{
language --> main category, parent
- source language --> for example AF
-- target language --> for example AFAR for Africans to Arabics
--- lessons
----- lesson 1 --> up to 100 lessons entries
-- next target language
}}}
and so on
this complete structure is lost after import - they are all changed to parent categories no single child category.
I will attach the export file.",christian_gnoth
1,21597,WordPress Importer $base_url index failed,,Import,3.4,normal,normal,,defect (bug),new,has-patch,2012-08-15T18:30:11Z,2019-06-04T20:03:35Z,"When XRS file without the site url tag is imported, it throws a notice. This patch allow people to upload hand-made and not-attached-to-any-site XRS file.
I came across creating a XRS file to import names of cities from Portugal to a specific custom taxonomy to some sites. This can reflect the necessity of this patch.",lightningspirit
3,16404,WordPress Importer fails to import images,,Import,3.0.4,normal,normal,,defect (bug),new,reporter-feedback,2011-01-29T00:42:28Z,2019-06-04T20:02:31Z,"WordPress Importer fails to import images and update image src urls when download and import file attachments is checked.
WordPress MS with images in a post via Media using WP image mapping, e.g. image url: http://site.domainname.com/files/2011/01/myimage.jpg
Fails to download, import and update image src url. All image src urls remain intact from the old domain name.
If you change the image source to specific directory rather than the WP uploads directory: e.g. image url:
http://site.domainname.com/images/myimage.jpg
Images are downloaded and imported to media but it fails to update image src url in posts. All image src urls in posts remain intact from the old domain name.
I tested this on clean install of WP 3.0.4 MultiSite with TwentyTen theme and no other plugins activated.",wlpdrpat
,32320,"WordPress Importer: WXR_Parser_Regex adds newlines to import data, breaking serialized post meta.",,Import,,normal,normal,,defect (bug),new,,2015-05-09T08:17:53Z,2019-06-04T20:13:25Z,"Original ticket: [https://plugins.trac.wordpress.org/ticket/2317]
Our plugin stores a fair amount of serialized data in post meta fields. When using the importer, the WXR_Parser_Regex parser loops through 8192 bytes of the import file at a time, appending a newline to the import data at the end of each loop. When a newline is inserted in the middle of our post meta, it breaks when the time comes to unserialize in the import process, leaving our users with a blank post meta field.
The offending code can be seen starting at line 459 of parsers.php...
{{{
if ( $in_post ) {
$post .= $importline . ""\n"";
}
}}}
Is that newline necessary? I have verified that removing it solves the problem and imports the serialized data correctly.
@duck_ has suggested removing rtrim() and the new line which I will submit as a patch. ",justinbusa
2,23275,WordPress Importer: line-ending mismatch corrupts serialized meta,,Import,,normal,normal,,defect (bug),new,has-patch,2013-01-23T16:56:04Z,2019-06-04T20:04:44Z,"A possible solution:
{{{
if ( $key ) {
// export gets meta straight from the DB so could have a serialized string
if ( ! $value )
$value = maybe_unserialize( $meta['value'] );
// Occationally, line-endings break unserialize()
if ( empty( $value ) ) // Try normalizing...
$value = maybe_unserialize( str_replace( array(""\r\n"", ""\r"", ""\n""), ""\r\n"", $meta['value'] ) );
if ( empty( $value ) ) // Adjust string length if needed
$value = maybe_unserialize(
preg_replace( // e flag deprecated in PHP 5.5.0 I think
'!s:(\d+):""(.*?)"";!se',
""'s:'.strlen('$2').':\""$2\"";'"",
$meta['value']
)
);
add_post_meta( $post_id, $key, $value );
do_action( 'import_post_meta', $post_id, $key, $value );
// if the post has a featured image, take note of this in case of remap
if ( '_thumbnail_id' == $key )
$this->featured_images[$post_id] = (int) $value;
}
}}}",WraithKenny
,12286,bug and fix when importing from Movable Type,,Import,,normal,normal,,defect (bug),new,,2010-02-19T13:26:59Z,2019-06-04T20:01:57Z,"I'm running WP Mu 2.9.1.1 and had a problem importing a Movable Type blog to WP and found a fix (sort of).
Symptom: When importing a blog from Movable Type to a blog in WP, you are asked to assign (or map) WP authors to MT authors. But, it turns out that the first author on the list is assigned to all posts. The other authors selected are neglected. Therefore, all of the posts end up belonging to one author.
Fix: I found the problem in wp-admin/import/mt.php. Specifically, ""$mtnames"" is not properly populated with authors from MT. So, I changed the code in function get_authors_from_post() as follows:
function get_authors_from_post() {
$formnames = array ();
$selectnames = array ();
$this->mtnames = $this->get_mt_authors();
I just added the last line shown above and then finally the import properly assings authors as intended.
(There might be a better place to put the last line, however.)
",leyburn888
,15586,"movabletype-importer, trivial: fix no index upload_type warning",,Import,3.1,normal,normal,,defect (bug),new,has-patch,2010-11-26T00:43:46Z,2019-06-04T20:02:24Z,"movabletype-importer, trivial: fix no index upload_type warning
ENV: http://plugins.svn.wordpress.org/movabletype-importer/trunk r315664",lloydbudd
1,21913,Detecting MIME Types in WXR Files,,Import,3.4.2,normal,normal,,enhancement,new,dev-feedback,2012-09-17T21:09:07Z,2019-06-04T20:03:48Z,"In the process of creating a service to convert TypePad data to WXR formatted files, we've encountered some unique problems with TypePad data. Namely, many TypePad files are saved without file extensions, which prevents the existing importer from importing those files into the wp-content/uploads folder.
In order to import and rename these otherwise ignored files, we've created a patch for the WordPress importer that does the following:
1. If there is an attachment in the WXR and the importer is not able to determine the file type from the file name (ie missing extension), the patched version will make a light (body-less) request to the web server where the file is hosted for information we can use about the file. The things we're interested in are file type, size, and filename.
2. If the importer is processing an attachment under the above situation, and it is able to determine the file type, then it will rewrite the local version of the file to have the appropriate file extension.
This is a simple bit of code, but it makes a huge difference as TypePad saves without file extensions quite regularly.
We've attached our patch and a sample WXR file from ragsgupta.com, the Brightcove co-founder's blog.",ReadyMadeWeb
3,22041,Importer dies silently when multisite upload limit is reached,,Import,,normal,normal,,enhancement,reopened,,2012-09-28T17:58:57Z,2019-06-04T20:03:50Z,"The scenario: You're importing a WXR file into a site on a multisite network and the WXR includes a number of large attachments. For whatever reason, the upload capacity for each site is set at 100MB.
If the upload capacity is reached during the import process, the import will look like it's hanging forever. Instead, it would be nice to show an alert that the upload capacity was reached or similar.",danielbachhuber
2,30978,Meta Fails for Nav Menu,,Import,4.1,normal,normal,,enhancement,new,,2015-01-11T12:39:16Z,2021-05-12T17:00:37Z,"Hi,
Wordpress Importer Plugin exports all metas but does not import menu meta. Also some other users had the same issue ;
https://wordpress.org/support/topic/failure-to-import-post-meta-for-nav-menu-item
If that fix won't be included then a hook would be useful. We can ofcourse fix that ourselves and make a fix plugin, but for mega menus you can't say all of your users to use different fixed importer instead of default WordPress Importer.
https://wordpress.org/plugins/wordpress-importer/",WPThemeTrends
2,22976,Remove reference to category to tag converter from the tools page,,Import,,normal,normal,,enhancement,new,,2012-12-17T16:02:00Z,2019-06-04T20:04:32Z,"It has been such a long time since version 2.3, does anybody really need a reminder for the existence of this tool on that relatively high profile page?",mark-k
1,23464,WXR importer: Poor UX when creating new user to import to,,Import,,normal,normal,,enhancement,new,,2013-02-13T07:05:33Z,2019-06-04T20:04:59Z,"When importing WXR you are prompted to assign a user to which of the existing users the imported content will be assigned, but it is also possible to provide a name of a new user which will be created and the content then will be associated with it.
The new user functionality sucks
1. No email or password is required therefor the user for a while is missing data which is assumed to always exist for a user. In the end of the import there is a small notice about updating the user data, but it gets lost in all the output being generated during import
2. Processing does not stop if user creation had failed (I used hebrew characters for user name) and the imported content is assigned to the current user. WTF?
",mark-k
,12578,import from movable type doesn't import tags or basename,,Import,3.0,normal,normal,,enhancement,assigned,needs-refresh,2010-03-11T00:58:46Z,2019-06-04T20:02:00Z,"The current movable type import script doesn't import tags from movable type and it doesn't import the basename (movable type's version of the post_name, which is necessary for a seemless transition). Adding support for importing these two important bits is not terribly difficult and I'm working on improving the import script to aid in my own upcoming migration. I'll attach a patch against the trunk.",stevecrozz
1,24791,Map audio/video shortcode IDs on import,,Import,,normal,normal,,task (blessed),new,,2013-07-17T21:39:47Z,2019-06-04T20:05:43Z,See #24458.,nacin
2,34236,Better passwords - differences between setting and resetting password?,,Login and Registration,4.3,normal,normal,,defect (bug),new,,2015-10-09T18:48:08Z,2021-02-23T06:07:14Z,"1) When user registers on a site, there is notification email ""Your username and password info"" which contains 2 URL addresses:
``
`http://localhost/wp-login.php`
Why is there the second URL? Nothing can be done here, only antispam filters can ban this email...
2) When user clicks the first link, new password can be set: ""Enter your new password below."" But why has button text ""Reset Password""? User is not resetting password, but only setting first (new) password. And after submitting, there is text ""Your password has been reset.""
3) Site admin receives 2 notification emails (for one registration):
- ""New User Registration"": New user registration on your site... (same in pre 4.3)
- ""Password Lost/Changed"": Password Lost and Changed for user...
So, every site admin receive another notification email with not relevant info, because password was not lost and changed, but created for the first time. For sites with many users, it is surprising and not needed... When user changes its password on Profile page, site admin also does not receive any notification. As I understand it, there is no difference when user set first password or reset lost password? It can be confusing for some users...
4) When site admin adds a new user, custom password can be set. But newly added user does not know about it? User received only standard ""Your username and password"" email with link to creation of new password: To set your password, visit the following address...
I am not sure, if I understand workflow completely, but it seems to me a little bit confusing...",pavelevap
1,30227,Inaccurate wording when creating a user with a reserved email address,,Login and Registration,3.3.2,normal,normal,,defect (bug),new,has-patch,2014-11-01T06:16:43Z,2020-02-06T19:47:07Z,"If you try to create a user on multisite using an email address that is tied to an unconfirmed user, you'll get this notice
That email address has already been used. Please check your inbox for an activation email. It will become available in a couple of days if you do nothing.
""Please check ''your'' inbox"" seems to imply that the logged in user should check their own inbox for an activation email. Not sure of the best way to reword that so it's clear without being overly wordy. Possibly something like
That email address is reserved pending activation. It will become available in a couple of days if left unconfirmed.
or
That email address is reserved. An activation email has been sent to that address. If left unconfirmed it will become available in a couple of days.
Also, ""couple of days"" could be any time less than 2 days, so perhaps a dynamic value could be used here giving a better approximatation of the time remaining till the unconfirmed address will be freed up.
''This is referenced in #20817''",trepmal
,27165,Incorrect nonce supplied when authenticated session expires,,Login and Registration,3.8.1,normal,minor,,defect (bug),new,has-patch,2014-02-20T11:55:44Z,2019-06-04T20:06:52Z,"I was using a nonce (with action name) for a nopriv ajax request and found nonce supplied via page load was invalid, whereas nonce supplied via ajax request was valid. This only occurs when admin area prompts to re-authenticate current user.
In my system, a nonce (action 'xyz', say) is given via localize script to the client on page load. This nonce is then used to verify a subsequent nopriv ajax request. This request then responds with the latest nonce (for 'xyz') (which may be the same, of course) for any further ajax requests.
However, I suddenly found that upon page reload, the nonce provided via localize script was invalid. Assuming this was a bug in my code, I commented out nonce verification in my action function. I then discovered that the ""new"" nonce being supplied in the ajax response was always different to the initial nonce despite the same action name being used in its creation. On further experimentation it became apparent that the nonce supplied by ajax response was valid and did verify with further ajax requests. I then found I had the admin area open in a separate tab and it was prompting me to re-authenticate. Upon logging back in the nonces realigned and worked again.
tl;dr: Requests by ajax consider current user differently to fresh page load (for nonces at least) when in logged in limbo. The bug is that it shouldn't.
It's a very minor issue but it was very confusing and took me quite some time to find the somewhat non-intuitive solution.",joe_bopper
2,36098,"Install: ""Repeat Password"" is not required when browser js is disabled",,Login and Registration,,normal,normal,,defect (bug),new,close,2016-03-05T00:57:39Z,2020-02-16T21:35:57Z,"Recreate:
1. Turn off browser JS.
2. Install WordPress.
3. Go to step 2.
The ""'''Repeat Password'''"" field is marked as '''required'''. It's not.
----
Recreate this step by step:
Leave all fields empty and press the install button.
You will see an error saying: `Please provide a valid username.`
Enter invalid username (use spaces).
You will see an error saying: `The username you provided has invalid characters.`
Enter valid username.
You will see an error saying: `You must provide an email address.`
Enter some text (not an email).
You will see this error message: `Sorry, that isn’t a valid email address. Email addresses look like username@example.com.`
If you provide a valid email, it will install WordPress. ''' Password is not required! '''",ramiy
1,13655,Login/Install/User Edit should stripslashes() $_POST data,,Login and Registration,3.0,normal,normal,,defect (bug),new,has-patch,2010-05-31T11:33:17Z,2019-06-04T20:02:12Z,"Following on from #13654 All Login/Registration/Install/User Edit functionality should stripslash $_POST data.
At present, it seems that we do not stripslash at all.
For existing user passwords, we should migrate passwords to their non-stripslashed versions:
[5/31/10 6:34:11 AM] Mark Jaquith: We could migrate people.[[BR]]
[5/31/10 6:34:13 AM] Dion (dd32): Perhaps oughta just add proper stripslashing in 3.1, and add back-compat to change password from non-stripslashed to stripslashed.. similar to the md5->phpass implementation..[[BR]]
[5/31/10 6:35:13 AM] Mark Jaquith: Yep. If the PW doesn't match, addslashes() and compare again. If that matches, set the new PW hash. Right?[[BR]]
[5/31/10 6:35:19 AM] Dion (dd32): yep
",dd32
5,27086,Make auth-check logins work with 1Password,,Login and Registration,,normal,normal,,defect (bug),new,,2014-02-10T15:51:22Z,2019-06-04T20:06:45Z,"After some conversation on Twitter, I've been testing 1Password's browser extensions against WordPress. It works fine when logging in normally, but when you get logged out and need to log in from an iframe, it fails pretty hard.
Specifically, 1Password decides to fill *every* text input — even those that are hidden, that have content, or that aren't in the same form — with the login name. This is despite the web form fields being configured, present, and matching up perfectly.
(By hidden I'm referring to type=""text"" that is visually hidden, not type=""hidden"".)
Basic steps to trigger the issue:
* Have a login saved from wp-login.php (making sure that your web form details are for ""log"", ""pwd"" and optionally ""rememberme"").
* Edit a post.
* Hit the 1Password global shortcut, ⌘\. It will fill in every text input, including the title, the tags meta box input, the slug meta box input, etc. It's a mess.
Steps to reproduce with a real login form:
* Have a login saved from wp-login.php, etc.
* Edit a post.
* Delete your login cookies. Wait three minutes, or speed things up by calling `wp.heartbeat.connectNow()` in your console.
* An iframe should pop up (assuming you're not cross-domain, at least). Log in using ⌘\.
* It'll log into the iframe and submit it, which closes it.
* Note that the title field and all other text fields.
Steps to reproduce to comedic results:
* Have a login saved from wp-login.php, etc.
* Visit Settings > General.
* Delete your login cookies. Wait three minutes, or speed things up by calling `wp.heartbeat.connectNow()` in your console.
* An iframe should pop up (assuming you're not cross-domain, at least). Log in using ⌘\.
* It'll log into the iframe and submit it, which closes it.
* Note that every single settings field is filled with your login.
Here's a dead-simple HTML page to try that involves two different forms. Doesn't matter where the focus is when ⌘\ is invoked. Doesn't matter if it's one form, multiple forms, an iframe, whether the other inputs are even wrapped by form.
{{{