Ross Jallo wrote:I've had apostrophes in edition information before, and never needed backslashes then
Another user reported to me the same observation through private communications. This is something that may have changed since Easter, when we moved from the old 8 CPU/32 bit server to the new 32 CPU/64 bit server. I especially guess that the transition from 32 to 64 bit may have implied some different treatment of special characters. I'll look into it, although sooner or later I would like to substantially re-write the script that handles submissions: it's very old, and already patched again and again.
I've entirely re-written the script that processes inputs from the "add work" form. It should be quite immune to backslash problems and much easier to maintain. However, it is not yet online as we should manage possible "teething problems" with it, being totally new.
As a side-product of the above effort, I found that a server running php can be configured to automatically add backslashes before apostrophes if they are not present already. Such "automatic escaping" setting was quite popular few years ago, so most servers were configured that way by default. Our old 8 CPU/32 bit server, running since 2008, was configured that way. More recently, it was found that "automatic escaping" creates more problems than solutions, so newer servers, like our brand new 32 CPU/64 bit one, are not any more configured by default to automatically add backslashes. This explains why our old server was tolerant to missing backslashes, while the new one is not. Anyway, the new script is conceived so that apostrophes are treated correctly without the need of backslashes, and this would work on all fields (work title, composer, edition notes, composition notes, etc.).