Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#54382 closed task (blessed) (fixed)

Finalise the Theme Editor admin menu item placement

Reported by: poena's profile poena Owned by: hellofromtonya's profile hellofromTonya
Milestone: 5.9 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch needs-docs needs-dev-note commit i18n-change
Focuses: ui Cc:

Description (last modified by poena)

From WordPress 5.9, the appearance menu will include an item called Editor, which leads to the new template editor (the full site editing site editor).
This new menu item is only available if a block theme is active.

https://github.com/WordPress/gutenberg/issues/29630

Having both an Editor menu item and a Theme editor menu item may be confusing.
To reduce confusion the theme editor menu item could be moved to tools.

Attachments (6)

appearance.png (8.9 KB) - added by poena 2 years ago.
Theme Editor menu item under appearance
54382.patch (1.1 KB) - added by poena 2 years ago.
Menu item moved from Appearance (themes.php) to Tools (tools.php).
theme-editor-tools-menu-54382.png (54.4 KB) - added by poena 2 years ago.
The appearance and tools menus after the patch is applied
54382-2.patch (1.7 KB) - added by poena 2 years ago.
Alternative 2, move both plugin editor and theme editor menu items to tools.
Capture d’écran 2021-11-25 à 21.48.15.png (327.1 KB) - added by audrasjb 2 years ago.
What about calling it the "Theme files editor"?
test-543892-after-pr1948-applied.gif (4.7 MB) - added by hellofromTonya 2 years ago.
Test Report: After applying PR 1948 : TT1 menu items in original locations and renamed; TT2 both are in Tools and renamed. ✅

Change History (59)

@poena
2 years ago

Theme Editor menu item under appearance

#1 @poena
2 years ago

  • Description modified (diff)

@poena
2 years ago

Menu item moved from Appearance (themes.php) to Tools (tools.php).

@poena
2 years ago

The appearance and tools menus after the patch is applied

#2 @poena
2 years ago

  • Keywords has-patch added

#3 @manfcarlo
2 years ago

Would it be a good idea to move the Plugin Editor to Tools as well? It seems lop-sided to move one but not the other.

@poena
2 years ago

Alternative 2, move both plugin editor and theme editor menu items to tools.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


2 years ago

#5 @desrosj
2 years ago

I am not sure moving the menus is the right solution here.

Personally, I think "Editor" is too generic and could cause confusion with the post editor, widget editor, etc.

#6 @hellofromTonya
2 years ago

I agree with @desrosj. I think moving pre-existing menus can cause confusion for users. I think the generic "Editor" name needs more thought to make it meaningful and easily understandable to users that the menu item is specifically for Template/Full site/Site Editor.

Leaving this ticket open past feature feature for more discussion.

#7 @poena
2 years ago

Instinctively I also felt that renaming the site editor menu item was confusing - not only because as a Gutenberg user and block theme developer I had gotten used to the menu.
-But because it would make it more difficult to differentiate between the different types of editors when providing support.

But as that decision had already been made, and the Editor menu item is already commited, this felt like the least bad solution for the Theme Editor menu item.

The other suggestion that was brought up was to completely remove the theme editor, with the argument that it is no longer needed. I strongly disagree with that.

I don't think this is the right ticket for continuing discussing the naming of the new editor, since that has been an ongoing discussion since March.
Continuing that discussion here would not surface it, since this Trac ticket was specifically for the theme editor.

https://github.com/WordPress/gutenberg/issues/29630

https://make.wordpress.org/design/2021/10/15/site-editing-ia-concepts-how-to-surface-and-access-new-features/

https://make.wordpress.org/design/2021/10/22/site-editing-ia-concepts-part-2/

Last edited 2 years ago by poena (previous) (diff)

#8 @poena
2 years ago

I now see that a new issue for moving the theme editor was opened in the GitHub repository earlier today:
https://github.com/WordPress/gutenberg/issues/36354

#9 @Clorith
2 years ago

Putting my voice in that I agree that "Editor" is quite generic, and just because it's been committed, there's nothing preventing renaming this to be more descriptive. I'd not be opposed to something like "Template Editor" being the label for the menu item, it's to the point, and removes ambiguity.

I'm also not convinced that moving the theme editor is the right option, there's too many editors to keep track of as is, and in moving it we would cause confusion for many years worth of existing user-made documentation about that one.

#10 @poena
2 years ago

