I can confirm the issue also for "prepend on edit".
To be more precise, it gets executed everytime the condition state changes, if placed in the config without condition, or if placed in a condition, everytime the condition gets activated.

I've quickly checked: there are a couple more commands in the source code that are not language encoded. I guess some of them needs correction.

> egrep -n "cmd=[A-Za-z]" elogd.c
10293:   rsprintf("    r.open('GET', '?jcmd=Unlock&edit_id=%d', true);\n", message_id);
11784:                      ("<label for=\"ELCode\"><a target=\"_blank\" href=\"?cmd=HelpELCode\">ELCode</a>&nbsp;&nbsp;</label>\n");
13663:                                "\r\n%s URL         : %s?cmd=Config&cfg_user=%s&unm=%s\r\n", loc("Logbook"),
14562:      redirect(lbs, "?cmd=Config");
14625:      sprintf(str, "../%s/?cmd=Config", getparam("lbname"));
14678:      sprintf(str, "../%s/?cmd=Config", lbn);
15703:   combine_url(lbs, host, "?cmd=GetMD5", url, sizeof(url), &ssl);
16378:         strcat(str, "?cmd=GetConfig"); // request complete config file
16380:         strcat(str, "?cmd=Download");  // request config section of logbook
16570:      strcat(str, "?cmd=GetPwdFile");   // request password file
17575:            rsprintf("<br><b><a href=\"../%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
17577:            rsprintf("<br><b><a href=\"%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
17579:            rsprintf("<br><b><a href=\"../%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
18959:   if (strstr(ref, "cmd=Search&"))
18960:      strlcpy(strstr(ref, "cmd=Search&"), strstr(ref, "cmd=Search&") + 11, sizeof(str));
26728:         rsprintf("<a href=\"?cmd=Synchronize\">%s</a></td>\n", loc("Synchronize all logbooks"));
 

> Correct Way prior to 2.3.8
> 
> http://192.168.0.1:99/Provisioning%20Request/35
> 
> Broken way with new version
> 
> http://192.168.0.1:99/Provisioning Request/35

Exactly this problem has been fixed between 2.3.7 and 2.3.8, so can it be 
that you mixed up these two versions? To be precise, the fix happend in 
Revision 1.113 from 2003/06/04 08:17:35. So are you sure that you use a 
version of elogd after that modification? I tried to reproduce your problem 
with the official 2.3.8 version, but I got the correct result.

> > Correct Way prior to 2.3.8
> > 
> > http://192.168.0.1:99/Provisioning%20Request/35
> > 
> > Broken way with new version
> > 
> > http://192.168.0.1:99/Provisioning Request/35
> 
> Exactly this problem has been fixed between 2.3.7 and 2.3.8, so can it be 
> that you mixed up these two versions? To be precise, the fix happend in 
> Revision 1.113 from 2003/06/04 08:17:35. So are you sure that you use a 
> version of elogd after that modification? I tried to reproduce your 
problem 
> with the official 2.3.8 version, but I got the correct result.

Im using the plain RPM from 2.3.8, i uninstalled the 2.3.7 RPM before this 
upgrade, the only thing I kept was my own stylesheets and the config file.

One thing I just noticed is that if you dont have the URL statement set 
under global properties, some machines quote the hostname of the machine at 
which point this breaks the link. if you define the URL to the IP address 
the problem goes away.

However even without the URL setting undefined, it works for some people 
but not for others, I tried from 2 seperate machines and got 2 lots of 
results, so I suspect it might be DNS related somewhere along the lines.

> Im using the plain RPM from 2.3.8, i uninstalled the 2.3.7 RPM before this 
> upgrade, the only thing I kept was my own stylesheets and the config file.
> 
> One thing I just noticed is that if you dont have the URL statement set 
> under global properties, some machines quote the hostname of the machine at 
> which point this breaks the link. if you define the URL to the IP address 
> the problem goes away.
> 
> However even without the URL setting undefined, it works for some people 
> but not for others, I tried from 2 seperate machines and got 2 lots of 
> results, so I suspect it might be DNS related somewhere along the lines.

The only place I can see this problem could arise from is the "Referer:" 
statement in the HTTP header. This is sent by the browser to elogd, so if the 
included URL contains a blank, this could cause the problem in case no "URL" 
statement is present in elogd.cfg. Can you please run "elogd -v" to see the 
communication betwen elogd and your browser and check this? Maybe it depends 
from the browser, or even from the history of previous accesses. If you 
confirm that the "Referer:" statement contains blanks, I can put in a fix.