New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Admin menu: Register Calypso settings pages as independent submenus #20100
Conversation
Caution: This PR has changes that must be merged to WordPress.com |
projects/plugins/jetpack/modules/masterbar/admin-menu/class-jetpack-admin-menu.php
Show resolved
Hide resolved
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available. Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped. Jetpack plugin:
|
// Page Optimize is active by default on all Atomic sites and registers a Settings > Performance submenu which | ||
// would conflict with our own Settings > Performance that links to Calypso, so we hide it it since the Calypso | ||
// performance settings already have a link to Page Optimize settings page. | ||
$this->hide_submenu_page( 'options-general.php', 'page-optimize' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the Calypso performance settings already have a link to Page Optimize settings page.
add_menu_page( esc_attr__( 'Settings', 'jetpack' ), __( 'Settings', 'jetpack' ), 'manage_options', $slug, null, 'dashicons-admin-settings', 80 ); | ||
add_submenu_page( $slug, esc_attr__( 'General', 'jetpack' ), __( 'General', 'jetpack' ), 'manage_options', $slug ); | ||
add_submenu_page( $slug, esc_attr__( 'Security', 'jetpack' ), __( 'Security', 'jetpack' ), 'manage_options', 'https://wordpress.com/settings/security/' . $this->domain ); | ||
add_submenu_page( $slug, esc_attr__( 'Performance', 'jetpack' ), __( 'Performance', 'jetpack' ), 'manage_options', 'https://wordpress.com/settings/performance/' . $this->domain ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small nitpick, can we extract this menu for https://wordpress.com/settings/performance
into a separate method, like we did with add_posts_menu
? We can pass $slug
as an argument and also reuse it in class-admin-menu.php:433
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is one of these cases where I prefer to sacrifice maintainability over readability and consistency. I don't like maintaining duplicated fragments of code, but it's something I'm willing to accept if the resulting code of avoiding it ends up being inconsistent with how the rest of the code behaves and/or forces the developer to jump back-and-forth into multiple source files in order have a fully understanding of the logic.
However, if folks feel strongly against this, I'm happy to refactor the code and get rid of the duplications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to have them in just one place because at some point the arguments can change for various reasons and we might end up with a menu with some arguments on one env while having different arguments on another one, after that things can be a bit tricky to change by someone else because they might not know the context of that change.
I don't have strong feelings about it since the changes are minor, so I'm fine with both approaches :)
$this->hide_submenu_page( 'options-general.php', 'options-discussion.php' ); | ||
$this->hide_submenu_page( 'options-general.php', 'options-writing.php' ); | ||
$submenus_to_update = array( | ||
'options-writing.php' => 'https://wordpress.com/settings/writing/' . $this->domain, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small nitpick: what if we move strings like 'https://wordpress.com/settings/writing/' . $this->domain
and 'https://wordpress.com/settings/discussion/' . $this->domain
into properties initialised in the constructor (e.g. $calypso_settings_writing_url)? This way we avoid duplicating the URLs in class-jetpack-admin-menu.php:230
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is one of these cases where I prefer to sacrifice maintainability over readability and consistency. I don't like maintaining duplicated fragments of code, but it's something I'm willing to accept if the resulting code of avoiding it ends up being inconsistent with how the rest of the code behaves and/or forces the developer to jump back-and-forth into multiple source files in order have a fully understanding of the logic.
However, if folks feel strongly against this, I'm happy to refactor the code and get rid of the duplications.
I have tested this on Simple & Atomic and works as expected, I am experiencing some env issues with Jetpack currently but I hope I can test it asap. |
This works for me in all environments! The only thing I noticed is some inconsistency in the menu highlighting. Clicking any of the expanded menus doesn't highlight them. Sometimes it would also retain the hover styling until I clicked away: Is that something we'd want to address in this PR or later? |
That's a known issue in Calypso. It will be fixed by this PR: Automattic/wp-calypso#53824 |
Great news! One last step: head over to your WordPress.com diff, D62989-code, and commit it. Thank you! |
Deployed to WP.com in r227680-wpcom. |
Part of Automattic/wp-calypso#53774.
Changes proposed in this Pull Request:
In order to accommodate changes that seek to remove the settings navigation bar from Calypso (Automattic/wp-calypso#53774), this PR registers the different Calypso settings pages as independent submenus of the Settings menu.
Jetpack product discussion
N/A.
Does this pull request change what data or activity we track or use?
No.
Testing instructions: