Hi Philipp, Thanks for the response! I'm a bit baffled as to how to deal with this, since I'm running 3.0.1 on both Author and Public and am still having the problem. Is there something I need to do to fix up my databases and bring them up to 3.0.1 standards?
Sean On 2/1/07 2:25 AM, "Philipp Bracher" <[email protected]> wrote: > The things started to get wrong by a bug in one of the 3.0 RCs. Due > to this bug activation added some extra lines by formating the sent > xml file. This bug is fixed since 3.0. > > Philipp Bracher > > On 29.01.2007, at 18:33, Sean McMains wrote: > >> Further investigation shows that this is likely an issue with the >> export >> from Edit, rather than anything on Public. Data from Edit dumped >> into any >> other database exhibits the same issues, and data from other >> instances works >> fine in Public. Drat. >> >> Any clues on how this could be cleaned up safely? >> >> Sean >> >> >> On 1/29/07 11:14 AM, "Sean McMains" <[email protected]> wrote: >> >>> We have an odd situation that's causing our forms to break. >>> >>> When we define a form selection paragraph on our edit stage, it >>> works fine. >>> However, when we publish it to our public stage, the various >>> selections all >>> end up lumped together into one selection, rather than split >>> across however >>> many they should be set up for. >>> >>> I wrote a little code to examine the ASCII values that the >>> form-selection.jsp paragraph is processing. On our edit stage, the >>> options >>> are separated by 13 and 10 -- the \r and \n values one would >>> expect (and >>> which the JSP code looks for). On the public stage, however, the >>> values are >>> 32 and 32 -- two spaces. The JSP doesn't recognize these as >>> separators, and >>> thus all of the options get rammed in there together. >>> >>> So my question is this: how would the CRLF get changed to Space/ >>> Space during >>> on the Public stage and, more importantly, how can I keep it from >>> happening? >>> The problem doesn't appear to occur on a virgin installation of >>> 3.0.1, nor >>> using our lightly customized code if allowed to bootstrap from >>> scratch, so >>> the issue must be in our database configuration somewhere. (I >>> tried working >>> around the issue by exporting the XML from Edit and importing it >>> to Public, >>> but with no better luck.) >>> >>> If it comes to it, I may do a mass export and let the database >>> bootstrap and >>> rebuild itself, but I'd like to avoid that if possible (especially >>> if it >>> turns out not to solve the problem). The database did start life >>> in one of >>> the release candidates, so it may be that a rebuild is finally >>> unavoidable. >>> >>> Thanks for any insight, >>> Sean >>> >>> >>> ---------------------------------------------------------------- >>> for list details see >>> http://www.magnolia.info/en/magnolia/developer.html >>> ---------------------------------------------------------------- >> >> >> ---------------------------------------------------------------- >> for list details see >> http://www.magnolia.info/en/magnolia/developer.html >> ---------------------------------------------------------------- > > > ---------------------------------------------------------------- > for list details see > http://www.magnolia.info/en/magnolia/developer.html > ---------------------------------------------------------------- ---------------------------------------------------------------- for list details see http://www.magnolia.info/en/magnolia/developer.html ----------------------------------------------------------------
