Import

[Guizmo]

Capability of importing a static web site would be nicely appreciated

[tsw]

its not as easy as it sounds.

where should we get page alias? from old title tag?

what content is taken? everything? (double and so on) everything in one div? (what about the rest)?

and so on, the list goes on.

if you have properly coded static site its quite easy to write small script that goes through them and adds into db directly, but thats not usually the case...

[Guizmo]

Why not having a look how the other do it ? Modx propose this capability

[cyberman]

With a nice cache you will have a semi static web site ...

[Guizmo]

Whatever CMS MS could have several rules to respect in importing, that would save time for many who could after finish the job manually

[cyberman]

Why not having a look how the other do it ?

You are invited to write this extension  ...

[graemep]

if you have properly coded static site its quite easy to write small script that goes through them and adds into db directly, but thats not usually the case...

I have a static site that is generated by scripts (a combination of hyperlatex and my own scripts) so I should not be too difficult to write a script to add the output to the database.

The biggest problem is that I cannot figure out what all the data base columns are for. For example, in cms_content, the hierarchy, id_hierarchy and hierarchy_path columns seem to duplicate data that can be derived from parent_id, content_alias and item_order. Is this some sort of caching for performance? Does my script need to fill all these columns in? I am also a bit vague about how the actual content in cms_content_props is linked to the data in cms_content.

I have not found any documentation of the database. Am I missing it somewhere? Thanks for any help.

[Guizmo]

I were particulary interested regarding import regarding CMS MS as some kind of a wiki usage.
I finally saw that dekiwiki http://www.opengarden.org/dekiwiki were about to support the import capability

[Ned Nowotny]

The general problem of importing existing pages is quite difficult.  In fact, it would be easier to retain the existing static pages and provide an import mechanism that creates "Link" content items that at least enable menu management for the static pages.

However, a bit more functionality would be desirable:

• Providing a tool to import images from a directory hierarchy while maintaining the relative pathnames of the images from the root directory of the hierarchy would be very helpful.  (This would almost certainly have to run against a directory hierarchy on the server--either pre-existing or transferred via FTP.)
• Providing an import mechanism for pages that would read in a file written in a structured format would be feasible.  What I mean is providing a file format (e.g. CSV, XML, etc.) that includes all of the page content attributes available through the user interface wrapped in a structure that would allow multiple pages to be specified in the file.

The second capability requires the user to prepare a file for import.  For most users, using the existing web interface to import one page at a time may be no more difficult than using their text editor to assemble and format a file for import.  However, people familiar with any of a number of scripting and macro languages should have no difficulty in preparing an import file.

Given a better understanding of the current database structure, this can be done today if the import file you create is an SQL file.  However, small errors may badly corrupt the database.  Moreover, what I really would like is something that enables me to prepare my content for import as if I entered the content through the web interface and then leaves it to the back-end of the web interface to perform all of the validation and support database updates performed today for each page.  For example, adding a page updates various log tables in the database.  I would not want to generate an SQL file containing all of those or other dependent updates necessary to perform a proper import.  Besides, not only would it be difficult to get right the first time, it would be even more difficult to keep it up to date as the CMS Made Simple database continues to evolve with each release.

[calguy1000]

If I were to import pages, I think it'd be easier to markup the existing pages first, so that an importer can handle it.

i.e:  you could markup your html with tags like and and then and , which an importer could then look for, parse and handle.

importing a template is a relatively simple matter now... there's no need to do that, just a means to bulk import a set of static pages for when you decide to 'cmsifhy' them.

Then it'd be a simple matter for anybody to go in, briefly add the tags that are needed to each file, and click import.

[Ned Nowotny]

A very good alternative.  The key is to get something that can process a file rather than a form post and some means to batch process a set of files.