The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions.  I don't see any update/change to that rule anywhere in the docs.

I have been using multi-character condition names successfully.   I find these are easier to use since they can be more descriptive of each condition.   It works, but I am concerned I may be doing something that might not be supported going forward.   (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)

Thank you, again, for this fine (and, may I add, fun?) tool.  I'm having a good time with it!

Same problem here, in version 3.1.3.   It would be very nice if this worked.

Could we update the doc for this?

I've been using elog for a few years now.  I've had the current setup working for me up until today.  

If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved.  The body (the part I can see in the editor) does not get saved.

Yesterday, I did do some updates on the server machine.  Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines).  Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also.  About 50 packages were updated altogether.

Here are the packages that were updated yesterday (in case this is of interest to solving the issue):

 bind9-host:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 ckeditor:amd64 (4.5.7+dfsg-2, 4.5.7+dfsg-2+deb9u1)
 cron:amd64 (3.0pl1-128+deb9u1, 3.0pl1-128+deb9u2)
 dnsutils:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 firefox-esr:amd64 (78.14.0esr-1~deb9u1, 78.15.0esr-1~deb9u1)
 libapache2-mod-php7.0:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 libavcodec57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libavfilter6:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libavformat57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libavresample3:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libavutil55:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libbind9-140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libcups2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
 libcupsimage2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
 libdns162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libdns-export162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libdw1:amd64 (0.168-1, 0.168-1+deb9u1)
 libelf1:amd64 (0.168-1, 0.168-1+deb9u1)
 libfaad2:amd64 (2.8.0~cvs20161113-1+deb9u2, 2.8.0~cvs20161113-1+deb9u3)
 libicu57:amd64 (57.1-6+deb9u4, 57.1-6+deb9u5)
 libisc160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libisccc140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libisccfg140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libisc-export160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libjbig2dec0:amd64 (0.13-4.1, 0.13-4.1+deb9u1)
 liblwres141:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libnghttp2-14:amd64 (1.18.1-1+deb9u1, 1.18.1-1+deb9u2)
 libntfs-3g871:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
 libopencv-core2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
 libopencv-imgproc2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
 libpostproc54:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libpython3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 libpython3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 libpython3.5-stdlib:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 libruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
 libsdl1.2debian:amd64 (1.2.15+dfsg1-4, 1.2.15+dfsg1-4+deb9u1)
 libswresample2:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libswscale4:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 ntfs-3g:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
 php7.0-cli:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-common:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-curl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-intl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-json:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-mbstring:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-opcache:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-readline:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-xml:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 python3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 python3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 ruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
 tzdata:amd64 (2021a-0+deb9u1, 2021a-0+deb9u2)

This is a devuan ascii server only for clients on a local area network.

Thank you for your quick response, Sebastion.  The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2?  It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.

(disregard my recent post here about missing package -- that wasn't the elog server!)

I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog.  It was apparently a security update, so I am not sure it is sensible to downgrade.  OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it would be much of an issue.   But please disabuse me of my ignorance if need be.

After downgrading ckeditor, my elog installation is working again.  Thanks for your help.