Opened 11 years ago
Closed 8 years ago
#24122 closed defect (bug) (fixed)
When opening a file in Plugin Editor, show correct plugin in the dropdown selector
Reported by: | Daedalon | Owned by: | swissspidy |
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | minor | Version: | |
Component: | Plugins | Keywords: | has-patch commit |
Focuses: | administration | Cc: |
Description
When opening a file in Plugin Editor, the reloaded page shows the first plugin according to alphabetical order in the dropdown next to "Select plugin to edit:". It should default to the plugin the loaded file belongs to.
Steps to reproduce
- Open wp-admin/plugin-editor.php
- Select any plugin from the "Select plugin to edit:" dropdown except the alphabetically first one, eg. WordPress Beta Tester, and click Select.
- The page reloads and WordPress Beta Tester is shown as the default value in the dropdown, as expected.
- Click any file under Plugin Files, eg. wordpress-beta-tester/readme.txt
-> The page reloads and shows the file in editor. However, "Select plugin to edit:" doesn't have a value set and shows the first plugin in alphabetical order by default.
-> However, if you chose the main plugin file, eg. wordpress-beta-tester/wp-beta-tester.php, "Select plugin to edit:" shows the correct plugin as the default value.
Any clicked file should lead to its plugin used as the default value for "Select plugin to edit:".
Attachments (5)
Change History (21)
#1
@
11 years ago
- Keywords has-patch added
The bug was there because when a file is selected for editing, it passes the filename
to $plugin
which compares $plugin
with the primary file of all plugins to find which plugin the file is a part of.
Fixed the bug by exploding the two strings, and comparing the first elements.
#4
@
10 years ago
I think the root of this problem is in different place. Here is where $plugin variable gets its awkward value:
if ( $file ) { $plugin = $file; } elseif ( empty( $plugin ) ) { $plugin = array_keys($plugins); $plugin = $plugin[0]; } $plugin_files = get_plugin_files($plugin); if ( empty($file) ) $file = $plugin_files[0];
It seems that it is done to invoke the get_plugin_files(), even when $plugin is not set. I think the whole thing should be the other way around:
if ( empty( $plugin ) ) { $plugin = array_keys($plugins); $plugin = $plugin[0]; } if ( empty($file) ) $file = $plugin; $plugin_files = get_plugin_files($file);
If $plugin is not set it will auto-resolve to the first plugin in the list. If $file is not set it will default to $plugin, which at this moment will be a path to the plugins entry file. Then to retain the logic of retrieving only a single level of files to list in the sidebar (another awkward behavior I think), we pass $file, instead of $plugin to get_plugin_files().
#7
follow-up:
↓ 8
@
10 years ago
I've tested this patch today and it needs a little adjustment.
Assume you have Aksimet and Akismet Spam Count, the main files are akismet/akismet.php and akismet_count.php respectively.
The current code evaluates both of these items as 'selected' in the drop down so when in the editor on Akismet you are selected for Aksimet Spam Count in the drop down. This can be remedied by adding a trailing slash to the path as per the attached patch.
#8
in reply to:
↑ 7
;
follow-up:
↓ 9
@
10 years ago
Replying to MattyRob:
I've tested this patch today and it needs a little adjustment.
Assume you have Aksimet and Akismet Spam Count, the main files are akismet/akismet.php and akismet_count.php respectively.
Have you tried my original patch? I do not seem to encounter such problem. Not sure why it was modified any further.
#9
in reply to:
↑ 8
@
10 years ago
- Keywords tested commit added
Replying to jayarjo:
Have you tried my original patch? I do not seem to encounter such problem. Not sure why it was modified any further.
I have now, I just presumed that the latest patch would be the most reliable. Having tested the #24122_fix_logic.diff patch I can confirm that it works perfectly so would propose that it gets committed (if a core committer is looking).
#10
@
10 years ago
- Keywords tested commit removed
#24122_fix_logic.diff still doesn't work if you click the Update File button.
The patch on #17552, however, appears to resolve both tickets.
#13
@
8 years ago
- Milestone changed from Awaiting Review to 4.7
35788.diff is an updated patch that solves this issue as well as #17552.
See #35788 for details.
#14
@
8 years ago
- Focuses administration added
Gave @swissspidy's patch a test, fixed the issue for me.
Fixes bug by changing the way the strings were being compared