Opened 9 years ago
Closed 9 years ago
#36359 closed defect (bug) (fixed)
"Insert/edit link" dialog no longer shows recent posts/pages
Reported by: | SergeyBiryukov | Owned by: | azaozz |
---|---|---|---|
Milestone: | 4.5 | Priority: | normal |
Severity: | normal | Version: | 4.6 |
Component: | Editor | Keywords: | has-patch needs-testing commit |
Focuses: | ui, administration | Cc: |
Description (last modified by )
Background: #33301
In 4.4, the "Insert/edit link" window shows the list of recent posts and pages if you leave the search box empty.
In trunk, there's no recent posts list, and I'm forced to do a search, which might be confusing (see #36357 for an example). What if I want to link to a recent post, but don't remember the exact keywords?
Seems like a regression to me.
Attachments (11)
Change History (55)
#4
@
9 years ago
Yeah. I don't know if this is a common use case... Usually you do remember at least some words of the post. It searches the whole content, not just the title. Maybe it makes it a bit easier if you want to link one of your latest posts, but not sure if it's worth adding a lot more UI for just that.
#5
@
9 years ago
There has been ONE comment in the forums about it - https://wordpress.org/support/topic/insertedit-link-existing-pages
A list of 'recent posts' and 'all pages' might be nice to have for people who don't want to search and are adding a link to the text of "In yesterday's post I talked about cooking with fire..." Things that aren't necessarily search terms.
#6
@
9 years ago
I am used to just browse through pages and recent posts, without searching. Please restore this to the way it worked before.
#7
@
9 years ago
Agree with @iseulde that the user case for always seeing recent posts is "weak". I know, with every UI change some users will miss the "old ways" :)
In the old modal the list of recent posts was shown mostly because that space would have been empty otherwise and look bad/strange. When inserting a link all users know what they want to link to. It is usually quite faster to search for what they know, rather than browse through recent posts to "fish it out". The only exception is in case the user wants to link to one of the last 10 posts (which were always shown).
#8
@
9 years ago
If you're in text editor, now you don't have ANY dropdowns which means you can't search at all for older posts. Which is actually a legit problem here. Unless we're saying SOL to anyone who for whatever reason can't use the Visual editor :)
https://cloudup.com/iyxTe6DETwk
I would like to see the last ten posts/pages be restored. I think that there is a use case for it, and it's not a case of 'missing the old days' but a legit experience of "I'm writing a series of posts..." Which bloggers often do :)
#9
@
9 years ago
If you're in text editor, now you don't have ANY dropdowns which means you can't search at all for older posts.
You can still search, no?
This ticket was mentioned in Slack in #core-editor by iseulde. View the logs.
9 years ago
#11
@
9 years ago
If you're in text editor, now you don't have ANY dropdowns which means you can't search at all for older posts.
Not sure what you mean here too :) It works in exactly the same way in both visual and text editors: can search from the URL field.
To restore the 10 most recent posts we will have to revert pretty much all changes to the old modal. It doesn't work that well on mobile, uses a "river" (infinite scroll) which has accessibility problems, is a bit buggy (fetches more results on scrolling up) etc.
#12
@
9 years ago
Greetings everyone,
I am the person who created the thread on the forums. Since there is a trac ticket, that thread was marked as resolved and I thought I would jump in here to throw in my 2 cents.
My problem was that I was not always getting the results that I expected to get using the built in search for the insert link. The best explanation that I got, and this seems to make sense from my tests, is that the built in search uses "and" and not "and/or".
For example, I have a page titled "Three Columns", which is a child of a page titled "Templates". Now, if I search for "templates" they both show up. If I search for "three" then the child page shows up. If I search for "columns", they both show up. So far, so good. But if I search for "3 Columns" - then only the parent page shows up. So, what baffled me and caused me to report it as a bug, is that I would expect for "3 columns" to show the child page, especially considering that just "columns" shows it.
I guess the search using "and" and not a "and/or" would explain that.
But still, that's not predictable results. And having a section where you can "link to existing content" would sure help a whole lot of users when those search results don't provide what we're expecting them to.
To me, this sounds less like a case of somebody missing the good ol' days and more like somebody trying to fix something that wasn't broken.
Thank You,
Travis
This ticket was mentioned in Slack in #core by mike. View the logs.
9 years ago
#14
@
9 years ago
But if I search for "3 Columns" - then only the parent page shows up. So, what baffled me and caused me to report it as a bug, is that I would expect for "3 columns" to show the child page, especially considering that just "columns" shows it.
Just to clarify something on that bug, it's not a bug. It behaves the same way on WP 4.4.x - Unexpected behavior, yes, but it didn't break in this change so it's not related.
#16
follow-up:
↓ 17
@
9 years ago
Fair enough. The search behavior did not change - but the fallback "link to existing content" did. Calling that a "bug" is poor word choice on my part, since it was the intentional removal of a feature. And, honestly, I thought it was a bug for the search feature to use only "and" logic and not "and/or" or something else that might deliver results that one would expect to get.
Anyways, for the purposes of this trac ticket, I personally believe that it would be a disservice to the WordPress community to remove the "link to existing content" feature. And it would seem that I'm not alone on this.
#17
in reply to:
↑ 16
@
9 years ago
Replying to RevelationTravis:
Anyways, for the purposes of this trac ticket, I personally believe that it would be a disservice to the WordPress community to remove the "link to existing content" feature. And it would seem that I'm not alone on this.
To be clear, the "link to existing content" feature isn't going anywhere and there was never a plan to remove it.
What this ticket covers is specifically the list of recent content that used to be present in the modal. What used to be the Search box in the expanded section of the modal was combined with the URL input.
Per discussion in #core at dev chat earlier today, the goal now is to restore the list of recent content, but again, intra-linking is still present via auto-complete in the URL field.
#18
@
9 years ago
When I said "link to existing content" feature, I'm talking about the list of recent content - not the intra-linking via auto-complete (since that does not always yield the results that one would expect to get).
English may be my first (and only) language, but I don't always have the best word choices to convey what I'm trying to say. Forgive me. :-)
I think that if the feature in question is restored, it would help to give us an option to link to existing content in those instances where the auto-complete feature fails to find what we're looking for. Which happens. You know, just in case you needed one more reason to put this feature back in. That's all I'm trying to say.
#19
@
9 years ago
- Keywords has-patch needs-testing added; ux-feedback 2nd-opinion removed
In 36359.patch: revert most changes to (the old) wpLink modal in order to bring displaying of the recent posts and pages back.
@afercia could you have a look if I haven't reverted something that is needed or have reverted a recent accessibility fix by mistake :)
Everybody else: please test the patch now!
#20
@
9 years ago
Tested 36359.patch, works as expected for me.
#21
follow-up:
↓ 22
@
9 years ago
Had to make sure I used a new browser cache so that it didn't act strangely (for anyone else testing).
Only thing I noticed -- if you:
- Select text
- Click link button
- Start typing
- Click advanced
It will tell you that you haven't typed anything, and leave you in this state:
No search item notice with search item shown
#22
in reply to:
↑ 21
@
9 years ago
Replying to mikeschroder:
Right, it transfers the string the user typed in the inline dialog (if any). That was intended for use in autocomplete on the URL field, however now there's no autocomplete there. New patch coming up.
#23
@
9 years ago
In 36359.1.patch: same as 36359.patch plus: check the string that was passed from the inline dialog. If it looks like URL, add it to the URL field. If not, add it to the search field and trigger a search.
This way it tries to be "clever" and help the user a bit / avoid some repeated typing. Or we can just ignore anything the user may have typed in the inline dialog.
#24
@
9 years ago
Related chat: https://wordpress.slack.com/archives/core/p1459368799002171
Tickets like this are a chore to grok without screenshots, so I attached some screenshots and, as always, encourage developers to include screenshots with their patches as a matter of habit and course.
This affects the dialog accessed through the gear icon, restoring it to its previous look. This restores the separate search field. Removing that was one of the reasons for doing this. I always accidentally search in the url field, moving on to the search field after realizing I'm in the wrong spot. But, since this interface is buried beneath the gear icon and the primary interface has a combined search+url box, I'll probably never see this dialog in the course of my editor flow.
#26
@
9 years ago
In 36359.2.patch: if the user has typed a search string in the inline dialog, pass it to the search field in the modal and trigger a search. Do that when editing an existing link or adding a new link.
#27
@
9 years ago
In 36359.3.patch: also check if the user has typed or pasted an URL or email address in the inline dialog, and add it to the URL field instead of searching with it.
#28
follow-up:
↓ 29
@
9 years ago
In Chrome and Safari the modal doesn't seem to get any focus when I click the gear button directly without entering something first. When I enter something first the input is highlighted but has no focus either. Works in Firefox.
#29
in reply to:
↑ 28
@
9 years ago
Replying to ocean90:
In Chrome and Safari the modal doesn't seem to get any focus when I click the gear button directly without entering something first. When I enter something first the input is highlighted but has no focus either. Works in Firefox.
Should "Or link to existing content" open automatically if the search field is auto-filled and the list was previously hidden?
#30
@
9 years ago
The search field doesn't get cleared and is still filled when I'm adding another link. Not sure if that's expected. In 4.4 the modal was in a clean state for each link.
#31
@
9 years ago
Tested and this works well for me. In the link dialog, I tried entering a url an email address and some plain text; all worked as expected.
I agree with @ocean90 - the search field should probably clear out, especially if i start a new link and leave the inline link empty and click the gear icon, this will help users who are used to the recent post list more easily find what they need as well.
Question: Does the > Or link to existing content
section start open by default? if not, we should ensure the search section is open when the dialog is opened with some existing text in the field, since a search is already taking place.
Screenshots:
#32
@
9 years ago
Seeing the same behavior as @ocean90 in OSX Chrome. This also keeps ESC from being used to leave modal.
Otherwise, 36359.3.patch seems to work as intended.
#33
@
9 years ago
In 36359.4.patch:
- Fix focusing the modal's url field on open in Safari and Chrome on Mac. That's a weird one, seems these browsers don't like to focus and select the field at the same time. Works properly in Firefox and Chrome on Windows.
- Expand the modal when we pass a search string from the inline dialog. As discussed with @iseulde: we probably should remove that expand/collapse toggle. This is the "Advanced" modal now, no need for "simple" mode for it.
The search field doesn't get cleared and is still filled when I'm adding another link.
I see the same behaviour in 4.4. Should we always reset it?
#34
follow-up:
↓ 36
@
9 years ago
As discussed with @iseulde: we probably should remove that expand/collapse toggle. This is the "Advanced" modal now, no need for "simple" mode for it.
That is in 36359.5.patch:
- When opening modal, always show the expanded version
- Remove
Or link to existing content
text and link - Remove JS handler for expand action (no longer needed)
#35
@
9 years ago
On my 4.4.2, it does clear, but there's a bug where the displayed search results are from the previous search.
#36
in reply to:
↑ 34
@
9 years ago
Replying to adamsilverstein:
Remove
Or link to existing content
text and link
Was thinking we could keep the text, just remove the arrow. Same as the modal being open. Also will need to remove search_panel_visible
and the css for it. I'll refresh the patch in a min.
there's a bug where the displayed search results are from the previous search
Right. Didn't realize there were so many inconsistencies in this :)
Looking at 4.2, 4.3, and 4.4 (in Chrome on Windows) the modal always keeps the old search string and search results when reopening it. Is this a bug or a feature? :)
#37
@
9 years ago
In 36359.6.patch:
- Make the modal always expanded.
- Remove the toggle together with the js, css and the user setting for it.
#38
follow-up:
↓ 40
@
9 years ago
In 36359.7.patch: also always reset the search field and swap the "rivers" when reopening the modal.
This ticket was mentioned in Slack in #core by azaozz. View the logs.
9 years ago
#40
in reply to:
↑ 38
@
9 years ago
Replying to azaozz:
In 36359.7.patch: also always reset the search field and swap the "rivers" when reopening the modal.
Looks good!
Tested and this works well. I wasn't sure about cleaning out CSS in case someone used it :) Verified search field AND search results reset on re-opening modal/new link. Thanks!
#41
@
9 years ago
- Keywords commit added
This seems to be working well. Can still tweak the behaviour a bit if needed but think it's ready. Of course more people testing it will always be better :)
#42
@
9 years ago
I'm a bit more on the novice side of things and couldn't figure out how to apply the patch to test it. I was waiting for it to roll out into the nightly release.
I also wanted to express how much I appreciate you guys listening to feedback and working so hard on this! Thank you.
#43
@
9 years ago
36359.7.patch looks good to me.
Seems like this was intended behavior.
@azaozz @iseulde @melchoyce, any opinions here?