We are migrating CKEditor issue tracking to GitHub. Please, use GitHub to report any new issues.

The former tracking system (this website) will still be available in the read-only mode. All issues reported in the past will still be available publicly and can be referenced.

Important: we decided not to transfer all the tickets to GitHub, as many of them are not reproducible anymore or simply no longer requested by the community. If the issue you are interested in, can be still reproduced in the latest version of CKEditor, feel free to report it again on GitHub. At the same time please note that issues reported on this website are still taken into consideration when picking up candidates for next milestones.

Right now I think that Internet Explorer doesn't allow to create setters
and getters, so at best it would be a function like .SetEnabled( bNewValue)

Date: 2007-04-02 15:20
Sender: saul11

Independant of this request I have written a toggleFCKeditor function. It
disables and re-enables the FCKeditor. When disbaled, the whole toolbar is
grayed out and the editorArea will not receive any input. Optionally the
toolbar can be hidden or collapsed. In this manner, when re-enabled, the
toolbar will show again or be expanded.
Note: When disabled, the editorArea is also grayed out in IE.

With this patch, clicking on a link while readonly mode is enabled and afer you disable it, links in the editor are opened inside the editor frame.
Also, the context menu still works, yet all options in it are disabled.

I think that we should define exactly what are the features of this configuration.