If this is where you prefer to continue the discussion :), then I will add that there already is a template editor.

https://make.wordpress.org/core/2021/06/16/introducing-the-template-editor-in-wordpress-5-8/

The template editor was added in 5.8 and is accessed via the block editor when a theme or plugin has added support for it.
A full site editing theme is not needed to use the template editor.

The template editor and what we have called the site editor until now has some differences, they are not the same editor, I would recommend against using this label.

In the template editor you view the content you created in the post and page, as part of a template.
In the site editor, you view the same templates but with placeholder content.
In the site editor you edit the homepage, blog, archives, 404 etc, and you have access to the global styles.

Last edited 2 years ago by poena (previous) (diff)

#11 @poena
2 years ago

Please note that a pull request that moves the menu item to tools only when a full site editing theme is active, has been merged into Gutenberg:
https://github.com/WordPress/gutenberg/pull/36723

#12 @youknowriad
2 years ago

I didn't know about this ticket so I went ahead with the PR but happy to follow-up with any actionable item we agree upon.

Personally for me, I'd be in favor of removing the "theme editor" entirely because for FSE themes, the site editor is a "theme editor" but instead of changing files, it changes the theme in the database. For the user, it's still a theme editor no matter how it's done.

That said, I'm also ok with moving it under "tools" to deamphasize it and avoid ambiguity with the new theme/site editor.

@audrasjb
2 years ago

What about calling it the "Theme files editor"?

#13 @audrasjb
2 years ago

☝️ what about calling it the "Theme files editor"?
Maybe it's too redundant, but it actually describes what it does :)

(and the "Plugin editor" would also be replaced with "Plugin files editor", which is not that bad since it also describes what it does)

Last edited 2 years ago by audrasjb (previous) (diff)

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


2 years ago

#15 follow-up: @johnbillion
2 years ago

  • Keywords needs-design-feedback needs-patch added; has-patch removed
  • Summary changed from Move the Theme Editor admin menu item to Finalise the Theme Editor admin menu item placement
  • Type changed from enhancement to task (blessed)

Note that in the PR that Caroline linked above, the existing Theme Editor menu was moved into Tools. Riad mentioned that he mistakenly thought a decision had been made.

Moving existing menu items causes a burden for end users. The existing Theme Editor is not a feature we can retire just yet. Take a look at how real users customise their site and you'll see usage of the Theme Editor many times higher than us contributors would like to imagine. Moving this menu item creates an inconsistency when switching between FSE-enabled themes and existing themes, and it will place burden on end users who expect it to be where it always is and on support volunteers in the forums.

I think the Theme Editor menu item should be reinstated into its previous position under Appearance and be renamed Theme File Editor. As JB mentioned, for consistency the plugin equivalent can be renamed Plugin File Editor.

This ticket was mentioned in PR #1948 on WordPress/wordpress-develop by audrasjb.


2 years ago
#16

  • Keywords has-patch added; needs-patch removed

#17 @audrasjb
2 years ago

  • Keywords needs-docs needs-dev-note added

#18 @audrasjb
2 years ago

The PR above is a proposal to implement the change to Theme|Plugin File Editor. It also reverts the previous change that was moving the Theme Editor to the Tools menu.

#19 in reply to: ↑ 15 ; follow-up: @SergeyBiryukov
2 years ago

Replying to johnbillion:

I think the Theme Editor menu item should be reinstated into its previous position under Appearance and be renamed Theme File Editor. As JB mentioned, for consistency the plugin equivalent can be renamed Plugin File Editor.

This seems like the preferred approach to me as well.

#20 @youknowriad
2 years ago

I disagree with keeping it in the previous place personally. For me with FSE themes we shouldn't be assuming any prior experience with themes. It's a new kind of UX we want to propose to our users. And the theme editor is a suboptimal side editor as it's there to edit the theme files where we can edit these (styles and templates) in a better way in the site editor for FSE themes.

I personally prefer to move it under tools or remove it.

#21 @audrasjb
2 years ago

Even if we move it elsewhere, renaming would be necessary to avoid misunderstanding.

And the theme editor is a suboptimal side editor as it's there to edit the theme files where we can edit these (styles and templates) in a better way in the site editor for FSE themes.

I agree with you concerning template files, but what about configuration files, like functions.php and other files that could be living in some /inc folders? (and even theme.json itself)

With a better name for the file editor, it would be easier to identify the purpose of each submenu item.

