`
Narrowed down the issue to `do_shortcodes_in_html_tags()` where I found this:
{{{
if ( ( false === $single || $open < $single ) && ( false === $double || $open < $double ) ) {
// $attr like '[shortcode]' or 'name = [shortcode]' implies unfiltered_html.
// In this specific situation we assume KSES did not run because the input
// was written by an administrator, so we should avoid changing the output
// and we do not need to run KSES here.
$attr = preg_replace_callback( ""/$pattern/s"", 'do_shortcode_tag', $attr );
}}}
What bothers me is the part where it says ""assumes KSES did not run because the input was written by an administrator"".
Why not really check if an admin did write the input, at least for posts?
Attached is a patch that I did which possibly needs improvement from the WP gods :)
Thanks.
Mike",mikelopez
Tickets Needing Feedback,43686,Shortcodes containing asterisks may create invalid regex breaking the editor,,Shortcodes,,normal,normal,Future Release,defect (bug),new,dev-feedback,2018-04-03T21:31:40Z,2019-01-16T02:41:00Z,"Despite not being a reserved character an asterisk in a shortcode followed by another character will generate invalid regex which breaks the editor.
This code reproduces the issue:
{{{#!php
added after shortcodes,aaroncampbell,Formatting,3.0,normal,normal,,defect (bug),assigned,,2010-06-22T18:15:27Z,2019-06-04T19:43:02Z,"Currently `wpautop()` wraps a shortcode in `` tags as well as adding a ` ` tag after the shortcode. We then use `shortcode_unautop()` to remove the `
` tags, but the ` ` stays.
To replicate, just drop a few caption shortcodes into a post and set them all to align left or right. You'll see that even though they all float (assuming that's how your theme handles them) they stair step down because of the extra ` `
I'm not a regex expert so someone should probably double check my patch, but it seems to work for me.",aaroncampbell
Unpatched Bugs,34039,shortcode_parse_atts() no longer parses embedded html fragments,,Formatting,4.3.1,normal,normal,,defect (bug),new,,2015-09-27T03:38:25Z,2019-06-04T19:51:55Z,"I have a shortcode:
[show_custom_field field=""image_media"" before="" ""]
Previously, shortcode_parse_atts() would accept the attribute:
before="" 'desktop',
'expert' => '0',
'num_to_show' => '25',
'tooltip' => 'on'
), $atts ) );
the ""expert"" attribute/variable is getting quotes around the end result after being parsed",markclotfelter
Tickets Awaiting Review,56481,Short-circuit HEAD methods in Core controllers,,REST API,4.7,normal,normal,Awaiting Review,enhancement,new,,2022-08-31T19:53:43Z,2022-08-31T19:53:43Z,"The REST API has built-in support for responding to a `HEAD` request. If no callback is specifically registered for the method, the server will fallback to the associated `GET` handler. However, this means that the server is throwing away work when no response body is needed.
`GET` routes can be adapted to check if the `WP_REST_Request::get_method` is `HEAD` and if so skip preparing the response body. For single item routes, this is pretty straightforward.
It is a little more nebulous for collection routes. We still need to provide any headers like pagination which are currently prepared after the response body is generated.
I think we'd want to extract the pagination logic to it's own method. Then, before making the database query,
adjust the query to only return `ids`. This will give us enough information to build the pagination headers and allow us to send the `HEAD` response.
See https://github.com/WordPress/gutenberg/pull/43703",TimothyBlynJacobs
Tickets Awaiting Review,40280,Short-circuit filters can't return common values,,General,4.8,normal,normal,Awaiting Review,enhancement,new,has-patch,2017-03-27T19:09:10Z,2017-12-08T21:47:40Z,"#37930 contemplates adding another short-circuit filter, `pre_option`. This follows a pattern that is already duplicated several times and even somewhat fragmented in its implementations.
The short-circuit filter pattern has this problem: the return value is overloaded. Its meaning is either ""nothing changed"" or ""this is the new value"" and there are collisions between these meanings in cases where you might want to short-circuit-return `false` or `null`, depending on which short-circuit filter is being used. One proposed improvement is to use only `null` as the value meaning ""nothing changed"", as this is less likely than `false` is to be a value in any short-circuit situation.
The pattern using `null` can be formalized in a new function that does not overload the return value. This is accomplished by returning multiple values, which we can do in PHP by reference passing. A simple implementation using `null` and a usage example:
{{{
function apply_filters_pre( $filter, &$value ) {
$value = apply_filters( $filter, null );
return !is_null( $value );
}
if ( apply_filters_pre( 'get_option_pre', $value ) ) {
return $value;
}
}}}
(Other proposed function names include `if_apply_filters` and `apply_filters_short_circuit`.)
This centralizes the pattern and its documentation to a single core function, encapsulates the overloaded parameter as an implementation detail, and simplifies every existing and future call site. The diff would be net red. However, we are still unable to return `null` from a short-circuit position, which becomes a plausible use case if we enshrine this pattern in a core function. The collision space can be minimized by using a special type used nowhere else:
{{{
class WP_Unfiltered_Value {}
function apply_filters_pre( $filter, &$value ) {
$value = apply_filters( $filter, new WP_Unfiltered_Value );
return !is_object( $value ) || !is_a( $value, 'WP_Unfiltered_Value' );
}
}}}",andy
Candidates for Closure,46087,Short-circuit `page_on_front` check during site creation,,Rewrite Rules,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-01-23T22:58:45Z,2019-01-23T22:58:45Z,"During site initialization, `wp_installing()` is set to `true`. Among other things, this toggle disables all caching from `get_option()`. While I think that this behavior could use a general review (it's legacy behavior from MU that may have been an overly-broad fix for a narrow `alloptions` problem), there's one specific offender I'd like to consider addressing: `page_on_front`. `generate_rewrite_rules()` calls `get_option( 'page_on_front' )` several times for each rewrite rule, and each of these calls requires a database read.
Since `page_on_front` is set to 0 in the default schema, I propose that we short-circuit the check during site initialization (`wp_install_defaults()`). Something like:
{{{
add_filter( 'pre_option_page_on_front', '__return_empty_string' );
$wp_rewrite->init();
$wp_rewrite->flush_rules();
remove_filter( 'pre_option_page_on_front', '__return_empty_string' );
}}}
Not terribly elegant, but it can reduce DB I/O by many dozens of reads.",boonebgorges
Tickets Awaiting Review,59561,Short Description is missing in code comment,,General,6.3.2,normal,normal,Awaiting Review,enhancement,new,,2023-10-07T09:00:18Z,2023-10-25T21:44:20Z,"Short Description helps to understand variable behavior and it seems missing at the following locations.
https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/edit-form-advanced.php#L19
https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/edit-form-blocks.php#L23
https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/edit.php#L35
https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/post-new.php#L17
https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/post.php#L35
",1naveengiri
Tickets Awaiting Review,53405,short circuit before current filters for get_edit_user_link,,Users,,normal,normal,Awaiting Review,enhancement,new,,2021-06-15T07:50:14Z,2021-06-29T05:37:24Z,"currently the function get_edit_user_link can be filtered BUT it is only after it has gone searching for an appropriate value.
This is problematic as on multisite this search may call get_edit_profile_url and then get_dashboard_url which in turn then runs get_blogs_of_user which pulls all the options for every site that the user is a member of into memory. This can be huge and completely unnecessary!!
There needs to be a way to short cicuit this function at the start before all this occurs.
",shawfactor
Unpatched Enhancements,31531,Shiny Updates: Updates on update-core.php,,Upgrade/Install,,normal,normal,Future Release,task (blessed),assigned,,2015-03-05T04:10:58Z,2021-08-11T15:49:10Z,"Branched from #29820.
There are several improvements that can be made to `update-core.php`.
Adding inline update support to each of the sections on the page would be a great start, allowing everything to be updated without leaving the page.
Once this is in place, some sort of ""Update Everything"" button would potentially be a nice addition - it would also lay the groundwork for hiding a lot of the UI. If everything can be updated from one button, do we really need to show update buttons for every plugin and theme?
Finally, (this has been mentioned a few times since the original shiny updates work was done), this page is the ideal place for allowing admins to opt-in to auto updates for major WordPress releases, plugins, and themes.",pento
Unpatched Enhancements,31902,Shiny Updates: Language packs updates,,Upgrade/Install,4.2,normal,normal,,enhancement,new,,2015-04-06T10:25:26Z,2023-07-09T16:13:52Z,"Installing or updating plugin
WP 4.1: There is also language packs update triggered and users are notified what was updated.
Current trunk: There is only message ""Updated!"" and nobody knows if language packs update was also triggered and which languages were updated?",pavelevap
Unpatched Enhancements,31534,Shiny Updates: Language pack install support,,Upgrade/Install,,normal,normal,,enhancement,new,,2015-03-05T04:14:59Z,2019-06-04T21:14:19Z,"Branched from #29820.
With the addition of the FTP credentials screen, it'd be nice if language pack installation could make use of it.",pento
Tickets with Patches,37470,Shiny Updates: Erroneous Plugin Deactivation,,Plugins,4.2.4,normal,normal,Future Release,defect (bug),reopened,has-patch,2016-07-26T15:53:12Z,2017-08-08T21:40:31Z,"I recently noticed with a plugin of mine, that if you change the name of the main file in a version update, i.e.:
`plugin-name/plugin-name.php` => `plugin-name/different-name.php`
the plugin becomes inactive after the update. This was not the case prior to Shiny Updates and is still an issue in trunk. I installed 4.1.x just to be sure.
Steps to reproduce:
1. Put plugin on .org repo
2. Install/activate plugin on a site.
3. Change the name of the main file in svn and commit it with a version bump.
4. Update the plugin with Shiny Updates.
",voldemortensen
Tickets with Patches,31532,Shiny Updates: Don't activate plugins with PHP errors,,Upgrade/Install,,normal,normal,,enhancement,assigned,has-patch,2015-03-05T04:12:28Z,2020-01-07T23:57:59Z,"Branched from #29820.
When we try to activate a plugin through shiny updates, we shouldn't do it if it causes PHP errors.",pento
Tickets with Patches,37669,Shiny Updates: Cancelling the filesystem credentials when updating within the pop-up prevents updating again (without closing/opening) and leaves UI artefacts,,Themes,4.6,normal,normal,Future Release,defect (bug),new,has-patch,2016-08-15T14:16:55Z,2021-02-06T11:39:52Z,"Reproducible on RC3: 4.6-RC3-38260
Reproducible: every time
Steps to reproduce:
1) Set up WordPress, and set permissions to that the 'filesystem credentials' dialog will be required when performing theme updates.
2) Tweak a version number so that you will have a theme that needs an update. Then, go to /wp-admin/themes.php
3) Do *not* click on the immediately visible ""Update now"". Instead, click on the theme such that the pop-up pops up.
4) Click on the ""Update now"" link within the pop-up. If step 1) was done correctly, then the filesystem dialog should now pop up.
5) Close the filesystem credentials dialog.
Result: ""Updating..."" will still show there. But nothing will be updating. You cannot update until you close the pop-up and re-open it.
Excepted result: The ""update now"" link re-appears, and ""Updating.."" disappears.
Result: nothing happens.
#37285 is similar, but a separate (and now fixed) issue.
",DavidAnderson
Slated for Next Release,60814,several typo corrections in formatting.php file,audrasjb*,Formatting,,normal,trivial,6.6,defect (bug),accepted,commit,2024-03-20T17:06:23Z,2024-03-20T17:36:50Z,"several typo corrections in wp-includes/formatting.php file inline comments
`parethesis` -> `parenthesis`
`paretheses` -> `parentheses`
`puctuation` -> `punctuation`",shailu25
Tickets with Patches,43896,Several flex and grid CSS properties listed as Unknown property in Customizer,,Customize,4.9,normal,normal,Future Release,defect (bug),new,has-patch,2018-04-29T01:11:57Z,2021-05-30T17:53:57Z,"When I use the CSS editor in the Customizer it suggests element properties as I start typing them. One of the properties that it suggests is the justify-items property. When I save the settings in the Customizer I get a notice of ""Unknown property 'justify-items'.""
I've checked some of the other flexbox and grid properties, and there are several others that this is the case for, namely:
- justify-items
- grid-gap
- grid-column-gap
- grid-row-gap
- place-self
The properties still work in supported browsers, they just display an error in the Customizer. Some valid values for properties that are recognized also give errors, such as the values of start and end for several grid properties.",davidjlaietta
Tickets Needing Feedback,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
Slated for Next Release,43936,Settings: Warn when open registration and new user default is privileged,audrasjb*,Security,,normal,normal,6.6,feature request,accepted,has-patch,2018-05-02T18:21:52Z,2024-03-24T05:30:34Z,"Much like our Strong Passwords work, we can help inform site administrators when their actions may be sub-optimal.
WordPress allows a site owner to open registration AND set the default new user level to ""Administrator"". While this combination may make sense for some sites (on an intranet?), this is typically a really really bad idea.
We should provide some type of confirmation to ensure site administrators are intending to open their site up.
If registration is open and default level is Subscriber (`read` cap only), the current behavior is fine. If registration is open and other capabilities are included in the default role, we should have some type of checkbox or ""are you sure"" notice. ""By allowing open registration and a default role of {role}, anyone who can visit the site would have the ability to {have full control of your site|publish content|etc}.""
We saw this in the wild on a site in support today :).",kraftbj
Unpatched Enhancements,29288,Settings updated within the Customizer Preview are not synced up to main app Panel,,Customize,3.4,lowest,normal,Future Release,enhancement,new,,2014-08-20T20:05:43Z,2021-05-22T19:32:28Z,"The Customizer has two copies of models for the registered settings: one set in in the Customizer panel parent frame, and changes to these result in the settings getting copied over to the preview either via postMessage or via a refreshing the preview entirely. Updating a setting model from within preview directly, however, does not propagate up to the model. There is currently a one-way-sync from the panel to the preview.
As a workaround, the preview can send messages to the panel for which handlers can apply the updates to the settings, but it would be good if this was automatic.
By implementing a bi-directional syncing of settings between the panel and preview, there would be lots of opportunities for inline front-end editor controls to more easily be added into the preview directly.
See also https://twitter.com/bradyvercher/status/502163462990995456",westonruter
Unpatched Enhancements,16413,Settings page needs HTML refactoring and UI improvements,joedolson*,Administration,3.1,normal,normal,Future Release,enhancement,accepted,,2011-01-30T20:22:09Z,2023-11-10T16:20:51Z,"The settings pages haven't had much attention or improvement in a while.
We need to refactor the HTML on the settings pages, as they are still using tables instead of divs.
We also want to make some minor UI improvements including:
- clearer differentiation between option groupings
- using consistent text styles for descriptions and links (including the time zone/date format comment)
- restructure for better readability
Comment if you have any other",chexee
Tickets with Patches,33551,Settings API: Filter sections and fields before displaying them,obenland,"Options, Meta APIs",2.7,normal,normal,,enhancement,assigned,needs-docs,2015-08-26T06:08:48Z,2019-11-27T18:26:09Z,"Once a section or settings field was added, there is currently no good way to remove it or change the order they are displayed in. It would be good to add filters in `do_settings_section()` and `do_settings_fields()` to allow for that to happen.
We could also think about providing convenience functions to use in a callback to those filters, along the lines of `remove_option_whitelist()`.",obenland
Tickets Awaiting Review,55584,Settings API autoload hook,,"Options, Meta APIs",,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-04-18T04:56:49Z,2023-08-31T17:43:17Z,"Currently all settings registered via Settings API is forced to enable autoload, There is no hook to replace this.
Lets imagine just for example:
1. all wordpress plugins is using this to register their settings data. but not delete this value during uninstall.
2. Average wodpress admin install then uninstall 50 plugins in their lifetime.
3. Average autoloaded setting is 100kb per plugin
there will be 5mb autoloaded options which not used anymore. that event is per pageload. Just imagine that. ",hir88en
Unpatched Bugs,9296,Settings API & Permalink Settings Page Bug,jfarthing84,Permalinks,2.7.1,normal,major,Future Release,defect (bug),reopened,,2009-03-07T05:33:55Z,2020-09-25T23:12:01Z,"Although there is a hook in the options-permalink.php to insert custom settings, it does not actually save any custom setting which is added to that page. Instead of posting to options.php like all the other options pages, it posts to itself and only handles the form data which is built into the wordpress core. It should be implemented on that page to also store custom settings that may be hooked onto that page.",jfarthing84
Unpatched Bugs,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
Tickets Awaiting Review,46943,Settings ->Discussion bad view dropdown in mobile version,,Comments,,normal,normal,Awaiting Review,defect (bug),new,,2019-04-15T23:00:28Z,2019-10-21T16:44:39Z,"Settings ->Discussion all dropdown are bigger on the responsive view. so need to make it size small same as desktop view and content align proper same as desktop view.
",ketanumretiya030
Tickets Awaiting Review,35771,Setting Size for Native Video Player Doesn't Work,,Media,,normal,normal,Awaiting Review,defect (bug),new,,2016-02-07T21:28:00Z,2017-06-27T16:50:20Z,"Width and height rules do not affix the size of the embedded native media player.
Width is ultimately honored, but height setting is overruled and set proportionally based on video's proportions. Consequently, if width of the player is set to fill in the theme's available content space, but the embedded video is vertical (filmed vertically, whereby height of the video is greater than width), then the player will be stretched way too tall, regardless of height settings (which is ultimately ignored).
To reproduce:
Embed any locally hosted, vertical video using native video player, using the Embed Media Player option from the Insert Media attachment window. Set width to the width of your theme's content area, and height to less than width. Height will not be honored.
Desired solution:
Set player size to the width and height chosen by the user. Fit the video within the set space of the player.",Tranny
Unpatched Enhancements,31283,Setting poster image for videos inside a video playlist is not very intuitive,,Media,4.2,normal,normal,,enhancement,new,,2015-02-10T15:43:13Z,2019-06-04T20:11:16Z,"This is somehow a follow-up to #27891.
When you create a video playlist, it's very hard to understand how to change the poster images of the videos.
Here is the workflow :
1. Upload some videos
1. Create a new article and insert one single video
1. Edit the inserted video to open the media modal again, and select a poster image for your video
1. Nice !
1. Create another article and insert a video playlist
1. When you choose video, the one that was inserted in the previous article is shown with the poster image instead of the default video icon : very nice !
1. For other videos, there is no way to select a poster image, neither during initial playlist creation, nor after having inserted the playlist :-(
1. To select a poster image, you have to go back to the main Media menu, find the right video and edit its details, and then set the featured image (that you guessed it was the same as the poster image)
I see at least three ways to improve that workflow.
1. In the ""Edit video playlist"" modal, add a ""Select poster image"" menu, similar to the one that exists in the ""Video details"" modal for the video shortcode.
1. When browsing videos in the media modal, add a link to set the poster image, in the same manner that the ""Edit image"" link works for images
1. When browsing videos in the main Medias menu, add a link to set the poster image, in the same manner that the ""Edit image"" link works for images
1. Bonus : change ""Featured Image"" title to ""Poster image"" in the video attachment post edition page
1. Big Bonus : when browsing videos in the main Medias menu, add a button ""take a screenshot and set as poster"" when a video is shown. This will load the video into a canvas, generate an image from this canvas, send the image to the server and set it as poster !
",Fab1en
Tickets Needing Feedback,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
Tickets Awaiting Review,50885,Setting a pre_get_posts query post_type to array results in broken wp-admin filters,,Query,5.4.2,normal,normal,Awaiting Review,defect (bug),new,,2020-08-10T12:46:14Z,2020-08-11T01:27:00Z,"I have a in-house plugin which creates a few extra alternate post types (eg. `post_custom`), and one of its requirements is that these post types are queried together with normal posts.
To do this, I've implemented a function which converts any queries for the `post` post type into `array( 'post', 'post_custom', ... )` and it works as it should, but when on wp-admin, if one tries to go into the default ""Posts"" menu and filter by author or even search for anything, it will return a message saying ""Invalid post type"".
Checking the URL, it will contain the `post_type` query string as ""Array"" instead of ""post"", and changing it manually to ""post"" fixes the issue. I guess the wp-admin interface is not handling the array of post types correctly?",matpratta
Unpatched Bugs,33977,"set_transient('settings_errors', get_settings_errors(), 30); and multi user @ wp-admin/options.php",,"Options, Meta APIs",4.3.1,normal,normal,,defect (bug),new,,2015-09-23T13:37:52Z,2019-06-04T20:51:48Z,"
{{{
#!div style=""font-size: 80%""
Code highlighting:
{{{#!php
/**
* Handle settings errors and return to options page
*/
// If no settings errors were registered add a general 'updated' message.
if ( !count( get_settings_errors() ) )
add_settings_error('general', 'settings_updated', __('Settings saved.'), 'updated');
set_transient('settings_errors', get_settings_errors(), 30);
/**
* Redirect back to the settings page that was submitted
*/
$goback = add_query_arg( 'settings-updated', 'true', wp_get_referer() );
wp_redirect( $goback );
exit;
}}}
}}}
I see the code above in wp-admin/options.php
since the key 'settings_errors' is not binding to a user, Is there a chance than one user's error message may be shown on another user's page?",coldwinds
Tickets Awaiting Review,34322,set_transient and get_transient don't seem to be working for some users since WP 4.3,,"Options, Meta APIs",4.3,normal,normal,Awaiting Review,defect (bug),new,,2015-10-16T04:07:34Z,2017-04-06T17:08:22Z,"I'm the developer of a social media plugin which relies on the WordPress set_transient and get_transient functions to temporarily cache data in the user's database. Since the WordPress 4.3 update, we've had reports of the cache not clearing automatically as it should, meaning that the transients aren't expiring correctly in the database. This seems to only be happening on some servers as I haven't been able to replicate the issue on my own test site, but have confirmed it on user sites, and looks like it could be related to [https://make.wordpress.org/core/2015/07/30/get_transient-is-now-more-strict-in-4-3/ this thread]. The same problem seems to be happening to other developers of similar plugins, and I've had some users report that other unrelated WordPress plugins they're using are also not automatically updating either any more, which I'm assuming is caused by the same issue. I've been able to confirm the problem on user sites by using a page template containing the following basic code. I've commented it to explain what it does and can provide a Facebook Access Token privately if needed, although I included a link on how to obtain your own. The transient set using the script below should expire every 30 minutes and then the script should check the URL again for new data, but it doesn't unless I delete the transient manually.
{{{
';
//Show the date the data was last updated from Facebook
echo 'Last updated: ' . json_decode( json_encode($transient) )->headers->date;
} else {
//No transient in the database - get the data from Facebook
$facebook_data = wp_remote_get( $url );
//Cache the data in the database
set_transient( 'test_transient_expiration', $facebook_data, 1800 );
echo 'Got the data from the URL ';
//Show the date the data was last updated from Facebook
echo 'Last updated: ' . json_decode( json_encode($facebook_data) )->headers->date;
}
?>
}}}
I was in two minds whether to report this as a bug as I've never reported one before, however it definitely seems like this could be a bug as the above code should work, but doesn't on some user's sites. I use code very similar to the above in my plugin and nothing has been changed in that code, but users started reporting an issue shortly after the WordPress 4.3 update was released. Through reading the change logs for the 4.3 update I know some changes were made to transients and so I'm wondering if that's what caused this problem.
Sorry for the long post!
John",smashballoon
Unpatched Bugs,32863,set_custom_fields function in wp_xmlrpc_server class,,XML-RPC,4.2.2,normal,trivial,,defect (bug),new,,2015-07-02T10:04:32Z,2019-06-05T06:41:07Z,"Hi,
I was working with wp_xmlrpc_server class to insert and update woocommerce products but i found that my custom fields are not working properly. When i inspected the code of function set_custom_fields , i noticed that we are using wp_unslash to remove underscores from custom field keys. So keys like _price , _quantity and _stock were not working for the product custom post type. Secondly we are using add_post_meta to insert the meta data. Can we change it to the update_post_meta ?
I have attached the updated function.Please test it and let me know.
{{{
public function set_custom_fields($post_id, $fields) {
$post_id = (int) $post_id;
foreach ( (array) $fields as $meta ) {
if ( isset($meta['id']) ) {
$meta['id'] = (int) $meta['id'];
$pmeta = get_metadata_by_mid( 'post', $meta['id'] );
if ( isset($meta['key']) ) {
$meta['key'] = ( $meta['key'] );
if ( $meta['key'] !== $pmeta->meta_key )
continue;
$meta['value'] = ( $meta['value'] );
if ( current_user_can( 'edit_post_meta', $post_id, $meta['key'] ) )
update_metadata_by_mid( 'post', $meta['id'], $meta['value'] );
} elseif ( current_user_can( 'delete_post_meta', $post_id, $pmeta->meta_key ) ) {
delete_metadata_by_mid( 'post', $meta['id'] );
}
} else{
update_post_meta( $post_id, $meta['key'], $meta['value'] );
}
}
}
}}}
Regards,
Arif
Skype: arifamir33
",marifamir
Candidates for Closure,54479,Set_blog_id performance,,General,5.9,normal,normal,Awaiting Review,enhancement,new,reporter-feedback,2021-11-20T10:06:43Z,2021-11-20T17:27:05Z,"On multisite many plugins switches blog (wbdb->set_blog_id) many times (few thousands).
There is a performance impact in wpdb->tables method.
Simple caching reduces overall execution time.",wladwm
Tickets Awaiting Review,50682,Set theme information popup in vertically middle.,,Themes,5.5,normal,normal,Awaiting Review,defect (bug),new,has-patch,2020-07-16T14:49:18Z,2021-10-03T04:32:08Z,When we open theme info popup has more space on top. It should be vertically middle.,chetan200891
Tickets with Patches,36791,Set load order when enqueuing scripts and styles,,Script Loader,4.6,normal,normal,,enhancement,new,has-patch,2016-05-09T18:42:31Z,2019-06-04T21:22:48Z,I've implemented a patch and associated unit tests to add the ability to set the offset within the style or script queue when enqueuing styles or scripts. This will allow a developer to prioritize or set a strict order in which the stylesheets and/or scripts should load. This new functionality is optional and so all current code will continue to function as it always has.,logistiker
Tickets Awaiting Review,29795,Set JPEG quality for individual image_size,,Media,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2014-09-29T14:20:54Z,2017-11-10T12:24:43Z,"Based on this idea I would like to work on this topic:
https://wordpress.org/ideas/topic/jpeg-compression-factor-for-different-image_size
Usecase:
If a theme use an image as a full screen background image the image quality doesn't need to be as high as for a featured image or thumbnail.
The difference in file-size would benefit the webspace and the speed on page load.
I can think of two ways to solve it:
1. Add a argument to add_image_size:
{{{
add_image_size( $name, $width, $height, $crop, $quality );
}}}
2. Add filter for it:
{{{
apply_filters( 'jpeg_quality_for_image_size', $quality, $size );
}}}
In both cases the information about the current image size needs to be added to the set_quality or get_quality functions to be available.",Drivingralle
Candidates for Closure,58927,Set featured image missing,,General,6.2.2,normal,major,Awaiting Review,defect (bug),reopened,close,2023-07-28T07:13:02Z,2023-08-24T22:53:05Z,"Latest version 6.2.2, php version 8.1
Why it happens - unknown
Happens even if all plugins deactivated, changed theme
Expected set featured image button, this section is missing
Theme support added to the functions.php, but this happens with all twenty themes as well
Server information below
Set featured image is missing, cannot set featured image. Tried all browsers, disabling all plugins, changing theme. Only installing ""disable gutenberg"" plugin helps and ""set featured image"" back again.
Fresh install.
Also this happens with other older websites (v6.1.1)
On some websites it works fine, but there is slight delay before it appears.
cPanel Version 110.0 (build 7)
Apache Version 2.4.57
MySQL Version 10.3.38-MariaDB-log-cll-lve
Architecture x86_64
Operating System linux
Path to Sendmail /usr/sbin/sendmail
Path to Perl /usr/bin/perl
Perl Version 5.16.3
Kernel Version 3.10.0-962.3.2.lve1.5.80.el7.x86_64",ernasx
Tickets Awaiting Review,37597,served oEmbed from cache even when expired,,Embeds,4.0,normal,normal,Awaiting Review,defect (bug),reopened,,2016-08-08T11:37:17Z,2018-03-05T15:26:53Z,"There is wrong condition in wp-includes/class-wp-embed.php
Embeds are pulled from cache even if $cached_recently is false = expired.
This condition:
{{{#!php
usecache || $cached_recently ) {
}}}
should be changed to:
{{{#!php
usecache && $cached_recently ) {
}}}",zabatonni
Tickets Awaiting Review,45296,Serious side-effects when login in another tab after session expiration in first tab,,Users,,normal,normal,Awaiting Review,defect (bug),new,,2018-11-06T08:31:26Z,2018-11-06T22:24:04Z,"= A. STEPS TO REPRODUCE:
1. Start editing a new blog post.
2. Open a preview of it in some other browser tab.
3. Leave it open and hibernate computer for several hours (or otherwise expire the session without refreshing / closing the editor).
4. Add a new comment to that blog that requires moderation or otherwise cause owner to receive e-mail with a link to a blog.
5. Click on received link. New browser tab or window will open. Session is expired so login screen appears (correct!).
6. Login to WordPress.
7. Go back to the other / left open / hibernated browser tabs and try to do anything.
In that ""old"" / other tab you're logged-off / you have session expired (even though you have just logged in again), but WordPress isn't able to handle this situation gracefully.
= B. SIDE-EFFECTS
== B1. UNABLE TO ADD AN IMAGE
1. An attempt to add an image causes image browser to display ""loading knob"" infinitely.
== B2. UNABLE TO SAVE THE DRAFT
1. An attempt to save the draft actually DESTROYS the draft in the database.
2. Clicking this button causes WordPress to display login screen (even though you're already logged in; see below).
3. From this moment on your draft preview (the other ""old"" tab) will be constantly showing ""Page not found"".
4. After publishing and unpublishing the page it gets even worse -- only ""Page not found"" page title appears in tab and tab is constantly being refreshed endlessly by the browser.
== B3. UNABLE TO LOGIN
1. An attempt to refresh the page displays login screen (even though you're already logged in).
2. Logging in is impossible. After login WordPress displays login page again and says that browser has cookies disabled (not true).
3. To solve this problem one must restart entire browser (cleaning session cookies?) and login again.
= C. Conclusions
Restarting browser solves the B3 and B1 problems only. B2 problem partially remains. Wordpress is able to save the draft, but still doing this incorrectly and later isn't able to show preview of the post, claiming that page is not found or reloading page forever.
To solve last part of B2 problem one must restart browser, re-login and save the draft several times.",trejder
Unpatched Bugs,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
Tickets Needing Feedback,14125,Seperate out non-editable options in edit site,sorich87*,"Options, Meta APIs",,normal,normal,,enhancement,accepted,dev-feedback,2010-06-28T04:11:36Z,2019-06-04T20:41:23Z,"In the edit site screen, blog options which are arrays are shown as SERIALIZED and the textbox is disabled. The attached patch pulls those options out of the options metabox and displays the option name in another metabox below.
Related: #14120",wpmuguru
Tickets with Patches,39960,Separate Supported Status for Trackbacks and Pingbacks,,Pings/Trackbacks,4.3,low,minor,Future Release,defect (bug),new,has-patch,2017-02-24T04:01:35Z,2018-10-08T04:38:00Z,"In #31168, get_default_comment_status was introduced, with the intent to set default pingback and comment status for new comments.
With the current design, it isn't possible to address these items separately.
get_default_comment_status treats the 'supports' => 'trackbacks' statement as intent to open pings. While I see the rationale for why this was done, it is not consistent.
Supporting trackbacks is not actually clear to someone calling it what it is supposed to do. According to the code, excluding allowing pings by default as amended in this function and a few other places, it adds the 'Send Trackbacks' metabox.
What I am proposing here is therefore a change that might confuse backward compatibility. I can't see another easy way to separate these two.
Let's say, for the sake of fairness as a default, that if you want to be able to send pings or trackbacks, you should also support receiving them.
So, my proposal would be to separate post_type_support into two features:
'trackbacks' - which will add the trackback metabox and govern the default desire to accept trackbacks for that post type
'pingbacks' - which will set whether the default for pingbacks for a given post type is set to send/receive by default.
That handles the intent of the post type default. Then we move to the individual post issue.
So, the logic I'm proposing is that if pings are open for the post(ping_status set to open), it means it will support whatever protocols the post type supports. While it would be nice to get more granular, it would create too much of a strain on backward compatibility.
Conversely, suggesting that someone might want to turn pingbacks or trackbacks on or off for an entire post type makes sense. I can't see a scenario where someone would want support on or off for a specific post. If they decide to turn pings off, they are turning off whatever type of linkback the post chooses to support.
A plugin or theme could change this behavior using the get_default_comment_status filter that already exists.
Relate: #38207 discusses the idea of disabling trackbacks by default, but retaining pingbacks for the foreseeable future. The first step is allowing for these sensible defaults by post type, and then making the decision about default support for the 'post' post type.
I'd like to get some feedback on the proposed solution or alternatives.",dshanske
Tickets Awaiting Review,47735,Separate sites I have created and sites I have joined in a network install,,Networks and Sites,,normal,normal,Awaiting Review,enhancement,new,,2019-07-18T21:31:53Z,2019-07-19T00:51:13Z,"In a network install there doesn't seem to be a way to separate ""My Sites"". For example, ""My Sites"" in wp-admin/my-sites.php includes both sites I have created and sites I have joined. As a user I would like to see the sites I have created and manage in a different area to the sites I have joined.
",henry.wright
Candidates for Closure,43208,Separate setting validation from sanitization,,"Options, Meta APIs",,normal,normal,Awaiting Review,enhancement,new,needs-unit-tests,2018-02-01T23:45:12Z,2020-11-06T23:12:25Z,"As widely known, validation is different from sanitization. A value should first be validated and then be sanitized. Historically, WordPress has been mixing these two responsibilities in the `sanitize_option()` function, however it is easily possible to add an extra layer on top of that which maintains full backward-compatibility.
Newer parts of core, such as the Customizer and the REST API, have been dealing with this in a better way, keeping the two separate. We can achieve the same for options themselves too.
I suggest introducing a `validate_option_{$option}` filter that works somewhat similar like the `customize_validate_{$setting_id}` filter used in the Customizer. It passes an empty `WP_Error` object that can be added to. In addition to allow separate validation from sanitization, it also makes handling of validation easier, since it can then automatically set the value to the previous value and call `add_settings_error()`, passing any error messages set, which matches current core behavior.",flixos90
Candidates for Closure,13372,Separate Image sizes for different post types,,Media,4.6.1,normal,normal,Awaiting Review,enhancement,reopened,close,2010-05-13T07:59:07Z,2020-04-18T04:45:23Z,"Would be nice, especially moving forward with custom post types to have the ability to set different image sizes using an additional parameter of `add_image_size()` for different post types: Page, Post, and Custom.",brandondove
Tickets with Patches,35829,Separate functions from wp-login.php,,Login and Registration,,normal,normal,,enhancement,new,has-patch,2016-02-14T13:10:10Z,2019-06-04T20:22:28Z,"There are some functions in `wp-login.php`. But it makes hard to customize login page. (e.g. [https://github.com/georgestephanis/two-factor/pull/62 2FA Feature plugin])
Related: #20279",extendwings
Unpatched Enhancements,52288,Separate Color Palette for Text,sarahricker,Editor,,normal,normal,Future Release,enhancement,assigned,,2021-01-13T09:22:54Z,2021-05-21T15:39:45Z,"It would be great with a separate Theme Support feature to be able to add a color palette for text colors only. It is often not a good feature to allow the average user to have access to a lot of colors that can be mixed in any way. Readability can be discarded.
add_theme_support( 'editor-text-color-palette' , [ ... ] );
add_theme_support( 'editor-color-palette' , [ ... ] );
",jontng
Tickets Awaiting Review,37934,Separate account settings and profile settings,,Users,,normal,normal,Awaiting Review,enhancement,new,,2016-09-03T13:36:41Z,2023-01-10T18:35:40Z,"Current limitations of profile management in WordPress:
On `wp-admin/profile.php` there's too much you can do:
* Change personal preferences
* Account and session management
* Update publicly visible profile data
If plugins add additional fields to that page, it gets very long quite quickly. Even without plugins you have to scroll all the way down to change your password. Pretty sure you change your password more often than disabling the visual editor, so that order isn't ideal.
Idea:
Separate account management and profile settings. Platforms like WordPress.com, Facebook or Twitter do this for a reason.
This was recently mentioned in a discussion about adding 2FA to core, see https://wordpress.slack.com/archives/core/p1470765550002658.
The plugin I mentioned there: https://wordpress.org/plugins/wp-user-profiles/
Slightly related: #26769.
Account management:
* Change backend preferences
* Change email address
* Change password
* Log out everywhere else (perhaps with a session overview in the future as was originally the plan)
Profile management:
* Show/change profile picture
* Change biographical info like name, contact methods",swissspidy
Tickets Awaiting Review,56895,SEO tools can't differ from Tag and Categories,,Taxonomy,,normal,normal,Awaiting Review,feature request,new,,2022-10-24T14:59:08Z,2022-10-24T15:39:05Z,"To avoid duplicate titles, we need to make it possible to differ between the tag archive and the category archive.
Today we need a plugin like Yoast to fix it.
If we change general-template.php line 1208-1217
From:
{{{#!php
get_bulk_actions() uses ""if ( current_user_can( 'edit_users' ) )"" as the condition to determine if this can be allowed. The same check is performed in the single_row() method when the actions are specified.
I understand there are restrictions in multi-site for user creation/editing for non-super admins, however I believe this is not a security action and should not be restricted for site administrators.",jcutler
Tickets Awaiting Review,57233,Send password reset action link not working on multisite,,Networks and Sites,6.1.1,normal,normal,Awaiting Review,defect (bug),new,,2022-11-30T08:08:46Z,2022-11-30T08:08:46Z,"In a multisite installation while the quick action link ""Send password reset"" shows up when accessing users list (wp-admin/network/site-users.php), it doesn't send the email neither any admin notice appear when clicked. It simply redirects to the main multisite users screen (wp-admin/network/users.php).",christopherplus
Tickets with Patches,33717,Send Notification Email When a Comment is Approved From Moderation,,Comments,,normal,normal,Future Release,enhancement,assigned,has-patch,2015-09-04T00:43:09Z,2021-05-13T20:02:21Z,"Currently in WordPress, commenters have no idea their comment is approved unless they visit the page often. When a comment is held for moderation, WordPress should send the commenter an email notification when their comment is approved. I'm using the [http://wptavern.com/an-easy-way-to-notify-users-when-their-comment-is-approved Comment Approved] plugin to add this functionality to WordPress but I really think it should be a core feature. ",jeffr0
Tickets Awaiting Review,38028,Send emails via an action,,Mail,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2016-09-12T20:55:20Z,2020-01-16T14:30:48Z,"There are a number of ways that you may want to interact with core emails in WordPress. To name two
* Use a different server to send (e.g. to benefit from DKIM/SPF)
* Use custom templates, HTML, multipart etc.
Currently solutions to achieve these things are not ideal. Pluggable functions leave exposure to other core changes and leave no scope for a 'fallback' to default if it is necessary.
Filters for content are inconsistently (if at all) applied leaving some messages totally inaccessible to developers, save through the wp_mail filter - which is hacky at best (try catching a translated message).
My proposal is relatively simple - send all emails in core through an action hook.
`do_action( 'wp_mail_{email_id}', $args );`
`$args` of course would carry the necessary elements for the dynamic parts of a message.
An call add_action can then exactly replace what is being done at present to generate the message and make the `wp_mail` call.
Any developer that wants to interact with the message can then simply remove the core action and add their own - to alter the message and/or send using an alternative mechanism to `wp_mail`, falling back to it if necessary. Possibilities for developers are then endless.
`wp_mail` stays in tact and as the hook call replaces current functionality there is no issue with backward compatibility - all existing filters can stay in place.",markcallen
Unpatched Enhancements,32459,Send custom metadata alongside a file upload via the media uploader,,Media,4.2.2,normal,normal,,enhancement,new,,2015-05-21T18:53:13Z,2019-06-04T20:14:00Z,"As WordPress has evolved into a very powerful CMS, responsive layouts and high-resolution screens are growing more and more common. It's not uncommon for large sites to register several additional image sizes, and adding 2X support doubles the number of images created behind the scenes.
It would be nice for plugins to be able to have more granular control over the sizes that are created when an image is uploaded.
An example: a company Team page features portraits for each employee. Only two sizes are needed: 250x250 and 500x500 (2x). Meanwhile, the rest of the site has nearly a dozen custom image sizes. When the portraits are uploaded, a dozen sizes are created, but only two are needed. Similarly, registering these two new sizes registers them for every image uploaded to the site.
In a plugin like Advanced Custom Fields, I'd like to be able to tell the uploader to skip all of the built-in sizes and hand-pick the sizes I do want to create.
In other words, a new set of sizes would need to be registered that aren't automatically included in the global set of image sizes, but are available for plugins to select and send to the uploader. The uploader could be given a special set of sizes when it's opened, and those special sizes can be fetched from the theme.
To be clear, I'm not talking about generating new image sizes when the theme requests them. This request is for overriding the sizes that the uploader applies to a new image.
I've explored the built-in functions and hooks and filters, but it doesn't appear there's a way to override the sizes that are created in the way I describe.",danphilibin
Unpatched Enhancements,26504,Semantic elements for non-link links,joedolson*,Administration,3.8,normal,normal,Future Release,task (blessed),accepted,,2013-12-09T14:29:18Z,2024-01-30T15:12:56Z,"Using the [http://heydonworks.com/revenge_css_bookmarklet/ revenge.css bookmarklet] on the dashboard gives a very [http://d.pr/i/yVYh clear indication] that some of the links on there are semantically incorrect - they should be buttons, even if they should look like links.
The Actual Buttons Are Actual section of this [http://coding.smashingmagazine.com/2013/08/20/semantic-css-with-intelligent-selectors/ article] sums it up nicely why.
Unless the accessibility team have indicated otherwise, each of the 74+ occurrences (only counting PHP files, more in JS files) of links with `href=""#""` should probably be a ``, so that screen readers interpret it as a button that does something, rather than a link that takes you somewhere. It also reduces the number of links that can be pulled out of context.
Appearance isn't a problem either - taking the ""See 3 more…"" from the screenshot:
{{{
// Original:
See 3 more…
// New (might benefit from ARIA attribute):
See 3 more…
// Basic CSS:
.no-button {
background: none;
border: none;
color: #0074a2;
}
.no-button:hover {
color: #2EA2C9;
cursor: pointer;
}
",GaryJ
Tickets Needing Feedback,42193,Select text in readonly textarea on focus,,"Options, Meta APIs",4.9,normal,normal,Future Release,enhancement,new,has-patch,2017-10-12T09:30:03Z,2018-09-17T16:59:54Z,"[[Image(https://ibin.co/3dVwFgRPo6d1.png)]]
It would be better if the text is selected when the user clicks (focus) on a read-only textarea, especially when it's meant to be copied, for example in the Network Setup section, a user has to copy-paste in the wp-config.php or the .htaccess file.",NomNom99
Tickets Awaiting Review,48361,Select Files on iOS doesn't trigger on modal if start on Upload Files tab and switch to Media Library tab,adamsilverstein,Media,,normal,normal,Awaiting Review,defect (bug),assigned,,2019-10-17T23:27:06Z,2019-11-03T19:46:59Z,"Hello,
I came across an odd issues on a client site recently using ACF and the Gallery field so I did a fresh install and found the issue resides in core as well.
In short the 'Select Files' button doesn't trigger the uploader if you trigger the media modal starting on 'Upload Files' and then switching to 'Media Library' when there's no files present.
To reproduce use an iOS device (iPad/iPhone);
1. Install a clean WordPress
2. Create a new post.
3. Add a Gallery block
4. Click the 'Media Library' button.
5. If your Media Modal opens with 'Media Library' tab selected then switch to 'Upload Files' and reload the screen.
6. Your Media Modal should open on 'Upload Files' now.
7. Switch to the Media Library tab now.
8. Click the 'Select Files' button that appears below the 'No items found' text.
9. Note the uploader isn't triggered.
This seems to only occur when there's no items in your media library and you are using the Media Modal but your settings have it open on 'Upload Files' first and then you switch to 'Media Library'.
I initially came across this with an ACF Gallery field, but in my clean install it was the Gallery block that I was able to reproduce the issue with.
All the best,
Cheers
",garrett-eclipse
Unpatched Bugs,32952,Select elements don't have the same size as input elements,,Quick/Bulk Edit,3.8,normal,normal,,defect (bug),new,close,2015-07-09T20:22:56Z,2023-05-14T19:48:31Z,"[[Image(https://cldup.com/Daws15AjdJ.png)]]
- `select` elements should have the same font size as other `input` elements",sunnyratilal
Tickets Awaiting Review,51282,Select element does not honor admin color scheme on hover,,Administration,5.5.1,normal,minor,Awaiting Review,defect (bug),new,has-patch,2020-09-09T18:56:21Z,2020-09-23T23:54:09Z,"When select elements are hovered, the text color changes to the ""default color scheme"" and not to the color scheme selected bu the user.
For example, the user has selected ""sunrise"" color scheme the hover color on the select element should be from the ""red/orange"" palette. But it has the default color scheme's blue color.
Since all other inputs honor the color scheme color select element should also follow the same.
The fix should be that below selector should be added in color scheme CSS files with the respective scheme color.
{{{
.wp-core-ui select:hover {
color: #007cba;
}
}}}
[[Image(https://i.snipboard.io/RMaoLd.jpg)]]",vaakash
Tickets Awaiting Review,38062,SELECT DISTINCT ... ORDER BY ...,,Query,4.6,normal,normal,Awaiting Review,defect (bug),new,has-patch,2016-09-14T22:36:46Z,2019-04-09T18:51:23Z,"I'm not 100% certain of how best to change this in the code, but I've attached a patch that I believe is correct and fixes it ...
In '''./wp-includes/class-wp-query.php:2810''' (trunk), there is a query that looks like:
{{{
SELECT $found_rows $distinct {$this->db->posts}.ID
FROM {$this->db->posts} $join
WHERE 1=1 $where $groupby $orderby $limits
}}}
When run, in some cases at least, the query turns into:
{{{
SELECT SQL_CALC_FOUND_ROWS distinct wp_posts.ID
FROM wp_posts
...
ORDER BY wp_posts.post_date ...
}}}
The problem with the query is that it could potentially give unpredictable results ... the only reason it doesn't is because wp_posts.ID happens to be a Primary Key, and therefore, is already guaranteed that the post_date+ID will always be unique.
Now, I understand why the 'distinct' is used, as there are JOINs involved in the expanded query that could result in multiple rows being returned for each wp_post.ID, ie:
ID post_date
1 2016-09-01
2 2016-08-01
3 2016-07-01
4 2016-06-01
1 2016-09-01
4 2016-06-01
, but if that weren't the case, then the unpredictable results could come from a case like:
ID post_date
1 2016-09-01
2 2016-08-01
3 2016-07-01
4 2016-06-01
1 2016-05-01
4 2016-04-01
For the above query, which 1,4 date is to be used? If the first, then the order would be 1,2,3,4 ... if the second, the order would be 2,3,1,4 ...
If the query was changed to:
{{{
SELECT SQL_CALC_FOUND_ROWS distinct wp_posts.ID, wp_posts.post_date
}}}
... then the query becomes SQL compliant, and it is no longer possible to get unpredictable results, since in both my 'bad example' above, and in the case of the actually database table as defined for WordPress, the result would end up being:
1,2,3,4
I attached a patch that fixes the query in such a way that makes the query SQL Compliant and removes the potential unpredicatability of the results that right now is protected against by ensuring that the field itself is always UNIQUE in the first place ...
",yscrappy
Tickets Awaiting Review,49963,Security of failed update/rollback,,Upgrade/Install,5.5,normal,major,Awaiting Review,enhancement,new,dev-feedback,2020-04-20T20:31:29Z,2020-04-20T20:44:53Z,"As discussed on the [[https://make.wordpress.org/core/2020/04/16/devchat-meeting-summary-april-15-2020/|previous devchat]] in case of failed update/rollback there are email notifications.
Idea is good: any errors related to Core, Plugin or Theme update should be reported to an email of admin as soon as possible.
But in the real world there are too few properly configured mail servers in wordpress and servers at all. Actually there is no good documentation how to set up email: https://wordpress.org/search/mail
In addition there are a lot of ''lazy'' administrators with email addresses like admin@example.com or something similar.
Thus so many **really important mails** about failed update/rollback will be send to `/dev/null`. It is security issue because website will be inconsistent state indefinite amount of time (for example login plugin not updated and not rollbacked).
1. Do you know how many wordpress installs have properly configured mails?
2. How to motivate admins to use real email addresses?
3. Maybe there is sense to prepare good documentation about mailing in wordpress?
4. Should auto-updates plugin works at all wothout properly configured emergency notifications?
* Original Github Issue: https://github.com/WordPress/wp-autoupdates/issues/83
* Feature Plugin: WP Auto-updates https://make.wordpress.org/core/2020/02/26/feature-plugin-wp-auto-updates/",mahnunchik
Candidates for Closure,57280,Security automatic updates for plugins and themes,,Upgrade/Install,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-12-06T02:50:08Z,2022-12-06T17:04:31Z,"The option to enable automatic security updates for plugins and themes would allow users to secure their websites without worrying too much about significant/major breaking features.
This enhancement would allow more granular control of auto-updates without forcing users to update to major releases.
I propose new toggles in the WordPress Updates page under the Plugins and Themes section at wp-admin/update-core.php:
This site's plugins are automatically kept up to date with each new version
**Switch to automatic updates for maintenance and security releases only.
**
This site's plugins are automatically kept up to date with maintenance and security releases.
**Enable automatic updates for all new versions.
**
The same logic would be applied to themes.
Defining what kind of updates apply to security would be challenging, so I propose starting with popular or problematic plugins.",JosVelasco
Tickets Awaiting Review,21981,Securing the uploads directory,,Upload,,normal,normal,Awaiting Review,enhancement,reopened,,2012-09-24T04:35:11Z,2023-06-25T07:15:26Z,"Look at implementing something similar to an .htaccess file in the uploads directory with:
{{{php_flag engine off}}}
This may not work in every server scenario, but let's open the conversation, and some scenarios is probably better than none anyway.",japh
Tickets with Patches,39309,Secure WordPress Against Infrastructure Attacks,,Upgrade/Install,4.8,normal,critical,Future Release,task (blessed),assigned,has-patch,2016-12-16T17:50:14Z,2022-05-26T22:30:44Z,"(Similar to #25052 but much more focused on the implementation details)
== Background ==
Recommended reading:
1. http://seclists.org/oss-sec/2016/q4/478
2. https://www.wordfence.com/blog/2016/11/hacking-27-web-via-wordpress-auto-update/
3. https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-php-developers
Currently, if an attacker can compromise api.wordpress.org, they can issue a fake WordPress update and gain access to every WordPress install on the Internet that has automatic updating enabled. We're two minutes to midnight here (we were one minute to midnight before the Wordfence team found that vulnerability).
Given WordPress's ubiquity, an attacker with control of 27% of websites on the Internet is a grave threat to the security of the rest of the Internet. I don't know how much infrastructure could withstand that level of DDoS. (Maybe Google?)
The solution is to make the automatic update mechanism secure **even if the update server is totally owned up**. As published in the third link, the core elements of a totally secure automatic update system are:
1. Offline Cryptographic Signatures
2. Reproducible Builds
3. Decentralized Authenticity / Userbase Consistency Verification
4. Transport-Layer Security
5. Mirrors and Other Availability Concerns
6. Separation of Privileges
However, I'm mostly interested in 1, 2, and 3. I believe 4 is already implemented (if not, this just became a lot scarier).
== Proposed Solution ==
We're going to have to roll this out in phases, rather than all at once.
1. Offline Cryptographic Signatures
1. Decide on a digital signature algorithm and/or cryptography library to use.
2. Generate a keypair for the release managers to use.
3. Pin the public key in a major release (e.g. 4.8 or 4.9).
4. Add signature verification to the update process, but for the first release or two, **don't enforce it**. Just collect data until we're sure it works for everyone.
5. Enforce digital signatures. Then this is satisfied.
2. Reproducible Builds.
1. The update file should be easily reproduced by any end user.
2. The update file and update served by api.wordpress.org should be easily verifiable.
3. We wrote Pharaoh for auditing PHP Archives; something similar may be useful for WP updates: https://paragonie.com/project/pharaoh
3. Decentralized Authenticity / Userbase Consistency Verification
* See below.
4. Make plugin/theme updates secure.
Once core updates are secure, the next step is to allow plugin/theme developers to upload their own public keys which can be used to sign their own extensions.
If you want a reference implementation, we already have a working secure automatic update system built into CMS Airship (which is GPL 3):
* https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cryptography-powering-cms-airship
* https://github.com/paragonie/airship/blob/master/src/Engine/Continuum.php
* https://github.com/paragonie/airship/blob/master/src/Engine/Keyggdrasil.php
=== Decentralized Authenticity ===
In CMS Airship, we're totally decentralized: Every Airship maintains its own record of every update file or new/revoked public key since its inception. (This is because CMS Airship aims for maximum security.)
For WordPress, I'm recommending a federated model instead, but the concepts are mostly the same:
1. Notaries (WordPress blogs or other services that opt in to hosting/verifying the updates) will mirror a Merkle tree which contains (with timestamps and signatures):
* Any new public keys
* Any public key revocations
* Cryptographic hashes of any core/extension updates
2. WordPress blogs will have a pool of notaries they trust explicitly. (This can be provided by your hosting provider, who runs the single source of truth for all their clients, so long as they themselves practice due diligence.)
3. When an update is received from the server, after checking the signature against the WP core's public key, they will poll at least one trusted Notary (send a challenge nonce, current timestamp, a checksum of the update file, and any other useful identifying metadata e.g. ""wp-core version 4.9.2""). The Notary will verify that the update exists and matches the checksum on file, and respond with a signed message containing:
* The challenge nonce
* The response timestamp
* Whether or not the update was valid
This will be useful in the event that the WP.org's signing key is ever compromised by a sophisticated adversary: If they attempt to issue a silent, targeted update to a machine of interest, they cannot do so reliably: To pull off their attack, they have to allow the Merkle tree (that is mirrored by every Notary) to record/broadcast evidence of their attack in order for it to succeed. So while targeted attacks may still be theoretically possible, it will no longer be possible to do them silently.
In addition to a security layer, it's a deterrent against the most sophisticated threats.
=== Securing Plugins and Themes ===
This will probably be the last piece tackled. Basically: Offer the same signing capabilities to theme/plugin developers that will already be in the hands of the core team.
This can be done piecemeal (i.e. optional field on WP.org that allows them to upload their public key, generated by some tooling we provide developers). We should incentivize packages that provide their own signature by, for instance, placing them higher in the listings and/or giving them an attractive and desirable UI element that says ""we're secure"".
If we one day reach near-100% coverage of the WP ecosystem with digital signing, we can discuss making it mandatory.
== Implementation Recommendations ==
Okay, this section is going to be technical so feel free to skip most of this if you're not into cryptography.
TL;DR - We need a libsodium polyfill, which Paragon Initiative Enterprises is willing to write for free if (and only if) the cost of an independent third party audit is covered by the community and/or the community's corporate sponsors.
=== Digital signatures ===
PHP, out of the box, only supports RSA signatures (via the OpenSSL extension), but doesn't support RSASSA-PSS+MGF1SHA256. PKCS1v1.5 padding is unacceptable.
It may be tempting to move towards something like ECDSA, but a mix of security concerns (the Sony ECDSA k-value reuse incident, invalid curve attacks against Weierstrass curves) makes us wary even of RFC 6979 (deterministic ECDSA).
We propose a standardized digital signature algorithm based on twisted Edwards curves. Namely, **Ed25519** or **Ed448** (EdDSA over the RFC 7748 curves).
=== Merkle Trees ===
The TrimmedMerkleTree in Halite is probably the best starting point: https://github.com/paragonie/halite/blob/master/src/Structure/TrimmedMerkleTree.php
Halite's Merkle tree implementations are based on the BLAKE2b hash function (a SHA3 finalist with great performance in software based on the ChaCha20 round function).
=== Checksums ===
One of the following algorithms should be used where ever a checksum is required:
* BLAKE2b
* SHA-512/256
* SHA-512/224
* SHA-384
At no point should MD5 or SHA1 be considered. SHA-256 and SHA-512 are vulnerable to length-extension attacks and are not recommended.
== Action Plan ==
First, if this plan is agreeable by WordPress's security team, we'll get to work on a libsodium polyfill that works as far back as PHP 5.2.4 (in the spirit of WordPress's backwards compatibility tradition).
Once that's finished, independently audited by cryptography experts, and released to the public, we'll work on getting the core cryptographically signed. This will require some additional tooling; the release managers will need to run a command to produce a valid signature of the update file before releasing it.
After core updates are signed and signatures are being verified, we'll build the decentralized verification layer.
Then, we can move forward with making everyone's plugins and extensions securely delivered.
---
Edit Jan 3, 2019: As noted in [comment:50 comment #50], adding the sodium_compat library has been split out to a separate ticket, #45806, as it can serve a wider purpose than protecting against infrastructure attacks. -- @peterwilsoncc",paragoninitiativeenterprises
Candidates for Closure,55149,Secondary sites disappear from My Sites menu,,Toolbar,5.9,normal,major,Awaiting Review,defect (bug),new,reporter-feedback,2022-02-11T18:41:22Z,2023-04-25T20:21:22Z,"If you create a new multisite, only **Network Admin** and the **Main Site** appear in the **My Sites** dropdown, the secondary sites do not appear. To change to another Site you need to go to **My Sites > Network Admin > Dashboard** and then select **All Sites** in the **Sites** menu.
In old installations it works correctly, it only happens in new installations.
",jose64
Tickets Needing Feedback,18513,Searching with explicit post types unsets page post type,,Query,3.2.1,normal,normal,,defect (bug),new,needs-unit-tests,2011-08-24T22:13:08Z,2022-02-12T20:43:32Z,"Tested on WP 3.2.1, Twenty Eleven with no plugins, multisite.
If I explicitly limit a search query via a GET request using an array of post_type values, the post_type for page is automatically excluded.
To reproduce:
* Do a search on a WP install (perhaps through a modified search form), such that the URL is like:
http://example.com/?post_type[]=post&post_type[]=page&post_type[]=attachment&s=Test
or
http://example.com/?post_type[]=post&post_type[]=page&post_type[]=book&s=Test
That's searching for ""Test"" on post, page and attachment/book post types.
* Adding the following to a theme's functions.php:
{{{
add_filter( 'pre_get_posts', 'wpcpt_search' );
/**
*
* @param array $query
*/
function wpcpt_search( $query ) {
if ( ! $query->is_search )
return $query;
print_r( $query->query_vars );
return $query;
}
}}}
That spits out (and seemingly confirmed via the values shown in the Debug Bar plugin) the following at the beginning:
{{{
Array ( [s] => Test [post_type] => Array ( [0] => post [2] => attachment )
}}}
and only returns results for posts and attachments (or books). The fact that key 1 is missing makes me think that page was in the array at some point, but it's been unset, but I can't see where, or why, this might be done.
(When no post_type is set, giving a post_type of 'any', which in turn gives all of the non-excluded_from_search post types, then page is one of the array values, and the search results correctly include pages.)
",GaryJ
Tickets Awaiting Review,43626,Searching for tags using slugs work for English but does not work for Arabic,,Taxonomy,4.9.4,normal,normal,Awaiting Review,defect (bug),new,,2018-03-24T07:37:41Z,2018-03-26T06:55:22Z,"If i have created a tag with name: tag1 and slug: slug1 then searching for slug1 will return tag1 in the results, if i do the same thing but with Arabic then tag1 will not be returned.
Which means that searching for tags using slugs work for English but not for Arabic - probably for all other languages that don't use English characters
Here is how to reproduce the bug
1) create a new tag: name: tag1, slug: slug1
2) create a new tag: name: تاج1, slug:سلج1
3) search for tags using ""slug1"" phrase => tag1 will be in the results
4)search for tags using ""سلج1"" phrase => تاج1 will '''not''' be in the results
I have done the previous steps in a fresh installation of WordPress.
",ehabsan
Tickets Awaiting Review,41351,Searching for a category returns nothing if category is empty,,Menus,,normal,normal,Awaiting Review,defect (bug),new,,2017-07-17T21:53:56Z,2019-11-22T21:53:08Z,"Hi,
In the navigation menu creation page, when you are trying to add a category to the menu, if the category is empty, it won't show up in the search results. However, if the category itself is empty but has a child that is not empty, it will still be shown.
I have a blog with over 500 categories, and I'm trying to add some of them to the menu but they have no posts yet. Navigating through category list is going to take time, and is also frustrating.
Now I've tracked down the issue to `/wp-admin/includes/nav-menu.php`, ( starting at line 588 ) but can't find a filter or hook to do so.
This line (109) seems to be responsible for doing the search:
{{{
$terms = get_terms( $matches[2], array(
'name__like' => $query,
'number' => 10,
));
}}}
According to the documentations, this function accepts an argument for showing empty terms 'hide_empty' => false, but I can't see such option in this part of core's code. I've added this option to the core (temporarily) to see if it solves the issue, and it does.
The other `get_term()` functions withing this template file mostly use `'hide_empty' => false` so I'm not sure either this one was overlooked or not, I tagged this as a bug though.",jackjohansson
Candidates for Closure,57626,"Searches to add a link in post-edit, to be sortable/filterable to better find tags",,Editor,,normal,trivial,Awaiting Review,enhancement,new,reporter-feedback,2023-02-03T14:30:14Z,2023-03-20T13:51:02Z,"Currently when adding a link to a post, I can search for a term and get back a mix of posts, pages and tags. This is the intended behaviour.
However, if the search term I am using is broad (e.g. 'Movies') and there are more than 20 posts on my site featuring the word Movies (this is often the case for a broad term), then WordPress will prioritise returning me 20 search results that are all posts, and will not return the Movies tag.
This is a general sorting issue, the search function prioritises posts over tags.
I'd like see a change where an exact tag match would always appears as the top result.
If not, then an option to filter the search, perhaps with checkboxes to show Posts/Pages/Tags etc.",joshduffetywong
Tickets Needing Feedback,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
Tickets Awaiting Review,50467,Search results not displaying all entries in Admin > Posts in certain conditions,,"Posts, Post Types",5.4.2,normal,minor,Awaiting Review,defect (bug),new,,2020-06-24T20:54:20Z,2021-08-23T20:41:55Z,"**''Limitations of my bug report''**
I observed that bug in a live wordpress site, not even mine, so, my apologies, I cannot experiment with it as I would have liked otherwise. No deactivating plugins, no switching to another theme.
Thus: I report the issue, explain it the best I can, but I'm leaving it at that.
Either (a) it's affecting all wordpress installs, I'm glad I could help by reporting it, or (b) for some reason, it's only the blog on which I've seen it that has it, and then I'm perfectly fine with it, it's just that, me, I cannot tell at all on my side.
**''Context of the bug report''**
A wordpress blog, latest stable, on which the admins are preparing a number of posts that will be posted while they're away on holidays, with a schedule of 2 posts a day.
Those blog posts are written in advance, their title starts with ""READY TO POST ++"" or ""READY TO POST --"" (that part will be removed in the final scheduling phase, when dates are assigned).
Those blog posts are saved as Drafts for now.
**''Nature of the bug:''**
In blog administration > Posts > All Posts, I was reported there was an issue, and indeed,
- if I type ""READY TO POST"" in the upper-right search box, run the search,
- it returns the text ""12 items"", and that's the right number of posts that are currently called ""READY TO POST"", currently in Draft state...
- however in the listing of posts below, only 7 posts are listed, and there is no ""next page"" navigation to browse to a second page of posts listing
Here's a screenshot: https://imgur.com/a/qG4Awo8
I think I may have found either the origin, or a factor in the problem:
In Screen options (horizontal menu, in the admin, in the same Posts page), there is an entry called ""Number of items per page:"", with the value ""20"".
Screenshot: https://imgur.com/a/e3oDjBq
And that's wrong, it says ""20"", but there are only 7 posts listed in Admin > Posts > All Posts, be it the default listing, or a search.
I don't know if there's a relation, but the blog is configured to display 7 posts on the home page.
I tested something, in Admin > Posts > All Posts, I replaced that ""20"" by other numbers.
- If those numbers are above the number of search results, the current bug remains, telling there are 12 results, but only showing 7.
- If I replace ""Number of items per page"" by 11 or a smaller number, this time it still lists 7 posts only, but I get the missing pagination buttons, screenshot: https://imgur.com/a/fLBv7PL
Summary of what I tried: with a search, what I write on ""Number of items per page"" actually does NOT affect the number of displayed results, it's always 7, but depending on whether I choose a number lower, or above or equal to the expected number of results, I have, or haven't, the pagination buttons that allow to view the rest of the results posts.
*
I could partially reproduce the issue with another query.
Simply searching ""ready to"" returns 168 results among the posts.
- If I configure Number of items per page to 170, I get no navigation buttons: https://imgur.com/a/DKC70ZZ
- If I configure Number of items per page to 167, I get navigation buttons: https://imgur.com/a/HF3cLjN
... oh, damnit, I just realized. It's only a second page of results. No more. Even going into the URL of the page, trying replacing &paged=2 with something like &paged=3, did nothing, still listing the contents of &paged=2.
The only workaround is to choose to display 7 posts per page, screenshot: https://imgur.com/a/r2qwRqu
*
I forgot to list the plugins on the blog, namely: Add Browser Search, Akismet anti-spam, Antispam bee, Classic editor, Custom Smilies, Dave's wordpress live search, disable emojis (gdpr friendly), Display php version, Enhanced text widget, Inline spoilers, ManageWP- Worker, Nextscripts: social networks auto-poster, Php Code widget, Post-plugin library, Random Posts, Scheduled Post Trigger, Seemore, Shortcoder, Term Management Tools, ThreeWP Activity Monitor, User lLocker, WordPress editorial calender, Wp Editor (that one, with a community php fix to make it php7 compatible), Wp super cache, Wp-dbmanager, WP-pagenavi, Wp-polls, Wp-postratings, Wp-sweep, Wpdiscuz, WPS Hide Login, Yoast SEO, ZigWidgetClass
*
I checked the site's apache error log (I'm the host, it's on my dedi, and I help when there are issues), and I can tell there are zero events appearing in the error log while searching in the list of posts, or changing the number of display results.
*
I also helped last year, same period of time, and there wasn't that bug at that time.
*
Well, I don't see what else I could do here, hopefully it's only that blog that has that problem.
Apologies, also, that it's not a standard bug report, I'm not used to doing it at all. Good evening!",Sabinooo
Tickets Awaiting Review,39977,"Search results for custom post type = ""ANY""",,General,4.7.2,normal,normal,Awaiting Review,defect (bug),new,,2017-02-27T20:58:56Z,2019-03-15T13:46:54Z,"There is a bug for search results query for post type ""ANY"", any returns only page and post. If we use:
{{{#!php
$s,
'numberposts' => -1,
'post_type' => array('post','page','gallery')
);
$the_query = new WP_Query( $args );
}}}
Then works, also pre_get_post not working.
Debug info from QM:
{{{
order DESC
post_type any
posts_per_page 10
s Janis gallery
search_orderby_title
Array
(
[0] => wp_8b3200f070_posts.post_title LIKE '%Janis%'
[1] => wp_8b3200f070_posts.post_title LIKE '%gallery%'
)
search_terms
Array
(
[0] => Janis
[1] => gallery
)
}}}
If we use standart:
{{{
}}}
Then custom post types is not showed on search results. ",foxsk8
Tickets with Patches,27623,"Search results for "" "" text appearing on every plugin activation or deactivation",,Plugins,3.8.1,normal,normal,,defect (bug),reopened,has-patch,2014-04-01T15:01:03Z,2019-06-04T20:46:23Z,"When I activate or deactivate a plugin via the plugins page in WP admin, I get the following text appear at the top of the page next to the Plugins heading:
{{{Search results for “ ”}}}
The URL looks like:
{{{wp-admin/plugins.php?activate=true&plugin_status=search&paged=1&s=+}}}
As you can see from the URL, {{{$s}}} or {{{$_REQUEST['s']}}} is set which results in the following line (around 414) in wp-admin/plugins.php executing:
{{{printf( '' . __('Search results for “%s”') . ' ', esc_html( $s ) );}}}
Why is {{{$_REQUEST['s']}}} being set in this situation? Does it need to be?",henry.wright
Tickets Awaiting Review,50873,Search query parameter causes 404 on pagename match rules,,Query,5.4.2,normal,normal,Awaiting Review,defect (bug),new,has-patch,2020-08-07T14:55:32Z,2024-02-15T06:36:19Z,"With permalinks turned on, visit a post or page. Then append `?s=test` to the url. It should look like this: `https://example.com/post-slug/?s=test`. You will probably hit the 404 page.
The expected behavior is to get to the post or page you hit, ie `https://example.com/post-slug/`
Instead, you hit a 404 page.
This is due to both the search query and post slug query getting combined instead of one taking priority over the other.
The resulting query is a combination of a search query and post slug query which results in no posts being found, unless the search term is also in the post slug. See below:
{{{
SELECT wp_posts.*
FROM wp_posts
WHERE 1=1
AND wp_posts.post_name = 'post-slug'
AND (((wp_posts.post_title LIKE '%test%')
OR (wp_posts.post_excerpt LIKE '%test%')
OR (wp_posts.post_content LIKE '%test%')))
AND wp_posts.post_type = 'post'
ORDER BY wp_posts.post_title LIKE '%test%' DESC, wp_posts.post_date DESC
}}}
This is using `https://example.com/post-slug/?s=test` as the example url.
I would expect the search query string to be ignore unless the visitor is on the search page (front/home page by default).",MikeNGarrett
Tickets with Patches,50190,Search query doesnot know if the theme is already updated.,,Themes,,normal,normal,Future Release,defect (bug),reopened,has-patch,2020-05-17T07:06:42Z,2020-07-09T09:01:56Z,"If the theme is updated and the search box is used, there comes the 'New version available. Update Now.' again for that theme. ",sanzeeb3
Unpatched Enhancements,44842,Search post box in mobile,,"Posts, Post Types",,normal,normal,Future Release,enhancement,new,,2018-08-25T06:15:19Z,2022-05-18T16:41:22Z,"In mobile view when I go to posts screen, I found that search box is not on the top so I dragged all the way down and found that search box is there which is bit odd because why someone will go all the way down looking at posts to search any post.
Please see: https://prnt.sc/kmo3jn
We can make it like themes screen https://prnt.sc/kmo3k4 by just leaving the search box with a placeholder to search posts and since just typing and entering the text in the box works so they will be able to search the post
",prashantvatsh
Tickets Awaiting Review,39443,Search Page Template the_category() bug,,"Posts, Post Types",4.7,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-01-03T07:38:03Z,2020-01-04T03:30:46Z,"Suppose If I've selected three categories following a structure HR -> Reports -> Daily Reports.
Single.php shows the structure in the right way but when I use the same the_category () function inside Search template then it shows the different result. Rather than showing it in the default structure, it shows it like Daily Reports -> HR -> Reports. In search template the structure changes to order by name. The_category working perfectly in other pages.",cybentizen
Unpatched Enhancements,43464,Search Options in Customizer,,Customize,,normal,normal,Future Release,enhancement,new,,2018-03-04T07:05:30Z,2021-05-30T17:34:24Z,"If a theme has more than few settings, finding the setting gets frustrating at times. A search functionality in the customizer will be helpful.
Here is a plugin that we have developed as a POC:
https://wordpress.org/plugins/customizer-search/
But I believe, it will benefit if it is added in the core.
",brainstormforce
Unpatched Bugs,36966,Search is not working with soft hyphen symbols,,Query,4.5.2,normal,normal,,defect (bug),new,,2016-05-28T21:36:29Z,2019-06-04T20:59:30Z,"Site search doesn't work if a word contains soft hyphen symbols.
When a word is pretty long and it should fit within a limited space, the best solution seems to be to stuff it with soft hyphens (), so there will be no hanging lines.
It looks like this: Pseudopseudohypoparathyroidism
But in this case the word can't be found.",mvasin
Tickets with Patches,34886,Search Form should not submit empty strings,,Themes,,normal,normal,Future Release,enhancement,new,has-patch,2015-12-06T21:23:46Z,2020-10-28T16:17:53Z,"Depending on the styling it is not always obvious to the user that there is a text box to click in before hitting the search button. On WordPress.com we are seeing about 3.5% of all site search queries are an empty string.
For the end user this costs them the extra page load, and the confusion of having the page loaded. By selecting the field instead we avoid the user changing pages, and needing to re-find the search box.
Similar problems are very prevalent in many themes. The most popular single word (that is not a stop word) in site search for WordPress.com is ""search"" due to the default value text being searched in themes. For most of the Twenty themes this problem is solved by not displaying the search button at all (display: none;). Fixing this in core should help point the way for fixing it in themes.
Twenty Ten does not have the search button hidden and so is a good theme for reproducing the problem.
",gibrown
Tickets Awaiting Review,33141,Search form clear button is clipped in Safari (OS X),,General,,low,minor,Awaiting Review,defect (bug),new,has-patch,2015-07-27T15:06:53Z,2017-05-23T17:20:12Z,"Safari's search boxes have an ""X"" to clear the search terms. It is getting clipped. OS X.
The reason for this appears to be the padding on the search box, and that we're doing this:
{{{
input[type=""search""] {
-webkit-appearance: textfield;
}
}}}
which we HAVE to do in Safari in order to control certain aspects of the display.
[[Image(https://cldup.com/J90Zt5PGQW-3000x3000.png)]]
There is a pseudo-selector we might be able to use to fix this:
`::-webkit-search-cancel-button {}`",markjaquith
Tickets Awaiting Review,41564,Search for hyphenated post templates for post types with underscores,,"Posts, Post Types",,normal,normal,Awaiting Review,feature request,new,dev-feedback,2017-08-04T17:16:29Z,2017-08-13T15:54:10Z,"Custom post type names adhere to the rules within sanitize_key() (lowercase alphanumeric characters, dashes, and underscores).
This means registering a post type `some_post_type` is perfectly fine. The archive and single templates would be be `archive-some_post_type.php` and `single-some_post_type.php`.
These file names do not adhere to the core standard for file names.
Files should be named descriptively using lowercase letters. Hyphens should separate words.
Searching for `archive-some-post-type.php` in addition to `archive_some_post_type.php` would allow this standard to be followed better.",desrosj
Candidates for Closure,31728,Search bug (Cyrillic),,Permalinks,4.1.1,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2015-03-22T15:03:14Z,2020-07-20T12:52:35Z,"There is a bug, when I search something in my WordPress site.
The correct search link should be: {{{http://site.com/search/word}}}.
When I type something in English, the link is correct: {{{http://site.com/search/word}}}.
But when I type something in Bulgarian language (Cyrillic), the link is different: {{{http://site.com/?s=абвгд}}}.
The structure of my WordPress permalinks is: {{{http://site.com/%post_id%}}}.",kazumy
Tickets Awaiting Review,48784,Search box in Select / Upload image pop-up not working with cropped images,,Media,5.3,normal,normal,Awaiting Review,defect (bug),reopened,,2019-11-24T20:52:28Z,2020-03-28T20:10:45Z,"Hi, it seems that the search field in the pop-up of selecting or uploading images can not find the images which have been cropped before. For example, if I go to Appearance / Customize and want to change the Logo image, and I am asked to cropped the image, that image won't show in the search field. It will show the non cropped image, but not the cropped one.
Thank you!
In the attached image you can see how the search field can do find the filename ""Foto-de-Javier-1.jpg"" using just the letters ""jav"". But there is another image in the Media which name is ""cropped-Foto-de-Javier-1.jpg"" and this one does not appear.",javierr
Unpatched Bugs,39793,Scrolling up in the sticky post text editor does not scroll the page up to top,,Editor,,normal,normal,Future Release,defect (bug),new,,2017-02-06T13:03:53Z,2019-06-05T06:52:24Z,"In the sticky post editor, if I use arrow keys to navigate in the text mode tab (textarea#content), the page does not scroll up to the very top of the page, leaving part of the text hidden. I have to use mouse to again reveal the text. In the TinyMCE mode the scrolling works perfectly.
I attached a screenshot where I created lines of text to get the page scroll. At the bottom of the page, cursor can be seen all the time. Then, when I go and use arrow keys to scroll to the first line of the text, it only scrolls almost to the top, leaving about 6.5 lines above the scroll.
Additionally, using Ctrl+Home or Ctrl+End (on Windows) to navigate to the top or bottom of the textarea does not scroll the page.",elmo5
Tickets Awaiting Review,53046,Scrollbars Broken in latest visual editor,,Editor,5.7.1,normal,minor,Awaiting Review,defect (bug),new,,2021-04-15T23:34:48Z,2021-05-18T06:14:18Z,"Not only is the mouse disabled from scrolling using its scroll wheels, but the scroll bars on the side of the screen also are disabled except for the thumbs. You can drag the thumbs to scroll the content, but you can't click the arrows or scroll with the mouse. Rather clicking the arrows shows the clicked state of the arrow icons, but nothing scrolls.
Also, from within a block, a new set of full-screen scrollbars appears inside the outermost scrollbars (which make no sense and do nothing--mostly because the box is 1 unit high and doesn't need to stroll)",WhirledPress
Unpatched Enhancements,42913,Scroll widgets and widget containers independently in admin ui,,Widgets,5.1,normal,normal,Future Release,enhancement,new,,2017-12-15T18:31:30Z,2018-05-03T19:50:32Z,"A ""regular"" WordPress installation with a few plugins providing widgets can easily result in a situation where the height of the ""available widgets"" div on the left can be significantly larger than the height of the ""available widget containers"" div on the right, as a result of which one may need to scroll down significantly to reach the desired widget, then scroll back up _while dragging_ to place the widget in the desired container.
If the div on the right were to be configured with {{height: 1vh; overflow-y: scroll}} and then turned into fixed (?) position div, it would remain on-screen while the user scrolled through the list of available widgets, such that installing a new widget would only require scrolling to find the widget in question, and at no point would it be necessary to drag and scroll simultaneously (which, while frustrating, is easy enough on a desktop... but with a touchpad it becomes quite the challenge).
On further reflection, it might actually be easier and less hacky to assign both the left and right divs a height of 1vh (and perhaps throw in a {{min-height}}) and {{overflow-y: scroll}}, then there's no need for anything but the default positioning. Both containers would scroll independently, and no need to drag and scroll.
Attaching a video of the current experience.",ComputerGuru
Tickets Awaiting Review,51496,Scroll to the first plugin which is going to be updated after clicking on 'Apply' while Bulk actions 'Update' is selected to show that process is in a progress.,audrasjb,Upgrade/Install,5.5,normal,normal,Awaiting Review,enhancement,assigned,,2020-10-11T18:54:23Z,2023-06-08T08:35:51Z,"If you are clicking on 'Apply' while Bulk actions 'Update' it looks like nothing is happening and it's why you want to click several times in a row.
This functionality can be combined with an improvement according to #40966 ticket. If this multiple update issue is hard to fix, possibly to add a scroll to the first plugin which is going to be updated can be easier.",oglekler
Tickets Awaiting Review,40737,Script tags inside unclosed HTML comment in value passed to WP_Script->localize() breaks page,,Script Loader,,normal,normal,Awaiting Review,defect (bug),new,has-patch,2017-05-11T19:26:30Z,2017-06-01T18:45:45Z,"Hi. Thanks for your time. I encountered an edge case with the WP_Script->localize() method that can cause malformed html and cause javascript on the page to break.
Our site has a custom field for adding pixel tracking code html snippets. On the post edit admin page, the values from the custom fields are run through the localize method by the Wordpress-SEO plugin which adds their values to the wpseoReplaceVarsL10n var.
One of our users pasted code into this field like the following:
{{{
}}}
This gets serialized to JSON by WP_Script->localize and ends up being output like this. I simplified the structure a bit for the example.
{{{
}}}
This catches some interesting edge behavior in the browser. Notice the code comment is not actually closed correctly because it has {{{--!>}}} instead of {{{-->}}}. When testing that in html, I noticed that browsers seem to treat it as closing the comment and it doesn't break the page. It must be a common enough mistake.
If the field value is changed it have the proper {{{-->}}}, there are no issues. It also requires the {{{ tag when HTML tags are present within JS strings.,,General,,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2021-09-24T13:42:03Z,2021-09-26T01:26:06Z,"We are using a custom JS file that is reaching out to a web service, building a string from the data, and setting it as the innerHTML to a DOM Element already on the page. For some reason, HTML tags in this string were causing our script to get cut short, and whatever remained would instead by interpreted as HTML. A JavaScript snippet such as the following:
{{{
myElement.innerHTML = ‘’;
}}}
would cause a tag to be inserted between the
and