Upgrade importexportapi to Drupal 5

I guess this module is dead in the water then?

I don't have the time to continue maintaining this module myself, but I'd be very happy if someone was willing to help upgrade it to Drupal 5. I will be posting an announcement about this on the devel list soon.

This is _not_ actually me volunteering :-)

Jaza : do you happen to have a small idea of how hard it would be to upgrade the module ?
I mean, 4.7 -> 5.0 migration is generally not that much of a deal (much easier than 4.6 -> 4.7, FormAPI stuff...), but there might be some specifically tricky areas (CCK had, for instance) ?

Hello,

I would like to volunteer to help the ongoing effort in maintaining this important module.
I have extensive software engineering experience, although I am not by any means a Drupal expert.
I am getting up to speed, however, in the world-famous Drupal Dojo class (), and feel that this kind of activity would be perfect to help both my own knowledge of Drupal and to make an important contribution to the community.
If someone can get back to me, I would propose first of all making a reverse engineering (UML analysis) of the existing 4.7 working code after all 4.7 bugfixing is complete, and then organizing the feature requests, including migration to 5.0, into a priority list, and then taking it from there.

Victor Kane
awebfactory.com.ar

Just want to add that I have extensive XML experience, so I do consider myself qualified.

Thanks for volunteering to help with the upgrade and with ongoing maintenance of this module, Victor. You don't really need to 'apply' to help out with all this. You can just dive right in and get involved. You can submit a patch for the upgrade path, which I would be happy to review, and to ultimately commit. You're also welcome to submit patches for pending bugs, or to contribute whatever else you want (e.g. UML analysis diagrams).

in addition to the usual 5.0 upgrade steps, this module has table definitions for most core tables so it needs to be reflect any schema changes that happenned in core or cck for 5.0

I think we should jump into 5.0 version then resolve other issues. Drupal 5.0 dev is moving at lightning speed.

Subscribing

Subscribing.

subscribing

subscribing to issue.

I see the current HEAD version is for Drupal 5 and the functionality is there and it's working just fine. The lay-out and displaying needs some finetuning though, especially the module page and menu items.

Confirming Drupal 5 I would certainly add the following to importexportui.info:
dependencies importexportapi

Also the export/import menu items shouldn't go straight below 'Administer' but should fall below ' Content management' in their own 'Import/export data' submenu. I'll work on that this week and maybe add some (robust) funcionality to include a WHERE statement.

Subscribing, but also wondering what the main difference is between node_import and this module. Is there any advantage to one over the other. Neither has been successfully upgraded to 5.x

cghobbs,

node_import only allows you to import nodes, and only of a limited sort of types. The importexportapi module allows you to import and export and and all data in the Drupal database. Please note that the HEAD version of the importexportapi module is fully functional, albeit some UI placement issues.

Thanks! With two confirmations that HEAD is working in D5, I've created a D5 branch. If you'd care to elaborate on the UI issues, I'll try to get those fixed as well.

Trying out the D5 version, I get :

Warning: Illegal offset type in (...)/importexportapi.module on line 567
Warning: Illegal offset type in (...)/importexportapi.module on line 364

I have lots of cck-defined node types and I am using PHP4 (I think there are some differences between php4 and 5, in the way arrays behave).

Related lines are :

567 : return isset($types[$op][$type]) ? $types[$op][$type] : array();
364: $dependencies[$field[$child]['#reference_entity']] = $field[$child]['#reference_entity'];

I just realized that I should have said this happens when clicking on the first (and second) step of import and export. It actually stops the processing on the second steph.

Install ok.

Test with custom node.
- Export to csv - Does not provide option to map custom fields.
- Import from csv - Does not provide option to map custom fields.

Ref: ver 5.x

Here's a whole lot of fixes, that should pretty much complete the 5.x upgrade for importexportapi. Just committed this patch, which does all these things:

- finish updating schema definitions:
- Add GUID to aggregator def, per #61433.
- Add def for new blocks_roles table, per #18018.
- Add def for new node_type table, per #62340.
- Remove defs for page and story nodes, create new def logic for
nodes of a custom type.
- fix up menu callbacks and admin menu paths.

jaza did most of the work on upgrading the table definitions, with cck being the only holdup. See also 129785.

I'm still getting this illegal offset error using either the official release or the dev release that are linked on the project page for this module:

* warning: Illegal offset type in importexportapi.module on line 567.
* warning: Illegal offset type in importexportapi/importexportapi.module on line 567.
(directory paths removed)

Step two of the import process is incomprehensible to me - there seem to be options for field mappings that are iterated out several times. I'm not sure if something is not working or if I just don't understand how this module is supposed to work.

I'm using PHP4 and Drupal 5

Is your error different than 129785? If not, then please follow the solution there.

Step two of the importexportui module maps out your existing fields with the separate tables which are being written to. So you essentially need an understanding of which tables are being written to, and which fields are required to be populated.

For example, for user roles, only one table is being written, so there is only one set of fields to map. For users, three tables are being written to, so three field sets need to be mapped. This is regarding the 4.X version, but the principal is the same.