Link Control: persist advanced settings toggle state to preferences if available #52799
Conversation
scruffian
added
[Type] Feature
|
Size Change: +318 B (0%) Total Size: 1.44 MB
ℹ️ View Unchanged
|
|
I like the idea of this automagic behavior. In this PR the option does reset if I click a link that is already linked. |
| return select( blockEditorStore ).getSettings() | ||
| .setLinkControlAdvancedSettingsPreference; |
There was a problem hiding this comment.
I updated so the setter is provided by the block editor settings. This means any editor can provide their own preference store rather than having these hard coded to WP only as was previously the case.
| @@ -133,15 +139,33 @@ function LinkControl( { | |||
| withCreateSuggestion = true; | |||
| } | |||
|
|
|||
| const [ settingsOpen, setSettingsOpen ] = useState( false ); | |||
There was a problem hiding this comment.
We need the local state as a fallback in case that the preference isn't supplied. I considered using a local state as the value passed as the setting but I realised that is also no good because the editor might not pass the settings at all so we cannot rely on their presence.
|
Flaky tests detected in 10834d1. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5678980933
|
@scruffian please can you explain this a little more? Replication steps and exactly what you saw and expected? If you pull the latest changes does it still happen? 🙏 🙏 |
|
Needs unit test coverage before merging to test that the toggle behaviour works when a preference is available. |
@scruffian @draganescu I think the reason this is happening is because toggling the setting resets the internal state which then causes the value syncing to run. We've been looking at this value syncing and whether it should be removed in this PR. |
This comment was marked as outdated.
This comment was marked as outdated.
|
I'm concerned about this change. I think adding this preference to the editor settings means that each time you toggle the "drawer" it will cause the memoization of the settings to be invalidated which will cause the editor to re-render. That's probably what's contributing to the state reset we're seeing. I'm wondering if there are other options we could consider. For example, only persisting the preference when the current @Mamaduka I know you're really great an optimisations such as these. I'd greatly value your perspective here 🙇 |
|
With the change in facd271 it's harder to replicate the "wiping out state" bug, but here is a new video with replicate steps: Screen.Capture.on.2023-07-27.at.10-25-44.mp4 |
|
I think this is one of those options that doesn't have to be editor specific. Maybe we could use a general preference store and avoid funneling value/setter via settings. The |
|
Thank you for highlighting this. The approach is interesting to me as that seems like coupling block editor code to a concept of "Core". What is Core in Drupal? It seems like WP specific code which I understood should not exist in the block editor package 🤔
This would be preferable though... |
|
The preference scope can also be a cc @talldan |
|
Can't help to wonder if this is the case where we actually need a simpler solution like for this component only just use local storage. What's wrong with that? |
The preference layer can be configured to do that. But I assume you're talking about a standalone localstorage value for this UI only.
I'm not sure that's a great precedent to set. We'd end up with a tonne of "one off" things set in local storage. I think @Mamaduka is probably on to the right track with having a generic scope. But what I want to know is that another consumer of the |
They can. This is how WP does it - https://github.com/WordPress/wordpress-develop/blob/12a0205829c1411f16b4e216a713a153bcc62e2f/src/wp-includes/script-loader.php#L372-L388. |
|
Hi guys, I appreciate the work you put into trying to fix the problem regarding links which were introduced with the latest 6.3 release. I've dug into this the last few hours and saw that there are multiple threads dealing with possible solutions. My question is this: I'm a bit confused as to why this current thread here is closed and you guys consider it solved:
I'm afraid that it hasn't been resolved, here's why: You still have to go through the following tedious process:
So in anticipation of a fix, I've downloaded the latest Gutenberg 16.4 and tested the alleged solution. While it is true that now at least the "advanced" toggle remains open when editing links after opening it once, the fact remains that it still takes considerably more clicks and time to get a link to open in a new tab than in WP 6.2. Here's the current process after the "fix":
As you can see, the only thing that has been improved is that you don't have to click to open the "advanced" toggle each time (after you've clicked it once, that is). But why do you still make all users go through 6 clicks, just to create a link which opens in a new tab? Particularly, why do we have to click on the link again after creating it before even getting the "edit" option? Why not display the check box "open in new tab" right away at step 2 as it used to be before 6.3? So clearly, this issue has not been resolved and shouldn't be closed imho. Furthermore, the point brought up in #52216 still remains true: As explained above, it does still take a lot more clicks to insert a link and get it to open in a new tab than previously. I'm not sure why almost all threads which brought up this issue are closed, even though the issue persists and has only been improved a tiny bit with Gutenberg 16.4, but not really solved? Thanks guys! |
|
@EW0JY thanks for the report 👏🏻 I don't think the number of clicks is something more valuable in itself than the overal experience. Reducing visual clutter is also a valuable and it's a complicated process to figure out the trade offs. The aim is to, eventually, make things seamless. Currently with this PR tho the example you gave would be different, once you did steps 1 to 6 once, for all other links the settings drawer would remain open and the open in new tab be visible, right? |
Just noting this is a PR and not an Issue. Therefore when the PR is merged the "thread" is closed. Myself, @richtabor and other contributors are currently exploring other ways to improve the common use case of |
Apologies, I'm not an experienced GitHub user, my mistake. Your explanation makes perfect sense for closing this PR.
That's amazing! In fact, your screen capture here already shows the perfect solution! As we can see in your screen grab, we would no longer have to click a second time on the link to be able to edit it and in addition to that, the "open in new tab" option is directly accessible from the preview window. Once the reviewers have confirmed your solution, will it be available through the next Gutenberg plugin update? Thanks so much! |
|
You are changing something that was already good enough, to make it worse. It's incredible! Anyone working with content writing NEEDS to be able to set at least "no follow" and "open in new window" with just one click. It's absolutely insane that I've to do even just one more click to do this. These two features are very commonly used, given the impact on SEO and UX. I don't know why you guys are doing this, but it's really nonsense. We, who work with the editor on a daily basis, simply need to be able to enter the url and check the "no follow" and "open in new window" boxes when relevant. And this must be done with lightning speed. We don't need a clean interface if it complicates our work. The number of clicks is crucial, and in doing so you are going in a useless and harmful direction. If you design user experiences, design them for people! The world is full of useless beautiful designs. |
Absolutely fine. Not intended as a criticism.
If contributors are happy with the direction then the next step is to update the test coverage on the PR to ensure the tests provide coverage for the new behaviour. Once done then it will merge into the Gutenberg Plugin can land in the appropriate release. I intend to work on it today and next week but I can't promise exactly which release it will land in. Once merged, a
As noted above, we've noted the feedback and are making changes to accommodate. Please bear in mind that no one is intentionally trying to make things harder but sometimes (despite our best efforts) changes have unintended consequences or impact more widely than we would have anticipated. The nature of the project means we can pivot and make changes in response to constructive feedback. In short - we are listening. |
Awesome, thanks so much for the detailed explanation, Dave, I appreciate it! Also, no rush, I understand that it needs to be tested thoroughly so if it takes a few days or a week, then that's still pretty timely, which is great. I'll keep an eye on the milestone, like you suggested, as soon as it becomes available. I for one am pleasantly surprised that you and the other contributors are so open to feedback and willing to make changes asap where necessary, useful and requested. Much appreciated! |
That's subjective. There's always a balance and we're consistently iterating to get closer towards that. #53566 is a step in that direction, along with all the improvements outlined in #50891. |
|
As mentioned by others, I also appreciate your openness to feedback, primarily because the choices made here could potentially impact the work of millions. This isn't intended as criticism, but rather a constructive suggestion for the greater good.
Rich, it might be subjective, but the real question is: has anyone ever done a serious user needs analysis? Has anyone ever tried to validate the concept with a significant number of professional users?
This, too, is deeply subjective and obviously does not stem from any scientifically validated insights. None of us likely have insights from usability testing and A/B testing. However, it's a bit counterintuitive to believe that people prefer to do things with more effort. Personally, I seriously struggle to understand the "why" of the implementation of this feature. Basically, what could be the benefit of link preview? And which for the field for the anchor text? Does it make sense to be able to create a new blank page while I'm just inserting a link? All of these things are scattered throughout the mockups here and in #50891. However, perhaps we should ask ourselves whether developing this really helps users, or if for them the speed and ease of completing tasks is what really matters. Perhaps along these lines, doing some serious customer discovery, maybe we might have realized that it would have been more beneficial to direct efforts towards a different aspect. In enhancing the ability to search through posts and pages when attempting to add a link, for example. From experience, when you're developing something, you shouldn't just talk to the developers, but to the users. Otherwise, you'll end up expending a lot of energy on something that doesn't provide real benefits. The question here, in my humble opinion, isn't about releasing something that's not perfect, but about the stubbornness to persist in searching for a patch in a certain direction, instead of considering the feedback from users who clearly say: let us do things with 1 click. |
|
@elgato91 sounds like you feel exactly how I am feeling right now. I have just spent hours researching this. Seems there is an insistence on cleaning up the UI that does not take into account ease of use. I spend maybe 8 hours per day working in WordPress and I always want all my links to open in a new tab. It's hard to imagine how that can be bad in the world of SEO. The previous setting before this latest update worked perfectly. Just as there was previously an "i" to the top left of the screen that showed the the header structure of a page, but that's hidden as well. Anyway, that's another issue altogether. Back to the open links in new tab issue, the entire debate here and elsewhere reminds me of a story that I heard of programmers who were hired to program earthmoving equipment (to use automation instead of humans). The programmers were very good at their work (and much appreciated), but since they had never used earthmoving equipment, they programmed in unnecessarily complex steps. They didn't understand the user environment. The entire project had to be scrapped and people went back to operating the graders, etc. This change feels as if it was pushed by someone that does not spend even a few minutes inside WordPress creating posts. If you did you would understand the frustration. For us, a clean interface is one that simplifies tasks. Having 6 clicks where there were previously two is very much cluttered. As it is, I may have to revert to creating posts in Microsoft Word and then pasting them to WordPress. That change has added loads of frustration to my work. Sorry if I sound a bit caustic. I had to get that off my chest, it was bugging me for a while... |
|
Thanks to everyone for your feedback. As contributors have noted above, we are listening and making changes in response to feedback. I appreciate it can be cathartic to express frustration when it appears as though decisions were made in a manner that didn't consider your use case. However, what would really help at this stage in order improve things for everyone is to review and test the PRs that are already open to address the issues noted above. Namely:
As an open source project, WordPress relies on everyone working together to improve the software. Anyone is allowed to submit PRs and regular contributors will always try to be proactive in supporting with code reviews. If folks aren't able to contribute code then it's equally valuable to test PRs and check they are going in the direction that works for you. We anticipate the Link interface will continue to undergo iterations in the near future, so it would be hugely valuable if you felt able to follow PRs tagged with the associated label and provide feedback on their direction. Contributors look forward to working with the wider WP community to improve things for everyone. |
|
I believe that many of us can readily understand the situation, and the fact that we are commenting here is already symptomatic that we want to help you create something good. In my case, I can contribute some feedback on UX/Interaction Design, but honestly it seems to me that the entire Link UI design is against human-centered design principles, with useless functionality detrimental to the overall user experience. Unfortunately, many of us have only come to realize this now that we've been directly impacted by the issue. We can also comment on every single attempt to make this new UI better, but I think we should honestly acknowledge that there has been a significant regression from the old Link UI, which was better designed to be easier to use. We're insisting on cleaning up the interface, hiding the only controls that make sense. But we are also introducing a link preview. Who needs this? What advantages does it bring? Unfortunately, there has been no response on this. Similarly, we're implementing a text field for modifying the anchor text of a link, which is essentially a redundant function that can already be performed directly within the editor. Once again, we need to consider: Who benefits from this? What purpose does it serve? Guys, cleaning the interface in this way is a huge misstep. To achieve a purely aesthetic result, we are adding complexity to the interface and introducing unnecessary steps. A multi-level, multi-step interface is more complex. You cannot deny this. Even the choice of introducing advanced controls in the Link UI is flawed from the outset, and increases the general complexity of the WP user experience, because it would be more intuitive to place all the advanced controls in the sidebar, akin to other blocks. We can continue to give you feedback on your attempts to make it work, but be honest. This new Link UI is poorly designed. It doesn't take into account use cases at all, it highlights a lack of understanding of how WP is used by users and neglects basic principles of UX and ergonomics. It's the sort of outcome one might expect from novices, not from a globally collaborative project like WordPress. We need to approach this situation with honesty and humility and explore alternative paths: either reverting to the previous Link UI or re-design something more human-friendly. |
tellthemachines
added
the
Backport to WP Minor Release
|
I just cherry-picked this PR to the update/bugfixes-6-3-1 branch to get it included in the next release: a3d7887 |
…f available (#52799) * Link Control: Create a preference for whether the advanced section is open * move the useSelect to the component that uses it * Supply preference setter via settings * Pass setter to Post Editor * Provide local state fallbacks in absence of preference store settings * Conditionalise display of settings drawer to “edit” mode only * Extract to constant to improve comprehension * Fix bug in preferences resolution * Improve comments * Add e2e scaffold * Fix e2e test to correctly assert on feature * Remove focused test * Reinstate original logic to hide settings when not required * Scaffold documentation * Revert providing prefs via settings * Refactor to use `core/block-editor` as preference scope * Update docs * Reinstate remaining original conditional * tentative fix for the e2e test * Try a different syntax for shiftAlt * another attempt to fix the e2e test --------- Co-authored-by: Dave Smith <getdavemail@gmail.com> Co-authored-by: MaggieCabrera <maggie.cabrera@automattic.com>
tellthemachines
removed
the
Backport to WP Minor Release
|
Just some feedback from a non-dev but a heavy WP user. If someone doesn't use new tab/nofollow/sponsored settings and just pastes links as is, they can do that and simply ignore the settings at the bottom. How does it help users to hide them away? I don't understand that logic. I think in this case, it's pretty clear that these link settings should be easy and quick to access, as they were before 6.3. I'm not seeing any "balance" that needs to be struck here. Just don't bury them behind several additional clicks. |
|
I'm 100% on board with what pb7107 mentioned above. I'm no dev, so most of what the smarter people are commenting here is well over my head. But I run a music news website and literally every post we write up has at least one, if not more, external links to a band's preorder, website, link page, etc. We ALWAYS want these links to open in a new tab, and there is very little reason at all to hide these "advanced options" that were there before. It's not hyperbole for me to say this this is going to be huge PITA. |
|
@thewhitedrewcarey it's exactly what we have been saying all along. As another heavy user who works on several websites, I always want my links to open in a new tab. As a web user, I also always want the links that I am clicking on to open in a new tab. I don't want to be taken away from what I am reading simply because I have clicked on a referenced article. The situation that was there before 6.3 was perfect. Unfortunately it doesn't seem like there is going back to that. Fortunately something is being done, at least for the new tab issue. But for all the other settings hidden under Advanced? Well... I repeat, the link preview that is being given prominence here does nothing. Maybe it's the one that should be hidden under Advanced. |
|
I'll say this much: I just updated last night, have been using it last night and today, and I absolutely hate it. I don't know who it serves to remove this functionality, because it 100% was not hurting anyone at all to have these options immediately present when copy paste a link over text. This is a prime example of a solution looking for a problem. |
|
Noob dev here, but long-time user of WordPress with my team of 10. I created a profile just to comment on this thread. Because everyone's been complaining about this new link feature: Project Managers, Copywriters, and Content Editors. It doesn't make sense to have to click 5 times to simply open a link in a new tab. We've been churning hundreds of posts on a monthly basis, and we feel the pain. The behavior in the previous WP version was way more user-friendly. And I hope this will be fixed in a coming version. |
|
Hi @beixco and thank you for participating and offering your perspective. Improving the linking flows is still work in progress and all contribution is informed by helpful replies like yours. In recent mock-up explorations just one more click is required, but also a global prefference is suggested - so most of the times not even that click is needed. In the mean time, the original issues that this PR here tried to solved does not exist anymore (the original change where one had to create, click edit, click advanced, click save - is gone: now the advanced section stays open once it was open and also open in new tab is temporarily surfaced to be one click away). |
|
Thanks for sharing the mock-up explorations @draganescu - and sorry if I posted in the wrong thread, I followed a link from the WordPress forum. |
|
It's perfectly fine @beixco 🙇🏻 |
…f available (#52799) * Link Control: Create a preference for whether the advanced section is open * move the useSelect to the component that uses it * Supply preference setter via settings * Pass setter to Post Editor * Provide local state fallbacks in absence of preference store settings * Conditionalise display of settings drawer to “edit” mode only * Extract to constant to improve comprehension * Fix bug in preferences resolution * Improve comments * Add e2e scaffold * Fix e2e test to correctly assert on feature * Remove focused test * Reinstate original logic to hide settings when not required * Scaffold documentation * Revert providing prefs via settings * Refactor to use `core/block-editor` as preference scope * Update docs * Reinstate remaining original conditional * tentative fix for the e2e test * Try a different syntax for shiftAlt * another attempt to fix the e2e test --------- Co-authored-by: Dave Smith <getdavemail@gmail.com> Co-authored-by: MaggieCabrera <maggie.cabrera@automattic.com>
* Update document title buttons radius (#53221) * Fix: Sync status overlaps for some languages in Patterns post type page (#53243) * Image block: Fix stretched images constrained by max-width (#53274) * Fix dragging to resize from stretching image in the frontend * Add image block v7 deprecation * Update deprecation comment * Prevent image losing its aspect ratio at smaller window dimensions * Revert "Prevent image losing its aspect ratio at smaller window dimensions" This reverts commit 8ac9f8c. --------- Co-authored-by: scruffian <ben@scruffian.com> * Image Block: Don't render `DimensionsTool` if it is not resizable (#53181) * Fix missing Replace button in content-locked Image blocks (#53410) * Revert "don't display BlockContextualToolbar at all in contentonly locking (#53110)" This reverts commit 5efce0e. * Alternative fix to hide BlockContextualToolbar when there are no controls * fix the go to for non pages by showing it only for pages (#53408) * Site Editor: Fix document actions label helper method (#52974) * Site Editor: Fix document actions label helper method * Add missing useSelect dep * Fix e2e tests * Move the label map at the file level to avoid recreating the object on every render * Image: Clear aspect ratio when wide aligned (#53439) * RichText: Remove 'Footnotes' when interactive formatting is disabled (#53474) Introduce a new 'interactive' setting for format types * Preserve block style variations when securing theme json (#53466) * Preserve block style variations when securing theme json Valid and safe block style variations were being removed by `WP_Theme_JSON_Gutenberg::remove_insecure_properties` when securing the theme.json. When this was a problem varied depending upon site configuration, but out-of-the-box it was a problem for administrators on multi-site installs. This change adds explicit processing of variations in `remove_insecure_properties` so that they won't get removed. * Add another variation sanitisation test This test checks that when removing insecure properties an unknown/unsupported property is removed from the variation. * Site editor: add missing i18n in `HomeTemplateDetails` (#53543) * Site editor: add missing i18n in `HomeTemplateDetails` * Lint fix * Fix: Snack bar not fixed on certain pages in the Site Editor (#53207) * Fix document title alignment in command palette button (#53224) * Fallback to default max viewport if layout wide size is fluid. (#53551) * Link Control: persist advanced settings toggle state to preferences if available (#52799) * Link Control: Create a preference for whether the advanced section is open * move the useSelect to the component that uses it * Supply preference setter via settings * Pass setter to Post Editor * Provide local state fallbacks in absence of preference store settings * Conditionalise display of settings drawer to “edit” mode only * Extract to constant to improve comprehension * Fix bug in preferences resolution * Improve comments * Add e2e scaffold * Fix e2e test to correctly assert on feature * Remove focused test * Reinstate original logic to hide settings when not required * Scaffold documentation * Revert providing prefs via settings * Refactor to use `core/block-editor` as preference scope * Update docs * Reinstate remaining original conditional * tentative fix for the e2e test * Try a different syntax for shiftAlt * another attempt to fix the e2e test --------- Co-authored-by: Dave Smith <getdavemail@gmail.com> Co-authored-by: MaggieCabrera <maggie.cabrera@automattic.com> * Add tests for fluid layout + typography (#53554) * Fix support of sticky position in non-iframed post editor (#53540) * Fix support of sticky position in non-iframed post editor * Revert "Footnotes: Fix recursion into updating attributes when attributes is not an object (#53257)" This reverts commit ab04074. * Fix: indicator style when block moving mode (#53972) * Fix post editor top toolbar with custom fields in Safari (#53688) * Set top toolbar size dynamically (#53526) * fix the top toolbar size in the space remaining after plugin items are pinned * only resize above the tablet breakpoint * fix fixed block toolbar collapse button when icon labels are shown * Update height and scroll behavior * move the layout effect to the affected component, fixes for fullscreen, no block selected, icon labels height --------- Co-authored-by: jasmussen <joen@automattic.com> * Roll back camelCase change in 96b6b1e --------- Co-authored-by: James Koster <james@jameskoster.co.uk> Co-authored-by: Aki Hamano <54422211+t-hamano@users.noreply.github.com> Co-authored-by: Alex Lende <alex+github.com@lende.xyz> Co-authored-by: scruffian <ben@scruffian.com> Co-authored-by: Robert Anderson <robert@noisysocks.com> Co-authored-by: Andrei Draganescu <me@andreidraganescu.info> Co-authored-by: George Mamadashvili <georgemamadashvili@gmail.com> Co-authored-by: Dean Sas <dean.sas@automattic.com> Co-authored-by: Pascal Birchler <pascalb@google.com> Co-authored-by: Dave Smith <getdavemail@gmail.com> Co-authored-by: MaggieCabrera <maggie.cabrera@automattic.com> Co-authored-by: Mitchell Austin <mr.fye@oneandthesame.net> Co-authored-by: jasmussen <joen@automattic.com> Co-authored-by: ramon <ramonjd@gmail.com>
This is an alternative to #52321. Fixes #52216.
What?
Once a user opens the advanced section of link control it will stay open until they close it again.
Why?
This retains the UI state which will be useful for people who often use the "open in new tab" option.
How?
Adds a new preference that gets toggled when you open the advanced section of link control.
Testing Instructions
Automated Tests
e2e tests -
npm run test:e2e:playwright test/e2e/specs/editor/blocks/links.spec.js -- -g "toggle state of advanced link settings is preserved across editing links"Co-authored-by: Dave Smith 444434+getdave@users.noreply.github.com