I can't get the images to load to the page. I have tried the direct link option and moved the htaccess.security folder, created new media folders, but am now just getting a placeholder blank. Any suggestions?

You haven't told me much about your setup so it's hard to know what might be happening. Did you rename .htaccess.security to .htaccess? See winstyle.

Yes, I did, and see it in the various folders that need the media access. Can I outright delete the .security file? To be clear, I'm getting a blank placeholder so it's not finding the image, even though I've uploaded it to the correct folder. Could this be an ACL issue? My primary goal is to use the ckeditor , so would love to get this running. Thanks!

1. Try using the other .htaccess file, not .security but .htaccess.open, and rename it .htaccess. I can't say if it's an ACL issue since I don't know what our ACL is. You still haven't said anything about your configuration.

Is there a workaround with the file browser? Can I somehow use the dokuwiki file browser directly from the ckgeditor, i.e. not use the ckgeditor media browser?

No
See: http://www.mturner.org/fckgLite/doku.php?id=faq&b_disp=1#asking_questions. Most of those points refer to ckgedit as well.

When I select a line of text and click the “Indent” button, the line indents while in ckgedit. The HTML code that appears is <p style=“margin-left: 40px;”>

However, once I click “Save” (in ckgedit) the indent disappears - along with the HTML code for it.

Every other ckgedit function appears to work perfectly.

Any idea what the problem is? Thanks!!

I'm using Dokuwiki Release Release 2014-09-29a “Hrun” (although the problem also occurs in 2014-05-05a “Ponder Stibbons”)
ckgedit version: _ckgEdit-ckedit_43-14-Nov_6-08_20_
My browsers are Firefox version 33.0.3 and Google Chrome Version 38.0.2125.111
My web server is running Linux/Apache with PHP 5.4 (I also tried ckgedit after upgrading PHP to 5.5… the same issue persists).
This is a “fresh” installation of DokuWiki Hrun with NO additional Plugins installed other than “WRAP” & “DokuWiki Upgrade”. Also, there are no additional templates installed.

— rrandall 2014-11-07 23:41

The reason for this is that Dokuwiki doesn't support identation. For this you need a plugin. Try tab or wrap, depending on your needs.

— Myron Turner 2014-11-08 01:39

Thanks!! It is confusing to see a buttons (“Indent” & “Outdent”) in ckgedit that are non-functional for DokuWiki (and no note of this in the download page or discussion pages). Could these buttons be removed from a future version of ckgedit for DokuWiki? Or greyed out to indicate that it is non-functional? Thanks again for all the GREAT work that you do on DokuWiki!! I really appreciate having such great WYSIWYG editing tools as ckgedit and fckgedit!

— rrandall 2014-11-08 22:15

I didn't realize that you meant the indent and outdent buttons. I thought you were referring to the face that in the ckeditor you can indent text using the spacebar but that those spaces are removed on saving. Those buttons double in CKEdior for nesting and un-nesting lists. I will fix that, if possible, with new labels.

Ahhh. I see now. It's just the button/icon labeling that is incorrect / misleading. Thanks!!!

— rrandall 2014-11-09 01:48

Managed to fix the labels, in latest distro — Myron Turner 2014-11-09 14:07

I installed it and the new labeling make it MUCH easier to understand their function. Thanks!!!!

— rrandall 2014-11-09 17:01

How to reproduce the problem:

1. insert mturner http://www.mturner.org/fckgLite/doku.php?{NAME} into interwiki.conf (Conf dir)
2. Make sure you are in DW edit mode
3. Insert id=introduction on the page
4. The link is correct
5. Now change the edit mode into the ckgedit mode
6. Add something to the page and save
7. The interwiki link is wrong: http://www.mturner.org/fckgLite/doku.php?doku.php?id=introduction

This should be fixed in the latest distribution. I haven't had time to update github yet but you can get it from the fckgLite web site, the July 24th distribution: ckgEdit-ckedit_43-14-Jul_24-13_29.tgz

