I have been looking at a very simple (well…really not) export and import for weblogs. It would only work on “simple” stand alone weblogs that do not have field relationships or extended fields. As you all can imagine, it could be a very complex problem with the possibilities of items that conflict with the target database (fields, statuses, categories, weblogs).
I want to know a couple of things before I get too deep…
1) Is 2.0 going to totally “mess” with the database structure making this obsolete by 2.0?
2) Are there any big pitfalls that make this a fundamentally impossible thing to accomplish? You know, like “chicken and egg” which comes first type problems or other impossible to resolve issues?
Here is my basic logic:
Export: Create an export script that finds and exports all the needed database items and saves then in a structured array. Serialize the array into a file and allow the user to download and save the file locally. This way common weblogs could be traded, after all, how many times can you create the staff weblog before it drives one a little crazy?
Import: 1) Upload a file and check it over for conflicts with the current database data.
2) Return a page that lists all the information and their conflicts. Field groups, fields, status group, statuses, category groups, categories In the event of conflicts this page would give the user the option to rename the conflicting fields or otherwise resolve the conflict by changing the needed attribute. Keep validating the submitted attributes until all conflicts are resolved.
3) After validation of the data do the dirty work of inserting and remapping all the table entries. Obviously all the field_id’s, etc would change but I don’t think that is the difficult part.
Whadda y’all think? Please post your thoughts…
Initial thoughts on the import/export idea is that it would be a lot more tricky to integrate to an existing install, mainly because everything is linked together by a field number, entry number, weblog number. Importing into an existing install would mean you’d need to look at what references are available and adjust the imported content accordingly.
Regarding your point 2 on Import - asking the user will probably be pointless and annoying, an automated solution which chose the next free reference up would be more sensible, unless it’s a duplicate title of course. The biggest impact will be the reference numbering, not duplicate naming.
If you’re importing into a new install, why not just use the previous database and save the effort of writing a plugin. So therefore the point of this would have to be it imports into existing installs.
Exporting relationships etc, isn’t too difficult once you start understanding the structure of the databases, the tricky thing would be all the compatibility for every plugin, and their versions - e.g. Playa v1 stores it’s information completely different to Playa v2.
Thanks for your thoughts twobelowzero.
Correct. It is not a simple export/import. You have to insert data and get the record id’s and update data with the new record id’s.
Regarding confirmations. I would use this with multiple weblogs that have the same field groups/category groups ans status groups. If I simply inserted everything in the file then I would end up with multiple identical groups. In the case of fields I would have trouble because you cannot have fields with the same name - even if they are in different groups. I suppose if there were a perfect match it makes sense to use what is there rather than give the user a choice.
If you’re importing into a new install, why not just use the previous database and save the effort of writing a plugin. So therefore the point of this would have to be it imports into existing installs.
Exactly!
I have been thinking that I will only support a simple export - fields, status and categories and not get into third party plugins. Start out simple and then add later if it is useful and works as expected.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.