DokuWiki

I would like to change the displayed icons/funcionality from the ckgedit plugin. E. g. I want to remove the button “Bold” and “font size” so a user can not easily change these types. Where is the line in the code? I would like to remove the line for this displayed button (not the whole functionality itself). Thank you very much!

Use the forum or github for questions.

I have a client that I installed ckgEdit for. They're using Internet Explorer 11.0 on Windows 7. The web site is running DokuWiki ver. Hrun C, along with the current version of ckgEdit. When they attempt to edit a page, ckgEdit displays HTML. IF they click “Save”, then the page content is deleted and replaced with “false”.

ckgEdit works fine from the web site when accessed using the latest version of Google Chrome or Firefox.

Any idea what the problem might be?

— rrandall 2015-03-27 18:21

I don't have IE 11 on Windows 7 but I do have IE 11 on Windows Server, and it works in HRUN C without any problem on Windows Server. There shouldn't be a difference between the two. You might try turning on the javascript console and seeing if there are any errors reported. You might consider installing ckgedit 4.4.7: https://github.com/turnermm/ckgedit/archive/4.4.7.zip. This uses the most current version of the CKEditor. Also, if there are any other plugins installed, you might disable them and see if the problem persists. If ckgedit works, then you know there is a plugin conflict, and you can re-enable your plugins one-by-one, until the conflict shows up. Also, if this is not a fresh install of dokuwiki and/or ckgedit, clear out the browser cache and the dokuwiki cache and start fresh.

The javascript console reported no errors. I disabled, and then removed all of my added plugins. The problem persisted. I installed the latest version of CKEditor. Problem persisted. Next, I'm going wipe it out and re-install DokuWiki. But I must wait until a time when the client can tolerate the down-time. In the meantime, I replaced ckgEditor with fckgEditor - which seems to be working fine with IE 11. Is there still a problem with fckgEditor and IE 11?

— rrandall 2015-03-27 18:21

If it works, good. But I can't get it to run on windows server in IE 11, only in Win 7 with IE 10, using 10 compatibility mode together 9 browser mode. Thankfully Microsoft is getting rid of IE when Win10 is released. Consider that in IE 10 you can choose from a whole buffet of possible combinations of browser and compatibility types in order to get a site to run correctly! They are the only ones out of step with the rest of the browser community, where these problems never occur.

I just tested on Win8.1 with IE 11 and ckgedit. Only issue was that the filebrowser displayed broken images and I had to switch to winstyle mode. I believe this is the result of security issue with Windows 8. I didn't bother to investigate.

— flavio 2016-10-31 14:35

I have the same issue on a fresh installation of Dokuwiki and ckedit. When I switch between CKedit and DW editor the page content changes to “false” and everything is lost. I think that the problem comes during the switch between the two editors. I use Windows 10 with firefox 49.02.

I have use ckgedit for the markup-impaired in my lab and I have an issue with the latest version. When I installed it, either through the manager page or manually, I end up with a blank page. Removing the plugin altogether brings me back to a working wiki. Looking at Apache logs, I see no obvious pointers toward any error.

Where should I start for troubleshooting?

Thanks in advance

Sylvain

Without more information about the ckgedit version, the dokuwiki version, the OS your browsers are on,and which browsers, and the OS that dokuwiki is on, I can't help. If it was working before, which version were you using? You can go back to the previous version by checking the fckgLite web site: http://www.mturner.org/fckgLite/doku.php?id=dailies&b_disp=1#ckeditor_4

— Myron Turner 2014-06-04 19:03

Allo good points Ok, here goes: I installed the latest ckgedit from dokuwiki's plugins page on a on an Angua-based Dokuwiki. I am using the latest from both Safari and Firefox on Mac OS X Mavericks. The version that worked previously was fairly old. I went back to the dailies page and tried the last version for every month starting from the oldest: Dec. 15 works but not Jan 30.

I installed the most recent ckgedit on an angua wiki: Release 2012-01-25a “Angua”. I did not encounter this problem. I can't see anything in the Changes files between those two distros that stands out. The next step is to check for plugin conflicts. It's possible that the latest ckgedits conflict with one of your plugins. I would also entirely clear out data/cache. -Myron Turner

Checking for plugin conflicts requires disabling all plugins and re-enabling them one by one.

I had another thought. If you are using a version of PHP earlier than PHP 5.3, then you will need an alternate version of ckgedit/action/edit.php, which you can get here: at Sourceforge

