WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#16631 closed feature request (fixed)

Internal linking feature is not available when rich text editing is disabled

Reported by: laacz Owned by: koopersmith
Milestone: 3.2 Priority: normal
Severity: normal Version: 3.1
Component: Editor Keywords:
Focuses: Cc:

Description

In plain text editor (at least - when rich-text one is disabled in per-user settings) there is no internal linking feature available. Link button pops up just an link input dialog.

Attachments (1)

16631.diff (15.8 KB) - added by koopersmith 3 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 westi3 years ago

  • Type changed from defect (bug) to enhancement

This was done consciously.

Changing to an Enhancement

comment:2 jtsternberg3 years ago

who worked on this feature for 3.1? Would like to bug them into helping me make a plugin/future patch.

comment:3 mitchoyoshitaka3 years ago

  • Cc mitcho@… added

+1. I (we) would love to see this happen. Perhaps I will write a patch.

comment:4 jane3 years ago

  • Type changed from enhancement to feature request

What I would actually like to see, and have talked about with @koopersmith (who did the internal linking feature, to answer @jsternberg's question), is not replicating internal linking in the html view, but putting linking up on the level of media insertion, so the same thing is available to both. Not in scope for 3.2, but would love for 3.3, and a plugin in the meantime would be great.

comment:5 jane3 years ago

  • Cc jane koopersmith added

comment:6 koopersmith3 years ago

  • Keywords has-patch added
  • Owner set to koopersmith
  • Status changed from new to accepted

Patch adds internal linking to HTML mode. Tested in Chrome, FF, IE8.

We can explore relocating the linking trigger, but that should be done in a separate patch.

Note: The only compressed file is the TinyMCE editor_plugin.js, and there is a new js file, wpdialogs.dev.js (in the js directory inside the tinymce wpdialogs plugin).

koopersmith3 years ago

comment:7 azaozz3 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [17687]) Use wpLink in the HTML editor too, props koopersmith, fixes #16631

comment:8 azaozz3 years ago

  • Milestone changed from Awaiting Review to 3.2

comment:9 scribu3 years ago

Where exactly is this feature in the HTML editor? I can't find it, with or without TinyMCE enabled and with SCRIPT_DEBUG on.

Last edited 3 years ago by scribu (previous) (diff)

comment:10 nacin3 years ago

(In [17690]) Update wp-tinymce.js.gz and bump. see #16631.

comment:11 follow-up: scribu3 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

In Firefox 4, with the visual editor selected, refreshing the edit screen shows both the TinyMCE controls and the HTML controls above it: http://i.imgur.com/QMXFn.png

comment:12 in reply to: ↑ 11 koopersmith3 years ago

Replying to scribu:

In Firefox 4, with the visual editor selected, refreshing the edit screen shows both the TinyMCE controls and the HTML controls above it: http://i.imgur.com/QMXFn.png

I've encountered this error several times before (months ago) and have never been able to pin down the cause. I currently cannot reproduce the error and it usually goes away with a subsequent refresh/cleared cache/browser restart.

Is this happening consistently? Are there any signs pointing to this changeset?

comment:13 follow-up: scribu3 years ago

It's still happening today and it only started happening after [17690].

I have SCRIPT_DEBUG on and I've refreshed and restarted the browser several times.

If I switch to HTML mode and then back to visual mode, it goes away.

comment:14 in reply to: ↑ 13 azaozz3 years ago

Replying to scribu:

Does it happen in all browsers or only FF 4? Also can you check it with Firebug (or similar) if it's the same <div id="quicktags"... or there is a second one on page load.

Last edited 3 years ago by azaozz (previous) (diff)

comment:15 scribu3 years ago

It seems to also happen in Chrome (can't test other browsers atm).

Yes, it's the same div. The code that's supposed to hide it just doesn't seem to fire initially.

comment:16 scribu3 years ago

Also: no plugins active and using twentyten theme.

comment:17 aaroncampbell3 years ago

  • Keywords needs-patch added; has-patch removed

It happens to me too, but only in FF4. I tested (on Windows):

  • Opera 11
  • Chrome 11
  • IE 9
  • Safari 5

Like scribu said, changing tabs fixes the issue, but on the page load it's messed up.

comment:18 jane3 years ago

  • Milestone changed from 3.2 to Future Release

Didn't make it in before freeze, punting.

comment:19 nacin3 years ago

  • Milestone changed from Future Release to 3.2

This is in trunk. Anything left, koopersmith?

comment:20 koopersmith3 years ago

  • Keywords needs-patch removed
  • Resolution set to fixed
  • Status changed from reopened to closed

All good. If the double-toolbar bug keeps cropping up, please open a new ticket.

Note: See TracTickets for help on using tickets.