WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 18 months ago

#24048 new enhancement

Increase the usability of Plugin Editor's files list (separate directories, limit height)

Reported by: Daedalon Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.5.1
Component: Plugins Keywords: needs-patch
Focuses: ui Cc:

Description

Regarding the list under Plugin Files in the Plugin Editor (plugin-editor.php):

  1. Plugin root directory does not need to be mentioned in the file list.
  1. In order to improve readability, directories should be marked in a way that distinguishes them from the filename.

Preferably directories should not be shown next to every file, but rather as headers, under which all files in the same directory are grouped. This would make the list a lot shorter, as currently most of the filename-and-path-combinations span two lines.

  1. The form of the list should be changed to limit the total height of the list. This is especially useful for plugins with dozens of editable files.

One way would be to use a < ul > element with expansible/collapsible directory headers, showing only the first-level directories and files by default.

Change History (13)

#2 @helen
3 years ago

  • Focuses ui added
  • Keywords needs-patch added
  • Type changed from defect (bug) to enhancement

I have to admit that I'm not super excited about the prospect of either making some kind of tree nav or implementing and then maintaining an existing, compatible script. Something native to jQuery UI sounds nice but it doesn't seem to have any traction.

I also rather dislike the idea of making this look and feel like a sustainable way to be editing files. I don't think we should get rid of the file editors, but I also don't see any reason to make them particularly convenient or comfortable.

I could maybe get behind some basic headers. Probably need to fix #6531 first or alongside.

#3 follow-up: @bpetty
3 years ago

We've certainly had numerous discussions about removing the editors. In fact, even as a developer who writes a popular plugin focused on making these editors more usable, I've still argued the case for removing them myself. I don't think they ever will be though.

Regardless, they are here, and as long as they're here, there's no reason to ignore patches that improve their usability. I wouldn't discourage contributors from writing patches just because a number of us continue to debate whether they should be in core at all.

As for relying on and distributing another 3rd party library in core just for a file tree view, and also adding the requirement for JS to use the editors, that's something that does need to be discussed. It's obviously possible (as we currently do) to provide an interface that doesn't rely on JS or any 3rd party libraries, and it's not terrible. Also, in my opinion, pulling in a new 3rd party library to handle things like this screams "plugin territory" to me.

We could go for a smaller and more simple patch that provides some basic UI improvements to the current functionality that takes advantage of faster and smaller AJAX requests to navigate the tree when JS is available without reloading the editor itself (and making it possible to navigate the tree without losing unsaved changes in the editor), but continues to fall back gracefully on it's current behavior otherwise.

I also would be interested to see some new designs around how files are listed, and as this has bothered me significantly in the past, seeing designs that don't incorporate file descriptions in the list itself or sort files by those descriptions by default instead of by filename. I find that incredibly frustrating every time I use these editors myself, and I know others do too.

Those are just a couple ideas that would be more realistic, and have a better shot at being applied.

#4 in reply to: ↑ 3 ; follow-up: @helen
3 years ago

Replying to bpetty:

Regardless, they are here, and as long as they're here, there's no reason to ignore patches that improve their usability. I wouldn't discourage contributors from writing patches just because a number of us continue to debate whether they should be in core at all.

Not totally sure who or what you're addressing. There's no patch here, and I don't think the debate about keeping the editors is anything beyond academic. They're staying. :)

Anyway, let's just remember that these are basic editors and we should keep things basic. Think of them as a stepping stone to learning about more full-fledged development. If we make them too fancy/IDE-ish, it conveys the message that it's a good idea to be cowboy coding all the time, when it's not. But, speaking from personal experience, they can be a great way for somebody to find a whole new world of things to learn.

Design/concepts and/or patches happily encouraged here. Again, it could be as basic as adding some headers and showing files in a reasonable order and grouping.

#5 in reply to: ↑ 4 ; follow-up: @bpetty
3 years ago

Replying to helen:

Not totally sure who or what you're addressing. There's no patch here, and I don't think the debate about keeping the editors is anything beyond academic. They're staying. :)