Well, that pre-PHP 5.3 trick did the job: the latest ckgedit does work under Angua with it. It's time I have my server upgraded…

Thanks for the time

S

Whenever I hit the “Save” button nothing visible happens. Checking the console in Chrome I am getting the following error:

Uncaught ReferenceError: parse_wikitext is not defined doku.php?id=private:start&do=edit&rev=0:620
onmousedown

Did I do something wrong, or am I missing something?

Note: I can hit “Save” and no error appears and I am brought back to the main page, however it is only if I change something where the problem occurs.

parse_wikitext is embedded in the editor, i.e. in the same file that opens the editing window, so it can't be missing. It is the main parser that converts the HTML to Dokuwiki markup.
What Operating System are you using for your desktop and what version of Chrome? Have you tried editing with Firefox? Try and see what happens. On Debian 6, for instance, with the pre-installed version of Chrome, there was a similar problem which disappeared on update to a current version of Chrome.

I am using Windows 8 with the latest beta release of Google Chrome. Just for kicks I got out Internet Explorer and tested editing with ckgedit. I was able to successfully save it this way.
I downgraded from the beta version of Chrome, to the stable build and I am now able to save. Seems like the beta is causing issues.

I had the same problem when I had a <span http:=“”> tag that I have no idea where it came from … I removed it and now it works. however save button should probably also work with invalid html?

After you removed it, did it reappear the next time you loaded the page into the editor? — Myron Turner 2015-10-25 15:13

I was having some problem with this part for a while. Every time I made the code block (or file block) it would work when I viewd it but the page would become editable afterwards. I followed the steps perfectly, even watched this youtube http://www.youtube.com/watch?v=bI7x17EBbbI&feature=youtu.be, but it still didnt work. Then I realized that I was pasting xml code into a codeblock of php (it was actually my vhosts.conf apache file ). Once I told geshi it was an xml file it worked. I guess make sure you are telling geshi what type of code it is (and that its valid) or it will BREAK your page and become uneditable.

I think the problem here is not universal to all geshi code types but that Ckeditor saw the unidentified xml as html. That is, it would not happen if you put php into javascript or vice versa. Also, my tests show that if you have created a properly identified xml block, then added non-xml code, the code block will not break.

— Myron Turner 2013/10/08 12:58

I moved my website over from home to my office. I used chrome and internet explorer (not sure which version at home yet) and it all worked mostly just fine. At work we use internet explorer 8.0.7601 and I get these errors while runnign with ckgedit.

Message: Object doesn't support this property or method
Line: 312
Char: 299
Code: 0
URI: http://memphiswiki.local/lib/plugins/ckgedit/ckeditor/ckeditor.js

I reinstalled the version I was using before (cleared caches and all) still errors. I installed the new version you just spoke about. Still errors. Basically you can't click enter and do much. Not sure what to do..
I just tried it on chrome in my office, works fine. So ckgedit doesnt support Internet Explorer 8?

You probably need to set IE to compatbility mode. Also see internet_explorer.

I managed to find a copy of IE8 in a copy of XP . With compatibility mode on, I found no problems, including use of tag plugin and footnotes. Sorry I can't be of any further help.

Hmm I also tried it and it didnt work on another VM of xp in at my house. You have me wondering if I'm doing something different. What version are you using? Fckgedit works okay on xp ie8. I might be forced to use that program. At my company there are very strict rules about installing things (chrome frame) for safety reasons.
I tried again on fresh vm and only new doku wiki and your version installed. Same error. I'm not the only one http://www.freelists.org/post/fckglite/ckgEdit-JavaScript-error-with-IE-8,1 . Exact same error as me.I see your response as well about not being able to do anything about it, I guess we will need to use fckglite.

The *length* of my editing section is pretty short. I usually have to drag the bottom right corner to make it longer. Is there a way that I can customize this to make it longer. I know there's the maximize button to make it bigger, but I would prefer if it was juts a little longer. Jeremy

In ckgedit/ckeditor/config.js, set config.height, for instance config.height = '400px' . You must include it inside the CKEDITOR.editorConfig function.

Works Great! Thanks!

Sorry, as a non-programmer I don't know how to do this. I've put the command config.height = '400px' into the code of the file config.js in front of b.colors=new Array(…), but the only result ist that the editor window is empty. — Juergen_aus_Zuendorf 2015-03-18 14:23

