[MAGNOLIA-2017] additional Line Breaks after XML Import/Export Created: 24/Jan/08 Updated: 25/Jan/08 Resolved: 24/Jan/08 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 3.0.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Claudio Greuter | Assignee: | Magnolia International |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows Server 2003, Tomcat, Mysql |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
during a Migration from magnolia ce 3.0 to magnolia ce 3.5.2 we exported our sites to XML and imported them on the target system. after this, the pages containing longer text were completely messed up with random, additional line breaks. i worked around this issue by removing all line breaks from the XML files manually (using a search and replace), however this is a hack and i am worried about side effects. It seems as if the export tries to format the XML in a readable way, resulting in these line breaks. i tried the "format XML" switch, however the results were the same. I am aware that a similar bug has been reported quie a while ago, however this issue is marked as resolved, so i guess it was reintriduced somehow. Let me know if i can help with more details. |
| Comments |
| Comment by Jan Haderka [ 24/Jan/08 ] |
|
If I understand it correctly, those extra line breaks were introduced during export from 3.0.x, right? Could you please specify what exact 3.0 version it was. Also could you try to replicate the problem (i.e. export page and look in xml if there are any errorneous line breaks) in your 3.5.2? |
| Comment by Claudio Greuter [ 24/Jan/08 ] |
|
yes, you're right, the import were coming from 3.0.1. The reason for the export/importing procedure is simple: The mailing list stated that an update would be possible from 3.0.5 or so, so i assumed that older versions are not compatible without exporting. i could not find a clear migration path or data-backwards-compatibility, so i thought i go for the "safe" approach (this was also suggested by the mailing list). I think it would be a great feature for magnolia to provide some sort of migration-path for each version, so one knows what to do when updating from a specific version. i guess this would boost the popularity of magnolia even more, since the migrations using import/export require quiote a lot of work and time. as for your request to test the export with 3.5.2: i'll do this today and will provide the information here. many thanks for your reply, Claudio |
| Comment by Claudio Greuter [ 24/Jan/08 ] |
|
ok i shortly checked with an export of 3.5.2. It seems as this issue exists only in exports from 3.0.1. so this problem is only related to migration content from 3.0.1, and not related to the actual magnolia version. |
| Comment by Magnolia International [ 24/Jan/08 ] |
|
This was fixed in one of the 3.0 versions To upgrade from 3.0.1, the procedure to upgrade from 3.0.5 should work too. You might want to do a full backup first. (and possibly an intermediate upgrade to 3.0.5, but I don't think that'll help with anything) |
| Comment by Philipp Bracher [ 25/Jan/08 ] |
|
> I think it would be a great feature for magnolia to provide some sort of migration-path for each version, After 3.5 you will be able to update your system stepwise in a safe way. So you would update 3.0.1 to 3.0.5 and then update to the latest 3.5 release. For doing bulk export/import we are planing to write a backup restore tool for the 3.6 release. If you export ensure that the formating flag is not set. You could try to replace the core jar only (with the 3.0.5) and then doing an export |