__group__ ticket summary owner _component _version priority severity milestone type _status workflow _created modified _description _reporter 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 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 55475 Add Lists to Favorites for Plugins Plugins normal minor Awaiting Review enhancement new 2022-03-28T19:42:42Z 2022-03-28T19:42:42Z "Currently, you can click the ""heart"" icon next to a plugin name in the WordPress.org plugins directory. Example for Gutenberg: https://wordpress.org/plugins/gutenberg/ Screenshot: https://cloudup.com/c-Uk_AX1Vg0 Your favorites show up in your WordPress.org profile. Example here: https://profiles.wordpress.org/dansoschin/#content-favorites I would like to propose the ability to create lists of favorites so that you can ""heart"" a favorite and then are prompted to add it to a new list, add it to an existing list, or add it to all lists. The purpose of this would be for folks who work on multiple projects and might like to create groups of plugins for various types of projects." dansoschin Tickets Awaiting Review 54860 Enhancement for more accurate doing_action, doing_filter Plugins normal minor Awaiting Review enhancement new 2022-01-20T00:34:06Z 2022-01-20T06:18:22Z "**Problem** The `doing_action` function returns true if the currently active hook is a filter, not an action. Since all actions are filters, in a legacy and technical sense, this is OK for general purposes - we want to know if a hook is in progress, whether it's a filter or an action. But since there are two functions, `doing_action` and `doing_filter`, there is an implication that they should do something different. As of v4.7, the WP_Hook class does make an internal distinction that can be helpful elsewhere if surfaced. **Remedy** I suggest that going forward these functions should accurately reflect whether a __filter__ is being applied (from `apply_filters`, value being returned) **OR** whether an __action__ is being executed (from `do_action`, no value returned). ---- **Verification of this condition/claim:** [https://core.trac.wordpress.org/browser/tags/5.8.3/src/wp-includes/class-wp-hook.php?rev=52509#L52 Here] (ref current 5.8.3 source) in WP_Hook we verify that `$doing_action = false`, defaulting to the state of ""doing"" a filter. This was implemented in v4.7.0. [https://core.trac.wordpress.org/browser/tags/5.8.3/src/wp-includes/class-wp-hook.php?rev=52509#L325 Here] in WP_Hook we also see that `do_action` sets the value to true before passing on to the common `apply_filters` function. {{{#!php public function do_action( $args ) { $this->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 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 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 45056 Show Active plugins at the top of the plugin list in plugin-editor.php Plugins normal minor Awaiting Review enhancement new has-patch 2018-10-05T18:52:50Z 2020-06-29T17:34:44Z This is something I've thought would be useful for quite a while. codente Tickets Awaiting Review 48143 Unstyled error message when activating broken plugin Plugins normal minor Awaiting Review enhancement new 2019-09-26T01:52:43Z 2019-09-26T01:52:43Z The font of the error message shown in the iframe when activating a broken plugin doesn't match that of the rest of the page. See the attached image for an example. pierlo 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 30976 When selecting multiple plugins and performing deactivate, keep selected for next bulk action (if any) Plugins 4.2 normal minor Awaiting Review enhancement new has-patch 2015-01-11T05:16:01Z 2021-08-08T06:10:37Z aubreypwd 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 Candidates for Closure 47669 Content UI ISSUE:'Was' helping verbs looks wrong in plugin tab. Plugins 5.2.2 normal minor Awaiting Review defect (bug) new reporter-feedback 2019-07-09T13:29:13Z 2019-07-10T09:43:36Z "**Content UI ISSUE:** 'Was' helping verbs looks wrong in plugin tab. removed helping verbs 'was' from validation alert comes after deleted the plugin **Snapshot:** https://www.screencast.com/t/ZIzFEqsgh Video URL: https://www.screencast.com/t/0O2l59eXosj " jadhavravindra Candidates for Closure 45544 Headers already sent at Plugins Page Install Plugins 5.0 normal minor Awaiting Review defect (bug) new reporter-feedback 2018-12-08T23:21:02Z 2018-12-13T03:39:53Z "I updated to the latest version (Bebo 5.0) and began to appear this alert and this error on the plugins installation page. [[Image(https://lunestudio.com.ar/wp-colaborate/warnnings.png)]]" lunestudio Candidates for Closure 49729 Warning: fread() expects parameter 1 to be resource, bool given in \wp-includes\functions.php on line 5785 Plugins 5.3.2 normal minor Awaiting Review defect (bug) new reporter-feedback 2020-03-30T12:47:43Z 2022-03-10T15:46:55Z "Happens in dashboard and it goes coupled with: {{{ Warning: fread() expects parameter 1 to be resource, bool given in ...\wp-includes\functions.php on line 5785 Warning: fclose() expects parameter 1 to be resource, bool given in ...\wp-includes\functions.php on line 5788 }}} PHP 7.4 I think it occurs mostly when one loads the dashboard after a directory's previously active plugin has been deleted from the filesystem." DrLightman 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 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 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 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 Slated for Next Release 60663 Plugin Cards: Links with `.button-disabled` are still clickable costdev Plugins normal normal 6.6 defect (bug) assigned has-patch 2024-03-01T03:04:20Z 2024-03-11T11:03:57Z "Props to @swissspidy for noticing this while testing Plugin Dependencies. Currently, links with a `href` attribute and the `.button-disabled` class are still clickable. We should prevent the default `click` handling for elements with the `.button-disabled` class. While this appears to have been the case in earlier WordPress versions, it may be more apparent in the increased AJAX-ified experience added by the Plugin Dependencies feature. **Milestoning for 6.5 for awareness, though I welcome thoughts on whether this is something that needs to be handled in 6.5, or should wait until 6.6.** == Testing Instructions These steps define how to reproduce the issue, and indicate the expected behavior. === Steps to Reproduce 1. Navigate to `Plugins > 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 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 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 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 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 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 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 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 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 59375 "Plugin_Upgrader assumption causes incorrect ""Activate Plugin"" link after plugin installation resulting in ""The plugin does not have a valid header"" error" Plugins 6.3.1 normal normal Awaiting Review defect (bug) new has-patch 2023-09-17T13:13:19Z 2023-09-18T02:02:16Z "''Observed in WordPress 6.3.1'' == Issue Summary == The ""Activate Plugin"" link after installing a new plugin is inconsistent with the ""Activate"" link generated in the Installed Plugins listing table. The ""Activate Plugin"" link on the plugin installation screen makes assumptions that produces an incorrect link which results in the user encountering the ""The plugin does not have a valid header"" error. == Steps to Reproduce == 1. Create a plugin that contains another plugin. 1.a. The contained plugin's basename should be lexicographically less than the wrapper plugin which you are actually trying to install. For example, ""hello-pro/hello-pro.php"" is the main plugin which contains ""hello-pro/hello/hello.php"" as a base/dependency plugin. 2. Add the plugin via wp-admin > 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 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 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 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 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 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 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 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 string(0) """" }}} " Tkama Tickets Awaiting Review 47438 "do_action will convert ""single array object"" as ""object""" Plugins 5.1.1 normal normal Awaiting Review defect (bug) new 2019-05-30T19:42:28Z 2019-10-21T14:53:03Z " {{{ /* Correct if $object is not object*/ $orders = array(); $orders[] = 'abc'; do_action( 'action123', $orders); add_action('action123', 'func123'); function func123($orders){ //$orders will be array here (CORRECT) } /* BUG: if $orders is an object */ $orders = array(); $orders[]=new stdClass(); $orders->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 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 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: {{{ ... '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 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 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 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 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 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 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 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 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 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 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 52829 Getting some code when Update failed plugin Plugins 5.7 normal normal Awaiting Review defect (bug) new reporter-feedback 2021-03-17T04:55:36Z 2021-03-17T17:51:16Z "Hi, When i ma trying to update plugin then got script return n the page. So it is WordPress issue? You can see mentioned screenshot." sumitsingh 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 38012 Improve data validation in plugin.php Plugins 4.6 normal normal Awaiting Review defect (bug) new reporter-feedback 2016-09-09T19:04:22Z 2022-08-27T23:33:18Z "function plugin_basename does not do proper data validation of $realdir variable before attempting to use strpos(): PHP Warning: strpos(): Empty needle in /wp-includes/plugin.php on line 736" rpayne7264 Candidates for Closure 43716 "Not work ""option_active_plugins"" filter in front-end" Plugins 4.9.5 normal normal Awaiting Review defect (bug) new reporter-feedback 2018-04-07T07:46:22Z 2022-03-07T14:42:29Z "The ""option_active_plugins"" filter work just in admin and not work in front-end. i test wp_get_active_and_valid_plugins function in wp-includes/load.php#L598 the ""$active_plugins"" correct and work in front-end but related filter not work and i have to use ""alloptions"" filter for work" hamedmoodi Candidates for Closure 44582 Notice: Undefined property:stdClass::$plugin - wordpress Plugins 4.9.7 normal normal Awaiting Review defect (bug) new reporter-feedback 2018-07-13T19:15:50Z 2022-01-29T08:12:43Z Notice: Undefined property: stdClass::$plugin in /hermes/bosnaweb07a/b1754/ipg.account_name/folder_name/wp-includes/class-wp-list-util.php on line 150 sangwan4pankaj 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 53905 Plugin activation from overview not working Plugins 5.8 normal normal Awaiting Review defect (bug) new reporter-feedback 2021-08-10T08:59:21Z 2021-08-19T19:26:47Z "After I upgraded to the latest WordPress version, I can no longer activate recently installed plugins from the ""add new plugin"" overview. Clicking on the ""activate now"" Button will result in endless loading while it works fine from the ""installed plugins"" directory. " gre4twh1te 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 49454 Plugins list page update available shows 3 plugin to update but actually have only 2 plugins to update Plugins 5.3.2 normal normal Awaiting Review defect (bug) new reporter-feedback 2020-02-17T12:15:11Z 2020-02-17T13:19:36Z vivek5512 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 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 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 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 '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 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 46571 Fix contributors list in plugin information + duplicate CSS Plugins 5.2 normal normal Awaiting Review enhancement new dev-feedback 2019-03-20T08:28:07Z 2019-03-20T09:07:32Z I think the contributions list can be better with this change. mostafa.s1990 Candidates for Closure 37656 Improve plugin bootstrapping processes Plugins normal normal Awaiting Review enhancement new dev-feedback 2016-08-14T11:32:28Z 2019-12-13T19:04:03Z "I recently thought about if we could make bootstrapping plugins easier and take away some common tasks that (should) happen in every plugin. It would also be nice to have a general plugin class registry. What I was thinking of is to introduce an abstract class `WP_Plugin` that plugin developers can extend for their plugin's main class. Then they would call a new function `register_plugin( __FILE__, $plugin_class_name )` to register that class with WordPress. We could take some regular processes away from the developer and, by doing that, also make sure that they don't implement it the wrong way. For example, we could take care of plugin installation routines: If the class implements a static method `install()`, the base class `WP_Plugin` would register an activation hook to an internal function that takes care of whether the plugin is activated network-wide. The actual `install()` method would only contain those steps necessary for the setup on the current site (`WP_Plugin` would take care of switching sites as appropriate). Many plugin developers overlook Multisite in their setup routines, causing the plugin to only install on the main site although being network-activated. We could also deal with other tasks, like hooking the `bootstrap()` method of the plugin class in `plugins_loaded` or `muplugins_loaded` (detected by the base class). I think this whole concept could improve the way plugins initialize themselves. It would not be mandatory (since several plugins don't even use classes), but it would become a best practice. This is just an idea that I wanted to throw on Trac to discuss about it. If we get to the point that we agree this is a good idea, we would need to come up with actual details (of which I don't have any yet)." flixos90 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 60061 "Rename ""add new plugin"" button" Plugins normal normal Awaiting Review enhancement new dev-feedback 2023-12-13T16:26:01Z 2024-01-26T09:31:53Z "Hello For several versions now, we can update a plugin (and theme) by using the ""add new plugin"" feature. I think we should find a better wording because the button is not only to add a new plugin, we can update one too. At first, we could change the label button to ""Add new or update a plugin"" but it's quite long label" sebastienserre 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 37301 A way to test plugin/theme installs and updates before applying Plugins 4.4.3 normal normal Awaiting Review feature request new dev-feedback 2016-07-07T09:13:20Z 2020-04-15T20:41:18Z "The # 1 reason for WordPress sites going completely down or becoming partially broken is the bad install or an update of a plugin or a theme. The worst case scenario being a complete white screen of death from which the only way to recover is to manually remove the culprit plugin files, which unfortunately requires remote access to the server filesystem. The current plugin upgrader checks if the upgrade causes errors and can in some cases recover from the most obvious cases syntax errors in the critical plugin code. This however fails to mitigate the slightly more subtle issues like incompatibilities between plugins/themes and javascript errors that may still completely wreck the site. Furthermore, the more seasoned WordPress users are known to avoid updating plugins and themes on their site due to the volatility of running an update in production. This of course leaves their sites vulnerable to possible security issues. The best practice of running staging environments to test plugins before updating requires a significant amount of technical knowledge and labour, and is not widely practiced among regular users. I suggest we give the option for users to test plugin / theme installs and updates prior to applying them. This requires a sort of sandbox environment for the user where they can freely install and test plugins without worrying about breaking anything. I've created an example implementation of these plugin update sandboxes in (slightly hacky) plugin form. The plugin adds a ""test update"" button to the update.php admin screen, which creates a sandbox where the user can test the updated plugin without affecting the live site. Both the plugin directory and the database are separated from the live ones. https://github.com/anttiviljami/wp-safe-updates Screenshots: The ""test update"" button in update.php [[Image(https://github.com/anttiviljami/wp-safe-updates/raw/master/assets/screenshot-1.png)]] Updating the plugin in an alternate heap (sandbox) [[Image(https://github.com/anttiviljami/wp-safe-updates/raw/master/assets/screenshot-2.png)]] Testing the plugin inside the sandbox [[Image(https://github.com/anttiviljami/wp-safe-updates/raw/master/assets/screenshot-3.png)]] -- I would love more discussion about this. I feel the safety of theme / plugin updates is definitely among the most important issues to solve for the future of WordPress security. Love, @anttiviljami" Zuige 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 Candidates for Closure 46991 Stop propagation on actions or filter Plugins low normal Awaiting Review feature request new dev-feedback 2019-04-19T12:05:17Z 2020-11-19T12:02:38Z "It would be great to stop further filter-hooks/action-observer when we reached a state that should not continue. This helps especially for custom implementations: * Rejection actions that should not run. * Return filtered values without giving other plugins the chance to change them. All just for specific cases. Possible implementation: * Normal but impossible: Event-Class as wrapper reflecting whether to continue or stop. * Semi-normal-way: Throwing a exception like `\WP_Stop_Propagation_Exception` telling WP_Hook to stop. * Absolute absurd way: Setting a global variable like `$stop_propagation = true` ... and there may be more." screamingdev Tickets Needing Feedback 38211 Interference of AJAX search with input field auto-complete adamsilverstein Plugins 4.6 normal normal Future Release defect (bug) assigned has-patch 2016-10-02T12:09:55Z 2021-10-29T19:23:00Z "In WordPress 4.6 new feature was introduced in ""Add Plugin"" page - user input in ""Search Plugin"" field triggers AJAX search. That's great but it also makes browser's auto-complete of this field to disappear (at least in Chrome). Therefore it's difficult to select an already existing option of plugin name that browser's auto-complete offers because AJAX search gets triggered very soon after you type a letter in input field. So, in most cases I need to type full name of the plugin or try to select auto-complete option before AJAX gets triggered. I'm not sure what the solution for this would be but I don't think it's difficult to press Enter or tap Search button after you have written everything you wanted without system interfering with the process without user wanting it. In addition, the fact that button Search disappeared some time ago made it impossible to add a plugin on touch devices. I see that AJAX search perhaps tries to fix this but it breaks auto-complete as I mention above." armandsdz Tickets Needing Feedback 29539 Plugin viewer not displaying video tutorials. Plugins 4.0 normal normal Future Release defect (bug) new dev-feedback 2014-09-05T16:19:32Z 2017-05-05T20:25:17Z "In the WordPress 4.0 plugin page viewer, my video tutorials for my plugins are not displaying. [[Image(http://www.redeemerdanceacademy.ca/wp-content/uploads/2014/09/Ticket.png)]]" kidsguide Tickets Needing Feedback 27188 deactivated_plugin behaves improperly Plugins 2.9 normal normal defect (bug) new dev-feedback 2014-02-23T05:36:00Z 2023-10-22T09:59:16Z "Currently, if someone were to hook into `deactivated_plugin`, one should expect that the `$plugin` actually be deactivated. So if, for example, I hook into it with the following code, deactivating Addthis, I don't get the expected behavior. {{{ add_action( 'deactivated_plugin', 'dtat_deactivate_self', 10, 2 ); /** * Deactivate ourself if Premise is deactivated. */ function dtat_deactivate_self( $plugin, $network_deactivating ) { if ( 'addthis/addthis_social_widget.php' == $plugin ) { die( 'Addthis: ' . print_r( is_plugin_active( $plugin ), 1 ) ); } } }}} The plugin still shows that it is active. So if I hook in here to check if plugin has been deactivated, then it fails. Instead, the `deactivated_plugin` hook should appear after the `update_option` call, which is where the plugin is actually deactivated. OR, the docs are wrong and should be updated. Attached is a sample addthis plugin extension that deactivates after Addthis is deactivated by being forced to use `update_option_active_plugins` and `update_option_active_sitewide_plugins`. See [https://gist.github.com/wpsmith/26c2e07370ee8b4c3e3f Github Gist sample plugin] for [http://wordpress.org/plugins/addthis/ Addthis]." wpsmith Tickets Needing Feedback 28226 menu_page_url does not return correct URL on network admin Plugins 3.0 normal normal defect (bug) new dev-feedback 2014-05-12T18:54:57Z 2019-06-04T20:47:00Z the `menu_page_url` function calls `admin_url` to build the URL returned. it should check for network admin first and use `network_admin_url` if present norcross Tickets Needing Feedback 18501 plugin_dir_path() returns unsanitized path on Windows installs Plugins 2.8 normal normal defect (bug) new dev-feedback 2011-08-23T18:40:29Z 2019-06-04T20:42:11Z "Currently plugin_dir_path() only returns the result of dirname( $file ), which can produce mixed results on local Windows installations. Attached patch takes pieces from plugin_basename() and plugins_url() to guarantee a working and accurate plugin directory path is returned in all operating systems. See #BB1596 (and associated revisions) for back-story." johnjamesjacoby Tickets Needing Feedback 56221 Add download URL to plugins REST create (install) endpoint TimothyBlynJacobs* Plugins 5.5 normal normal Future Release enhancement accepted dev-feedback 2022-07-14T21:51:39Z 2023-06-27T07:04:57Z "The `wp-json/wp/v2/plugins` endpoint allows installing plugins by POSTING the `slug` parameter. It then queries the .org plugin repo for the download link and proceeds to download and install that zip file using `Plugin_Upgrader`. I would like to be able to specify the download URL so I can install plugins from outside the .org plugin repo. My plan is to install plugins to my site when a I create a new release on GitHub, i.e. use GitHub Actions to POST the new download URL to my site, then serve the plugin to other sites using SatisPress. I tried unsuccessfully to find past related tickets that maybe discussed if omitting this functionality was intentional. It looks like a relatively easy change. I'll make PR for it soon. https://github.com/WordPress/WordPress/blob/4c265b66297074f09d66c17d9f14d11a5fffdb00/wp-includes/rest-api/endpoints/class-wp-rest-plugins-controller.php#L289-L313" brianhenryie 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 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 Tickets Needing Feedback 12718 Better structure for admin menu Plugins normal normal Future Release enhancement reopened dev-feedback 2010-03-26T01:05:37Z 2018-02-07T09:17:16Z "Currently, the global $menu variable is one big linear array: {{{ $menu = array( [2] => 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 Needing Feedback 17133 Code Editor: Register ctrl + s event for plugin/theme editor Plugins 3.1 high normal Future Release enhancement new has-patch 2011-04-14T12:20:34Z 2023-11-28T19:29:05Z Often when modifying code or writing a post using the wordpress editor I instinctively hit ctrl + s to save it. Up pops the save website dialog which I then have to close. In Gmail when I hit ctrl+ s it saves the email to drafts. I think a similar thing would be useful for wordpress. jcnetsys Tickets with Patches 38112 Deleting an Active Plugin via Bulk Actions Fails Silently Plugins normal normal Future Release defect (bug) assigned has-patch 2016-09-20T17:43:26Z 2022-09-21T12:03:20Z "With the introduction of shinier updates in 4.6, it appears that the error messaging around deleting an activated plugin wasn't ported into the new system properly. '''To reproduce:''' 1. On Plugins Screen, select an activated plugin. 2. From ""Bulk Actions"" select ""Delete"" 3. Click Apply '''Result:''' Nothing happens. Silent failure (to delete). '''Expected Result:''' Error message explaining that you can't delete activated plugins. In one case, I actually saw the expected error message after refreshing the plugins page, but I haven't been able to replicate that since." mrwweb Tickets with Patches 14060 "Misleading ""You do not have sufficient permissions to access this page.""" SergeyBiryukov Plugins 3.0 normal normal Future Release defect (bug) reviewing has-patch 2010-06-23T14:46:16Z 2019-03-29T23:35:02Z "When accessing a page of a plugin in the admin that does not exists any longer, you're told by an error message, that: > 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 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 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 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 __( '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 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 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 20241 make it possible for plugins to activate other plugins Plugins normal normal Future Release enhancement assigned needs-unit-tests 2012-03-15T12:48:59Z 2022-08-05T22:43:52Z "When creating a plugin that depends on other plugins, i would like to enable those plugins during activation of the main plugin. This is currently not possible, as updates to active_plugins done by the other plugins get overwritten. Please apply the attached patch to fix this." magnus78 Tickets with Patches 19388 plugin_basename returns full directory in URL Plugins 3.3 normal normal enhancement new needs-unit-tests 2011-11-29T00:36:36Z 2019-06-04T20:42:35Z "If a trailing slash is specified on either then WP_PLUGIN_DIR or WPMU_PLUGIN_DIR settings, the plugin_basename function returns the whole directory path in the URL. The documentation does state not to use a trailing slash, however I think this function could be improved. By removing the explicit / in the preg_replace the correct plugin name will be returned even if a trailing slash is specified on the WP_PLUGIN_DIR or WPMU_PLUGIN_DIR constants. This should not affect the relative path as the trim before the return takes care of stripping off the first slash if it exists (effectively duplicating the remove in this case). While this is a very trivial change that won't affect most people (who read the docs properly) it was quite annoying to track down. Please see the attached diff." damianzaremba 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 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 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 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 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 38183 Add hooks to be run before and after each callback Plugins normal normal Future Release enhancement new needs-unit-tests 2016-09-28T23:41:23Z 2017-08-25T21:15:07Z "Since before the dawn of time, debugging tools have relied on the `all` hook to collect information about how long hooks take to run, and which callbacks are registered to that hook. This has a few drawbacks. Primarily, it's not possible to collect timing information about individual callbacks, and it's quite difficult to manage recursive hook behaviour. With that in mind, hooks that run before and after each callback would be quite valuable, but they do need to be considered carefully. * What kind of performance impact would they have? If there are no callbacks registered to these hooks, there should ideally be no performance impact. * Should they be `WP_DEBUG` only? This would discourage plugins from abusing them on production systems - they would only be used if the site admin explicitly sets the site to debugging mode. * Dealing with recursion is fun, should they provide any helpers for indicating recursion level, or is it up to the code hooking into them to handle that?" pento 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 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 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 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 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 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 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 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 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