See: https://github.com/turnermm/ckgedit/issues/75

I notices that you said above “There is a new and hopefully better technique for handling plugins.” However I don't really see you mention how thats done. I recently installed a plugin that will encrypt some information on my pages. When I use the dokuwiki edit the button is there and it works great. However I dont see the button with this edit window. Is there a way to get this button to appear with ckgedit.

No. The two toolbars are entirely separate. To create plugins with toolbar buttons see: Ckeditor tutorials.

Okay. I've gotten pretty far from 6 hours of work. What I did is I have the button added and it works and I can get it to call external functions just fine. The only problems though is that some of the code was relying upon having no tags (formatting, e.g <span> <P>) so that when you select the text it can do a dokuwiki replace with the new encrypted string. I have tried modifying that code 10 times over to find a way that I can simply replace what in my selected text with “<decrypt>theencryptedtext</decrypt> but can not find a way to do it. This is the only thing thats left to get this working. If you know a way to replace selected text with other text it would be greatly appreciated. Below is some samples of what I have tried.:

http://stackoverflow.com/questions/3964710/replacing-selected-text-in-the-textarea http://stackoverflow.com/questions/1642447/how-to-change-the-content-of-a-textarea-with-javascript

You have to use the Ckeditor's own functions. See http://docs.ckeditor.com/#!/api/CKEDITOR.editor-method-insertHtml and look at the Signature and Shortcuts plugins in the ckeditor/plugins directory for how to use insertHtml or insertText.

First I want to thank you for all your help. Second: It's WORKING PERFECTLY! Eveythings working just fine and now I can encrypt on both ckgedit and dokuwiki edit. In the end, to insert the text you just put “editor.insertText('<decrypt>secretpassword</decrypt>')” and it will slip the text right into the perfect spot, even between the formatting so it can be conserved. Thank you so much for this product. If you would like me to upload the plugin folder I can do that as well, but it is reliant on having the encrypted plugin installed right now. I might work around and use ckgedits dialog boxes, but right now its just using encryptedpasswords own dialog boxes.

Glad I could be of help. And it's good to have someone else learning to make plugins for ckgedit.

Hi, do you think you can upload your plugin somewhere? I'm afraid my knowledge is not enough to reproduce it myslelf.

I have been struggling with getting these two plugins to work together also, any chance you could supply some additional detail (paint by numbers version) on how you did this. Thanks in advance.

I didn't create the encryption plugin, I only helped another user to find how to do that for himself. Perhaps if he sees this he will be able to help. — Myron Turner 2015-06-23 23:06

Thanks, his plugin folder would be a big help.

How do you enable server side spell check. In fckglite you could do this by installing aspell and configure through the “Configuration Manager”. The configuration manager for ckgedit has some of these options but it doesnt seem to work. I also cant seem to find the code that uses aspell anywhere in ckgedit (aspell.php for instance in fkglite).

The default spell checker for CKEditor 4.x is Scayt, which checks as you type. For the old aspell checker, you will have to do a search. This looks promising: http://stackoverflow.com/questions/8723384/aspell-with-ckeditor, but it is directed at CKEditor 3.x. However much of what is done with 3.x also applies to 4.x. One of the unfortunate aspects of Scayt is its limited language support. However, you can apparently add your own dictionaries, though I haven't checked out how that is done. But there is a tab for doing this when you click on the Scayt toolbar button.

Thanks for the help, got it to work. Your link has another link to a dead page. Use this http://ckeditor.com/forums/CKEditor-3.x/Interest-aspellspellerpages-plug-for-CKE-3. Need to make some changes to get it to work. spellerpages/server-scripts/spellerchecker.php needs to be changed to reference your windows installation of aspell (it default to the linux). dialogs/aspell.js and plugin.js need to be changed so that it uses the correct language object to get its strings (text) from. Use CKEDITOR.lang.en.wsc.whateverstring. (there are alot of lines that need to be replaced in these files, have to find them all to get it to work, CKeditor must have changed how they handled their lang object from v3 to v4). You need a good icon as well and reference it in plugin.js.

Also as a sidenote, how do you handle dialog windows in fckglite? I try to make an overlay window and it just pushes everything down in the text area and messes everything up. Just trying to get encryptedpasswords working with fckglite like I did with ckgedit.

