Thanks for the fix, I merged it into the current development branch.

Stefan

Hi,
  I'm using elog 3.1.3 and I have an elogbook with an attribute with name 
Attributes = Author, CO2 Temp [deg], ...

If I add this attributes to quick list, 
Quick filter = Author, CO2 Temp [deg]

it does display on web page, but the search fails with "ERR_TOO_MANY_REDIRECTS" if I leave the default value in the corresponding quick filter box.

My understanding is that the presence of a "[]" in the default search value is the reason for failure and if I remove them the search works fine.

Is there a workaround?

I don't want to change the attribute name, since I do have quite a large number of entries in the elogbook, and I'd like to keep the attribute in the quick search if possible.

Thanks,
  Stefano

No, there is no quick workaround. The only way is to go through your logbook files manually (or with a script), and replace all occurrences of that attribute.

Stefan

Hi all,

  We came across a problem recently when clicking "Upload" button, then elog hanged and never being accessed. I have checked the elog logs and find that it seems that elog didn't get the path of the picture for some reason. So is it a bug or our operation isn't correct?

The problem is you have some weird characters in your file name R2BLM15 ? ? ? ? ? .PNG which confuses the interpreter. There should not be any special character or blanks in attached images.

Stefan

That make sense. Is there a way to recovery when hung except restart elogd? On the other hand, whether could  prompt for reloading attachment when interpreter detect error but not hang?

Wu Xuan

As the title says, we have our elog running behind an Apache proxy that is also providing authentication. We also have top groups enabled.  The first time a user views a top group page with a fresh browser cache, the index is delivered, but requests for elog.css and lock.png are returned with http 302 with location set to the elog root.  (I.e., if the server is proxied under server.example.com/logs,  the first request for server.example.com/logs/TopGroup1/elog.css returns a 302 with location set to server.example.com/logs// ). 

Any subsequent visits return the files fine. The attached screenshot shows the network requests in chrome. 

Is this a proxy configuration issue, something we've set wrong in elog, ??

Looks more like a bug to me. Will investigate.

Stefan