Re: Creating ELog Links not working properly in HTML Editor, posted by Stefan Ritt on Mon Sep 28 12:05:04 2015
|
Right, spaces won't work. But others work. Andreas, if you just put elog:1 without any link etc. just as plain text, it will be converted automatically into a link.
A workaround is to explicitly specify a link to an elog entry. Press the link button from the editor toolbar, enter a name and copy the full URL from the browser address bar, like here: https://midas.psi.ch/elogs/Forum/68129. If you switch to "Source" (Top left editor toolbar, you can changed the link name manually, like here.
Andreas Luedeke wrote: |
I can confirm this bug.
But I don't think this has to work as you've described it, when using the HTML editor: if you use HTML, you can use the link feature of the editor.
But that link feature does currently not work at all with internal elog references, not even a simple elog:1"> elog:1 (as you can see here). I suppose there is some more work to do for Stefan on that ;-)
Cheers, Andreas
Edmund Hertle wrote: |
Hey,
the syntax for creating links to other elog entries has a small issue in the HTML editor. The link will not be created properly if there are whitespaces in the name of the logbook. Using ELCode (or in a simple attribute field) the whitespaces can be replaced by "+", but this does not work in the HTML editor. The work-around would be to use ELCode mark-up instead of HTML.
Example 1 (this should work): elog:Contributions/47
Example 2 (this will not work): elog:Config+Examples/11
Example 3 (will also not work): elog:Config%20Examples/11
|
|
|
Re: Creating ELog Links not working properly in HTML Editor, posted by Andreas Luedeke on Tue Sep 29 08:50:30 2015
|
Hi Stefan,
yes, I know that a plain text " elog:1" works in the HTML editor, too.
But if you put " elog:1" in the URL field of the link dialog, then ELOG screws up: you get the text
and the link points to link type "URL", protocol "<other>", URL "1".
Or more precisely, the HTML source looks like the following:
<a href="1">elog.1</a>"><a href="1">elog.1</a>
(I've replaced ":" by "." here in the source, to avoid another iteration of links by ELOG).
That is not what I would have expected:
either it should have been remained unchanged, or it should point to the right URL of the entry elog:1 (the latter case preferred :-).
Cheers, Andreas
Stefan Ritt wrote: |
Right, spaces won't work. But others work. Andreas, if you just put elog:1 without any link etc. just as plain text, it will be converted automatically into a link.
A workaround is to explicitly specify a link to an elog entry. Press the link button from the editor toolbar, enter a name and copy the full URL from the browser address bar, like here: https://midas.psi.ch/elogs/Forum/68129. If you switch to "Source" (Top left editor toolbar, you can changed the link name manually, like here.
Andreas Luedeke wrote: |
I can confirm this bug.
But I don't think this has to work as you've described it, when using the HTML editor: if you use HTML, you can use the link feature of the editor.
But that link feature does currently not work at all with internal elog references, not even a simple elog:1"> elog:1 (as you can see here). I suppose there is some more work to do for Stefan on that ;-)
Cheers, Andreas
Edmund Hertle wrote: |
Hey,
the syntax for creating links to other elog entries has a small issue in the HTML editor. The link will not be created properly if there are whitespaces in the name of the logbook. Using ELCode (or in a simple attribute field) the whitespaces can be replaced by "+", but this does not work in the HTML editor. The work-around would be to use ELCode mark-up instead of HTML.
Example 1 (this should work): elog:Contributions/47
Example 2 (this will not work): elog:Config+Examples/11
Example 3 (will also not work): elog:Config%20Examples/11
|
|
|
|
restrict edit time and autosave, posted by Kester Habermann on Fri Oct 30 18:20:22 2015
|
Hello,
When using restrict edit time together with autosave, there is the following problem: The counter for restrict edit time seems to start after the autosave. If the time is up, it is no longer possible to submit the report.
It is also not possble to edit old drafts if restrict edit has elapsed since the creation of the save.
Autosave is definitively a nice new feature. However, I think it would be better if the counter for restrict edit time only started after the "submit" of the report and allowed edits to drafts no matter how old they are. As it is one needs to either set a really high value for restrict edit time or turn off autosave.
The issue seems to be related to: https://midas.psi.ch/elogs/Forum/68103
Regards
Kester
|
Re: restrict edit time and autosave, posted by Andreas Luedeke on Mon Nov 2 08:41:20 2015
|
Hi Kester,
yes, I did run into the same problem, that I could not even delete old drafts due to our restrict edit time.
We allow anonymous submissions in our operation logbooks. After a while drafts of unsubmitted messages just pile up; and I need to remove them as administrator.
While I can do that easily for anonymous drafts, I cannot do that for drafts of other users: I don't easily see those drafts.
It would be really nice, if drafts would be handled different then other entries regarding "Restrict edit time" as you've suggested.
Cheers, Andreas
Kester Habermann wrote: |
Hello,
When using restrict edit time together with autosave, there is the following problem: The counter for restrict edit time seems to start after the autosave. If the time is up, it is no longer possible to submit the report.
It is also not possble to edit old drafts if restrict edit has elapsed since the creation of the save.
Autosave is definitively a nice new feature. However, I think it would be better if the counter for restrict edit time only started after the "submit" of the report and allowed edits to drafts no matter how old they are. As it is one needs to either set a really high value for restrict edit time or turn off autosave.
The issue seems to be related to: https://midas.psi.ch/elogs/Forum/68103
Regards
Kester
|
|
Paste figure from Clipboard, CKEditor 4.5.1 and Firefox 42, posted by Simon Däster on Thu Nov 5 16:59:34 2015
|
I tried to paste an Image from Clipboard into the CKEditor 4.5.1. Unfortunatelly, that doesn't work. I used Firefox, version 42. When I looked in the javascript error console, it reported that "TypeError: b is undefined, ckeditor.js:1139:112". The variable d.config.filebrowserImageUploadUrl could not be found.
I set the variable in the file ckeditor-config.js in the folder scripts, but that didn't solve the problem. As far as I can tell, Pasting Image from Clipboard does not work in this forum neither, but I don't know whether this is in purpose.
Pasting via the button "Paste from Word" works as it inserts a 64base formated image, but that's not what I'm searching for. Also normal upload of files works fine and puts the file in the correct folder (logbook/year/)
|
Re: Paste figure from Clipboard, CKEditor 4.5.1 and Firefox 42, posted by Stefan Ritt on Tue Nov 10 14:08:47 2015
|
That seems a CKEditor problem. Can you see if it works on their site (ckeditor.com). The current version is 4.5.4. Maybe they fixed it. You can upgrade CKEditor yourself in elog by just copying the new verson over the old /elog/scripts/ckeditor directory.
Simon Däster wrote: |
I tried to paste an Image from Clipboard into the CKEditor 4.5.1. Unfortunatelly, that doesn't work. I used Firefox, version 42. When I looked in the javascript error console, it reported that "TypeError: b is undefined, ckeditor.js:1139:112". The variable d.config.filebrowserImageUploadUrl could not be found.
I set the variable in the file ckeditor-config.js in the folder scripts, but that didn't solve the problem. As far as I can tell, Pasting Image from Clipboard does not work in this forum neither, but I don't know whether this is in purpose.
Pasting via the button "Paste from Word" works as it inserts a 64base formated image, but that's not what I'm searching for. Also normal upload of files works fine and puts the file in the correct folder (logbook/year/)
|
|
Re: Paste figure from Clipboard, CKEditor 4.5.1 and Firefox 42, posted by Simon Däster on Mon Nov 23 10:32:37 2015
|
Updating CKeditor did work, thanks for the tip. |
Re: If a Required Attribute starts with a number – No CKEditor, posted by Andreas Luedeke on Fri Dec 11 14:30:10 2015
|
Hi David,
I can confirm a bug: changing the encoding does not work if you have a required attribute starting with a digit. The following minimal config reproduces the bug:
[global]
Default encoding = 1
[test]
Attributes = 7SWM
Options 7SWM = Name
Required Attributes = 7SWM
Whatever you choose as a default encoding you'll be stuck with. If you remove the "Required Attributes" it works again.
The workaround is very simple: do not use any attributes that do start with a digit :-)
Cheers, Andreas
David Dunne wrote: |
Hello, Is the below an issue or am I doing something incorrectly? Creating an attribute starting with a number and then including that attribute in the Required Attribute list prevents access to the CKEditior. This appears to be the case at least with FreeBSD (10.2 Rel) using Elog V3.1.0 and Windows 7 with Elog V3.1.1-3f311c5. The problem can be recreated using the Elog supplied sample config and adding the necessary attribute, sample config showing below. While attribute 7SWM is part of the Required Attributes the CKEditor fails to appear, remove 7SWM from the Required Attributes list and the CKEditor returns. [global] port = 8080 [demo] Theme = default Comment = General Linux Tips & Tricks Attributes = Author, Type, Category, Subject, 7SWM Options Type = Routine, Software Installation, Problem Fixed, Configuration, Other Options Category = General, Hardware, Software, Network, Other Options 7SWM = Name-1, Name-2, Name-3 Extendable Options = Category Required Attributes = Author, Type, 7SWM Page Title = ELOG - $subject Reverse sort = 1 Quick filter = Date, Type Thank you, David Dunne |
|
|