See http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.dialog.html#.add for an example and this link for the for the API: dialogDefinition.html. You can also use the ckgedit footnote plugin as an example; it has more features than the example at the above link but the above link gives you a clear skeleton.

Also as a sidenote, how do you handle dialog windows in fckglite? I know this isn't exactly the right place for it. I already got the dialog window working for ckeditor. I wanted to get it to work for the previous version, fckglite.

Do a google search for FCKEditor – plugins and/or checkout the plugins that come with fckgLite ad pop up dialog windows.

If I create a page in the DokuWiki Editor with the following text:

Test

Oh NO!!!

Yay!!!!

Save it, Switch the the CKEditor and then Switch back to the DokuWiki Editor, The Formatting is LOST!!!! Does anyone know how to fix this? The editor is unusable if it is going to corrupt original DokuWiki Formatting!

  Test\\
  >Oh NO!!!\\
  >>Yay!!!!

Had you entered your original Test into the editor, this dokuwiki markup would have been created for you automatically. If ckgedit is such a pain to use then don't use it. — Myron Turner 2014/04/18 21:21

Sorry… Didn't mean to be rude… Only been using DokuWiki for a week and I love it but don't believe people without a CS background would be willing to adapt to the built-in editor… Is there any way to have it parse normal new line characters rather than the explicit \\? thanks

Dokuwiki processes plain text in paragraphs. If you need a newline then you have to explicitly indicate it with the double backslash markup. If you write this:

The
man 

Dokuwiki will output it as

 The man

To get a new paragraph you have to double space.

I have also an adition regarding this problem. This plugin is very useful for people that don't use Dokuwiki syntax frequently. However some of our pages contains syntax that the plugin can't work with. This is an example. It's rendered fine with the standard Dokuwiki editor. But saving with the CKEditor mode on it goes wrong. Maybe there is a solution for this issue?

This is text

-- Comment
SELECT 1       

• This is also text

  -- resultset
  SELECT ...
    FROM #temp

This is again text

See ckgedit and geshi above.

—-

This issue is only confirmed in Binky

I currently have a dokuwiki list (using spaces and *) Wrapped (using Wrap plugin) inside a single cell of a Dokuwiki table. When I, or anyone with editing privileges switches to the CKG edit program and hit save, the <wrap> tag disappears and the table breaks. Is there any way to preserve the <wrap> tag and formatting for such tables using the Wrap plugin?

Manually re-adding the <wrap> tag and pasting the list back into the table doesn't work either.

Put the markup for a table cell with a list here on this page so that I can see what it looks like — Myron Turner 2014-05-28 21:48

Here is part of one of my tables… This only works properly if the Wrap plugin is enabled

