#11420 closed task (blessed) (fixed)
Easy within-site linking from new content
Reported by: | jane | Owned by: | koopersmith |
---|---|---|---|
Milestone: | 3.1 | Priority: | normal |
Severity: | normal | Version: | 2.9 |
Component: | Editor | Keywords: | has-patch |
Focuses: | Cc: |
Description (last modified by )
When writing a new post or page, we should make it easier to link to internal content (a previous post or page). The "Easy Post-to-Post Links" plugin enables shortcuts based on post ID or slug, but I'm envisioning something more user-friendly.
Something like you click a button for an internal link (though it should be same mechanism as for external link, possibly the popup could be sectioned or tabbed for external vs internal, like the media popup) and it allows you to search for a post or browse a list of existing content by title, date, author, etc. and select it for inclusion. It would allow you to enter the text you wanted linked, or would use the post title by default, maybe.
Attachments (25)
Change History (101)
#5
@
15 years ago
- Keywords reporter-feedback added
- Milestone changed from 3.0 to Future Release
Can you exemplary name existing software which implements "within-site linking" so it's easier to make up oneself's mind?
#9
@
14 years ago
I imagine a new core shortcode backing this which people can easily enter by hand as well with obvious arguments.
#10
@
14 years ago
As for plugin inspiration, you might want to check out Insights by Vladimir Prelovac which not only provides the ability to search for previous blog content, but has other sources of info available as well readily available within a meta box on the Post Writing screen.
#13
@
14 years ago
- Cc sennza added
I've just been having a quick go an an alpha version of this that blends in with the current link button in TinyMCE.
e.g. http://www.sennza.com.au/trac/posts.png
http://www.sennza.com.au/trac/pages.png
I've got to do some styling and add a scrollable div for when there are stacks of posts and pages and I might attempt to add a patch for a possible starting point with this feature. I'll have to add the additional fields mentioned by janeforshort as well then work on adding a search option too.
It'd be my first attempt to submit a patch to WordPress. I might not be heading down the right track with this so I dunno :)
#14
@
14 years ago
- Cc WordPress@… added
Assuming this is the internal linking task mentioned on the wpdevel blog yesterday, I know of an example implementation that I like, shortcode-wise: RB Internal Links. I'm not so sure I like the WYSIWYG implementation of that plugin, though.
It's nice to see the gist of #529 brought up again, with a happier resolution for users.
#16
@
14 years ago
- Keywords has-patch added; needs-patch reporter-feedback removed
- Owner set to koopersmith
- Status changed from new to accepted
Posting my first pass, which adds TinyMCE integration and maintains old link features. It needs post/term/etc selection to be written, but the foundation's there.
Patches welcome.
File guide:
- wp-includes/js/tinymce/wp-mce-link.php — the link dialog
- wp-includes/js/tinymce/plugins/wplink/ — TinyMCE plugin
- editor-plugin.js — the main frame's JS
- I left editor-plugin.js uncompressed and editor-plugin.dev.js empty for ease of development.
- js/wplink.js — the link dialog's JS
- editor-plugin.js — the main frame's JS
#17
@
14 years ago
- Cc idealien added
Would also be fantastic to have configurable custom post types available for internal linking.
#18
@
14 years ago
Before people get carried away and we have another custom menus situation on our hands, I just want to remind everyone of the scope of this ticket, which is v1 of an internal linking feature. The scope that has been accepted blessed is as follows: enable a search/autocomplete (similar to menus) option to link to internal content, while external links will continue to work the same. No other additions to the feature for v1. Freeze on this is in less than two weeks, and we'd hoped to have it in testing by now. If anyone wants to suggest things for v2 of an internal linking feature, please start a new ticket to keep this one focused on the feature that has actually been blessed (see type) by the lead developers. Thanks.
#20
@
14 years ago
Some suggestions after looking through the first patch:
- We can overload the command executed from the default 'link' button (similar to the Advanced Link plugin). This will remove the necessity of new translation, styling, etc. To return to the default link dialog the wpLink plugin can be disabled.
- We would need a custom "Suggest" script that would return post/category/tag name + URL, probably best in JSON format. It should post to admin-ajax.php.
- It's nice to hide the "advanced" link properties however the dialog looks incomplete/empty with so much white space at the bottom and cannot be resized dynamically. Perhaps we can leave them visible but move them under the fold, i. e. the user would have to scroll down to see them?
#21
@
14 years ago
Attached is my second pass. It covers most of the big functions, including list views and search for all applicable post types and taxonomies.
Here's what's left:
- Paging: Right now the links and PHP exist, but the AJAX does not.
- Overload default 'link' plugin as Andrew suggested.
- Do something about the "advanced" link properties.
- Styling/UX improvements:
- Disabling the "Update" button when an item isn't selected—currently it just silently stays put.
- Potentially writing "Insert" instead of "Update" in certain contexts.
We also cannot retrieve internal link info when editing a link (it currently defaults to external link), but IIRC, that may be v2 material.
I also wrote a simple reusable tabs interface—currently its coupled in the wp-link files, but I think they'd fit best elsewhere. The interface could potentially be applied in several places within core to reduce code duplication, and could, over time, roll in existing interfaces such as the menu tabs manager.
#22
@
14 years ago
This next patch adds AJAX for paging (AJAX for search was included in the previous patch as well).
#23
@
14 years ago
If you haven't seen yet, this is a great plugin with great UI to associate pages with posts http://wordpress.org/extend/plugins/post-page-association-plugin/
#24
@
14 years ago
Will be there any filter or hook to allow changes of output tranfered into editor window? For example, I do not want to insert post permalink as html link but shortcode with ID of this post...
#25
@
14 years ago
Can the post type and taxonomy panels be rendered on demand via AJAX? Right now it seems to load the first page of "all" and "new" for every type and tax, which is a bit slow.
#26
@
14 years ago
Wondering if we really want to show taxonomies in core. Sites that like to link back to their tag pages usually use an auto linker. Plus, it's a lame and annoying practice. ;-)
#27
@
14 years ago
I understand that the automated linking could be annoying, but what would be the point of having taxonomy pages if they weren't linked from anywhere? Most sites might be happy to just have something like "filed in ", but I'm sure there are cases where it makes sense to link to a taxonomy page. I'd like to see the capability, but I wouldn't be opposed to it being a post-3.1 feature.
#28
@
14 years ago
v1 was supposed to offer linking to posts, pages and files only. I'd like to keep it that way to make it easier to measure issues with the UI. The whole thing could be pluggable if people want to add access to taxonomy indexes, etc, but for now, people can still use the blank URL field to link to anything in the world. We need to exercise a little restraint and not throw in every possible option when we add stuff just because it's easy.
#29
@
14 years ago
Third pass covers what was discussed in last week's dev chat:
- All queries are done via AJAX.
- Taxonomies support removed.
- Convert "target" dropdown into an "open in new tab" checkbox.
- Remove "class" dropdown.
- Overload the default 'link' button (as per Andrew's comment above). We should consider #15139 from a UX perspective.
- ...plus refactoring and various odds and ends.
#33
@
14 years ago
- Reporter changed from janeforshort to jane
We'll want an admin_ajax_referer for the admin-ajax case. I would want a cap check there too, but that's going to be tough for editors on different post types ... might need to rely on WP_Query to only return posts the user can view.
#35
@
14 years ago
We need to get this finished up in the next day or two if possible. We've already missed a couple weeks we planned to be doing user testing with it.
#37
follow-up:
↓ 38
@
14 years ago
I have a site based on wp 3.1-alpha. When I was editting a post, after clicking the insert link button, pasting the external link url, it's no response when clicking the "update" button.
But it works in another testing wp blog of mine which is not in multisite mode.
Does this mean that this new link edit funtion is not ready for multisite mode?
#38
in reply to:
↑ 37
@
14 years ago
Sorry, it's caused by WP-Minify.
Replying to lonelicloud:
I have a site based on wp 3.1-alpha. When I was editting a post, after clicking the insert link button, pasting the external link url, it's no response when clicking the "update" button.
But it works in another testing wp blog of mine which is not in multisite mode.
Does this mean that this new link edit funtion is not ready for multisite mode?
#49
@
14 years ago
Hey mmuro, didn't forget about your patch. It would have made more sense to apply this to wp-admin.dev.css versus the individual color stylesheets, but it was even easier -- once Koopersmith and I figured it out -- to fix the root problem, which was that the anchor was missing the href attribute.
#54
in reply to:
↑ 53
@
14 years ago
Replying to ocean90:
What happens if no title is defined: http://grab.by/7tiW
Which could easily happen if, say, asides from the upcoming Post Formats feature are used, as they have no title. Good place to check for an empty string and use "(untitled)" or a localized version?
#55
@
14 years ago
@voyagerfan5761: I'm not sure, but the P2 theme basically takes the first x words and treats them like the title for listing on edit.php, would expect something similar.
#59
in reply to:
↑ 53
@
14 years ago
Replying to ocean90:
What happens if no title is defined: http://grab.by/7tiW
Would be fixed with no.title.11420.patch.
#60
follow-up:
↓ 61
@
14 years ago
- Cc batmoo@… added
Patch is supposed to cache search results to avoid multiple AJAX calls for the same query, but I noticed that it horribly breaks pagination. Reworking it so ignore.
#61
in reply to:
↑ 60
@
14 years ago
Replying to batmoo:
Patch is supposed to cache search results to avoid multiple AJAX calls for the same query, but I noticed that it horribly breaks pagination. Reworking it so ignore.
Cool, nice improvement! Koop and I spoke about this, but it opens the door for a memory leak, so we need to tread lightly.
#64
@
14 years ago
- Cc sbressler@… added
Just attached a screenshot of an oddity with regards to display of post dates with posts with long titles.
#65
follow-up:
↓ 66
@
14 years ago
Incomplete list of items remaining:
- Expand/collapse on the internal linking section.
- Fix rendering issues for long titles and no titles. Row should expand. Items with no titles should say 'Untitled' in emphasis tags (not sure why that isn't showing up). A trim() should occur first to verify an empty title.
- IE7 fixes.
- IE6 fixes.
- (X) in the search box (well, all search boxes) to clear the search terms.
#66
in reply to:
↑ 65
@
14 years ago
@nacin
Patch for no title is already there: no.title.11420.patch
#67
@
14 years ago
Patch should fix text wrapping issues when the title is too long. Needed to use a clearing div to make it work nicely with early IE.
#70
in reply to:
↑ 69
@
14 years ago
Replying to nacin:
That changeset should handle no titles and long titles. Need to confirm that
clear: both
was enough for IE6.
clear: both
doesn't quite do it :( See 11420_text_wrapping.diff for a fix that works in IE6. Screenshots attached for both.
Also see ocean90's patch for the no title issue (no.title.11420.patch). Using the _draft_or_post_title
function seems like a good idea.
#71
@
14 years ago
_draft_or_post_title pushes things through the filter, which we weren't doing. Adding a trim here and allowing the JS to handle the no title seems to work fine.
The issue with 11420_text_wrapping.diff is that it puts a width limit on the title. But that's basically the only solution, as otherwise you can't float something to the right when it's after a block element in the HTML flow and expect it to appear on the same line in IE6. That's what's happening here.
We can probably get away with clearfix instead of the extra markup.
Going to let koopersmith review and advise.
#73
@
14 years ago
Latest change leverages get_the_title(), as _draft_or_post_title() would have. Still handling "(no title)" through JS though, that way we can easily account for that and prevent "(no title)" from being added to the title attribute field.
Please provide a patch.