Error messages upon attempting to install and use current HEAD version in Drupal 5.x
| Project: | Import / Export API |
| Version: | HEAD |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | victorkane |
| Status: | duplicate |
As a first step in our work to get this module Drupal 5.0 ready, I downloaded the current HEAD code with CVS (we are working in HEAD until we get basic stable code functioning). These include Doug's changes to bring the code inline with Drupal 5.x syntax.
My Test Cases can be found in my blog.
Here I was attempting to run Test Case 002 ( http://awebfactory.com.ar/node/185 ), which involves installing to Drupal 5.1 and importing a few book pages exported from a documented 4.7.6 install.
As the results showed in Test Case 002, there was a series of errors in importexportapi.module. I fixed those (patch available just in a few minutes).
Then, I had the module installed in Drupal 5.1, and enabled under Access Control (The importexport.info syntax is wrong, so the version doesn't show correctly, fix will be included in patch.
The following error was produced upon attempting to access the Administer >> import page.
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'importexporui_initial_selection_form' was given in /var/www/drupal-5.x/includes/form.inc on line 218.
Will post patch for installation problems as stated in few minutes, then will go on and analyze these errors (unless someone beats me to it!). I am mindful of other comments here also.
Let's get this fine module on the road!
#1
Patch to bring importexport.module into line with Drupal 5.x syntax.
See http://awebfactory.com.ar/node/185 for details of test case run.
Doug: please commit so I can continue work on the warning with updated code from HEAD.
#2
Will now analyze warning message on accessing Administer >> import. If it is obvious to anyone, give a shout. Otherwise, will be edifying (if I have time before going off to client's shop, in which case will check back tonight).
#3
OK, this warning simply stems from the fact that we need to upgrade importexportui.module to the Drupal 5 FormAPI.
In this error, at least, specifically in the function importexportui_initial_selection_form() on line 90.
This is not using, of course, the FormAPI.
I will start on this tonight (it's 7 in the morning now in Buenos Aires) when I get back from a round of customer meetings and work sessions, if no-one beats me to it and will report in 24 hours. If someone else is going to do this, give a shout, otherwise will post patch tomorrow morning (can convert to FormAPI thanks to pointers in Josh's Drupal Dojo lessons :)
#4
OK, on the track of the above "elusive" warning:
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'importexporui_initial_selection_form' was given in /var/www/drupal-5.x/includes/form.inc on line 218.after careful perusal of "Converting 4.7.x modules to 5.x" (http://drupal.org/node/64279), and studying drupal_get_form() in the API reference, etc. I see that Doug's changes are all correct in terms of the FAPI building method and automatic recognition of form callback functions by their form id.
Then, I catch the typo, which is right in the warning all the time :)
The form id is supposed to be 'importexportui_initial_selection_form' and not 'importexporui_initial_selection_form' ("t" missing in first word).
OK, now the real fun starts.
Now the page goes blank. It's easy to see why, there are a zillion log messages saying the same thing, so we either have a character by character (html entity) process or an infinite loop.
The error in watchdog is as follows:
Type phpDate Thursday, February 8, 2007 - 21:42
User victorkane
Location http://mentor/drupal/admin/import
Referrer http://mentor/drupal/admin
Message htmlspecialchars() expects parameter 1 to be string, array given in /var/www/drupal-5.x/includes/bootstrap.inc on line 588.
Severity error
Hostname 127.0.0.1
So, the typo is not worth a patch, I think, till I get to the bottom of this one (and the form at least materializes on the screen).
Will report back some time later... same issue, same moebius channel...
#5
This looks like a pretty deep problem.
I did a print_r on the $form in the import form builder callback function, and the following segment (listing the node types) looks weird, and may indicate an inability to call the database.
I don't know about this. Here is the result of the print_r statement:
Array
(
[entities] => Array
(
[#type] => checkboxes
[#title] => Entities to <em>import</em>
[#description] => Select the entities that you wish to <em>import</em>. The list of entities is sorted in order of dependency. For example, if entity 'z' depends on entities 'x' and 'y', then entity 'z' is listed below entities 'x' and 'y'. It is recommended that you try to <em>import</em> non-dependent entities before dependent entities.
[#options] => Array
(
[block] => Block
[input_format] => Input format
[filter] => Filter
[menu_item] => Menu item
[variable] => Variable
[vocabulary] => Vocabulary
[term] => Term
[role] => User role
[user] => User
[watchdog_message] => Watchdog log message
[content_field] => Content field
[content_type] => Content type
[dojo] => Array
(
[0] =>
)
[page] => Array
(
[0] =>
)
[project_issue] => Array
(
[0] =>
)
[project_project] => Array
(
[0] =>
)
[project_release] => Array
(
[0] =>
)
[story] => Array
(
[0] =>
)
[block_custom] => Block (custom)
[node_access] => Node access rule
[file] => File
[battle] => Array
(
[0] =>
)
[comment] => Comment
)
[#required] => 1
)
[engine] => Array
(
[#type] => radios
[#title] => Format of <em>import</em> data
[#description] => Select the format in which you wish to <em>import</em> your data. The list of available formats is determined by the 'get' and 'put' engines that you have installed.
[#options] => Array
(
[csv] => CSV (Comma Separated Values)
[xml] => XML (eXtensible Markup Language)
)
[#required] => 1
)
[submit] => Array
(
[#type] => submit
[#value] => Next (field mappings)
)
)
#6
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'importexporui_initial_selection_form' was given in /var/www/drupal-5.x/includes/form.inc on line 218.Hi, notice the missing "t" in 'importexpor(t)ui...
Though, after changing this, you get a white screen :)
Ian
#7
Hi Ian!
Thanks a lot, although, two updates ago I say:
"Then, I catch the typo, which is right in the warning all the time :) ... The form id is supposed to be 'importexportui_initial_selection_form' and not 'importexporui_initial_selection_form' ("t" missing in first word).
OK, now the real fun starts: Now the page goes blank."
I just decided in the light of the blank page, a patch fixing the typo would not be worthwhile until I fix some of the database stuff, which will take a little while.
As my free time permits, I am in the process of assembling in a single document all the database queries, both in installation/update as well as in operations; as per Moshe's suggestion on another issue for this project (something along the lines of "in addition to the regular updating from 4.7.x to 5.x, it will be necessary to update the database access in line with 5.x...).
I spoke to Jaza, the author of this module, and he agrees that the database stuff will have to be fixed to overcome where we have gotten to.
Anyway, I'll learn a lot!
thanks again, Ian, don't feel so lonely now :)
saludos,
Victor
#8
I've been watching this too, and appreciate all your efforts in making this module work. I haven't ever debugged a drupal module before, but I will spend some time on this module in the future when time permits.
#9
I am just going to throw in my .02 here because I am working with this module right now in 4.7.x. I am running php 5.x and I was having trouble getting a successful import/export going. I looked through the code and did a lot of var_dumps. At a certain point I was running into trouble around some php array_merge calls. According to the php website, array_merge has changed in php 5.x and as a result all parameters to the function must be array types. Their suggestion is explicitly cast any function parameters to array to be sure.
I went through the module code and as a start added the cast to every array_merge function call. Not sure if this is in any way affecting you guys but it seems that it should be done to the current code as there are a lot of php 5.x sites out there and adding the cast will not affect php 4.x sites.
The next issue I ran into was with the definition file for cck. The code makes a few assumptions about cck field names which I am not sure are based on some sort of cck naming convention that I do not know about. If you have a cck field name with a name that spans 1 or more underscores (_) you will run into trouble at some point. Right now I have worked around that in the cck definition file but since I am not sure if there is a standing cck field naming convention I am unsure how to proceed.
Sorry I don't have a 5.x site to add my comments on the port to 5.x. I am wondering if you've all managed to use this module successfully in the 4.7.x core?
#10
I did successfully use this module in 4.7.4 to import and export data to a cck type, in addition to import/export into the roles type.
I created my own module using the importexportapiUI as a model. My module was an event driven automatic update of content types. So, yes, I got the module to work just fine in 4.7.
In the spirit of utilizing this module as an api, I think the data definitions should be separated from the module, similar to the languages concept in Drupal. Have the default content types that come with drupal come with the module, and then have separate I/E modules for non standard content types as separate modules to be downloaded as needed. This way, there could be a standard way of creating subsidiary content type modules to keep pace with the rise in alternative content types and fields within the content types.
Specifically with CCK, I was able to I/E all the standard fields, but was unable to I/E a matrix field type. The matrix field type creates its own table in the database, and so it was handled differently in the I/E module. Separating the I/E module and translation engines from the non-standard content type definitions seems like a good way of keeping this boat afloat.
#11
The issue here looks like it's in the upgrading of the forms. Instead of using the 4.7.x way of drupal_get_form, where it is included as part of the form generation function, you have to use it outside of the form generation.
So we do the following changes:
<?php
/**
* Menu callback; display the import or export page.
*/
function importexportui_page($op, $entities = NULL, $engine = NULL) {
if (!isset($entities) || !isset($engine)) {
return drupal_get_form('importexportui_initial_selection_form', $op);
}
$entity_list = explode(',', $entities);
return drupal_get_form('importexportui_mapping_form', $op, $entity_list, $engine);
}
?>
and
<?php
/**
* The initial selection form that the user is presented with on the import and
* export pages.
*/
function importexportui_initial_selection_form($op) {
$form = array();
$form['entities'] = array(
'#type' => 'checkboxes',
'#title' => t('Entities to %op', array('%op' => $op)),
'#description' => t("Select the entities that you wish to %op. The list of entities is sorted in order of dependency. For example, if entity 'z' depends on entities 'x' and 'y', then entity 'z' is listed below entities 'x' and 'y'. It is recommended that you try to %op non-dependent entities before dependent entities.", array('%op' => $op)),
'#options' => _importexportui_get_entity_list(),
'#required' => TRUE
);
$form['engine'] = array(
'#type' => 'radios',
'#title' => t('Format of %op data', array('%op' => $op)),
'#description' => t("Select the format in which you wish to %op your data. The list of available formats is determined by the 'get' and 'put' engines that you have installed.", array('%op' => $op)),
'#options' => _importexportui_get_format_list($op),
'#required' => TRUE
);
$form['submit'] = array(
'#type' => 'submit',
'#value' => t('Next (field mappings)')
);
return $form;
}
/**
* Displays the field mappings form.
*/
function importexportui_mapping_form($op, $entity_list, $engine) {
$form = array();
$def = importexportapi_get_def(NULL, TRUE);
$type = ($op == 'export' ? 'put' : 'get');
$file_list = ($op == 'import' ? _importexportui_list_raw_files($engine) : NULL);
$raw_list = array();
if ($op == 'import' && $engine == 'xml') {
if ($engine == 'xml') {
$form['raw'] = array(
'#type' => 'radios',
'#title' => t('Raw %op file', array('%op' => $op)),
'#description' => t("Select the file containing the raw data that you wish to %op. In order to be listed here, the file must be in the '/testdata' directory of the importexportapi package, and its format must match the format that you have chosen.", array('%op' => $op)),
'#options' => $file_list,
'#default_value' => key($file_list),
'#required' => TRUE
);
}
}
foreach ($entity_list as $entity_id) {
if (isset($def[$entity_id])) {
if ($op == 'import' && $engine == 'csv') {
$entity_name = "'". $def[$entity_id]['#title'] ."'";
$form['raw_'. $entity_id] = array(
'#type' => 'radios',
'#title' => t('Raw %op file for %entity', array('%op' => $op, '%entity' => $entity_name)),
'#description' => t("Select the file containing the raw data for %entity that you wish to %op. In order to be listed here, the file must be in the '/testdata' directory of the importexportapi package, and its format must match the format that you have chosen.", array('%op' => $op, '%entity' => $entity_name)),
'#options' => $file_list,
'#default_value' => key($file_list),
'#required' => TRUE
);
$raw_list_temp['csv_plural'] = $def[$entity_id]['#get']['#csv_plural'];
$raw_list_temp['id'] = $entity_id;
$raw_list[] = $raw_list_temp;
}
if (empty($def[$entity_id]["#$type"]["#$engine".'_hidden'])) {
if (isset($def[$entity_id]["#$type"]["#$engine".'_plural'])) {
$form[$entity_id .'_plural'] = array(
'#type' => 'textfield',
'#title' => $def[$entity_id]['#title'] . t(' (plural)'),
'#default_value' => $def[$entity_id]["#$type"]["#$engine".'_plural'],
'#required' => TRUE
);
}
if (isset($def[$entity_id]["#$type"]["#$engine".'_mapping'])) {
$form[$entity_id .'_mapping'] = array(
'#type' => 'textfield',
'#title' => $def[$entity_id]['#title'] . t(' (mapping)'),
'#default_value' => $def[$entity_id]["#$type"]["#$engine".'_mapping'],
'#required' => TRUE
);
}
}
_importexportui_mapping_form($form, $def[$entity_id], $op, $engine, $type, $file_list, $raw_list);
}
}
$form['ie_op'] = array(
'#type' => 'value',
'#value' => $op
);
$form['ie_type'] = array(
'#type' => 'value',
'#value' => $type
);
$form['entity_list'] = array(
'#type' => 'value',
'#value' => $entity_list
);
if ($op == 'import' && $engine == 'csv') {
$form['raw_list'] = array(
'#type' => 'value',
'#value' => $raw_list
);
}
$form['engine'] = array(
'#type' => 'value',
'#value' => $engine
);
$form['back'] = array(
'#type' => 'submit',
'#value' => t('Back (initial selection)')
);
$form['submit'] = array(
'#type' => 'submit',
'#value' => t('Run %op', array('%op' => $op))
);
return $form;
}
?>
Notice that the only changes I've made to the bottom two functions are to remove the drupal_get_form call, which is used in the changes in the initial function.
Dave
#12
Sorry for taking so long to get this port done -- I volunteered/inherited the project from the original developer about a month ago and I'm still a little unfamiliar with how everything works. I just spent a little time fixing the export, forms api, CCK name changes, etc. Please check-out the current HEAD branch.
#13
I think that this issue has been superceeded by others, so I'm marking it as a duplicate (although this was probably the original patch). The port is mostly done, although the the CCK definitions [are] not upgraded to D5 yet.