^Phase  ^  Description  ^  Actions/Response  ^ 
|1  | No viruses have been reported to cause infections in humans  | Appoint pandemic coordinator and/or pandemic task force team\\     | 
|2  | An animal influenza virus is known to have caused an infection in humans, low risk to humans   | Begin to prepare for possible pandemic.  Reaffirm policies with employees and remind them of basic hygiene practices to reduce vulnerabilities.\\     | 
|3  |  An animal or human-animal influenza virus has cause sporadic cases or small clusters of the disease  |<wrap>  *Convene the Pandemic Task Force and establish regular advisories and communication.\\
  *Appoint member to frequently check [[http://pandemicflu.gov/|http://pandemicflu.gov]] and [[http://www.who.int/csr/outbreaknetwork/en|www.who.int/csr/outbreaknetwork/en]]\\
  *Refer inquires from employees and clients to one person on the Task Force to ensure that uniform information is being relayed to all employees and clients.\\
  *Display signage and posters regarding flu season. \\
  ***Distribute Employee Addendum to all employees (attached).**\\   \\
  *Advise employees of the Pandemic Plan and have employees refer to Employee Addendum for workplace hygiene protocols.\\
  *Review and maintain emergency contact list – employees, clients, vendors.\\
</wrap>| 

Here is your table: http://www.mturner.org/devel/doku.php?id=temp:wrap. It has been opened many times in the ckgedit editor and resaved, without any problems. Here is how:

You can't begin with the Dokuwiki editor but you must create the <wrap> in the ckgedit editor. Start with an empty cell. Place the wrap tags at the top and the bottom of the cell. Then paste into it the text which you are wrapping. Avoid using these \\ line-break mark-ups. ckgedit takes care of that. If you use them, ckgedit will escape them with percents: %% and you might find that your text is aligned to the right of the cell, which is in itself easily handled by right-clicking on the cell and opening cell properties where you can re-set the alignment.

The problem is that we have a couple thousand pages in DokuWiki already. Some of these are generated using an HTMLtoDokuWiki converter and have remarkably complex/large tables. The example I gave you is not really significant. Also, there is extensive use of the \\ character and DokuWiki interprets them fine as it is. The current team at our company is small and all know how to use the DokuWiki editor. We will be combining with another team of over 50 people (that have been using the fancy confluence and are comprised of quite a few non-technical personnel) and would like to extend our current DokuWiki with a WYSIWYG editor. Is there anyway to have CKGEdit not add its own formatting modifications to already existing pages?

I believe I may have found a solution for you. Try this version of edit.php, which goes in the directory ckgedit/action: https://www.dropbox.com/s/2br4flkv7j7ootz/edit.zip. And please let me know the result, so that if it works without any side-effects, I will integrate it into the plugin.

Note: Changed the link to the edit.zip: https://www.dropbox.com/s/2br4flkv7j7ootz/edit.zip

Oh Wow… That is much better… My pages with formatting that CKGEdit handles poorly(IE wraps written in the DW editor placed inside table cells) can now survive people clicking the Edit-Page button and then Canceling changes. Also, they can switch from the DokuWiki Editor to the CKGEditor without corrupting the original formatting. However, it still auto saves changes when switching from the CKGEditor back to the DokuWiki Editor. This is definitely an improvement but not quite there for my needs :) … I'm wondering if a better solution is to write a program to go through and change wraps inside table cells to something else, but I'm not sure what would work instead.

The problem is all of the newlines. The parser takes the newline to signal the end of the table, therefore whatever follows is printed below the table, as coming after the table. The wrap plugin hides the newlines, so the table is not broken. You say you have thousands of pages. So this may not be doable, but if you load each table into the ckgeditor, it will remove the newlines; just save the page. Then you don't need the wrap plugin; the result will be the same as with wrap. I'm not sure what your problem is with the auto-save, but that's not something I plan to change at the moment.

Ah .. Ok… I see what you're saying now. I guess I was confused because even though the WYSIWYG editor shows the list within the table cell, it still breaks the table because of the new-line. I think the CKG editor is valuable enough to write a script to go through the existing pages and remove the new line markers within table cells…The table edit feature alone is better than any of the standalone table-editors I've tested these last few days. I'll be posting here if I find anything else that doesn't get interpreted properly. Thanks for all your help! :)

It's not the new line markers that have to be removed–not these: \\, but the actual newlines insdie each cell, which is what the fix I made does. If you open the dokuwiki editor after the ckgeidtor has fixed the cel you wil see this:

