Make WordPress Core

Opened 5 years ago

Last modified 7 weeks ago

#55524 new defect (bug)

Menus listing alphabetized bug, Upload pages cleanup, and Hide the browsers.

Reported by: akissz Owned by:
Priority: normal Milestone: Awaiting Review
Component: General Version:
Severity: normal Keywords: has-patch
Cc: Focuses:

Description

I continuously see new wordpress versions be released without addressing some of these problems...

1.) The Menus listing in the customizer is alphabetized either by default or something else spesific, and I think in my opinion this is a bad bug. The list should be listed the way I write the configuration or menu details, etc. For example, the menu title Footer should not be listed above the menu title Header.

2.) The upload page for the theme upland and the plugin upload, they both seem to function a little bit different visually. It would be a good idea to clean this up a bit so it looks more seamless.

3.) Feature request, ability to hide or disable completely the theme and plugin browsers. So then when disabled the only thing displayed would be the upload button for theme / plugin. I tried a partial disable with php exit script and this functions partly but looks visually bad so I think having a real filter or disable option would be great.

Change History (4)

#1 @sabernhardt
7 weeks ago

This ticket mentions multiple topics, but I can add details for two of them.

Listing menu titles differently

Yes, the Customizer and the nav-menus.php Menus screen both list menus ​alphabetically by name. I do not consider this to be a bug. It is awkward for certain titles such as 'Header' and 'Footer' in English. However:

  1. Alternative names such as 'Primary' and 'Secondary' are likely appropriate and fit alphabetically.
  2. In French, Entête (header) comes before Pied de page (footer).

Sorting by ID, lowest to highest, could make sense for some sites because the most important menus are usually created first. But when someone replaces a menu, that sort order could easily be less appropriate than alphabetical. If sorting by ID is a better choice for your site(s), you could use the wp_get_nav_menus filter (below is a very simple example that changes the order globally).

function wptrac_sort_nav_menus_by_id( $menus, $args ) {
	$args['orderby'] = 'term_id';
	return get_terms( $args );
}
add_filter( 'wp_get_nav_menus', 'wptrac_sort_nav_menus_by_id', 10, 2 );

Disabling the Plugins list pulled from the API

There already is a way to access a page with only the plugin upload form, at plugin-install.php?tab=upload.

If you use a plugin like ​Admin Menu Editor, you could add an "Upload Plugin" link to plugin-install.php?tab=upload within the submenu.

Or you could replace the target for the existing "Add Plugin" link, using a custom plugin.

function wptrac_replace_add_plugin_link_in_admin_menu() {
	global $submenu;
	if ( isset( $submenu['plugins.php'][10][2] ) && 'plugin-install.php' === $submenu['plugins.php'][10][2] ) {
		$submenu['plugins.php'][10][2] = 'plugin-install.php?tab=upload'; 
	}
}
add_action( 'admin_menu', 'wptrac_replace_add_plugin_link_in_admin_menu', 999 );

(I do not think the Add Theme screen has a similar way to disable the visual list, though in that case you could use CSS to show the .upload-theme form container and to hide the .upload-view-toggle button, .wp-filter, .theme-browser, and the .upload-theme ~ h2 headings.)

Last edited 7 weeks ago by sabernhardt (previous) (diff)

This ticket was mentioned in ​PR #13219 on ​WordPress/wordpress-develop by ​@wprashed.


7 weeks ago
#2

  • Keywords has-patch added

## Trac Ticket
https://core.trac.wordpress.org/ticket/55524

## Description

Harmonizes visual styles and responsive breakpoints between .upload-plugin and .upload-theme in src/wp-admin/css/themes.css:

  • Extends the @media only screen and (max-width: 1120px) font-size and padding adjustments to .upload-plugin .install-help to match .upload-theme .install-help.
  • Fixes whitespace/tab indentation on .upload-theme .wp-upload-form input[type="file"].

Fixes #55524.

#3 @sadmansakibnadvi
7 weeks ago

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/13219
This report covers only the upload screens part of this ticket, which is what the linked PR changes. I have not tested the menu ordering or the browser-hiding items.
Environment:

  • WordPress: 7.2-alpha-63332 (nightly, unpatched baseline) and the PR build of trunk, 7.2-alpha-20260821
  • Browser: Chrome 151, macOS
  • Theme: default
  • Plugins: none

Steps: compared Appearance > Themes > Add New Theme > Upload Theme against Plugins > Add New Plugin > Upload Plugin, at 900px wide (inside the media query) and 1400px (outside it).
Unpatched: at 900px the theme screen help text shrinks as expected, but the plugin screen keeps the desktop styling, with the help text 27px tall. The two screens do not match.
Patched: at 900px both screens render the help text at 15px with 20px top padding, 42.5px tall on both, and the upload form lands at the same rect on both screens (459x84 at x 239.5, y 207.5).
At 1400px both screens still use the desktop styling, 18px with no top padding, so nothing outside the media query changed.
The upload form on the plugin screen sits 15.5px lower after the patch. That is the expected consequence of the help text dropping to 15px and gaining 20px of top padding (27px to 42.5px). The box's own size and horizontal centering are unchanged. On the theme screen the form's bounding rect is identical before and after, so the whitespace normalisation on the adjacent rule has no visual effect.
Result: works as described. No regression found.
Note on method: Playground renders wp-admin inside an iframe, so I set the frame width rather than the browser window width. Media queries evaluate against the frame's own viewport, and innerWidth measured exactly 900 and 1400 in each case.

​@sadmansakibnadvi commented on ​PR #13219:


7 weeks ago
#4

Tested this on the Playground build for the PR and posted a full test report on the ticket. Short version: at 900px both upload screens now render the help text identically, and nothing changes at 1400px. No regression on the theme screen.

Note: See TracTickets for help on using tickets.