Entire hour for 20-30 pages?!! There's something very wrong in your
system if that's the case. I can export 70-80 pages in just a few
seconds and the export has never failed to load. Just tested it
actually .... about 40 seconds total time from hitting the export button
to download completed.
Just for the record though, my environment:
Mandrake Linux 10 on a Dell Optiplex (just a couple of years old)
MySQL version 4
Magnolia 3.0.3-SNAPSHOT (4/6/2007) custom build to use jackrabbit 1.2.3
(only changed the dependencies in the pom.xml files)
Tomcat 5.5.23 / Sun JDK 1.5.0_06
I've checked the coding for the persistence manager in jackrabbit 1.2.3
and it's the same as in 1.0.1 (currently shipped with magnolia 3.0.2CE)
except they added some retry logic for when the db connection goes bad.
Can you provide more detail for your export? Are you checking the "Keep
versions" checkbox? That would make the export much bigger (and take
longer).
--David
Miranda Jones wrote:
I have never been able to get the export tool (from the Tools menu) to
export XML correctly even with the "Format XML" box left unchecked. I
just tried this again to reverify (which took an entire hour for about
20-30 pages!) and there are still line breaks all through the
paragraph content (sometimes even in the middle of HTML tags).
This is definitely extremely undesirable. Even if re-saving the
paragraphs again worked, that is not a very good solution for a site
import with scores of pages and hundreds of paragraphs! It doesn't
work though, as the line breaks are turned into <br/>.
We use MySQL to store content, so right now our backup method is to
just make sure the MySQL databases are kept backed up. It would be
nice, though, to have a working XML export, too.
-- Miranda
David Smith wrote:
I'm sure the answer was in this thread somewhere, but I'll ask
because it's easier ....
Just out of curiosity, how did you do the export?
I've seen the right-click export method create the "pretty" formatted
indented xml which does cause problems on import. Using the magnolia
export tool (Export from the Tools menu on the left in AdminCentral)
and then making sure the "Format XML" checkbox is clear always works
for me.
--David
Jean Pierre Malrieu wrote:
It's even worse than I thought then, if it affects every backup-
restore cycle.
I can tell that my paragraphs (pasted from word in fck) CANNOT be
"reconverted" by saving again the paragraph. I don't want to be too
critical, because magnolia CE is an open source tool, and a very
promising one, but a CMS that cannot be saved and restored, and in
the case of magnolia CE, that cannot be updated, is not ready for
production.
JPM
Le 26 avr. 07 à 19:32, Sebastian Frick a écrit :
I remember this issue has already been reported in JIRA. Usually
you can "re-convert" those richtext-fields by clicking the
responsible dialog and save the data again. I don't think this
behaviour isn't caused by a different tomcat-version. Nevertheless
this issue is a big blocker for me...
Sebastian
Maintaining a site with magnolia proves to be a real nightmare.
The bugs in 3.0.1 forced me to update to 3.0.2.
I also downgraded from Tomcat 5.5.17 to 5.0.28, because of some
issues with table paragraphs, and because 5.0.28 is the version
magnolia ships with.
I exported everything and imported it back.
Most of the pages have problems now: line breaks appearing
randomly, tables created with fck editor which confuse content
and html, and so on...
What a mess!
Am I the only one to experience this?
At least we should be warned that one should not export and
import to magnolia instances running on a different version of
tomcat...
What's the point with exporting to xml if everything gets scrumbled?
JPM
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