|3  |  An animal or human-animal influenza virus has cause sporadic cases or small clusters of the disease  |*Convene the Pandemic Task Force and establish regular advisories and communication. \\ *Appoint member to frequently check [[http://pandemicflu.gov/|http://pandemicflu.gov]] and [[http://www.who.int/csr/outbreaknetwork/en|www.who.int/csr/outbreaknetwork/en]] \\  *Refer inquires from employees and clients to one person on the Task Force to ensure that uniform information is being relayed to all employees and clients. \\  *Display signage and posters regarding flu season. \\  ***Distribute Employee Addendum to all employees (attached).**  \\   \\ *Advise employees of the Pandemic Plan and have employees refer to Employee Addendum for workplace hygiene protocols. \\ *Review and maintain emergency contact list – employees, clients, vendors.|

Everything in the cell is now on one line; the newline markers can remain.

Yes… that is the revelation that I had before I made my last post =] … New-line vs break-line… Thanks for clearing that up for future readers!
Edit: Wait… if you're fix is supposed to do that, then (for me) it's not working as expected. If I open a dokuwiki created list within a table cell surrounded by a wrap, the initial <wrap> and everything before the first return disappears in the WYSIWYG editor and on page… everything else (after the initial line break) is visible outside the table (expected broken table) … This is how it's been before and after your new code.
I can fix it in the text files in the pages directory though so I'm just going to write a script to go through the pages and fix these instances removing the new-lines… Thanks again!

The fix was written specifically with your case in mind where you combine forced newlines(\\) and standard newlines. It was not meant to remove all new lines from tables, so that you could create lists. What you are getting in fact are not lists, but starred items. The wrap plugin can create lists only in divs, which require the upper case <WRAP> and divs will break tables.

Well I gave this problem another shot. The following works only if there is a forced newline – \\ – at the end of each line: https://www.dropbox.com/s/2br4flkv7j7ootz/edit.zip. What you've done, as I said earlier, doesn't create true lists but starred items;it's a clever (but not very pretty ) workaround for a markup that would otherwise break the table, that is, the wrap container protects the table cell from the newlines. But in ckgedit plugins are not rendered into HTML; they are left as plain text, so what is needed is to convert the newlines into forced newlines which –not being plugins –are converted into HTML BR's.

This new version of edit.php successfully maintains single <wrap></wrap> elements within cells. However, if there is a multi-wrap as follows, <wrap><wrap></wrap><wrap></wrap></wrap>, the table breaks lol… Can anything ever be simple? The tables that use this syntax were generated while using an HtmlToDokuWiki converter for non-simple tables. I'm not sure if you want to extend your plugin to be able to handle complex wrapping like this, but I would certainly update the code with your new basic wrap handling because it is definitely an improvement and most people new to DokuWiki will have the Wrap plugin as it is suggested by default when retrieving an install from the Download page. Thanks again for all your help!

I have included the wrap fix in the latest distribution. — Myron Turner 2014-06-10 02:00

The wrap fix appears to be working well in the latest version … I really appreciate all of your effort!

The conversation for this problem started in the above Wrap-plugin discussion but is unrelated so I have started a new section.

I am a new CKGEdit user and this is off-topic from my original problem and probably not representative of the entire CKGEdit user-base, however, in response to your other point, the problem with CKGEdit saving everytime somebody switches to the DWEditor is two-fold:

1. You get ghost revisions that have little-no meaning, are without revision comments, and make it difficult to maintain the change-control that is of the utmost importance to most organizations.
2. It is being assumed that the CKG interpretation of a page is perfectly in-tune with the DokuWiki Editor's interpretation and every plugin that a DokuWiki Administrator chooses to add-on to his page, which, as my original problem points out, is not the case.
   • On a side note, I have to forgo incorporating the publish plugin because of this problem

I've looked at this and couldn't reproduce it with Firefox/Windows 7, latest Dokuwiki on a linux server. I didn't go beyond this, so perhaps you can give me more details as to browsers,servers, versions of DW and ckgedit. As for the publish plugin, I suspect there is a conflict between one of its event handlers and one of ckgedit's. This is one of the occasional side effects of hundreds of plugins written by hundreds of authors.

To reproduce it on my machines, you have to open a page that was last saved with the DW Editor in the CKGEditor. Then, click the DW Edit button and voila… you've got a new revision just from switching editors haha… I've tested it on a page that just had the text “Test” and it still occurred.

Physical environment specifications:
Server: Windows Server 2012R2(x64) running IIS 8.5 and php 5.5.9 non-threadsafe optimized for FastCGI.
Client-PC: Able to reproduce and tested on Win7(FF and Chrome) and Server 2012(FF)
DokuWiki: Binky with latest version of CKGEdit (also able to reproduce on previous version of CKGEdit)
I certainly hope its not some non-standardization issue between php for windows and php on linux .
Activated Plugins: 1) IndexMenu 2) Catlist 3) npd 4) PageQuery 5) authad 6) wrap 7) dw2pdf 8)pageredirect
Activated Theme: Vector

Please don't take my comments the wrong way… So much of what CKGEdit does is worlds ahead of Plugins that try to achieve just a part of its functionality. Especially Tables/Font management! I'm hoping this save feature is just a boolean or variable that needs to be toggled somewhere so that I can change it in just my environment …

I found the problem (I hope). So give the latest github distribution a try.

Whoah whoah whoah lol… Revert immediately haha … Now when I switch from CKGEditor to DWEditor all page content is replaced by “false”
Edit: The fix appears to be working on my production server (Where security-permissions are properly set) and having odd results on my test server where security is not configured properly for experimental reasons… please ignore my original reaction as I look into what is causing the differences in results.
Edit: Ok… so it doesn't seem like it has to do with bad-permissioning… I can't tell you the cause, but it seems to be some weird browser issue. Firefox 29 seems to handle the fix perfectly fine. I can switch between DW Edit and CKGEdit without adding revisions. IE9 and Chrome 34 (no plugins) both replace the page content with

 __false__ 