I wasn't claiming there was one, just clarifying that despite your comments, it didn't mean no-one should bother even submitting a patch (because that's what it sounded like).

If we make them too fancy/IDE-ish

Certainly not advocating building a full IDE here either. We're just talking about making the file tree (that we already provide) actually work the way it was intended to. If you think providing a way to actually select files to edit is too much of an "IDE feature", then we have a case for removing it entirely. We're not in the habit of adding half-working features just because we sort of think it should be there, but we've intentionally made it difficult (and in some situations here, impossible) to use in order to discourage users from using it.

I completely understand your concerns here, but we're not talking about optional new features like "jump to file", "find in files", syntax highlighting, line numbers, or anything like that. This is absolutely required functionality for selecting which file to edit. It doesn't get more basic than that.

#6 in reply to: ↑ 5 @helen
3 years ago

Replying to bpetty:

I don't even know what you're talking about anymore. If for some bizarre reason I was opposed to making this better at all, I would have closed the ticket. Let's quit this non-discussion so as not to scare anybody else off, because even I'm scared now.

#7 @nacin
3 years ago

Well, I don't know what either of you are talking about, so there. :-)

Right now, the plugin screen lists the path to each file. There are a few ways to improve this. One would be "grouping" each level and directory with a heading, and then all files below that header are inside that directory. This would probably be "flat", with a heading specifying the full path to that directory, versus some kind of hierarchy.

Another option is to actually show hierarchy. This would require some sort of tree. It doesn't necessarily need to be collapsible, and I really wouldn't think we need to bring in a new JS library for this. Simple nested unordered lists with a dash of JS would get the right result. If you wanted a full-fledged "tree view" file browser, I think that would be plugin territory.

I don't know which is best. And really, I don't know if either of them would be a significant improvement. Perhaps we could at the very least chop off a common path. Right now if you edit a plugin within a folder, you get the full path on top of the page (makes sense) but also the folder repeated all the way down the tree. Even just removing that one segment would probably go a long way to cleaning this up, and I don't think we'd even need to do much more than that.

#8 @Daedalon
3 years ago

I agree with Nacin. It would improve the UI significantly just to:

  1. Not display the common part of the path (the plugin root directory)
  2. Arrange files in groups by folders where the folder name is a header instead of being repeated for every filename.
  3. Make the list collapsible.

Any of the above steps would improve the usability considerably by itself, so it's best to implement even just one of them for 3.9 instead of making them all depend on the most debatable one.

The ideal end result would look something like http://www.jqueryscript.net/other/jQuery-Flat-Folder-Tree-Plugin-simplefolders.html.

To comment on 'cowboy coding', I'd like to emphasize that having an editor doesn't require using it carelessly. I know people (e.g. students) who do a bulk of their site development through WP-admin due to a limited ability to install anything. The editor can be used on a dummy site from where it's easy to copy the finished changes to a live one. For many of those who use plugin solutions, the editor in core was a crucial first step and is an important backup.

#9 @mordauk
3 years ago

Aside from visual aides, one of the main reasons I'd get behind this is simply to provide a way to edit any file within a plugin or theme. As it stands, the plugin / theme does not always make all of the files of the theme or plugin available. I'm not sure of the exact logic for how the files are loaded, but it seems that only files included directly into the main plugin file or theme's functions.php file are displayed.

The WP Editor plugin gets around this limitation by providing a browsable directory structure. I think it's overkill for what this ticket should and/or could introduce, but it does provide a nice contrast in usability to the current editor.

To summarize, I'd love to see the ability to show / edit all files within a plugin or theme instead of just some.

Last edited 3 years ago by mordauk (previous) (diff)

#10 @Daedalon
3 years ago

That's a good point, Mordauk. #6531 is a separate ticket about that.

#11 @helen
3 years ago

Yes, the bug regarding actually listing files should be fixed.

I in no way oppose improvements here. I am just cautious about going too far and people getting *too* comfortable in the editor, when they should probably eventually be encouraged to grow out of it if it becomes a common task. A nested unordered list with proper hierarchy and maybe some headers seems like it could go a long way.

#12 @chriscct7
18 months ago

I personally think this would make a great usability enhancement. I don't use the editors often myself, but I know alot of users do, and when trying to find a file in a several hundred file plugin, it's a nightmare in the editor currently.

#13 @DrewAPicture
18 months ago

Still no patch here, which is what this ticket needs to move forward.

Note: See TracTickets for help on using tickets.