Last edited 2 years ago by audrasjb (previous) (diff)

#22 @Joen
2 years ago

“Editor” is a good term, especially in context of the Apperance menu. This is inclusive of people new to WordPress.

The classic theme editor I personally think of as a power-user tool which you should very rarely use, if ever, given it has direct access to the file system. The fact that it comes with a warning modal as soon as you enter it, suggests that it could well be placed in context of other power tools. In that light, placement in the Tools menu — whether permanent along with the Plugin editor, or just when a block theme is active — makes a lot of sense to me.

#23 @audrasjb
2 years ago

I'm not strongly opposed to move it to Tools submenus, though we have to consider the fact that people won't be able to find it anymore, which will generate many support requests. While it's an understandable move from the perspective of block themes, I think we need to take care of the current state of the ecosystem.

If we decide to move the plugin/theme file editor in Tools, a dev note on Make/Core won't be enough. We need at least a clear callout in the about page …and I'm not sure it's enough since WordPress auto-updates itself, so most users won't see this page.

#24 @youknowriad
2 years ago

The removal of the Customizer is in a lot of ways more impactful for users (and potential support requests) than the theme editor. I agree that we need documentation about this and I do think all of this should be part of the introduction of the block themes experience, no matter what format is that.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


2 years ago

#26 in reply to: ↑ 19 @joyously
2 years ago

Replying to SergeyBiryukov:

Replying to johnbillion:

I think the Theme Editor menu item should be reinstated into its previous position under Appearance and be renamed Theme File Editor. As JB mentioned, for consistency the plugin equivalent can be renamed Plugin File Editor.

This seems like the preferred approach to me as well.

I agree with Sergey and John that the existing menu item should stay put, perhaps renamed, because of the millions of existing users and documentation.
I can't tell if the proposal is for this menu item to move dependent on the theme, but that's not a good idea. It should be stable.
Also, even if you are using a block theme, you might want to tweak the base HTML or JSON, so this should be available the same as always.

Make the new thing have a new name and leave the old one alone.

#27 @audrasjb
2 years ago

I still think it was suboptimal to move an "Appearance" related screen to "Tools". It's not a good place for this feature.