… I'll run more experiments later to see why, but maybe you have more of an idea of what's going on… I've done the usual clear the cache in DokuWiki and in each browser.

Edit: After using Fiddler to analyze the HTTP transactions, particularly the cookies sent, in both Firefox and Chrome, the only differences that I noticed were the order that the Firefox/Chrome cookies were sent in and the fact that Firefox used the: Cache-Control: no-cache header while Chrome used the Cache-Control: max-age=0 header … Some initial research from a Stack Overflow question seems to indicate that there could be some anomalies based on how the browser handles such things… I'm not sure I can be of any more help here … For all I know I could just be distracting you from what is actually causing the problem… If anyone else is reading this, please test so we can see if this is just isolated for my environments.

I know what the problem is and will try to fix it when I get the time. In the menatime I've removed the offending code. — Myron Turner 2014-06-11 00:15

Because you found that Chrome failed with a __false__ where other browsers didn't, I did a series of tests and found that the editor switching did not fail in any of the major browsers nor in Opera. And it failed in Chrome on both OS X and Windows 7. The fault wasn't in the editor switching (or cookies) but in the Cancel, that is, in order to abort the edits, you have to excecute a javascript cancel. So, I have simply by-passed the problem by setting an alternate dwedit button for Chrome. Here is the revision: ckgEdit-ckedit_43-14-Jun_10-22_49.tgz. Thanks for your help, and give this revision a try.

