__group__ ticket summary owner _component _version priority severity milestone type _status workflow _created modified _description _reporter Candidates for Closure 54994 Action Hook admin_enqueue_scripts and wp_enqueue_scripts Plugins 5.9 normal normal Awaiting Review defect (bug) new reporter-feedback 2022-01-30T08:58:51Z 2022-01-31T01:12:29Z "Hey, I'm a developer, I wanted to know if it's a bug, or am I doing it wrong way? When using admin_enqueue_scripts (both methods static in the same class, I can not use it this way [ ( new self() ), 'admin_enqueue_scripts' ], It will throw errors). {{{#!php 'Resources', 'default' => 10, 'option' => 'resources_per_page' )); } }}} However, the hooknames do match when using `add_menu_page()` and `add_submenu_page()` with a callback slugname. This code works (notice only the first line has been changed to use callback slugs instead of filename slugs): {{{ $hookname = add_submenu_page('dashboard', 'Resources', 'Resources', 'edit_pages', 'myresources', 'myresources'); add_action($hookname, 'add_resources_options' ); function add_resources_options() { add_screen_option('per_page', array( 'label' => 'Resources', 'default' => 10, 'option' => 'resources_per_page' )); } }}} The solution is either: * Modify `function get_plugin_page_hookname() …` to return a hookname that is caught by `do_action( 'load-' . $plugin_page );`. * Or modify `do_action( 'load-' . $plugin_page );` to use the hookname currently returned by `get_plugin_page_hookname()`. " quinncom Candidates for Closure 43453 heartbeat_received filter requires data in order to execute Plugins 3.6 normal normal Awaiting Review defect (bug) new reporter-feedback 2018-03-01T15:38:38Z 2022-02-26T22:34:38Z "With regards to the heartbeat api, the plugin developer handbook states: Not every feature will need all three of these steps. For example, if you don’t need to send any data to the server, you can use just the latter two steps. But this does not seem to be the case given this line of of [https://core.trac.wordpress.org/browser/tags/4.9/src/wp-admin/includes/ajax-actions.php#L2808 wp_ajax_heartbeat]. This makes it less useful if you just want to include some new data on an interval. It requires an approach like: {{{ #!javascript $( document ).on('heartbeat-send', (e, data) => { data.wouldLikeFilterToTrigger = true; }); $(document).on('heartbeat-tick', (e, data) => { // do something with data generated by filter console.log(data); }); }}} If you omit the send event, the filter on the server never runs. It seems like this constraint should be lifted, or at the very least the documentation should be updated." brianscaturro Candidates for Closure 57792 no way to find the plugin Plugins 6.1.1 normal major Awaiting Review defect (bug) new reporter-feedback 2023-02-23T06:44:18Z 2023-05-10T17:10:55Z In the add new plugins section there is a problem, which can be seen in the screenshot. purisov Candidates for Closure 58933 plugin-install.php search works incorrect Plugins 6.2.2 normal normal Awaiting Review defect (bug) new reporter-feedback 2023-07-29T11:41:02Z 2023-08-08T16:43:13Z "i got 29 pages as result of search but after i go to last page more results coming also search very weak by default many irrelevant results coming after search with 2 keywords " AlexeyVertinsky Candidates for Closure 43949 Need filter in get_metadata Plugins normal normal Awaiting Review enhancement new reporter-feedback 2018-05-03T13:19:13Z 2018-05-23T13:55:22Z "When accessing get_post_meta('ID_HERE') Need to filter the output array. Existing get_{$meta_type}_metadata filter works before fetching data. The filter required before returning or Processing value of $meta_cache" fitehal Candidates for Closure 41910 Update plugin/theme maintenance message Plugins normal normal Awaiting Review enhancement new reporter-feedback 2017-09-18T13:41:50Z 2019-06-20T21:06:25Z "Hey The message that shows up when updating plugins or themes should not remove the visible site. Instead it should keep the old plugin/theme until it has finished updating and then smoothly change over to the new without disrupting the frontend of the site. On fatal error it should automatically revert to the old and just give a message in the backend that it could not update to the new plugin/theme because of whatever reason. Then a message saying let the author of the theme/plugin know about the error. " paaljoachim Candidates for Closure 55089 ajax `wp_ajax_update_plugin` show download failed when contain another update (eg: translations) with same process fail. Plugins 5.9 normal minor Awaiting Review enhancement assigned reporter-feedback 2022-02-05T15:02:59Z 2022-02-05T15:02:59Z "I found that {{{wp_ajax_update_plugin}}} contain invalid response when trying to update plugin via ajax request. This happend when {{{$upgrader->bulk_upgrade( array( $plugin ) );}}} called, and any other update progress run on same time. Eg: there are translations update exists and when contain errors on translations update, the plugin update tell that the plugin fail to download, but the plugins successfully updated. " arrayiterator Candidates for Closure 47492 Multisite Feature for Plugins Plugins normal normal Awaiting Review feature request new reporter-feedback 2019-06-06T13:40:33Z 2020-12-27T18:35:48Z It would be great to see on the dashboard which plugins are running on what sites on a multisite. anonymized_16100632 Tickets Awaiting Review 43489 Strengthen resilience of wp_register_plugin_realpath to support Gutenberg Plugins normal normal Awaiting Review defect (bug) new needs-unit-tests 2018-03-07T18:25:25Z 2020-12-01T05:24:00Z "For many years now I've been working in a Windows development environment with multiple subdirectory installs referencing plugins using symlinks. Every now and then I get problems due to plugin files apparently not being present when they quite clearly are. I have not been able to track it down. I think it's a bug in PHP associated with OpCache. Anyway, the bottom line is that sometimes this problem, or something similar, results in the `$wp_plugin_paths` array containing entries with a null value for `$realdir`. This can lead to the following: `Warning: strpos(): Empty needle in C:\apache\htdocs\hm\wp-includes\plugin.php on line 658.` This message has the uncanny knack of happening at the most inappropriate times. Now, with Gutenberg looming, the problem is further reducing my ability to create content locally; Gutenberg can't handle the unexpected Warnings and Notices from a development server and fails. See https://github.com/WordPress/gutenberg/issues/5439 To reduce the likelihood of the problem I'd like to propose a change to `wp_register_plugin_path()` to cater for a false value being returned from the `realpath()` PHP function. The proposal being that if `$plugin_realpath` does appear to be null, then don't add an entry in `$wp_plugin_paths`. This change will prevent the warning message being issued from plugin_basename()'s test {{{ if ( strpos( $file, $realdir ) === 0 ) { }}} and therefore increases the robustness of the system. Bottom line. - `realpath()` may return false. - This should be catered for. " bobbingwide Tickets Awaiting Review 45374 apply_filters_ref_array() no longer passes arguments by reference Plugins 4.7 normal normal Awaiting Review defect (bug) new needs-unit-tests 2018-11-19T10:58:35Z 2019-01-25T13:54:36Z "It appears that since the introduction of the `WP_Hook` class in WordPress 4.7 (#17817), `apply_filters_ref_array()` no longer passes its arguments by reference. Example: {{{ add_filter( 'posts_clauses', function( $clauses, &$query ) { return $clauses; }, 10, 2 ); }}} The above code will trigger the following PHP warning: {{{ Parameter 2 to {closure}() expected to be a reference, value given }}} cc @jbrinley FYI" johnbillion Tickets Awaiting Review 9968 dynamically adding/removing filters breaks plugins Plugins low normal Awaiting Review defect (bug) reopened needs-unit-tests 2009-05-28T23:43:11Z 2020-03-02T15:43:22Z "noticed this while doing something similar to this: {{{ add_action('foo', 'bar1', 10); add_action('foo', 'bar2', 20); function bar1() { remove_filter('foo', 'bar1', 10); } }}} in the above, bar2() doesn't get called. it is because of the usage of next()/current() to loop through filters. attached patch uses a foreach loop instead, to make it work." Denis-de-Bernardy Tickets Needing Feedback 31136 Allow plugin authors to register an additional 'Uninstall Notification' plugin header and to display back to the user during plugin uninstall flow Plugins normal normal Future Release enhancement new needs-unit-tests 2015-01-26T06:14:19Z 2017-02-05T09:58:14Z "In wp-admin/plugins.php wordpress displays to the user information about the plugins you are attempting to uninstall. Currently it only displays the name of the plugin name ($plugin[ 'Name' ]) and the plugin author ($plugin[ 'AuthorName' ]). In V4.1 this output is generated around lines 289-304. Is it possible to add another field that contains a short piece of information from the plugin author, that can be presented to the user for each plugin? The plugin would need to register this information with wordpress when it was installed or updated. Specifically, I envisage this being used for details that the user might need to follow to preserve any data that they might have before they actually delete the plugin. An example string that I can see being used by a plugin: If you wish to uninstall without losing your data, see the details at http://example.com/plugin-uninstall. Notes: - Such a string should of course be optional to preserve backward compatibility. - Appropriate filtering and length checks should be done on the string to ensure that the uninstall plugin UI isn't easily broken or disturbed. This avoids the plugin author filling the field with a string that stops the user from being unable to uninstall the plugin." cefiar Tickets with Patches 36406 $network_wide is unreliable Plugins 3.0 normal critical Future Release defect (bug) reviewing needs-unit-tests 2016-04-03T09:20:33Z 2019-07-09T10:20:39Z "This issue may be related to ticket #31104 Scenario: In a WordPress network an admin decides a plugin must not be network activated. Only a per site or even a site specific activation shall be allowed. Idea: Conditional check during plugin activation and die with an error message if $network_wide is true. Result: Plugin does not get activated but the custom error message is not displayed Assume the following function run during activation (it is simplified and the real activation sequence does not have echos!) {{{ function test_activation_hook( $network_wide ) { echo '1 | '; // exit( 1 ); if ( is_multisite() ) { echo '2: | '; // exit( 2 ); if ( $network_wide ) { echo '3: | '; // exit( 3 ); } else { echo '4: | '; // exit( 4 ); } } else { echo '5: | '; // exit( 5 ); } echo '6: | '; exit( 6 ); } }}} If you exit after if(is_multisite) the message displayed will be '1 | 2 |' If you exit after if($network_wide) during a networkwide activation the message displayed is '1 | 2 | 4 | 6' instead of '1 | 2| 3|' Exiting at 4, 5, or 6 will display '1 | 2| 4|', '1 | 2| 5|' and '1 | 2| 6|' as expected. After many hours of debuging I realized the function (the action filter 'activate_' . $plugin) gets executed 3 times if you exit it early. And only the first call has the argument $network_wide set to true if it is an network_wide activation. If you like to exit at 3, that is you do not want a network activation, the flow is therefore as follows: - The first run (click on network activate) has $network_wide set to true and will exit at 3 - the second run (no idea why) has $network_wide set to false and will pass 1 | 2 | 4 | 6 - the third run (no idea why) has $network_wide set to false and will pass 1 | 2 | 4 | 6 Imho calling the activation function (or the code) three times in case you exit it (better say terminate because you cant end a plugin installiton clean) is wrong at all. However if this is by design then $network_wide must be reliably set to true if it originally was. " mensmaximus Tickets with Patches 34358 plugin_dir_url( __FILE__ ) returns plugins directory when plugin symlinked to mu-plugins Plugins 4.3.1 normal normal Future Release defect (bug) new needs-unit-tests 2015-10-19T17:53:00Z 2017-10-02T15:02:25Z "With a plugin symlinked to the mu-plugins folder, paths to find assets via the URL are broken if using `plugin_dir_url()`. This does not happen when using the `WPMU_PLUGIN_URL` constant. However, if using the constant then the plugin is not portable to the normal `plugins` directory without additional checks. {{{#!php Add New Plugin`. 2. Click ""Install Now"". 3. Once installed, click ""Activate"". 4. 🐞 Once activated, click on the disabled ""Active"" button. === Expected Results When testing a patch to validate it works as expected: - ✅ The link does not work. When reproducing a bug: - ❌ The link still works despite the `.button-disabled` class being present." costdev Slated for Next Release 59402 Plugin cannot be uninstalled if uninstall crashes swissspidy Plugins 2.7 normal normal 6.6 defect (bug) assigned has-patch 2023-09-20T06:59:37Z 2024-02-19T09:31:50Z "If a plugin register the ""register_uninstall_hook"" conditionally (e.g. only on activation,...) a plugin cannot be uninstalled anymore if it exits (e.g. timeout,...) during uninstall. This is because the uninstall file/callback is removed from the option before the actual uninstall happens: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/includes/plugin.php#L1253 https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/includes/plugin.php#L1269 " kkmuffme Slated for Next Release 42670 Symlinked plugin makes plugin_basename function return wrong basename brianhenryie Plugins 4.9 normal normal 6.6 defect (bug) assigned has-patch 2017-11-23T11:36:11Z 2024-02-26T16:59:49Z "Symlinked plugin makes plugin_basename function return wrong basename for plugins which goes after the symlinked plugin. If symlinked plugin name is substring of WP root directory name. For instance, plugin name is feedback-plugin and WP root directory is feedback-plugin-wp. Cause of such a behavior is condition: {{{#!php // wp-includes/plugin.php plugin_basename function (line 658). if ( strpos( $file, $realdir ) === 0 ) { $file = $dir . substr( $file, strlen( $realdir ) ); } }}} Solution: {{{#!php $pattern = '/^' . str_replace('/', '\/', $realdir) . '\//'; if ( preg_match( $pattern, $file ) ) { $file = $dir . substr( $file, strlen( $realdir ) ); } }}} " sergiienko Tickets Awaiting Review 46982 Avoid loading dot files in the mu-plugins directory. Plugins 2.8 normal normal Awaiting Review defect (bug) new has-patch 2019-04-18T19:08:07Z 2022-03-10T21:41:15Z "In some circumstances, metadata files are generated in the `mu-plugins` directory. For example, editing a plugin file `my-mu-plugin.php` folder using a Mac via SMB can result in a metadata file `._my-mu-plugin.php` being created. Because of the way `wp_get_mu_plugins()` works, this metadata file will be loaded as a valid plugin and the contents of the file will be output in the page header. I'm attaching a small patch to avoid loading `._` files in the unfortunate event that they are created." dcavins Tickets Awaiting Review 59022 Bulk Action Issue For Plugin Component Plugins normal normal Awaiting Review defect (bug) new has-patch 2023-08-09T12:39:29Z 2023-08-10T05:31:03Z "When a user chooses a bulk action to enable and disable an auto-update plugin in the plugin field, it doesn't operate as intended. Likewise, if all plugins are set to auto-update by default and the user chooses to enable auto-update in the bulk action selection, the action instead does an enable to deactivate auto-update. https://www.awesomescreenshot.com/video/19806536?key=c795fd47ff5abdbfcb54f4499cebd0f0" harsh175 Tickets Awaiting Review 49021 Misaligned rows in Plugins list table on mobile after deleting some plugins Plugins 5.3 normal normal Awaiting Review defect (bug) new has-patch 2019-12-18T07:06:30Z 2022-02-01T05:53:35Z "Hi, When we have deleted the plugin then not showing properly UI in plugin listing page admin side. For more information see mention screenshot. Thanks" sumitsingh Tickets Awaiting Review 53979 Non-valid plugins should be removed from the 'active_plugins' option Plugins normal normal Awaiting Review defect (bug) new has-patch 2021-08-23T14:00:49Z 2022-01-03T20:57:22Z "**Issue as found** Failed auto-update of WooCommerce resulted in an empty `/woocommerce/` plugin folder, but `woocommerce/woocommerce.php` remaining inside the `active_plugins` option resulted in a dependent plugin throwing a fatal error, since its internal checks against the `active_plugins` option still returned true. To recreate this issue, a default install with WooCommerce & WooCommerce Subscriptions plugins installed is enough. Empty the contents of the `/woocommerce/` plugin folder to simulate a failed auto-update, there will now be a fatal error on front-end and admin. ''Note'' that whilst I ran into this issue with WooCommerce & WooCommerce Subscriptons, this issue could theoretically happen with any plugin and extension plugin combination that uses the `active_plugins` option to determine if dependency has been met. **Outline** Plugins which fail to validate inside `wp_get_active_and_valid_plugins()` should also be removed from the `active_plugins` option to avoid further clashes and potential fatal errors. Currently the function excludes the plugins from loading, but leaves the plugin key inside the `active_plugins` option which can be problematic if dependant plugins are checking that option for the parent plugin key. Expected outcome would be that a plugin which fails to validate for any reason should also be removed from the `active plugins` option. **Proposed solution** If a plugin fails to validate it should not just be excluded from loading at runtime, but also its key removed from the `active_plugins` option to avoid loading attempts in the future, and further issues caused by dependant plugins. I have tested a patch within `wp_get_active_and_valid_plugins()` which resolves this, should this bug report be accepted. **Acknowledgement of plugin specific issue** I appreciate that at first glance this appears like a plugin specific issue in that without the parent / dependant plugin structure using `active_plugins` as a dependency check then there would be no issue here. However given the ubiquitous nature of something like WooCommerce and their [https://docs.woocommerce.com/document/create-a-plugin/] developer docs pointing toward using `active_plugins` as a dependency check, it's clear that WordPress users getting a WSoD from a failed plugin update could be avoided with a core patch. " tommusrhodus Tickets Awaiting Review 44884 "Notice something like ""Notice: Constant WP_UNINSTALL_PLUGIN already defined in testsite\wp-admin\includes\plugin.php on line 1016"" appears when try to delete multiple plugins by ""delete_plugins()"" function" Plugins 4.9.8 normal normal Awaiting Review defect (bug) new has-patch 2018-09-03T06:18:33Z 2018-09-10T21:48:13Z "When i try to uninstall multiple plugins, I am getting warning like ""Notice: Constant WP_UNINSTALL_PLUGIN already defined in testsite\wp-admin\includes\plugin.php on line 1016"". To demonstrate this issue i have developed testcode. Issue reproduce steps: * Please ensure that debug mode is on in your WordPress setup by ensuring below constant is on root/wp-config.php file: {{{#!php Plugins > Add New and upload the plugin zip file. 3. Upon successful installation, click the ""Activate Plugin"" link. 3.a. Notice that the ""?action=activate&plugin=..."" plugin value is wrong as it refers to the contained plugin's main file within the wrapper plugin. 4. Observe the wp_die() error screen which says ""The plugin does not have a valid header"" == Problematic Source Code == The incorrect ""Activate Plugin"" link is generated here: https://github.com/WordPress/WordPress/blob/3546f04e160fbd31b46ba70b583d0a1d9fe1d80b/wp-admin/includes/class-plugin-installer-skin.php#L115 The offending assumption is here: https://github.com/WordPress/WordPress/blob/3546f04e160fbd31b46ba70b583d0a1d9fe1d80b/wp-admin/includes/class-plugin-upgrader.php#L546 Caused by an arbitrary situation here: https://github.com/WordPress/WordPress/blob/3546f04e160fbd31b46ba70b583d0a1d9fe1d80b/wp-admin/includes/plugin.php#L348 === Explanation === The ""Activate Plugin"" link on the ""Installing plugin from uploaded file"" screen in wp-admin uses the least lexicographic plugin basename discovered within the plugin's files. This is an arbitrary situation which can result in the incorrect plugin basename being referenced for activation, which ultimately results in the user experiencing an error screen. == Desired Solution == The ""Activate Plugin"" link after adding a new plugin and the ""Activate"" link in the installed plugin's table row actions should match. The ""Activate"" link in the plugins listing table is preferred as it refers to the correct plugin basename for activation." michelleblanchette Tickets Awaiting Review 58057 Replace loose comparison operator in plugins.php Plugins 6.3 normal normal Awaiting Review defect (bug) new has-patch 2023-04-02T10:36:41Z 2023-04-02T13:13:18Z The code is using a loose comparison operator (==) instead of a strict comparison operator (===). The difference between these operators is that a strict comparison checks for both value and data type, while a loose comparison only checks for value. This can lead to unexpected behavior and potential security vulnerabilities in the code. sharif200 Tickets Awaiting Review 52218 WordPress Multisite 5.5.3 All Plugins set have Auto-Updates Disabled, but they Updated themselves anyway Plugins 5.5.3 normal normal Awaiting Review defect (bug) new has-patch 2021-01-04T18:44:30Z 2021-01-04T18:58:06Z "Running a WordPress Multisite Installation on Version 5.5.3 at the time of the issue. All plugins have Auto-Updates DISABLED (I like to run them only when I have time available to troubleshoot in case something goes wrong.) However, on December 14, 2020 (coincidentally at the same time as the big Google outage) - All 14 of my plugins that had updates available automatically updated themselves, even though I had all auto-updates disabled. This caused my site to get overloaded and go down, which was a big issue since google was also down and made it hard to communicate. I have since updated to WordPress 5.6, and run other updates manually (core and themes), but I cannot figure out why the plugins auto-updated themselves. I suspect it could be a multisite issue. Some plugins are network activated and others are only activated on one site. The core and themes did NOT auto-update only the plugins updated themselves. I am very nervous that it could happen again and cause downtime. I need to be able to plan ahead and control the update timing to occur on a slow time of day. Not sure if others with multisite installations have experienced the same. Thanks!" wellesleyps Tickets Awaiting Review 52405 activate_{$plugin} not passing $network_wide boolean to action handler Plugins 3.0 normal normal Awaiting Review defect (bug) new has-patch 2021-01-31T07:19:07Z 2021-02-23T01:04:05Z "When using {{{register_activation_hook}}}, the {{{""activate_{$plugin}""}}} action doesn't pass the {{{$network_wide}}} boolean as the parameter for the callback. Instead, the parameter gets substituted with an empty string, breaking the page when using strict typing, as it expects a boolean. Looking at how it's done when activating plugins, it uses {{{is_network_admin()}}} as the parameter https://core.trac.wordpress.org/browser/trunk/src/wp-admin/plugins.php?rev=49683#L124 Same thing should happen here: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/plugins.php?rev=49683#L193 {{{do_action( ""activate_{$plugin}"", is_network_admin() );}}} " noplanman Tickets Awaiting Review 41736 validate_file function will always return error for file paths in windows dev environments Plugins 4.8 normal normal Awaiting Review defect (bug) new has-patch 2017-08-27T18:50:51Z 2017-08-30T16:30:16Z "In Windows dev environments such as WAMP or XAMPP a file path always contains a colon after a drive letter, so all plugins making conditional checks with `validate_file()` would fail. " lechdulian Tickets Awaiting Review 23253 Lack of a do_settings_section (singular) function Plugins normal normal Awaiting Review enhancement reopened has-patch 2013-01-21T19:20:06Z 2021-02-27T18:30:24Z "After considerable research I have found that plugin authors, including myself, have to go to great lengths to put options into tabs on a plugin settings page. The majority use JavaScript to modify the DOM in order to achieve this, others have broken their options into several settings arrays instead of the recommended single array to facilitate the creation of tabs using the traditional WordPress nav-tab-wrapper class approach. To get my own options into tabs in a fully scoped css jquery ui theme I ended up adding my own hacky function to my plugin: myplugin_do_settings_section( $page, $sectionid ) - which is just a copy of the core function do_settings_sections( $page ) with an additional parameter for the section id and an added conditional to only output the section with the requested id. This allows me to wrap each section in the appropriately classed tags for either jquery ui tabs or traditional WordPress nav-tabs. This however, is not an acceptable long-term solution as the core code will undoubtedly change, I already see tickets and revisions relating to the removal of those nasty tables... This functionality should be in the core code. A settings section is a ''section'' and it should be possible to output them one at a time to allow for styling. Thanks for considering my proposal. (Also, the Iris color picker does not play nice with jquery-ui - it needs its own css scope or something - that will be a separate ticket once I have a better understanding of what is wrong with it and have searched for existing tickets on the subject.) " auniquename Tickets Awaiting Review 27303 "Make the ""Plugins bubble-link"" only show plugins that have an update available" Plugins 3.8.1 normal normal Awaiting Review enhancement new has-patch 2014-03-06T19:03:20Z 2020-09-23T19:51:37Z "If I click on ""Plugins"", I get the full list of plugins. (plugins.php) If I click on the bubble, I get the plugins with an update available. (plugins.php?plugin_status=upgrade) It's a very small enhancement, but it will save me a click every time I go to update my plugins. :) [[Image(https://i.cloudup.com/7UkYAUAV38.png)]]" Fredelig Tickets Awaiting Review 55522 Misleading method names plugin_dir_path and plugin_dir_url Plugins 5.9.2 normal normal Awaiting Review enhancement new has-patch 2022-04-04T05:43:45Z 2022-04-07T17:18:01Z "The method names `plugin_dir_path` and `plugin_dir_url` names are very misleading. Both the methods, as their names suggest should either return the path and URL of the base plugin directory i.e. `wp-content/plugins` or a specific plugin directory based on plugin file path that is supplied in the methods. But in practice, they are designed to reurn any path starting from application root to theme and everything. Logically this is fine but ideally the behaviour should match the method names! The best option would be to have different method names for differnt purposes, e.g. `plugin_dir_path` and `file_path` although they are doing the same thing! But adding two new methods, that too for doing the same thing might not be a good idea. So I would suggest the following so that at least the methods can return base plugin dierectory pth and URL with no or empty value `_FILE_` is passed. {{{#!php You do not have sufficient permissions to access this page. This message is a little misleading, because there is no such page. A message that better reflects the decision to display it would be less misleading, e.g.: > The requested page is not accessible. " hakre Tickets with Patches 39794 Notice if update_plugins cap is off SergeyBiryukov Plugins normal normal Future Release defect (bug) reviewing has-patch 2017-02-06T13:03:56Z 2017-05-18T15:01:43Z "In wp-admin/includes/update.php:378 i have condition: {{{#!php `PHP Notice: Constant WP_UNINSTALL_PLUGIN already defined` The notice will never be noticed by most users, because it will be silenced by default, but this could be an issue if plugins are checking for the value of `WP_UNINSTALL_PLUGIN`, as recommended [http://wordpress.stackexchange.com/questions/25910/uninstall-activate-deactivate-a-plugin-typical-features-how-to/25979#25979 here] (which is linked to [http://codex.wordpress.org/Function_Reference/register_uninstall_hook#Discussions from the codex]), and not just whether it is defined. I don't have a good solution, sorry." jdgrimes Tickets with Patches 46032 Plugin details text direction layout (RTL) SergeyBiryukov Plugins normal normal Future Release defect (bug) reviewing has-patch 2019-01-18T07:55:21Z 2021-11-13T22:56:51Z "Hi, This RTL CSS minor was noticed before 5.0 release, but with increasing number of plugins that have been translated to RTL languages! It would be nice fix it at present. **In the plugin details screen**, when site language or admin choosing RTL panel: Text direction for plugin Description, Changelog, Screenshots captions, and Reviews tabs appears LTR and some phrases become not quickly understood. (Screenshot attached [https://moqbel.net/s/WP-admin-plugins-description-RTL-PrtScn]). In this case (especially for those plugins that have been translated to any RTL language) I think the following needs to be fixed: direction: ltr; {{{ #plugin-information .section { direction: rtl; } }}} And for section ul class: margin-left: 24px; {{{ #plugin-information .section ol, #plugin-information .section ul { list-style-type: disc; margin-right: 24px; } }}} ---- **For Reviews tab (RTL):** 1. star-rating: float: left; {{{ #plugin-information .reviewer-info .star-rating { float: right; } }}} 2. review-title-section h4 float: left; margin: 0 6px 0 0; {{{ #plugin-information .review-title-section h4 { display: inline-block; float: right; margin: 0 0 0 6px; } }}} 3. reviewer-info .avatar float: left; margin: 4px 6px 0 0; {{{ #plugin-information .reviewer-info .avatar { float: right; margin: 4px 0 0 6px; } }}} ---- Finally will be displayed correctly as this PrtScn: [https://moqbel.net/s/WP-admin-plugins-description-RTL-PrtScn-fixed] Many thanks," nabilmoqbel 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 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 31183 "Users with ""update_plugins"" capability can not see update details" Plugins 4.1 normal normal Future Release defect (bug) new has-patch 2015-01-30T13:19:09Z 2017-12-05T20:14:19Z "Users with the ""update_plugins"" capability can see available updates for plugins, but see the message ""You do not have sufficient permissions"" when clicking on ""View version x.y.z details"", because that page requires the ""install_plugins"" capability. The details page (with changelog, etc) should also be available with only the ""update_plugins"" capability." michel.weimerskirch Tickets with Patches 32235 When searching through installed plugins $context changes to 'all' after an available update Plugins 4.2.1 normal normal defect (bug) new has-patch 2015-05-02T09:33:51Z 2019-06-04T20:49:51Z "Let's search for ""git"" in the installed plugins. There are 3 results and update is available for the second one. The `$context` for the third plugin will chage from ""search"" to ""all"" in `apply_filters( $prefix . 'plugin_action_links' ...` " szepe.viktor Tickets with Patches 10535 _wp_filter_build_unique_id issues with the first time a filter is hooked by a class Plugins 2.9 normal normal defect (bug) reopened has-patch 2009-08-02T12:22:18Z 2019-06-04T20:40:50Z "Ref #8723 The first time _wp_filter_build_unique_id is used to generate an ID the ID returned is different to the second time it is called. This presents a problem if the first ID is used when adding a filter which then needs to be removed later in the app flow... as the IDs don't match the filter is unremovable. One workaround proposed is to set a wp_filter_id property before add the filter, and this will cause _wp_filter_build_unique_id to bypass the problem code and effectively forces the ""unique"" ID which is generated... this workaround feels unpoetic. ;)" simonwheatley Tickets with Patches 39338 class-wp-hook.php - apply_filters() infinite loop Plugins 4.7 normal critical Future Release defect (bug) new has-patch 2016-12-20T08:16:25Z 2019-08-01T00:55:14Z "I just saw nearly 60 million error log entries (17 GB) due to this bug. In line 303 of class-wp-hook.php, there is a piece of code that will cause an infinite loop: {{{#!php } while ( false !== next( $this->iterations[ $nesting_level ] ) ); }}} The problem is that {{{#!php $this->iterations[ $nesting_level ] }}} can be null. Suggested fix: {{{#!php } while ( ! is_null( $this->iterations[ $nesting_level ] ) && false !== next( $this->iterations[ $nesting_level ] ) ); }}} I also urge developers to look for similar ""false !== next()"" constructs in code, as they '''will''' lead to infinite loops." frettled Tickets with Patches 18857 get_plugin_page_hookname uses menu_title to construct subpage load-hooks chriscct7 Plugins 3.1.4 normal normal Future Release defect (bug) assigned has-patch 2011-10-04T15:16:33Z 2024-02-27T22:04:37Z "The load-hook for PluginSubPages isn't working anymore if the PluginPage is translated. The reason seems to be that the get_plugin_page_hookname function uses the menu_title instead of the menu_slug to create the hookname. I attached a possible fix." apocalip Tickets with Patches 15906 validate_plugin needs all_plugins filter Plugins normal normal defect (bug) new has-patch 2010-12-20T03:13:12Z 2019-06-04T20:41:40Z "If a plugin adds plugins to the plugin list in the plugin admin screens using the all_plugins filter, the added plugins will not validate. If the all_plugins filter is added to the validate function, then the plugin validates and activates fine. " wpmuguru Tickets with Patches 28085 "Add a ""Recently Updated"" Plugins' view" Plugins 3.9 normal normal Future Release enhancement assigned has-patch 2014-05-01T00:04:19Z 2021-08-11T15:45:06Z "Hello I will propose a new ""view"" in the plugins list. Like ""Recently Active"", a ""Recently Updated"" can be useful to know which plugins have been .... recently updated, obviously. I did this as a plugin, but i think it could be logical to get this in core, here come my (first) core patch. Also, i add you this snippet, i don't know where to put this function i use each time before the 'upgrader_process_complete' hook. {{{ function wp_set_recently_updated( $array ) { $recently_updated = get_option( 'recently_updated' ); foreach ( $array['plugins'] as $plugin ) { $recently_updated[ $plugin ] = time(); } update_option( 'recently_updated', $recently_updated ); } }}}" juliobox Tickets with Patches 27316 Add search for favourite plugins Plugins 3.8 normal normal enhancement new has-patch 2014-03-07T13:20:45Z 2022-03-11T09:05:10Z "Many magicians (and me) have a lot of favorite plugins on wordpress.org. So this is the enhancement in order to have the search feature in favorite plugins too. Actually it's a workaround on the plugins_api, if there were the 's' (search) argument.. it would be better. But that's it and it works." mirkolofio Tickets with Patches 37041 Allow arbitrary return redirects when activating plugins Plugins normal normal enhancement new has-patch 2016-06-07T03:15:30Z 2019-06-04T21:00:02Z "After activating a plugin, the return redirect is set to either `import.php` or `plugins.php` depending on the `from` query parameter. It'd be nice to have the ability to specify an arbitrary `redirect_to` similar to the login process. This should probably be locked down using `wp_safe_redirect`." rmccue Tickets with Patches 18954 Automatically whitelist screen options added via add_screen_option() Plugins normal normal enhancement new has-patch 2011-10-14T22:54:08Z 2019-06-04T20:42:29Z "{{{set_screen_options()}}} currently maintains a hardcoded whitelist of screens that can set options. The list is extendable via the filter: {{{ apply_filters('set-screen-option', false, $option, $value); }}} but that's sort of a pain. If a plugin calls {{{add_screen_option()}}}, it should be added to the whitelist automatically. Also note that {{{set_screen_options()}}} is called so early, there's no convenient place for plugins to add to the {{{set-screen-option}}} filter. The best workaround I've been able to come up with is to manually call {{{set_screen_options()}}} again inside the page's {{{load-$hook}}}. Example naive plugin code that does not work in <=3.3. {{{ # Inside a menu page's load-$hook // Display per-page settings in screen options add_screen_option( 'per_page', array( 'label' => __( 'Things' ) ) ); }}}" mdawaffe Tickets with Patches 16185 Bulk Actions Dropdown Box JS Sync Ajax-Tables Plugins 3.1 normal normal Future Release enhancement new has-patch 2011-01-11T11:15:33Z 2018-04-30T16:56:35Z "It would be an increase in usability - if JS is enabled - to sync the changes between the bulk-action-drop-down on top of the table with the one below the table. In my scenario I increased the amount of entries to over 100. So you need to scroll. So to set the bulk action on top and then you might think twice, need to check something, scroll down to the list to check the last entry and you want to press the bulk submit down below. That combo box is still on the default value right now. To spare additional clicks, it would be nice that it got synched with the one on top. Related: #14579; #15580" hakre Tickets with Patches 60190 Drop PHP 4 support for arrays with 1 object element Plugins normal normal Future Release enhancement new has-patch 2024-01-04T01:33:51Z 2024-03-27T20:41:29Z " {{{#!php do_action( 'foo', array( (object) null ) ); function foo_cb( array $arg ) {} add_action( 'foo', 'foo_cb' ); }}} This will fail with a fatal error in PHP 7+, since `do_action` (as the only one, this isn't an issue with `apply_filters` or `do_action_ref_array`) will convert arrays with only 1 object into that object. The reason for that is some PHP 4 legacy behavior, see #48312 It's time to drop this PHP 4 support, as this prevent using native types in callback functions in cases where the argument is an array of objects. " kkmuffme Tickets with Patches 32238 Enhancement has_filter function Plugins 4.2.1 normal normal enhancement new has-patch 2015-05-02T17:03:48Z 2019-06-04T20:49:56Z "I am optimize has_filter wordpress function. It is simple logic. Code here: [http://pastebin.com/mW0tBstE] I cannot create a path file. So I create this ticket. Hope someone will accepted that." tuanphp Tickets with Patches 44090 Reword plugin compatibility text to something more meaningful SergeyBiryukov Plugins normal minor Future Release enhancement reviewing has-patch 2018-05-15T13:52:46Z 2020-10-20T02:10:48Z "Currently, when looking at the plugins update table on the `/wp-admin/update-core.php` page, it says whether the plugin is compatible with the version of WordPress you are running and the latest version (or just the latest if you're on it). It states that it's 100% compatible. This seems to be left over from the old days when people could rate if a plugin worked on a certain version, but this doesn't apply anymore as it either does work, or it doesn't. You can't quantify it with a percentage because it's just not possible. It either works or doesn't. I'd suggest the wording here is updated to reflect the current state of plugin compatibility by replacing the percentage with either a yes or no value. It's my understanding that based on the meta data in the plugin readme, it'll either be 0% or 100%, so that's either a 0 (no) or 1 (yes). I've attached a screenshot of what I mean." danieltj Tickets with Patches 32497 The plugin list table is not very extendable Plugins 4.3 normal normal enhancement new has-patch 2015-05-26T14:14:39Z 2019-06-04T20:50:02Z "The plugin list table in wp-admin is a bit strict. For instance, it would be impossible to create custom views like this: [[Image(https://cldup.com/Qt2BpELMbZ.png)]] In the example above, we use custom plugin statuses 'Updates Automatically' and 'Updates Manually' In order to support custom plugin statuses and lists, we need a few more filters in `wp-admin/includes/class-wp-plugins-list-table.php`" roccotripaldi Tickets with Patches 11538 Unbundle Hello Dolly westi Plugins 3.0 normal normal enhancement reopened has-patch 2009-12-20T22:47:27Z 2024-03-02T21:23:22Z "Now that WordPress is a mature platform, having Hello Dolly as a default plugin is really a bit of an embarrassment. With the impending focus on canonical plugins, this strikes me as a good opportunity to remove Hello Dolly and replace it with a plugin which is actually useful. Hello Dolly could be kept in the repo for the sake of nostalgia if it's wanted by anyone..." caesarsgrunt Tickets with Patches 12801 Add Info link to plugins management screen chriscct7 Plugins 3.0 normal minor feature request reviewing has-patch 2010-04-01T19:08:40Z 2019-06-04T20:41:12Z "Related to #11050 but instead of the search results, on the regular plugins.php screen. Add ""Info"" link to left of Activate/Deactivate action links, which brings in the tabbed info from the repo. If not from the repo, link does not appear." jane Tickets with Patches 14569 Assign plugins on a per-site-basis Plugins normal normal Future Release feature request new has-patch 2010-08-09T09:35:55Z 2022-07-15T14:43:01Z It's possible to assign themes per site with WordPress Multisite. However it isn't possible to assign plugins per site. Some plugins are only used for the mainsite and I don't want them to be visible in subsites. ChantalC Tickets with Patches 55645 Docs: Improve the documentation for `plugins_api()`. Plugins 2.7 normal normal Future Release task (blessed) new has-patch 2022-05-02T02:23:02Z 2024-02-19T20:37:31Z "The docblock for [https://developer.wordpress.org/reference/functions/plugins_api/ plugins_api()] needs some improvement, including: - it does not document the make-up of possible return values. - it has a self-reference in the `@return` annotation. Related ticket: #55480" costdev Tickets Awaiting Review 47730 Function plugins_api is not triggered for non wp-marketplace plugins Plugins 5.2.2 normal normal Awaiting Review defect (bug) new dev-feedback 2019-07-18T07:32:17Z 2019-08-23T07:28:43Z "I currently try to setup a private-hosted repository for my own plugins / themes and tried to do that with the filter hooks in the plugin-install.php file - the documentation of it indicates that this should be possible, even on the latest version (5.2.2). I activated my own plugin on my bedrock (https://roots.io/bedrock/) setup and following the tutorial https://rudrastyh.com/wordpress/self-hosted-plugin-update.html#comments i tried to implement the update mechanism. I think while doing that i stumbled upon a bug that causes wordpress to not trigger the plugins_api method at all - i can hook into the ""site_transient_update_plugins"" filter to display the update-badge next to the plugins navbar item but the update text / button and show-details button for my plugins wont show up." marthm Tickets Awaiting Review 45861 Global variable in plugin main file Plugins normal normal Awaiting Review defect (bug) new dev-feedback 2019-01-08T10:51:14Z 2019-01-09T06:59:04Z "In the main plugin file, if we declare a variable, it will be used as a global variable in WordPress. This might lead to conflict for global variable names. The code is in [https://core.trac.wordpress.org/browser/trunk/src/wp-settings.php#L342 wp-settings.php] file. A simple fix is creating a function to load a plugin and include main plugin file inside that function. So the scope is function scope, not global scope." rilwis Tickets Awaiting Review 41638 Must-Use Plugin File Still Available With a dot at the beginning of a filename (aka supposedly hidden) Plugins 4.8.1 normal normal Awaiting Review defect (bug) new dev-feedback 2017-08-14T22:35:52Z 2022-02-18T19:14:43Z "If you place a dot in front of a must-use plugin file, I believe it shouldn't be included as part of your Must-Use arsenal and the code shouldn't be available as well. Perhaps I'm doing it the wrong way, but when I place a dot in front of something (e.g., folder, file), I expect that file to no longer be available. " ronalfy Tickets Awaiting Review 34052 Plugin-Install/Update Sections Plugins 4.3.1 normal normal Awaiting Review defect (bug) new dev-feedback 2015-09-28T08:16:47Z 2023-05-13T19:05:15Z "Hey WP-Community, I've found out that some plugins producing ""Cannot use object of type stdClass as array"" fatal errors when there is an update-notification and one clicks on the ""View version x.x.x details"" link. After the plugin information window pops up WordPress is not able to read the sections. In most cases this is caused by external plugins, I guess. However I was confisued to see that WordPress is doing a type casting already but not everywhere needed. Everything starts in the file [https://core.trac.wordpress.org/browser/tags/4.3.1/src/wp-admin/includes/plugin-install.php#L395 wp-admin/includes/plugin-install.php on line 395]. In this line the parameter ""sections"" from $api object is casted as an array. However a line later it's assumed that the parameter is an array already. Here is the code snippet: {{{ foreach ( (array) $api->sections as $section_name => $content ) { $api->sections[$section_name] = wp_kses( $content, $plugins_allowedtags ); } }}} The same problem appears on [https://core.trac.wordpress.org/browser/tags/4.3.1/src/wp-admin/includes/plugin-install.php#L408 line 408]. Wouldn't it be better to cast the parameter before everything happends? This would also avoid to type-cast the same parameter over and over again, see attached patchfile. {{{ $api->sections = (array) $api->sections; }}}" floriansimeth Tickets Awaiting Review 40393 Using remove_action within an action callback skips over execution of other callbacks with lower priority Plugins normal major Awaiting Review defect (bug) new dev-feedback 2017-04-07T16:01:05Z 2020-07-07T14:23:02Z "Description: When remove_action is used by an action callback to remove itself from the list of callbacks, this results in all callbacks hooked with the immediately lower priority to be skipped by apply_filters. Here is simple code to demonstrate: {{{#!php First Run'; echo '
';
		do_action('custom_action');
		echo '
'; echo '

Second Run

'; echo '
';
		do_action('custom_action');
		echo '
'; } public function callback_1() { echo ""Callback 1\n""; } public function callback_2() { echo ""Callback 2\n""; remove_action('custom_action', array($this, 'callback_2')); } public function callback_3() { echo ""Callback 3 - Priority 20\n""; } } $runner = new Sample; $runner->test(); }}} The output is: First Run Callback 1 Callback 2 Second Run Callback 1 Callback 3 - Priority 20 The expected output should be: First Run Callback 1 Callback 2 Callback 3 - Priority 20 Second Run Callback 1 Callback 3 - Priority 20 The net effect of this issue is that a plugin using remove_action in that way will break another, totally unrelated plugin, if they both add actions on same tag, with different prorities. WooCommerce is using this method, it uses remove_action inside a pre_get_posts action callback. This broke our Accelerated Mobile Pages plugin when doing AMP pages for WooCommerce. This was reported to [https://github.com/woocommerce/woocommerce/issues/14092 WooCommerce here], but it was then suggested it was a core issue. '''Additional notes''': - all callbacks must '''object methods'''. The problem does not occur if callbacks are functions. - the callback using remove_action must be the only registered callback for that priority level {{{#!php string(0) """" }}} " Tkama Tickets Awaiting Review 44853 Remove extra condition Plugins normal minor Awaiting Review enhancement new dev-feedback 2018-08-28T03:45:58Z 2018-09-04T17:06:56Z Remove extra `if` condition from `get_plugins` function. abhijitrakas Tickets Awaiting Review 60194 Add Preview in Playground buttons to plugin install screens Plugins trunk normal normal Awaiting Review feature request new dev-feedback 2024-01-05T04:40:55Z 2024-01-12T06:04:18Z "Proposal: add Preview buttons to plugin install screens within wp-admin. Background: The WordPress.org Plugin Directory now supports a Live Preview feature based on Playground; see https://meta.trac.wordpress.org/ticket/7251 for context. You can see an example working on the https://wordpress.org/plugins/convert-to-blocks/ plugin. Previews are currently only enabled on plugins where the developer has opted in and provided a blueprint.json file (which provides setup and configuration info). The preview button on the web site works simply by redirecting from `https://wordpress.org/plugins/PLUGIN-SLUG/?preview=1` to a `playground.wordpress.net` URL which loads the plugin's blueprint file. It opens the playground URL in a new window using `target=""_blank""`. I'm proposing that we do essentially the same thing from within wp-admin, on screens with an Install button for plugins: add a Preview button, which opens `https://wordpress.org/plugins/PLUGIN-SLUG/?preview=1` in a new window. The wordpress.org plugins API already returns a `preview_link` property containing the appropriate URL for plugins with a working preview. I'll attach a diff with a minimal implementation; this is intended as a starting point for testing and discussion, not a finished patch in its current state." tellyworth Tickets Awaiting Review 43621 Introduce `add_action_once` and `add_filter_once` sugar. Plugins normal normal Awaiting Review feature request new dev-feedback 2018-03-23T17:49:45Z 2018-04-06T17:12:29Z "It is often useful (especially when writing tests for filters, actions) to run a callback only once, regardless of how many times the filter/action is actually applied/done. {{{ add_filter_once( 'test_action_once', '__return_true' ); $this->assertTrue( apply_filters( 'test_action_once', false ) ); $this->assertFalse( apply_filters( 'test_action_once', false ) ); }}} This would allow developers to run anonymous callbacks that remove themselves from the filter after running once. This can currently be done with the following ugly workarounds: {{{ add_action( 'run_many_times', function() { // do stuff once and self-destruct remove_action( 'run_many_times', current( $GLOBALS['wp_filter'][ current_filter() ]->callbacks[ 10 ] )['function'] ); } ); }}} or {{{ $once = null; add_action( 'run_many_times', $null = function() use ( &$once ) { // do stuff once and self-destruct remove_action( 'run_many_times', $once ); } ); }}} This is '''not''' a duplicate of #38743, the concept is different, the naming is the same, yes. Non-clashing names here? - `​add_self_destructing_filter()` - `add_ephemeral_filter()` open to other suggestions :)" soulseekah Candidates for Closure 60550 A plugin is deactivated if it is updated and the plugin folder has been renamed at some point. Plugins 6.4.3 normal major Awaiting Review defect (bug) new dev-feedback 2024-02-15T14:56:38Z 2024-02-15T15:28:57Z "This seems to be a new unexpected behavior: A plugin whose folder has been renamed will be deactivated as soon as you update it. Reproduce: - Rename the folder of an activated plugin to something like plugin-name-xy (People do this all the time for several reasons) - The plugin will be disabled (expected due to the modified plugin folder) - Activate again the plugin via wp-admin - Update the plugin to a new version - The plugin folder will be renamed to plugin-name (Unexpected) - The plugin will be disabled silently (Unexpected) " ReneHermi Candidates for Closure 56176 After updating WP to 6.0, updating a(ny) pluging causes site to be stuck in maintenance mode. Plugins 6.0 normal major Awaiting Review defect (bug) new dev-feedback 2022-07-08T09:01:06Z 2022-07-26T15:07:12Z I updated all my WordPress sites (5 of them) to 6.0 from 5.9.3. Now, when I update a plugin, the sites becomes stuck in maintenance mode. I have to manually remove the .maintenance file to get the site out of maintenance mode. But as soon as I update another pluging, it gets stuck again. zippy1970 Candidates for Closure 59631 Despite using Update URI Plugin header, WP still tries to fetch the Update notes from WP org Plugins 5.8 normal normal Awaiting Review defect (bug) new dev-feedback 2023-10-16T05:17:22Z 2023-12-06T02:33:02Z "Despite setting a [https://make.wordpress.org/core/2021/06/29/introducing-update-uri-plugin-header-in-wordpress-5-8/ Plugin Header] Update URI directive WP still will try to fetch the Update information (changelog) from a WP Org plugin. And when filtering the url with [https://developer.wordpress.org/reference/hooks/update_plugins_hostname/ update_plugins_{hostname}] , it will simply load an instance of the ""Add new plugin"" screen in the ThickBox loaded when clicking ""View version vx.x.x details"" I am quite sure I do not miss anything, as I read through all the (undocumented) new feature announcements. This is a minimal approach you need to replicate the issue: - Update plugin header directive to use `Update URI: https://domain.tld` - Either hook into `update_plugins_{hostname}` and pass a version higher than your currently installed one, **or** - Hook into `pre_set_site_transient_update_plugins` and pass a new `new_version` higher than your currently installed one Of course make sure you do actually have a remote update to be shown. ==> You could also just edit the database entry of `_site_transient_update_plugins` to trigger the ""has update"" alert in the plugins list... All this makes the `Update URI` pretty much dysfunctional (in the sense that it is not really useful at all) and the developer still needs to manually filter the ThickBox content for the ""View update details"" or even for the ""Plugin details"". And the documentation about all this is either inexistent or very limited (opened a separate issue about that [https://github.com/WordPress/Documentation-Issue-Tracker/issues/1194 here] IMO, passing a custom Update URI should completely unhook all Callisto the WP Org Api and either not allow to ""view details"" at all, or at least provide some ways to populate that window with custom details (or at least read from the plugin data, which it does not: it reads from remote)." bedas Candidates for Closure 55616 Helper function to unhook anonymous class methods Plugins normal normal Awaiting Review defect (bug) new dev-feedback 2022-04-25T13:12:13Z 2022-05-13T08:50:06Z "Problem: it’s pretty common (even if it’s not polite) for plugins to use a class constructor to hook their own public methods into things, but doing so makes it ''near-impossible'' to unhook procedurally. Solution: I just ran across the following function on StackExchange, and imagined something similar could be quite useful to have globally available: https://wordpress.stackexchange.com/a/304861 It’s gnarly, but it works, and I think having WordPress core include this functionality makes more sense than having plugin authors all include their own version of it." johnjamesjacoby Candidates for Closure 51548 Orphan cron on multisite Plugins normal normal Awaiting Review defect (bug) new dev-feedback 2020-10-16T05:41:44Z 2020-10-16T05:41:44Z "Hello, on a multisite, the upgrade task for plugins and themes are done in the network level. Each sites " sebastienserre Candidates for Closure 55133 Using an array containing a single object as first $arg in do_action() Plugins normal normal Awaiting Review defect (bug) new dev-feedback 2022-02-10T07:55:43Z 2022-06-17T09:36:19Z "When passing an array containing 1 single object as the first argument of `do_action()`, the array is automatically flattened and all functions triggered by the hook will receive a single object as the first argument (instead of an array). **Example:** {{{#!php $var = [ (object) [ 'key' => 'name', 'value' => 'Pierre', ] ]; do_action( 'hook_name', $var ); }}} Any function hooked to `hook_name` receives this first argument: {{{#!php stdClass Object ( [key] => name [value] => Pierre ) }}} …instead of an array containing this object. I've found that this is because of some **PHP4** backward compatibility in the `do_action()` function: {{{#!php } elseif ( is_array( $arg[0] ) && 1 === count( $arg[0] ) && isset( $arg[0][0] ) && is_object( $arg[0][0] ) ) { // Backward compatibility for PHP4-style passing of `array( &$this )` as action `$arg`. $arg[0] = $arg[0][0]; } }}} This is a weird and unexpected behavior, could we add an additional condition in this `elseif` in order to check for the PHP version to apply this hack?" pskli Candidates for Closure 49599 Wrong PHPDoc wp_get_active_and_valid_plugins Plugins 5.3.2 normal normal Awaiting Review defect (bug) new dev-feedback 2020-03-08T14:08:07Z 2022-02-13T17:22:28Z "I found a misleading error in the documentation of wp_get_active_and_valid_plugins (in wp-includes/load.php): {{{#!php array('Dashboard', ... [4] => array('', 'read', 'separator1', ...), [5] => array('Posts', ...) ... ) }}} To allow plugins to add a menu item at the end of a group, we use a bunch of additional global variables that remember the last element in each group. Also, we use arbitrary numeric indexes to specify the order of the items, instead of being able to position items relative to one another. It's all very low level. Things would be a lot easier if we had an actual API for manipulating the menu items." scribu Tickets with Patches 39441 Improve the Settings API for accessibility and ease of use. Plugins normal normal Future Release enhancement new dev-feedback 2017-01-02T21:58:14Z 2023-01-10T18:32:17Z "Today a kickoff meeting for the Settings API took place on Slack (Archive: https://wordpress.slack.com/archives/accessibility/p1483376507000492) where we discussed ways to improve it, both in terms of accessibility and ease of use. After a good discussion we came to the conclusion that we would like to focus on the existing Settings API for now and do what we can to improve it. The Fields API project will eventually make the process of registering settings and having them automatically rendered even easier and complete, but we should not wait until it is ready for a core-merge, as some issues in the existing Settings API should be solved sooner than later. We figured out two main goals: * Add some basic support to automatically render fields so that plugin developers no longer need to write their own callback functions for basic fields. * Get rid of the table structure to improve accessibility. Furthermore the accessibility team should also ensure that the markup generated as the core field output is accessible. For the technical improvements, we would like to do the following: * Adjust `add_settings_field()` to support a predefined set of identifiers for a field type instead of a callback function. In that case a default callback function that we would introduce in core would take care of rendering the field. The requirement to write custom callbacks for even the most basic fields is one major issue with the current Settings API and why most people rely on external libraries for that. * Enhance the `$args` parameter of `add_settings_field()`. It should become more significant and probably go through some validation, filling it with default values. This is especially important for the new default callbacks. * Possibly support providing one `$args` array as sole parameter to `add_settings_field()` that contains the other parameters as well. This would of course need to work in a backward-compatible way. For the accessibility part, we would like to do the following: * Scaffold an HTML prototype for what a settings page should look like. This will give a good overview of the accessibility approach we should take without having to deal with the PHP implementation. * Get rid of the current table structure. Whatever the above prototype looks like, it will not have tables anymore. We can generally remove the table structure and change it to something else easily, since all the table output is generated by core (in particular by `do_settings_sections()` and `do_settings_fields()`). For everyone who uses the API as recommended, this will not bring any BC issues unless they are using specific table-related selectors (like `td`) in CSS or JS code. It is unclear whether these should be considered edge-cases and whether a dev-note reflecting the changes is sufficient, or whether we should only support the new markup through an additional parameter which would default to the current `table` way. The latter is backward-compatible, but on the other hand it would decrease the amount of sites that become more accessible out-of-the-box. * Do not deal with people who completely write the table markup manually. We simply cannot do this, other than recommending them to switch to using the Settings API or at least changing their markup. The only thing to keep in mind here is that we should never remove any CSS related to these tables, in order to keep their code working. All of these enhancements would also benefit #38734 as it would become a lot easier to change core's own settings pages to actually use the Settings API. We will from now on have meetings on Slack to continue discussion in detail every 2 weeks on Monday at 17:00 UTC. However, general opinions and discussion can and should also be placed in this ticket." flixos90 Unpatched Bugs 47160 Backport blocking of plugin updates if required PHP version is not supported Plugins 5.2 normal normal Future Release defect (bug) new dev-feedback 2019-05-06T21:46:08Z 2019-10-07T23:38:51Z "Follow-up from #43987 and #44350. Description from https://core.trac.wordpress.org/ticket/43987?cnum_edit=46#comment:41 With WordPress 5.2 requiring at least PHP 5.6, many plugin authors will start updating their plugins to also require PHP 5.6. This is fine for users running WordPress 5.2, but for users on older versions of WordPress they'll start receiving update notifications for plugins that they may no longer be able to run if they're using a version of PHP older than 5.6. If the user updates such a the plugin then they'll likely start seeing fatal errors. Backporting the changes that prevent updates from being served to sites that don't meet the plugin's minimum PHP version will help avoid users on older branches finding themselves updating a plugin to a version that no longer works. " azaozz Unpatched Enhancements 53149 Plugins: Consider using `block.json` file as an entry point for blocks from Block Directory Plugins normal normal feature request new dev-feedback 2021-05-04T07:51:05Z 2022-02-18T15:41:21Z "The original discussion sparked by a comment from @jipmoors on GitHub in https://github.com/WordPress/gutenberg/pull/13693#issuecomment-477904539: > WordPress automatically discovers all the block.json files in the plugin/core blocks folder and registers the corresponding block types. These block types are made available through the block registry (https://developer.wordpress.org/reference/classes/wp_block_type_registry/) PHP class, and the blocks scripts and styles are added as dependencies to the wp-block-library script and style handles. At the moment, it's mandatory to create the PHP file for the plugin that contains only a single block type registration code when developing for Block Directory. Those plugins rarely have PHP code, so we could simplify the flow for developers by making it possible to use `block.json` to source all required metadata. If the current metadata schema doesn't contain some fields that can be declared only in the PHP comment (some are duplicated in `readme.txt`, we can always include it in `block.json`. In the case when developers would like to use the `render_callback`, they could use the concept proposed in #53148 - the `renderTemplate` file reference in `block.json`. This way, the process of validation of block types submitted to Block Directory would get further simplified." gziolo Candidates for Closure 46737 Admin panel Plugin pagination issue Plugins 5.1 normal normal Awaiting Review defect (bug) new close 2019-03-30T09:50:36Z 2023-10-20T00:49:40Z "Hello Team, I found one issue while plugin listing pagination. Admin dashboard plugin listing pagination some time return 36 per page and some times 25 per page Link with issue: https://www.useloom.com/share/dd872eee74bd412e8484d01e415b3117 Thanks, Hitendra" Hitendra Chopda Candidates for Closure 44072 Plugin repository search error - cannot find plugin with Author's name Plugins normal normal Awaiting Review defect (bug) new close 2018-05-14T13:02:45Z 2023-10-20T00:33:06Z "If I search with Author option selected in plugin repository (/wp-admin/plugin-install.php), no plugin is found unless the author name is present in the Plugin name or may be somewhere in the description. Example: I searched with `Takayuki Miyoshi` as a Keyword and got a handful of result, but when I selected Author, it returned no result." subrataemfluence Candidates for Closure 59109 Prevent plugins from creating admin accounts Plugins 6.3 normal normal Awaiting Review defect (bug) new close 2023-08-15T13:32:51Z 2023-08-15T16:38:19Z "Honestly someone needs to see the sense in this. I'm pretty confident if you petitioned the worldwide wordpress community everyone would want this fixed regardless of it being self hosted or wordpress.com this is a flaw in the current wordpress. I have given you the email to describe the issue it explains fully. This flaw needs to be fixed. (13:14:10) James: Regardless of whether it's open source or not WordPress needs to be secure (13:14:23) James: People. Business, even enterprise use your product (13:14:59) James: There must be a way for WordPress to prevent any plugin from creating a admin account surely? (13:15:21) James: And only allow WordPress admin to do it (13:15:46) James: That would eliminate the flaw (13:15:54) James: And actually make it secure (13:16:57) James: I don't get how all these minds working on wordpress don't get this is important (13:17:55) Happiness Engineer: Part of the open source spirit is that everything is open and available to change for everybody. After downloading the software you can do with it whatever you want, this is what's also appealing for a lot of developers and users. (13:18:19) James: What you basically telling me is this flaw is OK because wordpress is open source? It's not OK? (13:18:28) Happiness Engineer: Suggestions to improve the software can be made using a tool called Trac https://core.trac.wordpress.org/ (13:19:46) James: Can you send this email to me please (13:19:54) James: I will post this message there (13:20:13) Happiness Engineer: You will receive a transcript of this conversation after we close i. (13:20:25) James: OK thanks let's close it (13:23:41) Happiness Engineer: Ok, no problem. Feel free to pop back in if there is anything else we can help you with. Conclusion... Honestly think of this from a critical point of view, this is a Flaw, that should be able to be fixed so that Plugins cannot make admin accounts and only Admin can make admin accounts. I'm not a coder, and I do not have the foggiest how this would be done, but I hope it can be done, because if you surveyed everyone who uses wordpress I think everyone would feel safer with this implemented." tspnet Candidates for Closure 41001 Recently Active Plugins Option does not reset when you delete a plugin. Plugins 4.8 normal normal Awaiting Review defect (bug) new close 2017-06-11T17:25:39Z 2022-02-26T20:18:45Z "When you deactivate a plugin like Akismet, a value gets saved into ""wp_options"" under the option name ""recently_activated"". The value looks like: ''a:1:{s:19:""akismet/akismet.php"";i:1497201452;}'' When you reactivate Akismet, the value is updated and resets the option back to look like this: ''a:0:{}'' '''The Bug.''' When you deactivate Akismet and delete akismet, the ""recently_activated"" option keeps this in the option value. ''a:1:{s:19:""akismet/akismet.php"";i:1497201452;}'' when it should reset back to ''a:0:{}''" GeekStreetWP Candidates for Closure 56729 Vulnerability in plugin update notification (impersonation of plugins with possible RCE) Plugins normal normal Awaiting Review defect (bug) new close 2022-10-04T09:21:13Z 2022-10-04T09:32:00Z "During the development of a private plugin (not uploaded to the WordPress market https://es.wordpress.org/plugins/) with our own metadata, we noticed that the WordPress plugin update notification system informs us that an update is available for our plugin, how is this possible? Well, the only explanation for this is that the update review system is based solely on the plugin's folder name, ignoring any authorship metadata and project URIs. To make sure that the update system is evidently ignoring any data in the plugin's metadata, we proceed to download it (the plugin). This confirms our suspicions, the update system is only governed by the name of a directory. Due to this lack of security in the metadata check, the only solution so far is to never activate the auto-update and to manually check each update. If you click on the ""update now"" link, the system will install the possible malicious plugin without any confirmation. Criticality: HIGH [8.8] - Exploitation of this vulnerability would affect the server in remote code execution (RCE) mode. It is downgraded from critical to high because it requires human action on plugin configuration. CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H Affected environments: All installations with custom plugins that are not in the official WordPress marketplace. Aggravated if the unattended updater is accidentally activated. If a maintenance technician is unaware of the custom plugin development and hits the update button. Conclusion: As there is no signature checking system in the plugin update review system, there is a possibility of impersonation of our plugin if an attacker created a plugin in the official market with the same name as the directory of our custom plugin, being able to execute remote code on our server. Temporary solution: Disable the automatic update systems and generate plugin page with a so that no one can get to take that name to perform the impersonation. Having today as a warning, process to request a CVE ID for the formal vulnerability write-up. " sylm87 Candidates for Closure 60040 While installing a plugin using wordpress plugin installer, a directory seems to be missing Plugins 6.3 normal normal Awaiting Review defect (bug) new close 2023-12-09T00:52:09Z 2024-02-15T16:29:41Z "**Description:** When installing the Aiify Blocks plugin (slug: aiify) via the WordPress plugin installer at wp-admin/plugin-install.php, it appears that the directory created at wp-content/plugins/aiify is missing a crucial subdirectory named ""aiify."" This subdirectory typically contains the primary plugin block files. Consequently, this missing directory structure renders the plugin non-functional. **Steps to Reproduce:** - Access the WordPress dashboard (wp-admin). - Navigate to the plugin installation section (wp-admin/plugin-install.php). - Search for and install the Aiify Blocks plugin (slug: **aiify**). **Expected Behavior:** Upon installation via the WordPress plugin installer, the directory wp-content/plugins/aiify should contain a subdirectory named ""**aiify**"" housing the necessary plugin block files. **Actual Behavior:** The directory wp-content/plugins/aiify lacks the expected ""aiify"" subdirectory after installation using the WordPress plugin installer, causing the plugin to malfunction. **Temporary Solution:** Downloading the plugin directly from the URL https://downloads.wordpress.org/plugin/aiify.0.1.1.zip and unzipping it provides the correct directory structure with the necessary ""aiify"" subdirectory intact, resolving the issue temporarily. **Additional Information:** - WordPress Version: 6.3.2 - Plugin Version: Aiify Blocks 0.1.1 - Server Environment: The hosting environment is provided by app.getflywheel.com ( which seems to be based somehow on wp-engine ) - Disclaimer : I'm the plugin developper, a user contacted me for support as he couldn't use the provided blocks, that's how I noticed the issue and the missing directory. This discrepancy in directory structure during installation impacts the functionality of the Aiify Blocks plugin ( and maybe other plugins ). **Investigation and Update:** While writing this ticket, I attempted to replicate the steps in wpsandbox.net (using WordPress 6.4), and the installation worked as expected. This suggests that the bug might be fixed or could be specific to the hosting environment. While planning to update the plugin and rename the problematic directory, I'm keen to understand why this ""bug"" occurred in the first place and if this irregularity might be specific to the hosting environment or is due somehow to a wordpress bug." rahal.aboulfeth Candidates for Closure 42637 Wrong button text for plugin installation failed! Plugins normal normal Awaiting Review defect (bug) new close 2017-11-20T07:42:07Z 2022-02-10T01:08:13Z "Button text should be `Installation Failed!` instead of `Update Failed!` if plugin installation failed. Check below gif: Latest version: http://bsf.io/yola3 After applied patch: http://bsf.io/rblas" Mahesh901122 Tickets with Patches 16418 get_plugin_data() doesn't apply kses when $markup and $translate are false dd32* Plugins 3.0.4 normal normal defect (bug) accepted close 2011-01-30T23:45:23Z 2019-06-04T20:41:49Z "`get_plugin_data()` uses `_get_plugin_data_markup_translate()` to apply kses, but this isn't invoked if $markup and $translate are both false. This behaviour is rather unexpected, since kses application isn't controlled directly by either parameter." kawauso Unpatched Bugs 60728 Install/upgrade latest supported version of plugin, when latest version of plugin is not supported Plugins trunk normal normal Future Release defect (bug) new close 2024-03-07T20:49:11Z 2024-03-14T13:38:00Z "== Expected behaviour == When a user finds a plugin to install and the latest version requires a newer version of WordPress, an older version of that plugin which does support the installed version of WordPress is installed. When a user goes to the plugins page to update their plugins, the user is prompted to install newer versions of a plugin which still support the installed version of WordPress. == Actual behaviour == User is presented with an error telling them that the plugin doesn't support their version of WordPress and can't be installed. User is not shown any updates available for plugins where the latest version doesn't support the installed version, even if dozens of newer versions are available which do support it. == Problem == This becomes a particular problem when using something like the Debian packaged version of WordPress (where the version will only be updated every 2 years) when combined with plugins (e.g. Yoast) that, for some reason, keep increasing the minimum version every few months to the latest release. In the above situation, the user upgrades to a newer version of WordPress, but the plugin has already made a new release that requires an even newer version of WordPress. Thus the user doesn't get any notification or easy way to upgrade a plugin which is now several years old and doesn't work with the installed version of WordPress." Dreamsorcerer Slated for Next Release 60783 plugins_api() and parameters audrasjb* Plugins normal normal 6.6 defect (bug) accepted 2024-03-15T13:57:13Z 2024-03-18T04:04:23Z "Hello there, (running WP6.5+, might be useless to say) By reading the doc for `plugins_api()` you can read that some fields are included or not in the response, the doc says ''""$fields: Array of fields which should or should not be returned.""'' and then you have a list of fields, some true some false by default. Let's try it, this is my simple request on my plugin on repo: {{{#!php 'secupress', 'fields' => [] ) ); }}} Since the doc says ''""@type bool $contributors Whether to return the list of contributors. **Default false**.""'' I should not receive this field. Let see the response: {{{#!php string(37) ""SecuPress Free — WordPress Security"" [""slug""]=> string(9) ""secupress"" [""version""]=> string(7) ""2.2.5.1"" [""author""]=> string(44) ""SecuPress"" [""author_profile""]=> string(41) ""https://profiles.wordpress.org/secupress/"" [""contributors""]=> array(4) { ... }}} There is. Same for those params that are ""false"" by default but still included: ""sections"", ""versions"", ""reviews"", ""banners"", ""active_installs"" (I don't know for ""group"", can't get the thing). Also there is one param that is not affected by the arguments passed and always returned: ""num_ratings"". Finally there is some fields that are always returned where the doc can't help, I tried to use they array keys to cancel them, no chance, this is : ""author', ""author_profile"" (those 2 may be forced, that's ok), ""support_threads"", ""support_threads_resolved"", ""upgrade_notice"", and ""requires_plugin"" (I know it's new, but don't forget it) The patch may have to be done on w.org since this is the site that add too much data and to not respect the passed parameters. Thanks for your time" juliobox Slated for Next Release 60495 "Following ""plugins_list"": Add a filter in get_views() in class-wp-plugins-list-table" Plugins 6.3 normal normal 6.6 enhancement new 2024-02-11T23:21:34Z 2024-02-13T12:55:21Z "Since WP 6.3 there is a new filter named ""**plugins_list**"" added in #57278 Using this filter, we can now add a new array key like ""''my_plugins''"" and set some plugins in here. ""''my_plugins''"" is now considered as a ""''status''"" by the WP behavior, like ""''all''"", ""''recently_activated''"", etc, the whole list is here : https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-plugins-list-table.php#L49 We can also delete (unset()) one of them if we want too, (like hide the must-use plugins or the ""''upgraded''"" tab) So now WordPress will go through each iteration of the array keys (aka statuses) and create a tab link to get a new view, here : https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-plugins-list-table.php#L495 **What's the issue here.** WP will try to display a ""text"" for each iteration, if there is no case in the switch, it will still display the $text var, and indeed the last used value, aka incorrect value. But remember line 49, WP sets a list of allowed statuses, this shouldn't be there anymore since the new filter '''plugins_list''' allow us to add ANY status using an array key. We have to remove line 49 and modify line 52 to remove the in_array() stuff. Still need a check to keep the same behavior when a wrong status is loaded? it's already done line 315: https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-plugins-list-table.php#L315 Now to get the correct translated label in get_views() we need a hook line 586 like: {{{#!php (%s)'; break; } }}} Now please test in WP 6.3.x, using this: {{{#!php { const emptySlide = { title: """", description: """", media: { url: """", id: null }, ctaLabel: """", ctaURL: """", backgroundColor: ""#CCC"", }; const newCurrentSlide = slides.length; setAttributes({ slides: [...slides, emptySlide], }); setTimeout(() => { setAttributes( { currentSlide: newCurrentSlide, }, 200 ); }); }; }}} However in the Save function it does not load an empty array the attribute is undefined. To try and solve this I set the slides attribute to an empty array if undefined, as I added objects to the slides array they appeared in the Save function. I then called a array map method on the slides in the returned JSX in the save function which returned some html for each array item. When I loaded the the block on the actual page (not the edit screen) it did not render the mapped JSX html, but the attribute slides does contain the updated array. To see the full code view the repo here : https://github.com/frankastin2023/fa-hero-slider " frankastin2023 Tickets Awaiting Review 53395 Cannot use wp_is_mobile() in Network activated plugins Plugins normal normal Awaiting Review defect (bug) new 2021-06-14T10:31:25Z 2021-06-14T21:56:30Z "Steps to reproduce - Create a network site - Create and activate a simple custom plugin, use wp_is_mobile() function anywhere in that plugin - Login to the network dashboard and then activate the plugin You will see an error: Uncaught Error: Call to undefined function wp_is_mobile() Looking at the source code of wp_is_mobile(), I can't see anything that would prevent it from loading earlier. Maybe it should be loaded earlier? " promz Tickets Awaiting Review 49731 Display embeds in WordPress plugin descriptions Plugins normal normal Awaiting Review defect (bug) new 2020-03-31T03:05:52Z 2020-03-31T04:08:25Z "The WordPress.org plugin directory [https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-plugin-directory.php#L573 supports two shortcode embeds] (specifically `[youtube` and `[vimeo`) and [https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-plugin-directory.php#L1401 several oembed locations]. Most of these embeds appear to return `iframe` elements, which are removed by Core, see [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/plugin-install.php#L533 $plugins_allowedtags]. For example, the Updraft Plus plugin has an embed on the WordPress.org site, but not within the WordPress Add new plugin screen. If you have Jetpack installed, it appears that it converts the `iframe` into a shortcode and displays that instead. This was originally reported as #meta2846, see that ticket for an example of the HTML that's stripped by this behaviour." dd32 Tickets Awaiting Review 43505 Display of html encoded text in dashboard. Plugins normal normal Awaiting Review defect (bug) new 2018-03-08T21:59:56Z 2018-03-08T22:57:45Z "I have discussed the issue in this thread https://make.wordpress.org/polyglots/2018/02/26/hello-18/, I report here the issue of the display of the text in UI, not the editorial choice of the translation itself. In fr_FR and fr_CA, there where changes done (last year?) to accomodate french ponctuation typographic rules but also, I guess, make sure the text doesnt fall on two line inadvertantly (ex. ""text !"", so a non-breaking space is inserted instead of a space). This non-breaking space is inserted as html encoded entity and it looks like it is displayed as is, without decoding like it is visible in this exemple screenshot : https://imgur.com/a/iVy9h " anonym999999 Tickets Awaiting Review 50554 Do not use iframe for plugin information dialog Plugins normal normal Awaiting Review defect (bug) new 2020-07-03T22:38:07Z 2020-10-08T23:11:45Z When you click a plugin title in the Add Plugins page, the plugin information dialog displays inside an iframe. This causes a problem if your htaccess file has X-Frame-Options: DENY. A solution to this problem would be to not use an iframe for the dialog. techboyg5 Tickets Awaiting Review 53384 "External plugins who can auto-update are always listed under ""auto-updates"" disabled" Plugins 5.7.2 normal normal Awaiting Review defect (bug) new 2021-06-11T13:57:21Z 2021-12-10T17:46:55Z "On my site, I have four plugins who can auto-update yet in the plugin screen they are shown under ""auto-updates disabled"". I think it would be better if those come under a list that has the name: ""external updating"" or something of that nature. OR a way for devs to tell WP their plugins can auto update so it doesn't appear on that list...? In it's current implementation, it can give the wrong idea to a site admin. " NekoJonez Tickets Awaiting Review 52443 Extra networkwide param in activate_plugin function Plugins normal normal Awaiting Review defect (bug) new 2021-02-04T08:52:18Z 2021-02-04T08:52:18Z "The issue is an extra $_GET parameter that is added in the `activate_plugin` function. {{{#!php 0 ? intval( $maxlen ) - 6 : 32; $temp_filename = strlen( $temp_filename ) > $max ? substr( $temp_filename, 0, $max ) : $temp_filename; // ... remainder omitted for clarity return $temp_filename; } }}} An alternative would be to require plugin upgrade files to have filenames shorter than [insert recommendation here], though actually checking that would mean a similar chunk of code would need to be added elsewhere in WP. (Not sure exactly where the best place to document this for plugin authors, which could be done immediately.)" rogerlos Tickets Awaiting Review 60448 Iframe from `$errmsg` is now removed from error message in the plugins page Plugins 6.3 normal normal Awaiting Review defect (bug) new 2024-02-06T21:27:23Z 2024-02-14T06:08:56Z "We have a `die` with a message in case of a plugin activation failure here: https://github.com/Automattic/sensei/blob/1933acc544be8a98866bec1b8790a5b195d5b4c7/sensei-lms.php#L65. The message used to work until WordPress 6.3, and it stopped working. I think it was broken with this change: [https://github.com/WordPress/WordPress/commit/768f51f60c308a06492dcda163b80c1c3ff6ebb9#diff-2740240ae408614059218246dd59f4bea9590b6c3f78a2bba71b1afbf8315e7a changeset 56573, wp-admin/plugins.php] The reason seems to be because the iframe is now concatenated in the `$errmsg` variable, which is sent to the `wp_admin_notice`, and later it goes through the `wp_kses_post`, being removed." renathoc Tickets Awaiting Review 52637 "Loading issue with ""popular plugin"" tab - twice the same page." Plugins 5.6.2 normal minor Awaiting Review defect (bug) new 2021-02-24T11:05:41Z 2021-03-10T09:40:04Z "Quite often when I scroll through the ""popular"" section of the plugin page, I get duplicate pages. As in, two pages that are the EXACT same. At the moment of writing, I started at page 1470 out of 1470 and went back using the arrows. Page 1468 and 1469 duplicated. I thought this was a cache issue, so I cleaned my cache... And the problem came back. I thought it was a browser enigne issue so I switched from Opera (Chromium) to Firefox (Gecko) and still found the same issue. On same pages, sadly I can't give an example but I often notice that the first two or three plugins of the list are the same as the last two on the previous page.... " NekoJonez Tickets Awaiting Review 43077 Misleading error when updating plugins Plugins 4.9.1 normal normal Awaiting Review defect (bug) new 2018-01-12T10:22:04Z 2018-09-16T03:45:16Z "Hi, I am in /wp-admin/plugins.php A plugin has a new update and I click ""Update now"". After a few seconds I get ""'''Update Failed: Could not copy file.'''"" However, when I refresh the page and I see that the plugin was updated. After a few tests I realise that if there are Core Translation Updates and they fail(for example due to bad filesystem permissions), you will get the error mentioned above even though the plugin was successfully updated. I would like to comment on two things: a) The translations shouldn't get updated with any plugin update. I might NOT want to update the translations. By doing it in the background without asking me that's bad. b) The error message shown is irrelevant to the plugin update and might cause confusion to some admins who might try to reinstall manually a plugin or do any other changes which might eventually end up breaking a site for nothing. Thanks in advance for your time." SGURYGF Tickets Awaiting Review 42656 Multisite Global $pagenow variable Plugins 5.1 normal normal Awaiting Review defect (bug) reopened 2017-11-22T03:58:15Z 2019-03-22T13:35:45Z "When the site is configured as multisite, plugins are loaded before ""vars.php"", causing plugin getting null value when trying to access the $pagenow variable. Sample Plugin : Brightcove Video Connect Defect : Setting page is empty Caused by : In the setting page logic, it will check whether $pagenow is in the array of 'admin-ajax.php', 'admin.php', 'post-new.php', 'edit.php', 'post.php'. And since the $pagenow is not initialized yet, it will just display an empty page." thorthecoder Tickets Awaiting Review 59413 PHP Warning: Undefined property: stdClass::$plugin Plugins 6.3.1 normal normal Awaiting Review defect (bug) new 2023-09-20T17:17:32Z 2023-10-27T22:06:50Z "Just checking php www-error.log and saw that there was this error: PHP Warning: Undefined property: stdClass::$plugin in /var/www/html/my-website/wp-admin/includes/class-wp-automatic-updater.php on line 228 Site is working as usual but the log is full of these warnings. PHP 8.0.27 Apache 2.4.37 WordPress 6.3.1" zerofoolcoder Tickets Awaiting Review 44696 Plugin Deactivation Page Jump Plugins 4.9.7 normal minor Awaiting Review defect (bug) new 2018-08-01T21:22:58Z 2020-06-22T16:58:18Z "This isn't so much a bug as it is a gripe with the plugin management interface that has long annoyed me. If you have a number of plugins installed and activated: 1. Scroll down the list of plugins 2. Deactivate a plugin near the bottom 3. Page refresh jumps back to top of the list Often, I am deactivating and reactivating plugins for testing or development purposes, or to check for potential conflicts. Having the page jump back to the top after deactivation, then having to scroll down the list of plugins and find the same or similarly named plugin again tends to waste a lot of my time. I think it would be much more convenient to load an anchor link to the deactivated plugin upon the page refresh, rather than sending the user back to the top of the list with every deactivation. Just a suggestion that would help me, and I'm sure many others. Thanks! :D" organicthemes Tickets Awaiting Review 50349 "Plugin Update deletes plugin and showing ""could not delete old plugin"" message." Plugins 6.2 normal normal Awaiting Review defect (bug) new 2020-06-09T16:54:11Z 2023-04-21T14:06:08Z "I just came across this on my local machine (Windows). I had a plugin directory open in vscode editor. I had also previously edited one of the files in that plugin (added {{{error_log}}}s in one of the functions for testing). I may or may not have had same file open with further unsaved changes (I don't know at this point). In the Plugins page I clicked the ""update now"" in the plugin row (directory was still open in vscode). The update resolved with a ""Could not delete old plugin"" error notice. However the plugin was removed and directory is left empty." apedog Tickets Awaiting Review 58214 Plugin authors should not be able to delete tags from SVN repository Plugins normal normal Awaiting Review defect (bug) new 2023-04-28T00:14:26Z 2023-04-28T00:14:46Z On https://developer.wordpress.org/plugins/wordpress-org/how-to-use-subversion/#delete-old-versions it notes that plugin developers may choose to delete from the SVN repository old tagged versions. I think that allowing plugin authors to rewrite history of production releases is a bad thing for WordPress to allow, much less suggest in the docs. The reason is that you may be relying on those older versions in your WordPress installation so a clean build might break without warning. E.g., if you are using wpackagist for dependency managementd, this can happen: https://github.com/outlandishideas/wpackagist/issues/497 . Since tags represent actual production releases (per the first link) WordPress should not allow tags to be deleted from the repository (or any other history to be rewritten for that matter if that's a thing in SVN), going forward. rkaiser0324 Tickets Awaiting Review 41141 Plugin edit: Missed message about making file writeable Plugins normal normal Awaiting Review defect (bug) new 2017-06-23T18:09:08Z 2017-06-23T18:25:28Z "Again, the messages are easy to miss. This may get scooped up in one improving ticket, but worth reporting. [[Image(https://cldup.com/zzF9FEjMvT.png)]] " karmatosed Tickets Awaiting Review 41139 Plugin editing: Should the 'browsing' stand out more? Plugins normal normal Awaiting Review defect (bug) new 2017-06-23T17:56:50Z 2017-06-23T18:25:28Z "This message seems to get lost on the page: [[Image(https://cldup.com/ZKUO4NfdPq.png)]] While we are reviewing this making it not just say 'active' and making the message a bit more relatable could be good. " karmatosed Tickets Awaiting Review 51467 Plugins API endpoint regex breaks javascript parsing. Plugins 5.5 normal normal Awaiting Review defect (bug) new 2020-10-07T12:47:36Z 2021-07-28T13:40:02Z "The plugin endpoint `/wp/v2/plugins/(?P[^.\/]+(?:\/[^.\/]+)?)` added in 5.5 breaks JavaScript parsing of the regular expression. This can be tested by adding the following into the console: `new RegExp(/^[^.\/]+(?:\/[^.\/]+$/);` Which results in: `VM90:1 Uncaught SyntaxError: Invalid regular expression: /^[^.\/]+(?:\/[^.\/]+$/: Unterminated group at :1:1` One of the effects is that the node-wpapi library can no longer autodiscover WordPress endpoints: https://github.com/WP-API/node-wpapi/issues/476" nielsdeblaauw Tickets Awaiting Review 57606 Recently Active instead of Recently Deactivated Plugins 6.1.1 normal major Awaiting Review defect (bug) new 2023-02-02T10:42:48Z 2023-07-09T15:35:23Z "Hello team, Hopefully, you are doing well. I am Afzaal Shamraiz a WordPress developer and a learner. I found on the 6.1.1 version that when I deactivate any plugin, the new filter comes up in the plugin filter menu ""**Recently Active**"", but when I click on it, it displays the list of the recently deactivated plugins, please make this correction. I think it should be ""**Recently Deactivated**"" [[Image(https://ataatravels.com/wp-content/uploads/2023/02/wordpress-bug.png)]]" afzaalshamraiz Tickets Awaiting Review 58291 Speed up WordPress hooks addition/removal by ~20% Plugins 6.3 normal normal Awaiting Review defect (bug) new 2023-05-11T01:02:20Z 2023-06-22T11:54:57Z "I present a patch where `add_filter`/`remove_filter`/`has_filter` are sped up by ~20%. Here's what's changed in the proposed patch: - Calling a static method than a function is faster - check `static-faster.php` for proof - Removed unused arguments, passing less data to the stack - speed should be obvious here - [https://github.com/php/php-src/blob/7c44baa/ext/spl/php_spl.c#L661-L672 spl_object_id] is faster than [https://github.com/php/php-src/blob/7c44baa/ext/spl/php_spl.c#L649-L659 spl_object_hash], as we are not calling [https://github.com/php/php-src/blob/7c44baa/ext/spl/php_spl.c#L674-L677 strpprintf]. - Sometimes `WP_Hook::build_unique_id` will return a string (when concatenated), and sometimes an integer, but this should be okay. - No need to concatenate `'::'` - speed should be obvious here, fewer strings to concatenate - If the argument is an object, return `spl_object_id` right away rather than constructing a pair where the second element is `''` and then concatenate that empty string - speed should be obvious here - Bail early on `add_filter` if `$idx` is null - speed should be obvious here Tested with PHP 8.2.5 by launching `wp shell` a lot of times, after adding `mu-plugin.php` to the `mu-plugins` folder. With the patch applied, several runs average `0.19570341110229492`. Without the patch, the runs average `0.24287629127502441`. Calculating `abs(0.24287629127502441 - 0.19570341110229492)/0.24287629127502441` we get a 19.57% improvement. " bor0 Tickets Awaiting Review 41140 Theme/plugin editing: Long file list goes off page Plugins normal normal Awaiting Review defect (bug) new 2017-06-23T18:01:40Z 2017-06-23T18:25:28Z "If you have a long list of files, the list goes a long way down. Could we paginate? Have a 'scrollbox' (probably bad idea)? Have some better way of showing these? [[Image(https://cldup.com/91gj2sr2jz.png)]] " karmatosed Tickets Awaiting Review 60318 Update URI: false - sometimes not working Plugins normal normal Awaiting Review defect (bug) new 2024-01-22T14:21:01Z 2024-01-22T14:21:01Z "I've recently copied and modified a small plugin from wp-org for my own need. I've set the {{{Update URI: false}}} header. However on the Plugins page, the View Details link still leads to the original plugin and the Enable/Disable auto-updates button link is present. I've changed the main plugin file name to something else, but not the directory name, however the View Details link is still present. I've removed the {{{readme.txt}}} file and that seems to do the trick. To test this, I've then tried restoring the {{{readme.txt}}} file, removed the {{{Update URI: false}}} header and renamed the plugin file to its original wp-org name. The View Details link was NOT restored. However, changing the plugin file name to something new again DID restore the View Details link. The experience has been very inconsistent throughout. I'm running a LocalWP installation on Windows 10. WordPress 6.4.2 PHP 8.2 VSCode editor. This is not a long-term problem for me as I intend to rename the plugin file AND directory name, but thought I'd report this bug for the record." apedog Tickets Awaiting Review 54602 Update bug caused crash and removal of Jetpack Plugins normal major Awaiting Review defect (bug) new 2021-12-09T02:39:27Z 2021-12-09T14:50:31Z "There's a bug in your latest update. The plugin update failed to properly install on my wordpress, and it removed Jetpack from my site. I can't reinstall Jetpack because the system is still reading a destination folder. I know this isn't a support section, but this is a bug issue, so I'm mentioning it here. Please fix the problem, and hopefully, let me know how to reinstall Jetpack correctly on my site, which is: amberdaulton.com Thanks! Amber" amberdaultonauthor Tickets Awaiting Review 49901 Updating plugins error messages for multiple plugins that error Plugins 5.4 normal normal Awaiting Review defect (bug) new 2020-04-14T02:05:08Z 2020-04-14T06:46:37Z "When updating plugins and more than 1 plugin causes an error the first error displays ok, but subsequent errors don't show correctly. They show the first plugin's error message not their own. When I update both plugins separately they both show the correct error message. When I update both plugins together, the first is correct but the second shows the same error message as 1st even its name.... " scole01 Tickets Awaiting Review 45853 Videos embedded in a plugins readme.txt does not load while searching for a plugin in an actual WP install (not wp.org) Plugins 5.0.2 normal normal Awaiting Review defect (bug) new 2019-01-07T16:06:38Z 2022-03-07T15:37:45Z "If you embed a video within your plugins readme.txt file it only shows the video on the wp.org website, videos do not load when you're searching for a plugin via an actual WordPress install. In addition, if you install a plugin and click on ""View Details"" to learn more about the plugin, the video also does not load here either. Inspect element shows an empty span tag: {{{ }}} This should either embed the video or at the least display a link to the video. Here's an example plugin for reference: https://wordpress.org/plugins/simple-icons/" thememason Tickets Awaiting Review 48656 Views details blocked by SAMEORIGIN Plugins 5.3 normal major Awaiting Review defect (bug) new 2019-11-15T19:43:41Z 2019-11-17T17:19:12Z "Hello, On multisite, the ""view detail"" link on this page /wp-admin/plugins.php (in each plugin) is bloked by an error {{{ Chargement refusé par X-Frame-Options : « SAMEORIGIN » à l’adresse « https://example.com/wp-admin/network/plugin-install.php?tab=plugin-information&plugin=loco-translate& », le site ne permet pas l’utilisation de cadres multiorigines depuis « https://example.com/wp-admin/plugins.php ». }}} " sebastienserre Tickets Awaiting Review 49656 WP_Plugins_List_Table: redirects on core row actions when the current view is a custom view Plugins normal normal Awaiting Review defect (bug) new 2020-03-16T18:49:55Z 2020-03-16T18:49:55Z "`WP_Plugins_List_Table::__construct()` sets a global variable to the current value of the `plugin_status` query arg. That global is used in the URLs of the row action links ('activate', 'deactivate', etc) core adds, so that when a user clicks any of those links the user is returned to same view they were on. Like all good list tables, `WP_Plugins_List_Table` allows custom views to be added (with the `views_plugins` and `views_plugins-network` filters). The problem is that the list table constructor sets the global variable to 'all' if `plugin_status` query arg is for a custom one. Hence, when the current view is a custom view, then the core row actions take the user back to 'all', which is a bad UX in that he behavior of core's row actions is different depending on whether the current view is built-in to core or is custom. This came up recently in [https://github.com/audrasjb/wp-autoupdates/issues/49#issuecomment-599068276 an issue] opened against the [https://wordpress.org/plugins/wp-autoupdates/ WordPress Auto-updates] Feature plugin. That specific issue will resolve itself when the feature plugin is merged in core because the `plugin_status` for the 2 views it adds will be added to the whitelist in the constructor. But the problem will still exist for any other plugins that add custom views to that list table. `WP_MS_Themes_List_Table::__construct()` also sets a global that is whitelisted to the statuses that core knows about. However, that is not a problem because it doesn't use that global to add a query arg to the row action links: the redirects on the row actions are handled differently. I think the easiest way to address this would be modify `WP_Plugins_List_Table` (and `wp-admin/plugins.php`) to handle the redirects on core row actions actions the same way that `WP_MS_Themes_List_Table` does." pbiron Tickets Awaiting Review 50850 When the deactivate_plugins() function is called in the ABSPATH/wp-admin/includes/plugin.php file, the is_plugin_active_for_network() conditional tag always returns true when the active_sitewide_plugins sitemeta option is set to 1 Plugins 5.4.2 normal normal Awaiting Review defect (bug) new 2020-08-05T01:28:10Z 2020-09-08T21:11:46Z "On multisite during the process of activating a plugin across the network (sitewide plugin activation), I noticed that if the activation process is not successful or if errors are triggered, the `active_sitewide_plugins' sitemeta option will be set to 1 and this causes the **is_plugin_active_for_network()** conditional tag to return true when called within the **deactivate_plugins** function, which is so untrue. Also, when on the admin or network `plugins.php` screen, the **deactivate_plugins()** function triggers the following error becuase the **$plugins = get_site_option( 'active_sitewide_plugins' )** code doesn't return the correct type (array): {{{ Fatal error: Uncaught Error: Cannot unset string offsets in ABSPATH\wp-admin\includes\plugin.php on line 779 }}} Futhermore, after exploring the error, I found that since the **active_sitewide_plugins** sitemeta option is set to 1 and the **array_keys()** function is used to extract the plugin basenames into a new array and merged with non-sitewide activated plugins, then when used in the **foreach()** loop, this will always return true. {{{#!php name='Order1'; do_action( 'action123', $orders); add_action('action123', 'func123'); function func123($orders){ //$orders will be non-array here (BUG?) } }}} Note: This will run correctly if $orders[] is not object " erikdemarco Tickets Awaiting Review 59408 how to fix below error Plugins 6.3 normal critical Awaiting Review defect (bug) new 2023-09-20T09:02:30Z 2023-09-20T09:02:30Z Fatal error: Uncaught Error: Call to undefined function topdeal_options() in /home/u380733166/domains/books.lk/public_html/wp-content/plugins/sw_woocommerce/includes/sw-woocommerce-shortcodes.php:960 Stack trace: #0 /home/u380733166/domains/books.lk/public_html/wp-includes/class-wp-hook.php(310): topdeal_buton('') #1 /home/u380733166/domains/books.lk/public_html/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters(NULL, Array) #2 /home/u380733166/domains/books.lk/public_html/wp-includes/plugin.php(517): WP_Hook->do_action(Array) #3 /home/u380733166/domains/books.lk/public_html/wp-includes/general-template.php(3069): do_action('wp_footer') #4 /home/u380733166/domains/books.lk/public_html/wp-includes/template-canvas.php(25): wp_footer() #5 /home/u380733166/domains/books.lk/public_html/wp-includes/template-loader.php(106): include('/home/u38073316...') #6 /home/u380733166/domains/books.lk/public_html/wp-blog-header.php(19): require_once('/home/u38073316...') #7 /home/u380733166/domains/books.lk/public_html/index.php(17 in /home/u380733166/domains/books.lk/public_html/wp-content/plugins/sw_woocommerce/includes/sw-woocommerce-shortcodes.php on line 960 nirmal1985 Tickets Awaiting Review 60373 plugin activation errors are accidentally hidden Plugins normal normal Awaiting Review defect (bug) new 2024-01-29T15:25:08Z 2024-01-29T15:25:08Z "in recent versions (can't tell exactly when) seems the admin_notice messages were being filtered by wp_kses_post, which caused breaking changes, which contradicts WP core itself. to reproduce, add this to plugin: {{{#!php register_activation_hook(__FILE__, function($x){ die('plugin can not activate, because XYZ'); } ); }}} then try to activate. it will show admin notice `Plugin could not be activated because it triggered a fatal error` and nothing more. however, it should have shown that XYZ message inside iframe, you can confirm that by looking : https://core.trac.wordpress.org/browser/tags/6.4.2/src/wp-admin/plugins.php#L685 (if you do `var_dump($errmsg)` before that `wp_admin_notice` line, you will see that iframe part is also included in `$errmsg`) however, inside `wp_admin_notice` there is `wp_kses_post` which filters out the `iframe` that was added by core itself: https://core.trac.wordpress.org/browser/tags/6.4.2/src/wp-includes/functions.php#L8891 so, that is contradiction in WP, and should be solved either way. I understand that stripping `iframe` might have been a security step, however, it was done incorrectly. that wp_kses_post should allow iframe, but itself the XYZ message itself (coming from plugin's activation) should be filtered, so that would achieve the security goal. at this moment, that change/misbehavior (which we noticed too late) have broken dozens of our plugins on wp.org. please fix it." ttodua Tickets Awaiting Review 55101 pre_set_site_transient_update_plugins was called from deactivated plugin while uninstall. Plugins 5.9 normal normal Awaiting Review defect (bug) new 2022-02-07T08:59:01Z 2022-02-13T12:45:42Z "I have this sample plugin. {{{#!php hooks(); } static public function uninstall() { error_log('uninstall method was called on ' . date('Y-m-d H:i:s')); } } $ATest = new \ATest(); $ATest->run(); }}} When I click on delete plugin (the plugin is already deactivated), the `pre_set_site_transient_update_plugins` hook was called. To reproduce. 1. Copy and paste the sample code above to new plugin file. For example test.php 2. Go to your WordPress > admin > plugins. 3. Activate this plugin. 4. Go to your DB, delete `_site_transient_update_plugins` option name in `options` table to make sure that this hook will be call next time. 5. Reload admin plugins page. This hook will be called as normal process because plugin is activated. The error log will be write to **wp-contents/debug.log** file. 6. Deactive this plugin. 7. Maybe try to reload plugins admin page again. The hook will not called from this plugin, no error log were write. This is correct. 8. Click on delete this plugin. 9. The error log were write because this hook is called while it is on uninstall process. This is incorrect!! It should not be called. WordPress 6.0-alpha-52682" okvee Tickets Awaiting Review 45779 probable issue in Plugin activation hook Plugins normal normal Awaiting Review defect (bug) new 2018-12-27T13:38:13Z 2019-01-07T00:17:08Z "i.e. if we have a simplest plugin: {{{ doing_action = true; $this->apply_filters( '', $args ); ... }}} [https://core.trac.wordpress.org/browser/tags/5.8.3/src/wp-includes/plugin.php#L590 In plugin.php] we see `doing_action` (implemented in v3.9.0) just wraps/returns `doing_filter`. {{{#!php function doing_action( $hook_name = null ) { return doing_filter( $hook_name ); } }}} The doing_filter function just tells us if we are processing a hook - it does not look into the hook to determine what kind of hook it is, action or filter. In short, this specific code just hasn't been enhanced yet in-line with WP_Hook. {{{#!php function doing_filter( $hook_name = null ) { global $wp_current_filter; if ( null === $hook_name ) { return ! empty( $wp_current_filter ); } return in_array( $hook_name, $wp_current_filter, true ); } }}} ---- **Proposed Enhancement Implementation !#1** While I'm a newcomer to WP internals I believe it would be more accurate to do something like this: {{{#!php function doing_filter( $hook_name = null ) { global $wp_filter, $wp_current_filter; if ( null === $hook_name ) { if(empty( $wp_current_filter )) { return false; } return $wp_filter[current_filter()]->isFilter(); } if($hook_name == current_filter()) { return $wp_filter[$hook_name]->isFilter(); } } }}} In WP_Hook, add the getter `isFilter()` to return the opposite value of $doing_action. Add another getter, `isAction()` that simply returns $doing_action. This encapsulation eliminates all confusion outside of WP_Hook about how it works. The `doing_action` function cannot simply negate the value from `doing_filter`. If $wp_current_filter is empty, both functions might return false. The new code for `doing_action` needs to be like `doing_filter`, but returning the value of isAction() for the `current_filter()`. To avoid breaking legacy code, perhaps new functions should be created, and the 'doing' functions can get a long-term deprecation. - executing_action - executing_filter - executing_hook The new executing_hook function should return the OR of executing_action() with executing_filter() - this is what developers should use to replace the current functions for code that doesn't actually care what kind of hook is being processed. (Also consider the prefix 'processing_'.) ---- **Proposed Enhancement Implementation !#2** Another way to implement this would be to add a second parameter to the existing functions, essentially a Boolean to invoke higher accuracy, with a default of false. Then the new functions above can be internal, there's no API change, no deprecation, etc. ---- **Bug or Feature?** I suggest this is an enhancement to address a v4.7 oversight. As noted above, this isn't a bug, since internally an action **is** a filter, so the result of `doing_action` is technically valid when a __filter__ is active. This enhancement can be stated as an introduction of more nuanced functionality, where the current functions are essentially synonymous with a less refined ""doing_hook"". Thanks for consideration." Starbuck Tickets Awaiting Review 16838 Excluding Akismet from Future WordPress Releases / Plugin Directory Plugins 3.1 normal normal Awaiting Review enhancement reopened 2011-03-12T02:49:31Z 2024-03-02T21:23:45Z "This issue was more mute prior to the shift in Akismet's 'keying', which previously just required you to have a free WP.com account to hook up to the API. Since Akismet now charges for access, or solicits fees by default for Personal website activations (when you go through the sign up process, it defaults at something like $5 with a slider that lets the person choose how much they want to pay). It's not immediately apparent that 'free' is an option within the slider, but that's not the primary issue here - I digress :) The issue is that Akismet is no longer free for EVERYONE. It's only an option for Personal sites, and in certain cases. What if someone has multiple personal sites? They click that option and they are categorized into a Professional plan, which has a fee associated to it. Since the plugin directory itself has officially been described (and in practice) to have a restriction that explicitly prohibits functionality be disabled from a plugin behind a Paywall, why wouldn't that apply in this case? I certainly don't mean to rock the boat, but this brings up a number of important questions. The plugin has a potentially confusing signup process that does lead people otherwise categorized as Personal site owners, to pay for the service while it's advertised under the plugin description that it's 'free' for Personal use. This produces a grey area of sorts, which puts this plugin under a sort of Paywall, which could be alleviated in a minor way by modifying the signup process. It still doesn't clear the air on how the Paywall for professional sites can be officially allowed versus a full Paywall. Perhaps someone who officially represents the WP.org Plugin Directory or WP.org can clarify the undocumented (not shown at http://wordpress.org/extend/plugins/about/) Paywall restriction for future reference. Besides the plugin itself now finding itself in this grey area, it's bundled with WordPress by default and presents what could be described as an unfair market advantage for Automattic's product offering, sort of like anti-competitive business practices. I feel weird saying that, but I'm not throwing stones here. Just saying what it feels like, even if the core developers say it should be included, I'd say it now doesn't cover the 70/30 rule (or whatever the amount is). If Akismet is allowed to remain in the plugin directory as is, and within WP core, then would other plugins be allowed to be included in the plugin directory that follow the same Paywall model and signup process?" sc0ttkclark Tickets Awaiting Review 46763 Improve plugin search results with already active plugins Plugins normal normal Awaiting Review enhancement new 2019-04-02T10:52:13Z 2022-11-02T14:05:37Z "Currently if you search for a plugin to do X, and X is something that a plugin you already have matches for, this is what you get: https://cloudup.com/c0GYNTynpF4 The disabled ""Active"" button there is not very useful, as it doesn't provide any context as to why that button is disabled. I'd like to propose a change: let's turn this into two separate groups of results, one that says ""these plugins you already have installed might be able to help"" and then a second group below that with other plugins. In my ideal world, we'd even have an ""admin search"" function, where you could be taken straight to the appropriate page for that keyword. This could be useful even for WordPress core, so I'm splitting that out into a second issue: #46764." joostdevalk Tickets Awaiting Review 43276 Install Progress Button Cover Name of Plugin Plugins 4.9.4 normal normal Awaiting Review enhancement new 2018-02-10T06:57:51Z 2019-02-04T18:12:05Z "Can we, find other position to avoid this visual error? " Marius84 Tickets Awaiting Review 37677 Introduce WP_Plugin class analogous to WP_Theme Plugins normal normal Awaiting Review enhancement new 2016-08-16T15:50:59Z 2017-05-04T19:30:55Z "Background: This ticket emerged from #37656. A `WP_Plugin` class has been previously mentioned in #22256 and brought up with a patch in #21883, but only in regards of hooks and filters (i.e. `$GLOBALS['wp_global_hooks'] = new WP_Plugin();`. With #17817 in contention, that approach would need some more tweaking. Also, the class name isn't ideal too because of `WP_Theme`. Using `WP_Plugin` for hooks but themes can use hooks too? Confusing. Proposal: Introducing a new `WP_Plugin` class that does similar things as the already existing `WP_Theme` class but for plugins. This would mainly mean handling caching, retrieving data from plugin file headers and adding any needed helper methods. As a result, we're less prone to errors since we can use 1 reliable API instead of `get_plugin_data()`, `get_plugins()`, etc." swissspidy Tickets Awaiting Review 43882 Introduce slug-specific hooks to manage plugin loading order Plugins normal normal Awaiting Review enhancement new 2018-04-27T16:48:35Z 2019-01-24T06:55:42Z "As already discussed in #41346, I'd like to propose a simple mechanism that can solve the loading order problems that inter-dependent plugins can have. The main mechanism just adds an action that is named after the plugin that was just loaded. In this way, other plugins are able to initiate actions based on when another plugin was loaded. A similar mechanism has been used in WP-CLI to solve the problems in the loading order of commands that rely on each other. You can read more about how commands can control their loading order here: https://make.wordpress.org/cli/2017/05/03/managing-command-dependencies/ Furthermore, this also allows for a small extension that can automatically resolve loading order, provided it knows about the dependency to look for. This is used in WP-CLI as well, where it is easy to deduce the parent command to look for, as described here: https://make.wordpress.org/cli/2017/05/31/command-dependencies-revisited/. For plugins, this could be solved by adding a simple plugin slug to the plugin header. I'll introduce a separate ticket to that regard. I will upload a patch that adds the above-mentioned action, together with `pre_plugin_loaded` and `post_plugin_loaded` actions that give further control to plugins. In case anyone wonders whether that might open the door to abuse and have plugins block loading of other plugins: that is already easily possible right now. A plugin can just remove whatever plugins it dislikes from the list of active plugins on activation hook." schlessera Tickets Awaiting Review 55107 List and Delete button to delete broken plugins Plugins normal normal Awaiting Review enhancement new 2022-02-07T21:53:35Z 2022-02-08T10:28:19Z "Much like we have for themes, there should be a list of broken plugins with an option to delete them directly from the admin panel. Along the lines of this ticket ( #28165 ) but for plugins." gmariani405 Tickets Awaiting Review 53132 MU/Network > Plugins: plugins (only) activated in subsite could be marked as such Plugins normal minor Awaiting Review enhancement new 2021-05-02T08:46:27Z 2022-02-26T15:56:13Z "This is a suggestion/request: In a multisite setup I have plugins which are not network-activated, but activated on a subsite. They are, correctly I suppose, listed as “inactive” in the Network > Plugins table. Plugins listed there have two actions “Network Activate” and “Delete”. The later is what brought me here. I can delete a plugin a subsite relies on without additional warning. Would it be feasible to either: 1. add a third action “Deactivate on subsites” while the network-deactivated plugin is still activated somewhere further down and have “Delete” disabled until the new action has been triggered or 2. have a new column above the table “All” “Active (network)” “Active (subsites)” … and plugins in “Active (subsites)” have “Network Activate” and “Deactivate on subsites” " retrovertigo Tickets Awaiting Review 53628 Maintenance Free Updates - Zero downtime Plugins 5.8 normal normal Awaiting Review enhancement new 2021-07-08T17:23:07Z 2022-03-18T16:21:51Z "I have been testing an approach to allow updates to be deployed to themes and plugins with Zero downtime (no maintenance page needed). It seems that WP if fairly sympathetic to the approach and I am keen to see if there are any red flags - and also the opportunity to get the approach into core so the world can benefit from it if! The approach is as follows: - When a plugin update is available - install the plugin into a directory that is namespaced with the plugin name AND version (as per the meta) e.g. /wp-content/plugins/plugin-v1.3.2 At this point WP will see two instances of the plugin - but it treats them as unique and the initial plugin remains active - Activate the plugin - via a database update - modify the wp_options row to set the new plugin to be active. It is critical that this is done as a database update - so that it is an atomic action - allowing WP to continue to process requests as the switch over takes place. The old plugin can remain in place to support roll back and then deleted Rollback is simply a question of restoring the active plugins options field back to the original settings Pros / Cons - I have tested this manually and WP seems happy - both locally and on hosted environments. As far as WP seems to be concerned it is seeing a new plugin. - As the plugin directory is now namespaced - all assets in it e.g. css /js will also be cache busted ensuring all assets in your release are updated. - WP does not currently have a plugin updated event - the activation of the new plugin will simply go live. - A ""pre flight"" step could be run on plugin update to check the plugin is well formed and no PHP errors exist - ensuring that it is not possible to activate a faulty plugin - We have also seen that with our automated plugin updater - it still works to deploy the new plugin as the location of the plugin deployed in a zip unpacks into a new directory. We are looking to build a WP_CLI plugin to deal with the activation - it works with plugin active / plugin deactivate - but this is not atomic so there would be a period of time where the plugin would be missing so we are replacing it with a transaction. I am very keen to get feedback on this approach - as we are going to start using it on our sites. " billybigpotatoes Tickets Awaiting Review 45804 Make WP_Hook gather callback performance information Plugins normal normal Awaiting Review enhancement new 2019-01-01T09:46:09Z 2019-09-23T19:14:00Z "The Hook API represents one of the most interesting parts of core from performance point of view. It is both widely used and implementation is in userland code, as opposed to language features (such as standalone function calls). However as of current implementation (`WP_Hook` class) it is a huge challenge to gather profiling information from it in safe and compatible way. Class itself is `final` and instances cannot be effectively replaced. Injecting custom logic at `all` hook and reimplementing hook execution in extension code is possible, but risky. I suggest we implement `WP_Hook` natively logging origin and duration times for executed callbacks. The information can be added to callback record which is in public access space and will not cause any backwards incompatible changes. My draft suggestion would be something like this (notably to account for multiple executions of hook/callback): {{{ [ 'function' => ... 'accepted_args' => ... 'runs' => [ [ 'start' => ..., 'duration' => ... ], [ 'start' => ..., 'duration' => ... ], [ 'start' => ..., 'duration' => ... ], ] ] }}} Main concern would be resource cost, with sites possibly calling tens of thousands of hooks. I think resource overhead should be reasonable with only adding two floats to array and no complex calls or calculations. This can be tested and profiled on a proof of concept implementation. The possible mitigation to runtime costs can be making the feature opt–in with flag analogous to `SAVEQUERIES`, for example `SAVE_HOOK_TIME`. The possible mitigation to memory costs can be implementing cut off limit to amount of timings stored, e.g. start discarding old records when a certain limit of X records is reached for a callback. If there is agreement on feasibility I will work on a patch." Rarst Tickets Awaiting Review 55449 "More filter options for searching theme's & plugins - ""Last updated"" / ""Test with my WP version""." Plugins normal normal Awaiting Review enhancement new 2022-03-23T11:30:36Z 2022-03-23T11:30:36Z "When I'm looking in WP to install a new theme/plugin I find it quite annoying that I'm unable to filter my search results a bit more. When I'm looking for a new plugin for a certain goal, I would love to filter on two things. 1) If the plugin is tested or not (and working) on my current WP version. 2) If the plugin got a recent update. (Maybe this might be a setting the user can choose. Since, for some is recent 1 year and for others it's 1 month.) I think these filter options, with maybe checkmarks ...? could fit nicely on where I placed green in the attached screenshot. " NekoJonez Tickets Awaiting Review 39414 New param in plugin_dir_path Plugins normal normal Awaiting Review enhancement new 2016-12-28T09:02:45Z 2019-03-15T01:17:40Z "New param - `path`. Function with this param return full path to file. Examples: {{{#!php Upload -> Replace existing, the registered activation hook function appears not to be called. This may lead to unwanted behaviour when the activation function calls dbDelta(). The request is to run the activation hook function in this case, making this way to install a dfifferent version functionally equivalent to the regular update procedure." opajaap Tickets Awaiting Review 58037 Use a placeholder icon when an icon is unable to load/be found in the plugin directory Plugins normal minor Awaiting Review enhancement new 2023-04-01T10:23:24Z 2023-04-02T15:48:16Z "Like shown in the screenshot, sometimes when going through the plugin directory in your WP install... for some reason a plugin icon is unable to load since there isn't one/it's missing/it's too big/blocked by AV/... In that case, it would be nice that some placeholder art is shown like the WP logo or the one in ""second screen"". " NekoJonez Tickets Awaiting Review 40156 Warning for invalid hook callback is not very useful Plugins 0.71 normal normal Awaiting Review enhancement new 2017-03-14T23:07:39Z 2017-03-15T08:38:54Z "If you add a hook with an uncallable callback, an error like `Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'not_a_function' not found or invalid function name in` is shown. This is technically correct, but not useful. When I say useful, I don't think it is useful to the following user profiles: 1) Non-technical user seeing errors. A non-developer might no what a WordPress hook is, but not how it works internally. Therefore they are not likely to understand this error is related to a hook. They are not given good information, and might be missing a clue as to who to ask for support (plugin or theme developer, host, etc.) 2) New developer. A developer new to WordPress might not understand yet what a hook is or that a missing callback generates this type of error. A more clear error will help guide their googling for the error and/ or help them find the issue in the code. 3) Experienced WordPress developer. When I see this error, I assume there is a non-callabale hook callback. But `call_user_func()` has other uses so it might be misleading to me. I think it would be way more helpful if the error triggered was something like `Hook $hook_name could not call $callback` or `The callback function $hook, registered for $hook_name is not callabale` " Shelob9 Tickets Awaiting Review 53385 "When adding a plugin/theme via ""add new plugin/theme"" it should show if the plugin/theme is translated or not" Plugins 5.7.2 normal normal Awaiting Review enhancement new 2021-06-11T14:08:02Z 2021-09-27T14:18:56Z "When you add a new plugin via the plugin menu and click on ""Add new plugin"" it should show if that plugin is translated to the site language. Eg: show the flag or something of that nature with a checkmark or a cross...? Of course, you could argue that if the explanation/plugin name is translated the translation is ""done"" but as a polygot for nl_BE and nl_NL myself, I can say that isn't the case. Since we have a TON of plugins where the readme isn't translated and even visa versa. " NekoJonez Tickets Awaiting Review 39772 add ajax functionality to switching tabs and pagination in plugins Plugins 4.8 normal normal Awaiting Review enhancement new 2017-02-02T22:06:48Z 2017-02-02T22:06:48Z Since we have the cool ajax search plugin functionality, maybe we add the ajax for the tabs on the add plugin page as same as with the pagination of the results. m1tk00 Tickets Awaiting Review 54978 recreate response plugins_api Plugins 5.8.3 normal minor Awaiting Review enhancement new 2022-01-28T15:13:58Z 2022-01-28T20:17:02Z "recreate plugins_api response using plugin_information to load a custom list of plugin install since query_plugins does not get a custom list of plugins, for example send a list of plugins to display and not as a general query like list of recommended plugins in file: \wordpress\wp-admin\includes\class-wp-plugin-install-list-table.php [[Image(https://user-images.githubusercontent.com/37667605/151275086-0027172d-6948-4602-b924-1071831dfa63.png)]]" hhklik Tickets Awaiting Review 50560 "show ""recently deleted"" plugins - a safer option than ""inactive plugins""" Plugins normal normal Awaiting Review enhancement new 2020-07-04T17:58:54Z 2020-07-07T15:28:57Z "== **The REQUEST:** **Please show recently removed plugins within /wp-admin/plugins.php** == **The STORY:** You may notice the title is unfamiliar to you because such a thing does NOT exist within wordpress. One of the reasons why people like me **do NOT remove inactive plugins** is because there is no way to remember the plugin once deleted. So i keep it. Now, even ""Site Health Status"" shows **""remove inactive plugins"" for security reasons**. [[Image(https://i.imgur.com/TuF1roA.jpg)]] If i do that, i will have to **take notes manually** and links of that awesome file manager or image compressor plugin i found and want to keep. Wordpress does NOT show the plugins that were used in the past (deleted). Now, **if wordpress WOULD show**, i would not have to keep it inactive in order to ""keep"" it to remember, because i might not use the plugin all the time, such as a file manager or image compressor plugin, hence the reason for inactivation because they are seldomly used, BUT if i delete it, i would have to go on a search to find it again. == **The SOLUTION:** (Here is a way how wordpress would make it more delightful for users to delete inactive plugins).. Simply show the recently removed plugins with the **NAME** and **URL** to the plugin itself as a simple line within **/wp-admin/plugins.php** somewhere. [[Image(https://i.imgur.com/rviZF3w.jpg)]] This way i will gladly delete the plugin right away and not keep it inactive, the settings of the plugin is obviously an entire different story." mikulabc Tickets Awaiting Review 52048 the functions activate_plugin and deactivate_plugin need validation Plugins 3.0 normal normal Awaiting Review enhancement assigned 2020-12-12T18:00:07Z 2020-12-30T22:25:02Z "The function activate_plugin https://core.trac.wordpress.org/browser/tags/5.6/src/wp-admin/includes/plugin.php#L633 would need the validation of the array of plugins before saving it. For normal installations, the current plugins are taken by $current = get_option( 'active_plugins', array() ); For multisites they are taken by: get_site_option( 'active_sitewide_plugins', array() ); Both the result of get_option( 'active_plugins', array() ) and get_site_option( 'active_sitewide_plugins', array() ) can be filtered by plugins, so you can't know if $current is a valid array of plugins. At least, $current should be unique, so I would add $current = array_unique( $current ); Then I would also check if the plugin files exist before saving the array of active plugins. I would do the same validation for the function deactivate_plugins https://core.trac.wordpress.org/browser/tags/5.6/src/wp-admin/includes/plugin.php#L633" giuse Tickets Awaiting Review 60507 Add a view for plugins with missing dependencies Plugins normal normal Awaiting Review feature request new 2024-02-12T14:39:07Z 2024-02-13T23:34:47Z "Instead of directing the user to review their plugins or look for plugins that cannot be activated, it would be really useful to have a filter (similar to Active, Update Available, etc.) that can be linked to. Maybe ""Missing Requirements"" or ""Unmet Requirements"". I don't love either of those names, but I prefer those over ""Missing Dependencies"" or ""Unmet Dependencies""." desrosj Tickets Awaiting Review 48486 Add compliance tab to plugin repository pages on WordPress.org Plugins 5.3 normal normal Awaiting Review feature request new 2019-11-03T18:46:36Z 2022-01-14T16:01:25Z "== Overview ""Compliance tab"" is a working title that can be amended to be less intimidating and/or more generalized. The benefit of this tab is to provide WordPress site owners who are researching plugins with privacy, accessibility, and other information to determine if this plugin will meet their site needs prior to installation and activation. Ideally, this information can also be used in search and filter scenarios on WordPress.org to find tools compatible with the needs of site owners. == Privacy A privacy statement could include testing done against specific regulatory standards, and a statement of where data is transferred and stored at rest. It should also include any statements that need to be added to a site owner's privacy policy as part of using this plugin. This could potentially leverage the privacy policy post box information currently available under ''Settings > Privacy'', added in WordPress 4.9.6. == Accessibility An accessibility statement could include the WCAG level that the plugin targets (A, AA, etc) and where to file any issues found. == Security A security statement should include code standards followed, measures taken, and who to contact if you find a vulnerability. == Certifications Any certifications that this plugin has undergone for compliance." katwhite Tickets Awaiting Review 44073 Add functionality to search plugin with double quoted keyword Plugins normal normal Awaiting Review feature request new 2018-05-14T14:22:42Z 2018-05-23T14:24:28Z "Is this possible to add a feature where plugins could be searched on `Add New Plugin` page either with: - More than one keyword wrapped inside double quotes. Example: ""my plugin"" OR - Add a filter like **Match Whole Phrase** (in existing filter dropdown) In either case, it would be much easier to locate the desired plugin as the result will become more filtered and less items would appear on screen. This can avoid scrolling through ""relevant results""." subrataemfluence Tickets Awaiting Review 57064 "Add individual ""Support"" links to the plugin list page / theme page" Plugins normal normal Awaiting Review feature request new 2022-11-10T15:23:38Z 2022-11-10T22:27:58Z "Finding context-relevant support can be challenging for new users and many of them are not aware of the fact that each plugin has its own support forum. One simple way to bridge this gap could be to include a ""Support"" link underneath the plugin description. This link would take to that plugin's forum." mrfoxtalbot Tickets Awaiting Review 51731 Add the reason for deactivation to the 'deactivate_plugin' hook. Plugins normal normal Awaiting Review feature request new 2020-11-09T14:28:12Z 2020-11-09T14:38:20Z To be able to check if a plugins was disabled by a user action or because of the 'validate_active_plugins' check that is done on when visiting the plugins.php page would be great from a management perspective. Many WordPress installations have some required plugins which are not necessary for the site to work but do need to be active for one reason or another. This enables the option to notify the admin when a plugin gets disabled by accident because of a failed updated or any other reason. merlijnvanlent Tickets Awaiting Review 40460 Add-On Grouping for Plugin List Screen Plugins normal normal Awaiting Review feature request new 2017-04-15T16:25:17Z 2017-04-15T16:25:17Z "I'd like to see if anyone has thoughts on (or has previously discussed) reworking the plugins API & plugins list screen to group ""child"" or ""add-on"" plugins under their required parent plugin. There are obviously some API implications that go along with this. It seems pretty common now for a well-rounded base plugin, premium or free, to develop a handful of add-ons that require the base functionality of the main plugin and provide no meaningful value on their own. These ""child"" plugins can be from the same developer as the parent, or from a 3rd party community that wants to extend the usefulness of the parent plugin. Because WordPress plugins have no concept of relationships between one another, several less-than-ideal scenarios can occur. Firstly, an add-on plugin can be activated while the parent plugin is not active or even present. Without it being expressed in the title or description, there's nothing to necessarily tell a user that another plugin is required for the one they're installing to function. In the best case scenario, the add-on plugin developer has put safe guards to check for the parent plugin into their code, and will write a message out to the user upon activation to tell them why there's an issue. In the worst case scenario, the developer simply assumed that they parent plugin would exist, did no checks for the availability of the base code, and WordPress encounters a fatal error. Now dependency management is a broad and weighty topic and I do not believe that a full-blown dependency system is what I am proposing here. We do already have a pattern for how to express a basic requirement in the existing parent + child theming system. A child theme expresses that it requires the parent theme with the template attribute and appropriate handling takes place upon it's activation. I think plugins could potentially take the same form. [[Image(https://raw.githubusercontent.com/brentjett/WP-Core-Add-On-Plugins-Proposal/master/plugin-declaration-with-template.png)]] A plugin declares that it requires it's base plugin to function with a ""Template"" (or Parent, Required, etc...), and the system handles including it at the proper time, or not at all depending on the base plugin's existence. The UI benefits from this by grouping these add-on plugins with their associated parent plugin so there is a visual understanding of that relationship. This serves to organize the plugin list in a friendlier way, regardless of what a plugin my be named. [[Image(https://raw.githubusercontent.com/brentjett/WP-Core-Add-On-Plugins-Proposal/master/plugin-screen-addon-groups.jpg)]] There's plenty of complexity to work out both in the UI and API design for this to be a nice addition to the platform. The plugin list should end up more clear and easy to read, not more cluttered and disjointed in the end. I'd love to hear thoughts! Thanks for taking the time." brentjett@… Tickets Awaiting Review 41627 Additional parameter for multisite activation Plugins 4.8.1 normal normal Awaiting Review feature request new 2017-08-13T13:42:15Z 2017-08-13T18:00:53Z "It could be good, if there was something additional parameter, which made 'register_activation_hook' function to be executed per individual sub-sites, while activating it from Network dashboard. that is good, because i.e. in activation hook, we want sometimes to create tables, add options ( and etc) per each sub-site." tazotodua Tickets Awaiting Review 49626 Allow plugin developers to opt-out their plugin from auto updates Plugins normal normal Awaiting Review feature request new 2020-03-12T01:36:43Z 2020-07-06T12:56:31Z "I would like to request a filter for plugin developers to be able to opt their plugin out from the automatic updates completely. For example in {{{wp_autoupdates_add_plugins_autoupdates_column_content}}} we could add something like {{{#!php if this is high, it must be a quite good plugin, otherwise not so many websites would use it - in plugin repository since -> plugin can be fairly new and therefore not yet have a high number of active installs - last updated -> to filter out plugins that are not regularly updated - rating I also would like to see that 'last updated' would be added to the info for a single plugin search result (where now only the number of active installs, developer and 'tested with' is displayed), so you can see right away if a plugin is well maintained or not. I would also suggest that plugins which have not been updated or maintained at all for over a year will be marked; for example with a traffic light: orange for 'updated more than a year ago', red for 'updated more than two years ago' (and off course green for 'updated less than a year ago'). I think the least plugin writers can do is test their plugin for compatibility with each new WP version and update this information if the plugin still works fine. Maybe make this mandatory if you want your plugin to be included in the plugin reporitory? I hope this will also encourage all plugin writers to maintain their plugins better. My goal is to separate the plugins of good quality and high developer dedication from the plugins that are less well maintained. And make this visible to users. I'm looking forward to a response from the core developers community. Thanks!" prodefu Tickets Awaiting Review 38743 Introduce add_action_once() Plugins normal normal Awaiting Review feature request new 2016-11-10T10:26:25Z 2018-03-23T20:04:13Z "Hi there. I was wondering if noone ever needed to add a callback to some action or filter hook only if it hasn't been added (potentially by someone else) before. Possible use cases are: * only add `my_callback` if it hasn't been added before, no matter with what priority; * only add `my_callback` if it hasn't been added before with a specific priority. Naming-wise, I'd suggest `add_action_once()` and `add_filter_once()`, respetively, although one could be more verbose (e.g., `add_action_if_not_exists()` etc.). Here is a possible implementation of this: {{{#!php The Plugin Block Directory is a new feature coming in WordPress 5.5 that allows specially-written Block Plugins to be instantly and seamlessly installed in the editor, without ever leaving the page. -- https://make.wordpress.org/plugins/2020/07/11/you-can-now-add-your-own-plugins-to-the-block-directory/ WordPress 5.5 will make it easier for folks to install block plugins, as they edit their posts and pages. As a result, and as the block directory becomes more and more popular, I assume the average number of plugins installed on a WordPress site will increase. On the Plugins screen UI we know, we'll see a mix of ""regular"" plugins as well as block plugins. I wonder if we should consider making some changes to the Plugins Screen UI to clearly separate the 2 plugin types. - This would help site owners quickly skim through their plugin list. - It would help them understand how a specific plugin was added to the site. - It may help them manage their plugin autoupdates (one could imagine a scenario where you'd want block plugins, including little PHP, to be automatically updated while ""regular"" plugins would require a manual update)." jeherve Tickets Awaiting Review 40651 Plugins: Make it easier to find plugin settings after install Plugins normal normal Awaiting Review feature request new 2017-05-03T18:24:19Z 2017-05-04T14:01:14Z "After installing new plugins, I invariably end up spending time hunting down wherever I need to configure or use it. Some plugins add a ""Settings"" link to their plugin card (very useful!) but this isn't always the case. It would be great to find a way to direct people to the settings screens upon activation. " melchoyce Tickets Awaiting Review 48190 Show information from Plugins Directory into WP-Admin plugins page Plugins normal normal Awaiting Review feature request new 2019-10-01T08:33:45Z 2019-10-04T08:51:39Z "Hello everyone, This is my first ticket/suggestion here. First of all, hope this is not a duplicate request. Recently one of the websites my company has been maintained got hacked: https://www.wordfence.com/blog/2019/09/rich-reviews-plugin-vulnerability-exploited-in-the-wild/ Issue was on the Rich Review plugin. The root cause of the problem was that we had installed on that website (was a theme requirement) the Rich Review plugins. We kept up to date all the plugins, WP core itself and themes on that websites and still the website got hacked. The general guideline to keep your WordPress website safe is update everything. In this case though it failed. It failed because we did not know that the Rich Review plugin was abandoned. On plugin directory it clearly tells that the plugin has been closed for security reasons: https://wordpress.org/plugins/rich-reviews/ So my question, request is, can it be made that we show this kind of information right away on the plugins list? To improve it even further, show a WordPress notice on wp-admin when an administrater logins and he can directly see that plugin X has been abandoned or has been closed. Thank you, Arber." arberbr Tickets Awaiting Review 42981 Sorting plugins and themes Plugins 4.9.1 normal normal Awaiting Review feature request new 2017-12-26T09:09:56Z 2019-04-02T18:51:39Z "PLEASE - Sort themes and plugins into : Premium Fremium / Cripple ware Free and fully functional Not as described in the image (Pretty picture, preview looks nothing like it = Hours of work to make it look like the demo. I'd write a theme if I wanted the work) Anything not updated in the last 12 months - ""Abandoned"" pile, not visible Anything with ratings - Sort by rating - Under 3 - not visible Not tested on latest WP version - not visible Not tested on PhP 7 - not visible Speed test rating - Google wants a 2 second load time for mobile. Let's have an apples for apples rating. 5 pages, 10 images, 1000 words and (say) Yoast, Wordfence, WooCommerce and 4 other common plugins. I am sick to death of wasting hours on sifting this garbage - Make these 'Filters' and help everybody. You tell us to update things for security reasons and some of us professionals do that. Client sees a pretty picture then it turns into a nightmare for the above reasons and who has to fix it for free or spend hours looking for a replacement? The login Username should not be the default Editor name. You've handed a hacker half the login. Security - Set permissions to prevent malware spreading - in 2017, one client had malware uploaded to his site and it spread to all other sites and within site folders. WordPress should be containerised by default and SQL / Updates / changes should require 2 factor authentication to update anything (Just a 'secret password') Yes, I know, experts can fix this. In reality, most people do not have the skills. I buy a tool and assume the manufacturer has designed it for Joe Public to use with inbuilt basic safety. Last suggestion - A fork of WP for eCom with included carts, security etc. Google wants fast loading and WP struggles, so fork it to optimised versions : Blogs eCom Membership Versatile - Current version (as is) and the revolutionary version - Offline. This is where the site is built offline and uploaded as a stripped down html5 flat file database version that is a speed demon static site. Lauyan.com looks promising. Regards" grumblenz Tickets Awaiting Review 41646 activate.php and deactivate.php for Plugins Plugins 4.8.1 normal normal Awaiting Review feature request new 2017-08-15T15:01:12Z 2017-08-15T18:21:58Z "There's currently a file for `uninstall.php` to simplify things. Alternatively, there's also a hook available. There's hooks for plugin activation and deactivation. However, I think those hooks can be a bit tricky for newbie plugin developers. I think by implementing a file for `activate.php` and `deactivate.php` could simply plugin development. I'm totally fine using hooks for my own sake, but I just thought it could help simplify plugin development slightly. It might also make things easier on the code review team?" michael.ecklund Tickets Needing Feedback 20578 Allow users to delete a plugin without uninstalling Plugins normal normal Future Release enhancement reviewing 2012-05-01T01:18:35Z 2021-08-27T15:40:46Z Sometimes, a user may need to delete plugin files without deleting all the plugin data. scribu Unpatched Bugs 36288 Bug Found when you update plugins... Plugins 4.4.2 normal normal defect (bug) reopened 2016-03-21T20:20:04Z 2019-06-04T20:55:53Z If you leave the checkbox(s) when you go to update a plugin php errors appear and a success message appears but no plugins where updated... georgemou Unpatched Bugs 32041 Bulk updating selected Plugins with and without updates fails Plugins 4.1.1 normal normal defect (bug) new 2015-04-21T17:54:54Z 2019-06-04T20:49:39Z "In WordPress 4.1.1 (and possibly some earlier releases of 4) there is a bug in the following scenario. Your site has n+ plugins that need updated. You navigate to the general 'installed Plugins' page. You select ALL plugins (including those without updates) and go to Bulk Actions and select 'update'. In prior versions WordPress would only update the plugins in the selected list with updates. Currently it takes you to the updating screen and says it's finished without updating any plugins or listing any plugin updates in the updating screen." gmariani405 Unpatched Bugs 31515 Cannot enable plugins with protected function redeclarations (PHP Fatal Error) Plugins 3.9.3 normal normal defect (bug) new 2015-03-03T18:48:17Z 2019-06-04T20:49:25Z "I'm working on a codebase where the theme or plugins concurrently declare the same function inside a function_exists() however the original plugin defines the function without a function_exists check. In this situation, all the declarations can live together at runtime, but attempting to activate (or reactivate) the original plugin causes an error. Since the plugin initialization sandbox occurs after wp is loaded, the other plugins (with their checks) will have filled the function, any additional function declarations will fail. However this is merely an artifact of the initialization system -- as this plugin is being artificially run much later than it will be regularly running. A usecase -- perhaps you are trying to wean yourself off the Advanced Custom Fields plugin so you've implemented the get_field function in the theme's functions file in a function_exists check. After disabling the ACF plugin, you decided to reenable it to adjust a field. Game over, Fatal Error." brokentone Unpatched Bugs 36704 Delete Plugin not compatible with Bulk Actions Plugins 4.5.1 normal normal defect (bug) new 2016-04-28T19:56:38Z 2019-06-04T20:58:09Z "`delete_plugins()` has a `foreach` loop which calls `uninstall_plugin()` which defines a constant: {{{ define('WP_UNINSTALL_PLUGIN', $file); }}} A constant cannot be defined twice. If several plugins are selected for bulk deletion and two of these have uninstall.php, only the first one will see the expected constant value. For example, Jetpack's uninstall.php dies immediately when the constant contains an unexpected value. This prevents the code at the end of `delete_plugins()` finishing the job for the plugins that were uninstalled and deleted. (Jetpack's uninstall.php isn't exactly doing it right, but it's a very real example.) The obvious fix is to remove Delete from bulk actions on the Plugins page. This leaves the working parts in working order and buys time to rewrite the delete/uninstall API to work with a bulk delete function if this is desirable. Part of the rework would involve rewriting `uninstall_plugin()` and the uninstall.php pattern so that it can return a `WP_Error` instead of dying. This way, `delete_plugins()` could continue without leaving the work of `delete_plugins()` incomplete for the plugins that were uninstalled. I propose removing Delete from bulk plugin actions until the uninstall API is made compatible with bulk deletion." andy Unpatched Bugs 18563 Disallowing editing of .php files in the plugin editor blocks access to allowable extensions Plugins 2.8 normal normal defect (bug) new 2011-09-01T04:12:29Z 2019-06-04T20:42:15Z "By using the editable_extensions filter, a user can disallow the editing of php files (more accurately: files with a php extension...) {{{ add_filter( 'editable_extensions', 'disallow_php_file_editing' ); function disallow_php_file_editing( $editable_extensions ) { unset( $editable_extensions[0] ); return $editable_extensions; } }}} However, the file selected when first clicking on the Editor link in the menu is always a php file, so the user is given the ""Files of this type are not editable"" wp_die() message without being presented with a chance to select a file with a different/allowable extension." trepmal Unpatched Bugs 60491 Fix handling of plugins with unmet requirements Plugins 5.1 normal normal Future Release defect (bug) new 2024-02-10T01:03:03Z 2024-02-20T07:25:40Z "There are several bugs/inconsistencies when WordPress handles plugins with unmet requirements. - A plugin with unmet requirements cannot be installed or updated when using the UI, but this is possible to do/there are no checks when a plugin is installed or updated directly (with FTP, SSH, or git/svn). - A plugin with unmet requirements cannot be activated if already installed (happens only when a plugins is installed/updated from FTP, SSH, or git/svn). But if the plugin is already activated, it is not deactivated and continues to load. - The UX can be better. The warnings in wp-admin when a plugin has unmet requirements are somewhat inconsistent, and there are no email notifications if any of these errors occur automatically (for example a script is running on the server that uses svn or git to update plugins). " azaozz Unpatched Bugs 31049 Hiding Administration Menu Items through remove_menu_page function can create unnecessary margin via the menu separator list item Plugins 4.1 normal normal defect (bug) new 2015-01-18T22:47:53Z 2019-06-04T20:48:43Z "In some situations where the Administration Menu has had menu items removed, the wp-menu-separator
  • may appear first. When the menu separator
  • appears first in the menu, unwanted extra margin is created. This issue occurs when the Dashboard menu item has been disabled, but could occur under other menu reorganizations and configurations." monopine Unpatched Bugs 33215 Main plugin file loaded multiple times under special circumstances on Network Activate Plugins 4.2.3 normal normal defect (bug) new 2015-07-31T10:06:02Z 2019-06-04T20:50:57Z "Consider the following code in the main plugin file: {{{ function test_plugin_install ( $network_wide = null ) { if ( $network_wide ) { trigger_error( 'Please activate individually.', E_USER_ERROR ); } } register_activation_hook( __FILE__, 'test_plugin_install' ); }}} and a multisite setup with * mysite.intern as main site * one.mysite.intern, two.mysite.intern, etc. as blog sites Now, if you first activate the plugin ''individually'' on mysite.intern, and then select ""Network Activate"", the following is logged: {{{ PHP Fatal error: Please activate individually. in test_plugin.php on line 17 PHP Fatal error: Cannot redeclare test_plugin_install() (previously declared in test_plugin.php:15) in test_plugin.php on line 15 PHP Fatal error: Cannot redeclare test_plugin_install() (previously declared in test_plugin.php:15) in test_plugin.php on line 15 }}} and only the last error is displayed on the admin page. If the plugin is first activated on another blog site or isn't activated individually anywhere, only the expected ""Please activate individually"" error is thrown and displayed on network activation, as expected. Wrapping the function test_plugin_install in a conditional only results in the next function in the plugin file triggering the redeclaration error." ccprog Unpatched Bugs 31184 Plugin update API times out too easily in practice, and is not handled gracefully Plugins 4.1 normal normal defect (bug) new 2015-01-30T16:54:46Z 2019-06-04T20:48:57Z "In wp_update_plugins() the timeout is set to ""Three seconds, plus one extra second for every 10 plugins"" when not doing a cron job. I did some testing (with reasonable bandwidth) and in practice I need about twice that to be safe. I realize you need to arbitrarily choose something, but the problem is that if timeouts do occur, there are unhandled warnings like Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /media/sf_shared/digipowers/www.digipowers.com/httpdocs/wp-includes/update.php on line 297 which doesn't alert you to the real problem, which is that api.wordpress.com took too long to resolve. To repro this, clear your transients to force an update check, and then force the timeout in class-http.php:96 to something short like 1s: {{{ /** * Filter the timeout value for an HTTP request. * * @since 2.7.0 * * @param int $timeout_value Time in seconds until a request times out. * Default 5. */ 'timeout' => 1, //apply_filters( 'http_request_timeout', 5 ), }}} Recommend you do 2 things: 1) increase the default timeout for the plugin check from say 5 to 10. 2) handle this condition more gracefully by stating what's wrong in this case, e.g., : ""WordPress could not connect to the API server to check for plugin updates; please try again later."". And needless to say, don't throw PHP warnings as they break the headers if you have error_reporting and display_errors set to be loud. " rkaiser0324 Unpatched Bugs 36705 Read-only plugins are uninstalled before deletion fails Plugins 4.5.1 normal normal defect (bug) new 2016-04-28T20:06:04Z 2019-06-04T20:58:14Z "Plugin uninstall happens before deletion is attempted. If the plugin's files are read-only, the plugins list action says ""Delete"" but all that happens is uninstall and an error. Plugins that cannot be deleted because they are read-only in the filesystem should not have Delete buttons. `is_writable()` should be checked while constructing the actions. If read-only, either remove the button or replace it with an action which deletes the plugin's data and leaves the files. I prefer the latter." andy Unpatched Bugs 40252 Redirection during activation Plugins normal normal Future Release defect (bug) new 2017-03-24T19:33:28Z 2024-02-29T10:56:50Z "for example, i select several plugins (which are deactivated) at once and click BULK ACTIVATE... if any of plugin has custom filter `add_action( 'activated_plugin', ...` (inside where it redirect to plugins settings page after activation), then those plugins are not activated in bulk, instead while that plugin's turn comes, it is activated and the page is redirected to that plugin's url.. i think there is no easy solution... you should create a new hook, that will be named i.e. `redirect_to_after_activation` which will be solely dedicated and used for redirection, while that plugin is activated individually. " tazotodua Unpatched Bugs 37395 Transients should be replaced with options, e.g. plugin delete notification Plugins normal normal defect (bug) new 2016-07-18T12:04:04Z 2019-06-04T21:01:46Z "Transient data is not guaranteed. Even in the shortest possible duration, on a page redirect! In `wp-admin/plugins.php` : {{{ set_transient('plugins_delete_result_' . $user_ID, $delete_result); //Store the result in a cache rather than a URL param due to object type & length wp_redirect( self_admin_url(""plugins.php?deleted=$plugins_to_delete&plugin_status=$status&paged=$page&s=$s"") ); }}} Now a delete notification is not critical, but it would be just as easy to do this with `set/get/delete_option()`, and set a good example for plugin authors. The retrieval step does an immediate delete: {{{ $delete_result = get_transient( 'plugins_delete_result_' . $user_ID ); delete_transient( 'plugins_delete_result_' . $user_ID ); }}} So it looks easy to write a patch substituting `set/get/delete_option()`, modulo multi-site perhaps. I expected to see more of these in the WP codebase related to notifications, but it's mainly other stuff. About half the use of transients in WP is wrong. I'll list them here for future bugs, but I leave this bug for the Plugins component. * GOOD: wp-admin/includes/dashboard.php ( $cache_key, 'plugin_slugs' ) * BAD: wp-admin/includes/template.php ( 'settings_errors' ) * GOOD: wp-admin/includes/theme-install.php ( 'wporg_theme_feature_list' ) * BAD: wp-admin/plugins.php ( see above: 'plugins_delete_result_' . $user_ID ) * ALL GOOD: wp-content/themes/* * PROB. BAD: wp-trunk/wp-cron.php AND wp-includes/cron.php ( 'doing_cron' ). Using it as a file lock is either egregious or just confusing, depending on whether it is doubling as a global store for the same run. Why not use `*_option()` instead? * GOOD: wp-includes/author-template.php ( 'is_multi_author' ) * PROB. BAD: wp-includes/class-feed.php ( $this->name, $this->mod_name ) * PROB. BAD: wp-includes/media.php ( $regeneration_lock ). Bad if it's to protect successive ajax calls, confusing if it's a global store for the same run. * GOOD: wp-includes/ms-functions.php ( 'dirsize_cache' ) * BAD: wp-includes/pluggable.php ( 'random_seed' ) * GOOD: wp-includes/rss.php ( $cache_option ) * BAD: wp-mail.php ( 'mailserver_last_checked' ) You were expecting a Clint Eastwood reference? Should all be easy fixes. " kitchin Unpatched Bugs 32602 View Details links for plugins on individual sites on a Multisite Network use the network admin URL Plugins 4.0 normal normal defect (bug) new 2015-06-09T21:05:31Z 2019-06-04T20:50:34Z "To duplicate, make sure you allow the plugins.php page to show on subites. Have (at least) one plugin that is ''not'' network activate and go to an individual site's plugin.php page. The URL for ""View details"" will be for the network admin, not the site. With WP installed at example.com: example.com/subsite/wp-admin/plugins.php links to example.com/wp-admin... subsite.example.com/wp-admin/plugins.php links to example.com/wp-admin... mappeddomain.com/wp-admin/plugins.php links to example.com/wp-admin... This is problematic when you have admin over HTTPS and the cross-site-scripting sanity check stops the view-details page from loading. `/wp-admin/includes/class-wp-plugins-list-table.php` line 628 has `network_admin_url()` in there, which is why it's defaulting to the network domain. https://core.trac.wordpress.org/ticket/17902#comment:31 and https://core.trac.wordpress.org/changeset/29595 appear to be where this issue stems from. To quote @jjj ""It probably just needs a series of `is_multisite()` and `is_plugin_active_for_network()` checks."" The URL should probably just default to whatever the URL of the current site is, to prevent cross-site shenanigans." Ipstenu Unpatched Bugs 30963 Wrong error message when uploading non-zip files on the plugin upload page Plugins normal normal Future Release defect (bug) new 2015-01-09T09:54:54Z 2020-07-02T18:23:00Z "If you go to plugins -> upload plugin and you try to insall a .php file instead of a zip file you get this error message: Abort class-pclzip.php : Missing zlib extensions. This error message is bad, zlib extensions are not missing, the file type is wrong. Also this message is missing translation support (I might be wrong on this)." jnhghy Unpatched Bugs 28727 plugin editor content empty when source contains an invalid character Plugins 3.9.1 normal normal defect (bug) new 2014-07-03T11:39:43Z 2019-06-04T20:47:22Z "I happened to create a plugin source file which contained a pound sterling character (£) copied and pasted from a web page, and which therefore appeared in my Windows text editor as lower case u acute ( hex A3, ascii 163 ). esc_textarea() makes a call to htmlspecialchars() which returns a null value for safe text. {{{ $safe_text = htmlspecialchars( $text, ENT_QUOTES, get_option( 'blog_charset' ) ); }}} Note: blog_charset is UTF-8 So the plugin editor displayed nothing at all for the source. Question: Is this really the expected behaviour? The documentation for htmlspecialchars says If the input string contains an invalid code unit sequence within the given encoding an empty string will be returned, unless either the ENT_IGNORE or ENT_SUBSTITUTE flags are set. Shouldn't the plugin editor pass ENT_IGNORE OR otherwise issue a message to the user at least advising not to save the empty file when the safe content is nothing like the original. " bobbingwide Unpatched Bugs 25648 plugin.php causes infinite loop and gigabytes of warning messages in error logs Plugins 3.6.1 normal normal defect (bug) reopened 2013-10-21T12:12:22Z 2019-06-04T20:45:02Z "We host several wordpress instances in a multi-user environment on our servers. Some installations cause regulary massive error log files with warnings like these: PHP Warning: next() expects parameter 1 to be array, boolean given in [...]/html/wordpress/wp-includes/plugin.php on line 408 PHP Warning: current() expects parameter 1 to be array, boolean given in [...]/html/wordpress/wp-includes/plugin.php on line 404 After some googling I found out, that this behaviour is known for more than 10 month. So, if you could fix that, that'd be great." ticktoo Unpatched Bugs 31496 register_uninstall_hook tries to serialize anonymous functions Plugins normal normal defect (bug) new 2015-03-01T04:56:28Z 2019-06-04T20:49:18Z "`register_uninstall_hook` saves uninstall callback in database. If one passes a closure as uninstall callback WordPress tries to serialize it, causing a ''Serialization of Closure'' Exception. `register_uninstall_hook` already ensures that array callbacks are not allowed if first element of the array is an object (see #13786). The complete check should be something like: {{{ if ( is_object( $callback ) || ( is_array( $callback ) && is_object( $callback[0] ) ) ) { }}} Checking for `is_object` also prevents usage of invokable objects. " giuseppe.mazzapica Unpatched Enhancements 36897 """You do not have sufficient permissions to access this page."" should have relevant links to go back to dashboard." Plugins 4.6 normal normal enhancement new 2016-05-21T03:45:54Z 2019-06-04T20:59:15Z "The ""You do not have sufficient permissions to access this page."" screen has no information where to go after seeing this error on screen. It would be better if there is a link to go back to the dashboard or maybe even better if the admin bar is visible on the screen with this error message." Nikschavan Unpatched Enhancements 58370 Add 'Activate' button to View details modal Plugins 6.3 normal normal Future Release enhancement new 2023-05-21T19:46:26Z 2024-01-29T20:19:05Z In [https://wordpress.slack.com/archives/CULBN711P/p1684696308556829?thread_ts=1684691032.713709&cid=CULBN711P| discussions] with @azaozz regarding the Plugin Dependencies feature, it was thought that a button in the View details modal would provide for a smoother UX. This way the user wouldn't need to go to a different page to activate an installed plugin. afragen Unpatched Enhancements 27994 Erroneous plugin deactivation should be a manual action Plugins 2.5 normal normal enhancement new 2014-04-23T16:00:01Z 2019-06-04T20:46:44Z """The plugin `foo.php` has been deactivated due to an error: Plugin file does not exist."" This seemingly harmless behaviour on the Plugins screen can end up being a royal pain for developers. Consider the scenario where you've renamed your plugins directory or any of the plugins within it (ie. to do some debugging with plugins disabled), and then you visit the Plugins screen. BAM, your plugins have been deactivated. I think this behaviour should be removed, and instead a list of erroneous plugins displayed, with the option to manually deactivate them. Thoughts?" johnbillion Unpatched Enhancements 33374 Improvements for the messages visible in the plugin manager Plugins normal normal Future Release enhancement new 2015-08-14T15:41:41Z 2017-07-21T00:44:28Z "Hello, WordPress is more and more popular and I think that it is the time to prepare better security-related messages into plugin manager. Outdated plugins are probably the most popular way to compromise websites based on WordPress. That’s why I suggest that in the plugin manager the following messages should appear too: - “This plugin has not been updated for more than 2 years” - some plugins are no longer developed and can contain vulnerabilities which are not managed by the plugin developer - “Security update” - it would be great to provide the plugin authors a possibility to add a message that the current update is a security update. Then users will know that they should update their plugin immediately (Currently I often check every changelog to make sure that I can made an update in weekend). - “No longer in directory” - some plugins were removed from the repository and of course are no longer maintained - it is a similar issue as the first one. Additionally it will help users to detect plugins which was accepted but breaks the WordPress.org rules. Sending e-mails connected with these messages would be also great for administrators. Yes, I know that there are plugins for the above features, but I think that due a big popularity of WordPress and more and more massive attacks which appears sometimes after few hours (!) after disclosure, WordPress should contain better tools which are built-in into the core code. Because a lot of people currently ignore updates or uses very old and vulnerable extensions. In my opinion “security” is a keyword which forces people for the updates." dziudek Unpatched Enhancements 37143 Missing Screen options tab in Add New plugin screen Plugins normal normal enhancement new 2016-06-21T22:29:07Z 2019-06-04T21:00:36Z "Hey It would be great to have Screen Options tab for Add New Plugin screen. With the option to select amount of plugins to view on each page. Having one very long add new plugin screen is preferable then to having 5-6 pages to have to jump through. Adding the Screen Options tab would really help." paaljoachim Unpatched Enhancements 23318 Plugins Admin Showing Details for Wrong Plugin Plugins normal normal WordPress.org enhancement new 2013-01-29T22:41:54Z 2022-08-23T17:46:47Z "I just set up a new site with some plugins, none of them activated yet. The plugins screen says: ""There is a new version of Google XML Sitemaps available. View version 4.1 details or update now."" I know for a fact there is no such version of this plugin. When I click details link, it tells me to install some other plugin called page-list?!" miqrogroove Unpatched Enhancements 52191 Show plugin update notifications on Plugins screen on WordPress Multisite sub blogs Plugins 3.1 normal minor Future Release enhancement new 2020-12-29T21:56:17Z 2021-11-15T22:45:53Z "The purpose of this request it to make plugin update notification equal for every type of WordPress installation without compromising the current capability checks. Currently, MultiSite sub blogs do not get an inline plugin update notice in the Plugins Page. They do however get a notification icon in the Admin Menu Bar. This might be confusing for users. On Single Site installs non-admins still see the inline update notice, but without the ""Update Now"" link. Also, if a third-party plugin is not activated network-wide, the Super Admin is likely to not see the update notice. Installing and updating and deleting plugins on a MultiSite installation can only be sone by a Super Admin in the Network Admin Page. WordPress plugin developers tend to use workarounds by using the action hooks `in_plugin_update_message-{$plugin_file}` and `after_plugin_row_{$plugin_file}` to notify their users, as documented here: [https://wisdomplugin.com/add-inline-plugin-update-message/ Wisdom] Yet, the MultiSite example already shows a flaw. Doing it this way the Network Admin Plugins Page will be cluttered with two inline notices. To prevent this the check `if( ! is_network_admin() )` should be added, because WordPress core already shows the default inline update notice in the network admin. Also, as a developer it always felt, to me personally, that the `after_plugin_row` action seems to be a non-preferred method, due to the many css classes that need to be included, unlike most hooks and filters. Changing the output check on **line 541** in `/wp-admin/includes/update.php` would solve that. Replacing `if ( is_network_admin() || ! is_multisite() )` with `if ( is_network_admin() || is_blog_admin() )` would show the in inline update notices exactly like on single installs by using the `in_plugin_update_message-{$plugin_file}` action hook. The rest of the code checks the user permissions and will automatically remove the ""Update Now"" link for non-admins. I have tested this change and it seems to work without any safety compromises. It appears to be a simple solution to enhance the user experience and helping developers to be aligned with the WordPress Core. For my own premium plugins is use the [https://github.com/YahnisElsts/plugin-update-checker Plugin Update Checker by Yahis Elsts], which works perfectly, except that it uses admin notices to notify the users of an available update on the sub blogs. I seem to remember a topic some months ago to reduce/limit plugin developers from using over-using admin notices. Perhaps this minor core code change would help with that as well. " DuisterDenHaag Unpatched Enhancements 36686 plugin_row_meta hook for specific plugin Plugins 4.5.1 normal normal enhancement new 2016-04-27T13:39:15Z 2019-06-04T20:57:51Z "Hello WordPressers, It is my first post here. So please forgive me if something is wrong. What I see here https://core.trac.wordpress.org/browser/tags/4.5.1/src/wp-admin/includes/class-wp-plugins-list-table.php#L773 plugin_row_meta is a filter hook available but It is not available for specific plugin like we have ""plugin_action_links_{$plugin_file}"" available here https://core.trac.wordpress.org/browser/tags/4.5.1/src/wp-admin/includes/class-wp-plugins-list-table.php#L682 Shouldn't there be a ""plugin_row_meta_{$plugin_file}"" filter to call on specific plugins ?? " hiddenpearls Unpatched Enhancements 15971 Add ability to rate and report compatibility of plugins from wp-admin Plugins 3.1 normal normal Future Release feature request new 2010-12-24T08:25:27Z 2019-04-08T19:34:03Z "For the millions of downloads some plugins get there are way to few ratings on them. I think the ability to rate and report the compatibility of plugs from the backend dashboard page would dramatically increase participation in rating. This could be accomplished most easily placing a link to the ""details"" of a plug-in (like the one that appears while searching for a plug-in) after it is installed on plugins.php. This could be accomplished even more effectively by showing direct link next to each listing on the plugins.php page link stars/compatibility and link text reading ""rate now or ""report compatibility now""... For reference I point you to the excellent new to FireFox 4 (beta) add-on compatibility reporting features. " jb510