github has now been updated — Myron Turner 2014-07-24 21:29

Big thanks (again) for the fast response!! I really appreciate your help!

Just as a matter of information: You don't have to switch over the the DW editor to create these links. You can enter them directory into the ckgeditor:

 [[mturner>id=features|features]] 

You can actually do this with any link.

Is it possible to edit interwiki type in editor? When I double click on the link the link window opens but the Interwiki Type combobox is disabled. Also, it seems that the link icon is not shown properly. I have a custom link with custom ikon but the editor shows the wikipedia icon instead. (The icon is displayed correctly when browsing the wiki so it is not the cache issue? )

First, I've asked that all issues be posted either to the forum or to github; this page is closed. To begin with the icon–ckgedit doesn't have access to your personal icon, so it gives you what it has as a default. Why your iwiki option is disabled I don't know. If you were using github or the forum we could post images to demonstrate exactly what is happening and should happen. And yes you can enter an interwiki link dierectly into the editor.

Explanation of the situation: We have a bunch of DokuWiki pages. We want to do a swith to the CKGEdit editor. Everything works perfect! Except one thing.

Some of our pages contains lines where the code tag is at the end of a line. With the normal Dokuwiki editor there is no problem. However using the CKGEdit editor the layout of the page gets broken.

Sample input:

• This is text

  SELECT 1 FROM TABLE

• This is also text

  SELECT 2 FROM TABLE

When opening in CKGEdit editor mode the preview looks fine. Let's add a new line. I've added 'test'. The layout is broken after saving.

I don't use geshi. Is there a way to get <code… always on a new line? Via a Dokuwiki plugin or a CKEditor plugin?

First, when formatting as sql you are automatically using geshi. About your problem: ckgedit cannot accept code or file blocks in lists, so you have to remove them from the list. There is no automated way to do this. You have to remove each code block manually. Here is how to do this:

1. Remove the code block by selecting the code block with your mouse (click anywhere inside the block)
2. Go to the Format menu and select normal
3. Then go to the Styles menu and select Code Block
4. Then move your sql code down one line and enter gesh: sql at the top of the code block.
5. Save

I made a small video clip which illustrates this: http://www.youtube.com/watch?v=J3cnxftJzYw

I believe I might have found a solution which will do this for you automatically. I will let you know possibly later today. — Myron Turner 2014-08-12 17:02

Try the lastest version. Install with the extension manager or download from github.

I've tried the latest version. It works! A tremendous help again Myron Turner. Big thanks!

Edit: when saving and re-opening, the editor adds <font 14px font-weight: normal; line-height: 1.4;/arial;;#000000;;#ffffff> multiple times.

This is not from ckgedit. You must be using another plugin to get the font. If you were setting the font with ckgedit it would look like one of these:

   <font 14px/arial;;#000000;;#ffffff>text</font>
   <font 14px/arial,helvetica,sans-serif;;#000000;;#ffffff>text</font>

The font-weight is not set with the font dialogs but with the bold button.

Feature request: Can the short-cut keys also work when using a numpad?

This is not in the current plans

Feature request: Add TAGADD support

See https://github.com/lisps/tagadd

This cannot be done without a great deal of trouble. The two tool bars do not share a common javascript environment.

When editing sites with much pictures or text, the amount of RAM needed for firefox raises exorbital. 1.3GB with only 1 tab is not uncommon. Sooner or later firefox then hungs up and crashes with the message that the Plugin Container doesn't work anymore. I assume this has something to do with javscript. Any ideas on that? (josh)

I've never seen that message. It doesn't come from the CKEditor and I can't find it in Dokuwiki. But what Firefox means by “Plugin” I don't know. It would have to be referring to one of its own.