Firefox still works well and can switch between the modes without saving revisions. Chrome now simply fails to switch and is stuck at the CKGEditor but atleast it doesn't save revisions anymore(which might be acceptable lol) … If I manually add the FCKG_USE = “_false_” cookie, I can get chrome stuck on the DW editor (it still doesn't switch when pressing the button)… IE 9 and IE 11 both replace page content with _false_ when switching to the DW Editor (however, I wouldn't trust my IE results as the CKGEditor is just a white-blank box without any editing tools) … I really hope you get this working as this is the last hiccup holding me from adding this to my production environment and I would love to be able to use this awesome editor!

New strategy for Chrome: ckgedit.0611_18-12.tgz. There's no issues with this distribution and IE11, not on WIN 7. Don't have IE9 anymore. If this is going into a production environment and you work for a company, it might consider making a small donation to the ckgedit/fckgLite society. at donate, assuming this now works.

Gah… Now Firefox is saving revisions again when switching … Chrome's DWEdit button has been replaced with a “Delete” button. Ok… this is acceptable I guess… only allowing the DokuWiki editor in Firefox/IE … IE 9 now picks up both the DWEdit and Delete Buttons (Firefox only has DWEdit which is best) … When you switch in IE, it sometimes prompts that a newer version is available or it just saves a new revision …
Regarding your other point: Your prompt responses and willingness to help people that come across issues with your plugin is admirable. Unfortunately, however, I am fairly new at my workplace and at the near bottom of the employee ladder (that's why they're giving me these semi-mediocre tasks of maintaining/upgrading the company Intranet when they have nothing else for me or don't want to do it themselves haha) … If we do adopt this plugin, then if the need arises I might be able to get them to contract you for feature upgrades (DokuWiki bounty kind of things) , but the Administrators here aren't even sure if they care for a WYSIWYG editor lol. I hope these remarks don't deter you from properly fixing the issue that we're dealing with … Truly, thanks for everything so far!

Whoah whoah lol… I'm confused… now IE and Firefox are both working fine… It seems that the page that I tested with was an “External Edit” which needs to save when you switch editors regardless… but after that, it switches fine without saving… I guess that works lol… I'll test some more later today… but so far, it seems acceptable
Edit: Even chrome is working fine … My eyes deceived me … The DWEdit button art doesn't render so you just see blue “DW Edit” text… Actually, the chrome fix works better than the other ones in my opinion haha… I'll continue to test throughout the day (for a few days actually)! … AWESOME! THANKS!!!!
The DW Edit Button in Chrome has been replaced by an action link, which doesn't submit the form.

I've been using this version of CKGEdit for a short while now and I am quite pleased with it. I wouldn't say that it's working perfectly, but the switching mechanism is acceptable. Maybe chrome users (who prefer the dokuwiki editor) would get annoyed after a while, but they can just switch browsers haha… I would like to see these changes in future versions of CKGEdit. I Appreciate all of your work. Thanks!

I did that on 12 June — Myron Turner 2014-06-19 01:48

the actual version (master branch) seems to work fine on firefox / chrome / ie11 (though on ie10 it seems to work intermittently .. in the beginning the “false” might come up) 2014-09-24

The situation: We have a Dokuwiki with several pages. Now we want to extend it with the CKGEDIT plugin.

I made a testcase.

• We have an existing page with following content (page is created before the CKGEDIT plugin was added).

===== URL =====

  * [[http://https://www.dokuwiki.org/dokuwiki|DokuWIKI URL1]]
  * [[http://https://www.dokuwiki.org/dokuwiki|DokuWIKI URL2]]
  * [[http://https://www.dokuwiki.org/dokuwiki|DokuWIKI URL3]]

• Press the edit page button.
• The layout is broken. All links are displayed on the same line.

Can this problem be fixed or did I something wrong?

This is just basic stuff. I can't reproduce your problem, testing in both Internet Explorer and in Firefox. What browser are you using and on what OS? And what version of dokuwiki and what version of ckgedit? — Myron Turner 2014-06-04 19:19

I use: Dokuwiki: 2013-05-10a “Weatherwax”, Browser: IE11, Chrome 34.0.1847.131 m, FireFox 29.0.1 on a Windows 8 Pro.
CKEditor 4.3 (revision d2184ac)
http://ckeditor.com

Modified for use with Dokuwiki, ckgeditor plugin version: _ckgEdit-ckedit_43-14-Apr_22-18_46_
I can reproduce the same on a Windows 2008 with IE9.

I loaded the April_22 distro into weatherwax on a windows apache server. Tested with IE 11, firefox 29.0.1 and Chrome, all on Windows, as you are doing. I can't reproduce this error. Does this happen on every page where you have a list of urls? Or is it only on a particular page? Have you tested this apart from the page(s) where the error occurs? My point is that if it is on some one page, then perhaps there is a conflict on that page, and I wouuld have to have that page with its markup. The other thing is this: if you create your list using ckgedit, does this happen? Because if you do and you check the markup, you will find that it is no different from what the dw editor creates. — Myron Turner 2014-06-05 14:09

I figured out that the plugin yalist (http://wiki.splitbrain.org/plugin:yalist) is not compatible with the CKGEdit. Myron big thanks for clearing out that the browser, pluginversion and OS was not the problem.

Thanks for pointing this out. I just updated the ckgedit plugin page for conflicts – the conflicts are basically the same as for the older fckg plugin but when I created the ckgedit page I forgot to include the conflicts. Glad to learn that it is working now.

The alignment of text in tables changes when hitting ENTER.

Step 1: Make a Dokuwiki table with DW Editor.

^ CELL 1 ^ CELL 2 |
| COL 1 | This is a sample |

Step2: Change to CFKEdit, then place the cursor after the word 'sample'. Hit Enter for adding a new line.

RESULT: The alignment of the content changes to right. I know pressing SHIFT + ENTER doesn't break this. But their are users that are not comfortable with this… There is also no way to 're-align'.

QUESTION: Is there a way to adjust this behavior? Adding plain HTML is not really a solution, because it should be very basic.

Can you use dropbox? If so, download the following file: save.zip. Unzip it and replace ckgedit/action/save.php with this save.php. Tables in the CKEditor, like many other features, have a context menu which pops up when you right-click on the item. There you can set alignments for cells and insert and/or remove rows and cols and make column and row spans. But the context menu doesn't fix the problem you found. But this save.php should fix the problem and if so I will include it in the distro. So, please let me know the results. — Myron Turner 2014-07-01 17:40

I updated save.php. It is still the same download url.

Thanks Myron Turner for the fast fix! Almost 100% solved. Only a small issue left. Hit ENTER in the cell, then via context menu choose for alignment right and save. Result: text is still rendered on the left.
I'm afraid there is no way around this because there is no way to tell whether the right align is intentional or accidental. It also affects center alignment. I'm not sure I'm going to use this fix in the distro. It's cleaner if users learn to use SHIFT-Enter to create newlines in table cells. I have no control over how CKEditor processes the Enter key in tables.

Please add an option to paste text only instead of formated text if pressing Strg + V.

Use the toolbar item:

This discussion is continued at: https://www.dokuwiki.org/plugin:ckgedit:discussion_2