Migrating to Revolution

Hope some work Shaun’s been doing helps there: http://docs.modxcms.com/modext/

I love it! I just started fighting with extjs, and actually managed to make a paging grid with a very simple search field/button, and this will be a big help.

Especially great are the examples; not just a few lines of code out of context (where do you put it?), but actual working examples.

SQL Files

(ducks and runs)

:P

Quote from: OpenGeek at Jan 26, 2008, 11:05 AM

Alright, 50 lashes to the next person that mentions SQL files. Forget SQL files, they will not be involved here at all. And yes, this would need to be broken up into smaller, practical pieces if run through a web UI.

Now I’m really confused. How can you export the content of the 0.9.6 site’s tables and translate that content without dealing with those files that we can’t mention any longer? The two DB’s might be on different servers and one might be remote and one local. Please enlighten me.

Bob

Quote from: BobRay at Jan 26, 2008, 04:24 PM

Now I’m really confused. How can you export the content of the 0.9.6 site’s tables and translate that content without dealing with those files that we can’t mention any longer? The two DB’s might be on different servers and one might be remote and one local. Please enlighten me.

That’s what xPDO is for. Let me explain, but first, ignore the db’s on different servers issue; that is a separate issue, with it’s own simple and complex solutions.

All you need is a connection to the database; then you simply generate a schema from the database and subsequently generate the classes representing the 0.9.6 tables. We can do that and include this library in the migration package. Then you simply read from one xPDO instance representing the 0.9.6 tables and write the content you’ve retrieved to the other instance (i.e. the 0.9.7 classes via MODx). I’ll pull up a sample script showing the actual steps and code to achieve all of these steps for any database tomorrow if I have time.

As for remote databases, you dump and load it local, OR create a set of simple web services using the XML-RPC or JSON-RPC libraries included in xPDO/MODx. Then you can do the same thing by reading data from those remote services, though admittedly, that has a lot more promise for use in other components.

All that said, you can of course perform this directly on a SQL file, but you will not have control over what tables and fields are being translated, unless you break them up into table-specific files (still no field control).

Ah ...

My thought was to parse the sql file into its component tables and fields, either in memory, or by extracting each table to a separate file, and then processing them in turn (I was drawn to this approach because it was more in line with my current skills). As long as you use the "create if not exists" option, the schema of each table is there in the file to use in creating the class.

That said, I can see real advantages to operating on the live tables in the DB. Going that route with JSON-RPC, xPDO, and ext, etc., I’d probably be more helpful as a tester rather than a coder or designer. Let me know how I can best contribute.

Bob

BTW, what does [~[*id*]~] translate to?
seems like the answer, but it looks soooo wrong.

Bob

Quote from: BobRay at Jan 27, 2008, 11:55 AM

BTW, what does [~[*id*]~] translate to?

  [[~[[*id]]]]

seems like the answer, but it looks soooo wrong.

Both forms look wrong IMHO; you’re just used to one over the other. The added benefits of the unified tag format far outweigh the time it takes to get used to it. Do a few templates with the new format and you’ll be so happy at all the new control you have over the parsing, being able to nest any kind of tag anywhere, being able to control caching of any tag, etc., you’ll forget how strange it looks compared to your perceived standard of normalcy, [~[*id*]~]. And besides, which is easier to type, eh?

Quote from: OpenGeek at Jan 27, 2008, 12:11 PM

Quote from: BobRay at Jan 27, 2008, 11:55 AM

BTW, what does [~[*id*]~] translate to?

  [[~[[*id]]]]

seems like the answer, but it looks soooo wrong.

Both forms look wrong IMHO;

Is there something better I should replace this with, or is what I want?

Bob

If you want to make a URL for the document being parsed, that’s correct.

I decided to go ahead with migrating my site so that I can understand the process better. I’m experimenting with which tables can be imported directly and what transformations will be necessary for them. I’m documenting the steps in a tutorial at my site that I’ll publish once I get things working (assuming that ever happens ).

I’ve had some success but am currently stuck.

I dumped the modx_site_content table from the old site and translated the tags in it. I imported it into a temporary database and added the three new fields for 0.9.7, then dumped it again. I imported it into the "official" 0.9.7 site and the import went smoothly. Now, the document tree in the manager is still empty, but the content of the home page actually shows up when I visit the site in my browser or preview it in the manager (unstyled and untemplated, of course). Do I need to set something, and if so how?

I also dumped the modx_site_templates and modx_site_htmlsnippets tables, translated the tags, and imported them. All the templates show up in the manager (and the main one works on the home page, with some errors), and I can edit unlocked ones, but when I try to edit a locked one, I get this:



With the chunks, the only chunks that show up in the Manager are the ones with a category of 0. Is this the only category now? The categories on my chunks from the old site go up to 7 but I have no idea what they mean or where they came from.

When I try to edit the chunks, I can edit the unlocked ones but the locked ones work like the locked templates:


Any thoughts appreciated. I’m most interested in getting the content documents to show up in the manager and setting the category correctly for the chunks.

Bob