The Plugin Container is used by firefox to run flash, javascript (and different other plugins) in a specific process (as far as I understood). When I use big sites the editor seems to (I assume buffer overflow) the javascript, and as a result of that, the Plugin Container crashes. I am no expert with things like that, but the problem is definitely triggered by ckgedit :( (josh)

I think I figured out what the problem is. On my side the problem seems to be triggered by the spellcheck. Every time I scroll down the amount of needed RAM raises fast. When I turn off SCAYT the used ram from firefox goes down immediately, and the site is much more responsive. When SCAYT is on, scrolling is very laggy and you can feel that the browser is on high workload in general. (josh)

You don't say how large your page is. But I have a test document for long documents. According to Microsoft Word's count this document is: 19 pages, 4629 words, 40,998 characters, 1047 lines. It has several images, two very large. And since the text is a mashup of javascript it has many 'misspellings' of terms not recognized by scayt. I do not get your error. It loads and saves and can be edited without any problems. Of course Scayt must do its job, so there is a bit of an initial slow-down until it is finished. I've tested this on two machines. Windows 7 with 16 gigabytes of memory and 64 bit processor, and a mac laptop with 8 gigs and 64 bit processor. In both tests I used firefox. — Myron Turner 2014-09-25 12:20

Within my wiki I use the Data-Plugin very heavily. I very much like the ckgedit-Plugin, but it can't handle the multi-line syntax of the data-plugin. By using section editing I could leave out the section containing the data-plugin-syntax, so that the syntax will not be broken by the CKEditor after saving. The data-plugin brings its own editor for data-entries. Would it be possible to use

• CKEditor for Heading based sections
• Data-entry-Editor (from data-plugin) for data-entries
• Standard-Dokuwiki-Editor for editing the whole page

If this could be configured via admin-interface, this would make sense for me. —

First, enclose the data entry between ckgedit's MULTI_PLUGIN macros:

    
~~MULTI_PLUGIN_OPEN~~
  Your Data Entry Block 
~~MULTI_PLUGIN_CLOSE~~

This will cause ckgedit to keep your line breaks. You can single space, by holding down the Shift key when pressing Return. See: http://www.mturner.org/fckgLite/doku.php?id=features&#multi-line_plugins

The Second step, described here, is no longer necessary, see permanent fix below.

Second,you will have to make a small edit in ckgedit/action/edit.php.¹⁾ At line 43, you will find the following:

if($this->helper->is_outOfScope()) return;
 
global $FCKG_show_preview;

Insert the following line:

if(isset($_REQUEST['target']) && $_REQUEST['target'] == 'plugin_data') return; 

So now you have:

if($this->helper->is_outOfScope()) return;
if(isset($_REQUEST['target']) && $_REQUEST['target'] == 'plugin_data') return;
global $FCKG_show_preview; 

Now when you click the data entry's edit button, it will open up the data entry editor.

As of Jan 13 2013, in ckgedit, but not in fckg, it is no longer necessary to insert the line checking for the $_REQUEST['target'] parameter; this is automatically done in helper->is_outOfScope(). It is still necessary to use the MULTI_PLUGIN macros.

If the data table is going to be in a page where ckgedit will open its editor, then the table should also be enclosed in the MULTI_PLUGIN macros. You should then be able to edit the table data, remembering to use SHIFT+ENTER to single space. You can, however, go directly to the native dokuwiki editor in one of two convenient ways.

1. You can set the dwedit_ns option to a name which will always open in the native editor. See the dwedit_ns configuration option.
2. If you are using the dokuwiki template, you can install the dwedit plugin. This will create an additional tool button which is inserted for registered users, on editing, and will open the dokuwiki editor instead of the ckgedit editor.
3. In current versions of ckgedit, you can double click to open an editing section in DW Edit mode. See double_click_method.

Thanks a lot for this solution! Works great for me. — stvoigt 2014-10-23 09:36

I had problems with IE 10 and IE11. CKGEdit startet to render Wiki-Syntax into HTML-Syntax but did not load the Editor GUI. Sometimes (depending on IE version) I did only see a white shape and the save/cancel/dw-edit/…-buttons. I also tried the different versions provided. But nothing helped.

I have to add, that I am running a public wiki under an URL belonging to our organisation. So the URL was interpreted as belonging to the Intranet sphere. When leaving the Intranet (switching from WIFI to 3G), CKGEdit suddenly worked normally. This was not explicable for me.

The solution: The developer-tools from IE helped to see, that IE used the compatibility mode for my wiki. IE10/11 is showing Intranet sites in compatibility mode (or Enterprise Mode) by default. Switching of this option makes CKGEdit also running within our Intranet. So this would be the client side solution for my problem.

To avoid this problem from server-side, you can change the ckgedit\action\edit.php in line 124 from

echo "\n" . '<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />' ."\n"; 

into

echo "\n" . '<meta http-equiv="X-UA-Compatible" content="IE=edge" />' ."\n";  

This made CKGEdit working in both IE10 and IE11 for me. As an alternative also “EmulateIE11” or “EmulateIE10” is possible, but “EmulateIE11” did not work in IE10.

“IE=EmulateIE8” is even coded into the CKGEdit-Version especially suggested for IE11. Maybe someone could check, if my solution is a correct one and thus should be adopted in the code. I am not a specialist… — stvoigt 2014-12-11 14:41

I've spent a lot of time trying to satisfy all of the variations of IE, and in my own tests the current configuration seems workable. If it doesn't work for you in all instances and you have found a work-around, then by all means please use it. I will leave your post here for others to consult if needed. With IE 11, Microsoft changed the User Agent string causing problems for web sites that depend on that for browser recognition. In my own software, it broke a javascript function needed in the file browser. The core Dokuwiki developers warn against using IE for Dokuwiki, if possible: Browser Support. — Myron Turner 2014-12-12 01:58

Hello, I have a little trouble with my fresh new dokuwiki install and CKGEDIT. I'm on a debian 8 server, with apache 2 and PHP 5.6. I have moved my data folder elsewhere on the system. When I try to add a internal link, the pop-up file explorer doesn't show any file except for the 3 orginal files in the wiki namespace/folder (AKA welcome, dokuwiki and syntax). I've been playing with the symlink until I understood that there not the ones that link to the pages. This part is working fine and redirecting properly to the media directory of my displaced data directory (if I want to ad a picture, the file browser goes to the right place)

My trouble is the path to the pages directory is still pointing to the dokuwiki/data/pages folder. I click on link then switch to internal links and click on browse server it show me the dokuwiki folder. Whenever I delete this data folder a new one is created with a folder inside for every namespace I try to link from. So everything is working fine execpt not in the rigth place.

When I switch back to DW edit, the internal links dialog is working, I see my displaced page folder and every file/link that have been created. So my savedir and datadir (the pages) must be rigth.

Is there a place where I can tell CKGEDIT where to look for my pages ? like the media symlink but for pages ? Thanks a lot

How did you install dokuwiki? Using the Debian package manager? Or from a tarball downloaded from Dokuwiki.org? — Myron Turner 2014-12-12 20:24

Using the tarball downloaded from dokuwiki.org.

The latest github distribution should clear this up. Also can be downloaded from the main ckgedit page.

Sorry – still needs a fix for the image filebrowser and I'm not sure when I'll get back to this.

I think I was wrong about the above. Try it and before using it clear out the data/cache directory as well as your browser cache. Your browser must point directly to the dokuwiki directory: what I found was that there was an error when I accessed the dokuwiki indirectly by means of a symbolic link. I did not test in Debian but in Centos, but I don't think this should matter. If this doesn't work, try the fckg editor. I have tested it on Debian and it seems to work.

A little update :
So I tried both you solutions, neither worked properly.
The github distribution broke the media links and didn't connect to the pages folder.
the FCKedit build the media links back (and they stay if I resintall CKGedit).
I saw that on the client side the path is retrieved from cookies. Meaning I should delete those ?
I tracked your commits on github and saw your long ass comment in ckedit/fckeditor/editor/filemanager/connector/php/config.php.

It tried to overwitre the relative and absolute paths in congif.php. I did it in setUpMediaPaths() function around line 366 with mixed results.
It's a very dumb overwrite, I juste put the paths of the data folder on my system insite Config. As you can guess, absolute is quite simple but relative as a shitton of ”../../“.

The image insert dialog didn't work anymore.The plugin forgot about se SymLink and used the paths and added a /image/ at the end of the path. So it buildt a image folder in the data folder. That's not what appaear to be the default Dokuwiki behavior and I'd prefer to stick to it (when I go back to the default dokuwiki editor, the image insertion dialog bring me to the media folder where the images my user uploaded are).
Also the image linking is broken, If I upload a image in the newly created folder and then try add it to the page, it show me a huge white and red cross and the OK button point to javascript.void();

The internal link dialog on the other hand show the whole data folder and I can access the page folder from here. But there is a twist. When I click on the page I want to link it come back to the first link dialog and with a dokuwiki namespace path something like this : ”:..:..:..:..:..:..:..:..:..:..:..:firstFolderFromRoot:anotherFolder:myWikiDataFolder:pages:myNamespace:myPage“ which obviously point to a “this page doesn't exist” on dokuwiki.

So yeah, it's not that simple.
I haven't grasped how everything works

Why can't we use the symlink for the pages ? You wrote you get error
Also Why can't we use the savedir and datadir property from dokuwiki ?

That is exactly what it is now doing. You seem to have misunderstood what I said about the symlink.

Regards

The new distribution from github works with Debian. I did a test in Debian 6. The commentary at the top of config.php is from the people at CKEdit, not from me. And since you don't really know what you are doing you should not change the code.

Short update, I ended up creating a Softlink from the Dokuwiki Data folder in place of the pages folder that point to my actual page folder. This seem to work for now.

This is a known bug with ckeditor in Chrome that's been patched, I'm just wondering if/when this will be applied to this plugin. To replicate, enter some arbitrary text:

This is a test.

Save and view source in the standard editor. Then switch back and copy/paste some text into the middle, say the word “This”. The end result will look something like this:

This <font 14px line-height: 19.6000003814697px;/inherit;;inherit;;inherit>This</font> is a test.

The actual font it uses differs if this is on an existing page. I've instructed my users to not use Chrome for the time being. Anyone fix this, or should I wait for the devs to implement the latest Ckeditor?

Chris Crocetti 2015-02-08 10:26

I am planning to update to the latest stable ckeditor, but I'm not sure when that will get done. In the meantime, there is a solution. First, this happens only when copying from one place in the ckeditor window to another. As far as I know it doesn't happen when pasting from a plain text document. In any event, here is how to handle this: After the copy paste, highlight the area with the copy/paste and click on the T_x tool in the toolbar. That removes all formatting. — Myron Turner 2015-02-18 18:58

I am working on an upgrade to the latest stable release (CKeditor 4.4.7) and this issue is still not fixed. So the only way to use chrome, if you are going to copy and paste from within the editor, is to use the T_x tool after the paste.

There is now a fix for this. It requires turning off the font and color options in the configuration settings. If both are turned off, then the ckgedit's parser will not parse Chrome's font styling settings. This means, of course, that users will not be able to use font and color settings. — Myron Turner

When I open a wiki page which includes svg-code with the ckgeditor, the editor interprets the html-code. Saving corrupts the svg-code and breaks the image. Has anyone an idea to get around this?

As long as the mime type is provided for you should be able to upload and display svg images in svg-compatible browsers. But for the code you will need one of the svg plugins. — Myron Turner 2016-11-25 14:08