For example, I don't expect a button that the users can click to toggle it, that would be more along #3944, there are times when the user might want to see how the page will look like, and others where the developer is the one that marks the content as read only. I think that this ticket should focus on this part and #3944 is the one for users.
Disabled form fields aren't sent back to the server, js can interact with them, but they aren't posted when the form is submitted. What should we do?
Is the user allowed to switch to source mode?
Should the content have some different (grayed) styling to signal that it's read only?
Are the contents expected to be active (links, buttons, javascript, plugins...).
A simple solution (maybe only for #3944 and depending on the requirements) would be to define a new mode "preview" or "readonly" similar to wysiwyg where the content is loaded in an iframe, but it's never marked as editable and the raw html (without protecting comments, javascript, plugins...) is used. This could avoid the need of defining "readyOnlyCommands" as each plugin could state if it can be enabled or not in "preview" or "readonly".

As I said, I would like to define first what are the expected behavior of this property and also how it relates and the differences with "preview" mode because that can help to avoid misunderstandings about what this property does.

I had this feature in mind since the early ages of CKEditor 3. These is the way I thought it:

This is definitely not a feature to be activate by the user. It's an editor mode, defined by the developer.

Again, this is a "mode", so it must change the ​editor.mode. We should introduce a new values for it: "readonly".

Having a mode change makes things much simpler as commands are activated depending on the "modes" property.

The contents should be loaded into an iframe by dedicated code, but should still pass through the data processor (this means that things like anchors or placeholders will still be rendered and the page will not be alive). This step is necessary also because the input data may not be HTML.

Regarding the form post, we must just make it work like a <textarea disabled="disabled"> element. The thing to note is that the readonly mode will make no changes to the input data.

Context menu... I'm a bit unsure. Some features like "Copy" may still be useful.

My use case for this feature is to use it as a web 2.0-ish wiki-editor - default mode is to simply browse the wiki and read what others have written, but occasionally you want to change a speling error, or add a sentence. With a read-only mode, users wouldn't have to reload the page, scroll down, find the stuff you want to change, change it, save, watch page reload, scroll again - you'd just click "edit" in a floating toolbar, change and press save. No page reloads, no searching for the stuff you wanted to change - just simple, intuitive, inline editing.

My use case for this feature is to use it as a web 2.0-ish wiki-editor...

I hope you've checked our divreplace sample for me it's not a use-case of the read-only mode.

Please tell me if this discussion should be moved to the forum.
The divreplace sample is pretty much how I put it together when I looked at it some months ago (​http://wiki.wendt.se/) - except I used Ext-core to attach a double click event and that you edit the full page and not just one part of it (moving text from one div/part to the other seems to force too much work for the user when only editing parts of the page).
I've also looked at full screen mode, and I tried to disable the editor (read-only) as suggest with the patch supplied on the forum (and in this ticket), but had to stop becuase of time constraints. With full screen and read only I had two points left to work out:

does the full page need to reload when following a link, or could just the wysiwygarea reload (and the browser's URL field/location field in the toolbar)

attach the double click event to the wysiwyg area, to have the editor change into edit mode

attach to escape button key press, and let that save data (ajax) and turn the editor back into readonly (browse) mode

The divreplace examples demonstrate perfect use for CMS:s, where you're only allowed to (and perhaps want to) edit parts of a complete page. For an enterprise wiki (such as confluence), with technical documentation, the use case is different.

after double clicking on the div, the word selected is selected when the editor instance is ready

when you edit a div which is longer than the height of the browser window (full page), the word/content double clicked should be in focus - basically with divreplace you have to handle scrolling issues - using a true read only-mode would not have this issue since you're already working in the wysiwyg area

@fredrik_wendt, note that "read-only" mode is not "browse" mode. As said before, the loaded contents will still be processed and rendered much like the "editing" (wysiwyg) mode. The only difference is that it'll not be possible to make changes to the contents.

This means that the editor contents will not be "active" in read-only mode, so things like links will not work (no navigation on click).

I have an ASP.NET website where CKEditor is almost exactly what I need - just missing one thing: a readonly capability.

Requirement:
Software to embed in an ASP.NET webpage so that one class of user can create a Word like document which another class of user can view (readonly) in another ASP.NET webpage.

I have used the current version CKEditor 3.4.1 (revision 5892) to create two separate CKEditor configurations.
One configuration creates a CKEditor box with a limited number of toolbar buttons which successfully provides the required functionality in a webpage that outputs the HTML to a document that is saved to disk.
The other configuration is used in a webpage that reads the document and renders the HTML to display the formatted text in the CKEditor box. This CKEditor configuration does not have any toolbar buttons so the user is unable to format any text.
Visually it appears that this successfully provides the required functionality for the 'readonly' class of users.
However, the user is still able to use a mouse or tab key to give focus to the CKEditor box and then add/delete text.
This is not ideal since it may confuse users.
This webpage does not provide any means by which this document can be updated so the document is safe from change by the 'readonly' class of user.

CKEditor is so close to being exactly what I need!

Please consider this scenario when designing any proposed 'readonly' modification to CKEditor.

I'd not mix too many things in this ticket. Preview mode mentioned in comment:11 should stay as a separate issue as its much more complicated, one may want to replace some placeholders using server side language in preview mode and do some other stuff with the content.

readOnly mode should stay as simple as possible instead and do only the following: disallow user from changing the content inside of the editor

all buttons useless in readOnly mode should be disabled

buttons/commands that are useful should be still available (Maximize, Find, Copy etc.)

I'd not worry that much about form elements and eventually fix all issues related to them later in separate tickets (and consider in the meantime using fake elements #5804)

New patch is a rough implementation of the idea following "readonly as a mode" - it behaves as a (special) parasitic mode that doesn't load/unload, which means it remain all functionality of an existing mode but just staying readonly at the API level, which set mutation restriction only inside of editor (user may change it anyway at DOM level).
The patch is not meant to be complete, polishing will be following once the idea is accepted.

I discovered that the buttons would still format the text so if you choose the function above you should also customize the toolbar for that particular setting by modifing the CKEDITOR.replace() command with something similar to:

Finally, the script worked for me, although I have prevented access to the buttons so they can not put links on selected text, for example.
For now it works, but Firebug detects a javascript error: "uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.queryCommandEnabled]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: ​http://websopde/panel/v3/_include/editor3/ckeditor.js?t=B1GG4Z6 :: u :: line 5793" data: no]"

Finally, the script worked for me, although I have prevented access to the buttons so they can not put links on selected text, for example.
For now it works, but Firebug detects a javascript error: "uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.queryCommandEnabled]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: ​http://websopde/panel/v3/_include/editor3/ckeditor.js?t=B1GG4Z6 :: u :: line 5793" data: no]"

After searching for information and find similar cases, I've found a way to put the editor in read mode. It also works if there are many editors on the same page, whether reading or writing. The operation of the editors are correct in all cases.

I found proposing 'readonly' as an mode looks awkward and requires much more hacks, for me it's more appropriate to just treat it as a configuration provided the 'editingblock' plugin, editing block relevant plugins must be ware of it (e.g. wysiwyg and sourcearea), while other plugins in most cases could just live in ignorance.

Additionally, I believe the state listening changes should not be handled by the editingblock plugin, being coded at the UI element level. This means that the editor should fire a "readonly" event that can be listened by these elements.

The command status updates could also be done in the editor.js code, instead of editingblock.

Basically, considering that we're not any more talking about a new edit mode, the editingblock code should have very little involvement with this tickets.

The "Print" and "Show Blocks" buttons are still enabled when switching to source view.

The editor becomes editable when using the Maximize buttons.

The "Select All" button is not working on read-only mode.

The editor.readOnly initialization should be done in the editor.js file, right after loading the configurations, not in the editingblock plugin.

The "mode" event should not fire the "readonly" event. If this happens it means that we're doing part of the processing wrongly and it's a hack. editor.readOnly must be checked on mode change instead.

CKEDITOR.editor.prototype.setReadOnly should be defined in editor.js. It should simply set editor.readOnly and fire "readonly" for the change. This is the only place to have this event fired.

Note that the "readonly" event is there not to say that the editor is in read-only mode, but to announce the readOnly property change, either to true or false (btw... do not fire if not changed). To understand if the editor is in read-only mode, the readOnly property is to be used.

My bad... the event name should be "readOnly".

There is no need to have the js alert when switching the read-only mode. This is distracting and the editor behavior change is quite evident.

The editing block change start from [6752] and subsequent changes are not good, it hacks things too much, introduced awkward code like below and make the "mode" event dirty with an empty state which will surely breaks back-compact, I'm just totally against it.

editor.setMode();
editor.setMode( 'wysiwyg' );

Anyway I'll not be able to review here since the reviewing role is already messed up.

That's ridiculous. You don't need to copy my comment from another ticket. This is a very different situation because we were not working on this ticket *at the same time*. I was the only person working on it. Here we had a r?. In the other ticket I got a r-, so we were both working on it at the same time.

---

The editing block change start from [6752] and subsequent changes are not good, it hacks things too much, introduced awkward code like below and make the "mode" event dirty with an empty state which will surely breaks back-compact, I'm just totally against it.

editor.setMode();
editor.setMode( 'wysiwyg' );

I'm not chancing any feature here, simply *adding* a new feature. You should be clear when you say that it breaks things, eventually pointing a specific example.

The way it has been implemented is much clearer now. It's up to the mode to do the read-only change job, and the way the wysiwyg mode does now is very clear: unload and reload the mode. Having it done by the editingblock was a much uglier hack. Just see that the sourcearea way is totally different and doesn't need reload.

Anyway I'll not be able to review here since the reviewing role is already messed up.

There is no fixed review role. We're all developing this thing together. If I see something to be fixed while reviewing, I simply go ahead changing things. Especially in this case, where just pointing out issues on comments would simply delay things a lot.

The way I made the changes were quite clear. I've created a branch and applied your patch to it. Than, over your patch, I've made several changes which can be then reviewed by you based on the branch log. Then, if you have further changes, it's enough to you to commit things again, which will be then reviewed by me... and so on... this cycle would go until a stage that one of us, when reviewing, would be satisfied with the final result.

From two comments the only thing that can be considered is the maximized thing pointed by Saar, even if it's an edge case that can be dealt on a separated ticket. to avoid delaying things further, I'm putting this on review again,