Make WordPress Core

Opened 13 years ago

Closed 13 years ago

#16631 closed feature request (fixed)

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

Reported by: laacz's profile laacz Owned by: koopersmith's profile 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 13 years ago.

Download all attachments as: .zip

Change History (21)

#1 @westi
13 years ago

  • Type changed from defect (bug) to enhancement

This was done consciously.

Changing to an Enhancement

#2 @jtsternberg
13 years ago

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

#3 @mitchoyoshitaka
13 years ago

  • Cc mitcho@… added

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

#4 @jane
13 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.

#5 @jane
13 years ago

  • Cc jane koopersmith added

#6 @koopersmith
13 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).

@koopersmith
13 years ago

#7 @azaozz
13 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

#8 @azaozz
13 years ago

  • Milestone changed from Awaiting Review to 3.2

#9 @scribu
13 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 13 years ago by scribu (previous) (diff)

#10 @nacin
13 years ago

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

#11 follow-up: @scribu
13 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

#12 in reply to: ↑ 11 @koopersmith
13 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?

#13 follow-up: @scribu
13 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.

#14 in reply to: ↑ 13 @azaozz
13 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 13 years ago by azaozz (previous) (diff)

#15 @scribu
13 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.

#16 @scribu
13 years ago

Also: no plugins active and using twentyten theme.

#17 @aaroncampbell
13 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.

#18 @jane
13 years ago

  • Milestone changed from 3.2 to Future Release

Didn't make it in before freeze, punting.

#19 @nacin
13 years ago

  • Milestone changed from Future Release to 3.2

This is in trunk. Anything left, koopersmith?

#20 @koopersmith
13 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.