But given we're almost at beta 3 stage, we need a compromise here. I suggest the following:

  • keep the changes introduced in https://github.com/WordPress/gutenberg/issues/29630 (it moved the Theme Editor to the "Tools" submenu for Block Themes)
  • properly document that change somewhere in the WP 5.9 callout
  • rename "Theme Editor" to "Theme File Editor" (and "Plugin Editor" to "Plugin File Editor") to help users to differentiate the two submenus (we should not have two different features with the exact same submenu label, even if it's not under the same menu section)

Thoughts? @youknowriad @Joen @SergeyBiryukov @johnbillion

#28 @costdev
2 years ago

I'm inclined to agree with previous comments from @johnbillion, @hellofromTonya, @Clorith, @SergeyBiryukov and @joyously.

A few points:

  • The Theme Editor is not just for power users. If a user wants to change some text, etc. sometimes the only available way at that time is to paste a filter snippet from support forums into the functions.php file. This requires zero knowledge about FTP or hosting control panel based file managers.
  • Unless I'm mistaken, the Theme Editor should still apply for block themes for the same reason as above.
  • Every support response that mentions the Theme Editor (on various websites that is, not just WP.org) will need to differentiate instructions between 5.9+ and <5.9, purely because we named something "Editor" and moved the old to make way for the generically-labelled new. "Editor" is a good term for it, but not when there's other editors available.
  • A decision to move menu items should be considered final given the impact it has and a repeat of that would cause unnecessary frustration for users.
  • We don't have consensus for this change. That usually means we don't implement the change.

@poena originally stated "Having both an Editor menu item and a Theme editor menu item may be confusing". I agree. As we don't have consensus for moving the menu items, what about one of these alternatives?

  1. Keep all three items in the submenu without changing the names. We can decide to change this in a later version based on user feedback.
  2. Keep all three items in the submenu, change "Editor" to "Site Editor".
  3. Keep all three items in the submenu, change "Theme Editor" to "Theme File Editor" and change "Plugin Editor" to "Plugin File Editor".
  4. Keep all three items in the submenu, change "Editor" to "Site Editor", "Theme Editor" to "Theme File Editor" and change "Plugin Editor" to "Plugin File Editor".

A Make post with a call for opinions may be appropriate to bring wider community opinion in on this.

Version 2, edited 2 years ago by costdev (previous) (next) (diff)

#29 @hellofromTonya
2 years ago

tl;dr

  • Need to restore the Theme Editor menu item under Appearance
  • Not opposed to renaming "Theme Editor" to "Theme File Editor" and "Plugin Editor" to "Plugin File Editor"
  • Strings need to be changed before Beta 3, as it's the soft string freeze

Replying to audrasjb:

I still think it was suboptimal to move an "Appearance" related screen to "Tools". It's not a good place for this feature.

Replying to johnbillion:

Moving existing menu items causes a burden for end users. The existing Theme Editor is not a feature we can retire just yet. Take a look at how real users customise their site and you'll see usage of the Theme Editor many times higher than us contributors would like to imagine. Moving this menu item creates an inconsistency when switching between FSE-enabled themes and existing themes, and it will place burden on end users who expect it to be where it always is and on support volunteers in the forums.

I think the Theme Editor menu item should be reinstated into its previous position under Appearance and be renamed Theme File Editor. As JB mentioned, for consistency the plugin equivalent can be renamed Plugin File Editor.

I agree with @johnbillion. This menu item cannot be retired (yet) nor should it be relocated for the reasons he laid out. It should be reinstated to its original position.

Replying to audrasjb:

  • rename "Theme Editor" to "Theme File Editor" (and "Plugin Editor" to "Plugin File Editor") to help users to differentiate the two submenus (we should not have two different features with the exact same submenu label, even if it's not under the same menu section)

Renaming to add File could also be confusing/disruptive for/to existing workflows when switch between theme types.

I don't find the original menu item naming to be confusing with "Editor <beta>" for site editor for existing users. New users may find it confusing, though clicking/activating either menu item clearly shows what each does. That said, I'm not opposed to the renaming, but it needs to be done before Beta 3 (soft string freeze).

hellofromtonya commented on PR #1948:


2 years ago
#30

@audrasjb can you update this PR to fix the merge conflicts?

audrasjb commented on PR #1948:


2 years ago
#31

Conflicts resolved. The failing e2e test looks unrelated.

#32 @audrasjb
2 years ago

Alright. Thank you all 👍
I'll make sure to commit PR1948 before beta 3.

Last edited 2 years ago by audrasjb (previous) (diff)

audrasjb commented on PR #1948:


2 years ago
#33

I think we should not move it back to appearance, having two ways to edit themes under appearance feels couter productive to me.
cc @jasmussen @jameskoster @mtias

Please note that it's also discussed in the related Trac ticket: https://core.trac.wordpress.org/ticket/54382

I proposed a compromise for 5.9 but it appears there is more committers voices supporting moving it back under Appearance menu.

jasmussen commented on PR #1948:


2 years ago
#34

To echo Riad, and to restate my comments from the trac ticket, I would be concerned with having two theme editing tools under appearance, one of them opening with a warning modal and risking changes being overwritten by theme updates.

jameskoster commented on PR #1948:


2 years ago
#35

Situations in which you'd need to use the file editor whilst a block theme is active seem almost non-existent. Especially because editing the source file won't have any effect if you've also edited the corresponding entity in the Site Editor already. This could make for some _very_ confusing experiences.

At the very least I think the file editor should be de-emphasised when a block theme is active.

hellofromtonya commented on PR #1948:


2 years ago
#36

Folks for voicing opinions. However, see @johnbillion's comment as to why this PR restores the Theme File Editor:

Moving existing menu items causes a burden for end users. The existing Theme Editor is not a feature we can retire just yet. Take a look at how real users customise their site and you'll see usage of the Theme Editor many times higher than us contributors would like to imagine. Moving this menu item creates an inconsistency when switching between FSE-enabled themes and existing themes, and it will place burden on end users who expect it to be where it always is and on support volunteers in the forums.

hellofromtonya commented on PR #1948:


2 years ago
#37

Looks like this PR is blocked for Beta 3. Needs to be resolved by Beta 4.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


2 years ago

jameskoster commented on PR #1948:


2 years ago
#39

I don't think anyone is suggesting to retire the feature. This is just an exercise in adjusting its prominence to suit an evolving site editing landscape.

To me this feels like an extension of the decision to conditionally hide the Customizer. If we apply the principles that lead to that decision here, then it seems sensible to be consistent, and do something similar with the theme file editor.

I totally appreciate the desire to minimise any disruption to current user flows and honour existing documentation. But if the trade-off is a confusing in-product user experience then it seems like a direction worth questioning.

0aveRyan commented on PR #1948:


2 years ago
#40

I hear the argument for making this change, but it should have been made months ago to make this release. The Customizer decision was made with ample time for the ecosystem to prepare. Last minute changes without ample time for input and preparation are confidence damaging. I think this change should be made iteratively and targeted for 6.0.

hellofromtonya commented on PR #1948:


2 years ago
#41

To echo Riad, and to restate my comments from the trac ticket, I would be concerned with having two theme editing tools under appearance, one of them opening with a warning modal and risking changes being overwritten by theme updates.

That same argument though can made for Customizer and Theme Editor menu items that existed in the Appearance menu before 5.9.

To me this feels like an extension of the decision to conditionally hide the Customizer. If we apply the principles that lead to that decision here, then it seems sensible to be consistent, and do something similar with the theme file editor.

The Site Editor is _replacing_ (and hiding) the Customizer for block themes.

Users have had 2 menu items under Appearance to customize their site via (a) selective/interactive interface or (b) via directly editing files within a file editing interface.

  • Pre-5.9: Customize menu was (a) and the Theme Editor menu was for (b).
  • 5.9: Site Editor is (a) and the Theme File Editor is still for (b).

These 2 menu items are different. The way each presents is very different. It's clear that Customizer or Site Editor is very different from the file editor interface with Theme File Editor. Personally, I don't see a workflow issue or why keeping the file editor in place would cause confusion or concern, whereas moving it could cause a burden on extenders and users as information has existed for years and is present across the web of what the Theme Editor is and what it does.

If there's a need to relocate these file editors (i.e. the theme and plugin versions), 6.0 would be a good target. That gives more time to collect user feedback and analyze UX workflows to determine if a problem exists or not with the file editor existing in the same Appearance menu space.

#42 @hellofromTonya
2 years ago

  • Keywords commit added

Marking PR 1948 for commit. This PR restores the menu item back to Appearance and renames it from "Theme Editor" to "Theme File Editor" for more clarity that it's for (and always has been for) editing theme files.

jameskoster commented on PR #1948:


2 years ago
#43

I disagree, and see the Site Editor as a visual evolution of the file editor as much as a replacement for the Customizer. Since it is able to interpret block theme files, I can think of very few situations in which you would want to edit the source files in wp-admin. Consequently it's a feature we should consider de-emphasising. Of course it's quite possible I'm missing something so would be keen to understand common use cases for the file editor.

As for confusing scenarios, here's one: You edit your Index template in the Site Editor, (creating a custom Index template in your database behind the scenes). You then go and edit the same Index template in the file editor, but the contents are different (because the site editor does not overwrite the original file) and your changes do not manifest on the frontend (because the template in the db is prioritised over the theme file). Without an understanding of the underlying technicals it's not clear at all why these editors behave differently.

hellofromtonya commented on PR #1948:


2 years ago
#44

As for confusing scenarios, here's one: You edit your Index template in the Site Editor, (creating a custom Index template in your database behind the scenes). You then go and edit the same Index template in the file editor, but the contents are different (because the site editor does not overwrite the original file) and your changes do not manifest on the frontend (because the template in the db is prioritised over the theme file). Without an understanding of the underlying technicals it's not clear at all why these editors behave differently.

@jameskoster thank you for raising this scenario. You're right.

A thought came to my mind this morning. The evolution is towards no-code. FSE with the Site Editor is part of that evolution. There's a solid argument to made that file/code editor interfaces do not fit within the next generation no-code workflows. These file/code editor interfaces are rather tools, and thus are better aligned under Tools.

Given the valid user confusion scenarios James raised combined with the next step forward towards no-code workflows in 5.9, I can see and now do support moving this file/code editor interfaces to Tools.

Next questions:
To avoid confusion, should the menu item be changed to Theme File Editor to more clearly denote what it does? And should the Plugin File Editor menu item also be relocated under Tools?

I'm thinking yes to both of these questions.

#45 @hellofromTonya
2 years ago

  • Keywords commit removed

Given the valid user confusion scenarios James raised combined with the next step forward towards no-code workflows in 5.9, I can see and now do support moving this file/code editor interfaces to Tools.

See my full comment and thinking iteration. Removing the commit keyword. Why?

I now agree that the original Theme Editor menu item no longer aligns to the Appearance as 5.9 takes a leap forward towards no-code workflows. The PR needs to remove that part of the change.

Also, there's the open question of also relocating the original "Plugin Editor" to the "Tools" section for a consistent file/code editing interface tool set.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


2 years ago

#47 @hellofromTonya
2 years ago

  • Keywords needs-design-feedback removed

There was an open, collaborative discussion about this ticket in the Making WordPress #core slack channel today. Consensus reached:

  • Rename both the Theme Editor and Plugin Editor menu items to include "File" for classic and block theme powered sites
  • Keep the Theme File Editor in Tools for block themes
  • Relocate the Plugin File Editor in Tools under the Theme File Editor menu item for block themes
  • For non-block themes, keep the menu items in their original locations

Further exploration of user research/feedback can happen in 6.0 to determine the next steps in consolidating workflows.

@hellofromTonya
2 years ago

Test Report: After applying PR 1948 : TT1 menu items in original locations and renamed; TT2 both are in Tools and renamed. ✅

#48 @hellofromTonya
2 years ago

  • Keywords commit i18n-change added

Test Report

Env:

  • OS: macOS Big Sur
  • Browser: Edge, Chrome, Firefox, Safari
  • Plugins: None
  • Theme: TT1 and then TT2
  • Localhost: wp-env

Steps

  1. Pull down and apply PR 1948
  2. Go to Appearance > Themes
  3. Activate Twenty Twenty-One (TT1) theme

Expected behavior:

  • Under Appearance, the "Theme Editor" menu item is renamed to "Theme File Editor".
  • Under Plugins, the "Plugin Editor" menu item is renamed to "Plugin File Editor".
  • Neither of these file editors appear in Tools.
  1. Activate Twenty Twenty-Two (TT2) theme

Expected behavior:

  • Under Appearance, the "Theme Editor" menu item does not appear.
  • Under Plugins, the "Plugin Editor" menu item does not appear.
  • Under Tools, the "Theme File Editor" and "Plugin File Editor" menu items are present.

Results

  • With TT1 (or any non-theme.json theme), the theme/plugin editor menus are retained in their original locations and are renamed ✅
  • With TT2, the theme/plugin editor menus are relocated to Tools and are renamed ✅

Marking PR 1948 for commit and adding the i18n-change keyword for the late string changes.

#49 @hellofromTonya
2 years ago

  • Owner set to hellofromTonya
  • Status changed from new to reviewing

Self-assigning for commit.

hellofromtonya commented on PR #1948:


2 years ago
#50

Folks, there was an open, collaborative discussion in Making WordPress slack core channel today. Attendees included @johnbillion, @costdev, @Clorith, @ipstenu, @audrasjb, @pbiron, and others. Consensus reached to:

  • Keep the Theme Editor under Tools for block themes
  • Move the Plugin Editor too for block themes (for consistency)
  • Rename both to include "File" in their menu names

Retaining the change to relocate these file editors to Tools aligns with direction and consensus from the core editor team. Thus, this PR is now unblocked and ready for Beta 4.

#51 @hellofromTonya
2 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 52406:

Administration: Add "File" to Theme/Plugin Editor menu names and relocate "Plugin File Editor" to Tools for block themes.

[52232] relocated the Theme Editor menu item from Appearance to Tools for block themes. This commit relocates the Plugin Editor menu item from Plugins to Tools for block themes for a consistent workflow.

Both the Theme Editor and Plugin Editor menu items are renamed to "Theme File Editor" and "Plugin File Editor" respectively. Why? To better identify their purpose, i.e. to directly edit the code in the theme or plugin files. The rename is not limited to only block themes.

Follow-up to [52232].

Props poena, annezazu, audrasjb, clorith, courane01, costdev, dryanpress, desrosj, hellofromTonya, ipstenu, jameskoster, joen, johnbillion, joyously, manfcarlo, marybaum, pbiron, SergeyBiryukov, walbo, youknowriad.
Fixes #54382.

#53 @annezazu
2 years ago

Just noting that I'm tracking user documentation changes due to this PR in this issue: https://github.com/WordPress/Documentation-Issue-Tracker/issues/91 I welcome folks reviewing in case there are spots I haven't found that need updates :)

Note: See TracTickets for help on using tickets.