-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Fix inconsistent references to Settings Sidebar #16138
Conversation
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.
Copy-wise, this is in great shape and gets a ✅ from me.
Before merge though, I'd like to get one final look from someone familiar with renaming files though to make sure this will translate correctly to the WP.org mirror. @gziolo can you take a look if you have a moment?
Thanks!
@chrisvanpatten or @nosolosw should know better, I have no idea how it works at the moment. The biggest concern I would personally have is that we should start adding redirects to every URL we change to ensure they work when linked from external websites. |
Lovely, I wasn't sure about changing the URL slugs and whether or not they'd redirect. I can roll them back if it seems like it'd be problematic, but if they will redirect it'd be best to change these references in as many places as possible, to reinforce consistent terminology. |
👋 There are a couple of other places in the docs where we are using inspector rather than settings sidebar: glossary, block registration. I've also noticed that the code primitives refer to Inspector (see). Probably that was the term used since the beginning (see glossary). I'd like both code and docs to refer to the same terms, as to have a common vocabulary among all of us, and also not to confuse authors that want to use the block editor APIs. Changing the code is feasible, but I also understand it'll be a slightly bigger challenge that's perhaps best addressed in a different PR. URLs One thing that we can do to know whether an URL will redirect automatically is to substitute the old slug by the new one. For example:
It won't work in this case. It's possible to ask people in meta to add this redirect, though. If we wanted to change the URL, we should probably add the redirects it as to not break existing external references to the handbook. |
Agreed x 1,000,000! I noticed this in the code but wasn't comfortable changing it myself for what are probably obvious reasons. 😄 I'm happy to file a follow-up issue though. Good to know that the URL wouldn't automatically update. Do you think we should just keep the existing URL, or ask for a redirect to be made manually? I'm definitely inclined to change the references in all instances (text, code, and URLs) for better consistency across all areas of the project, but I understand if this could prove more work than strictly warranted. |
1cb0de1
to
d80325b
Compare
I've merged and closing this one out to move forward with the changes. I've created an issue to address code here: #16437 I created this Meta Trac ticket for redirect: https://meta.trac.wordpress.org/ticket/4582#ticket And will open a new PR and reference this one for additional documentation changes. |
…rnmobile/track-unsupported-blocks * 'master' of https://github.com/WordPress/gutenberg: Bump plugin version to 6.1.0-rc.1 Update HTML anchor explaination text (#16142) Move post permalink to beneath title on mobile. (#16277) Export cloneBlock method to the mobile (#16441) Fix inconsistent references to Settings Sidebar (#16138) Adds a cache key to the blocks reducer in order to optimize the getBlock selector (#16407) Track the parent block to optimize hierarchy selectors (#16392)
This swaps out instances of Inspector and Block Settings with Settings Sidebar, as per our Design Patterns doc. I think I've got them all, but would appreciate a double-check.
I've also corrected a few instances of unclear references to the Block Toolbar when I came across them, and I've updated the code where it made sense and wouldn't break things, so we are more consistent about how we refer to things. The term "Inspector" still appears as the name of a React component, but that's a bigger change I'd rather not initiate here.
I've also changed a filename and slug, which I'm hoping won't break things, but we can revert if those will cause issues.
Fixes #14988.