Switch to using exportable entities for entity types

Thanks for this! Will review as soon as I can.

Sorry for the delay. Been looking into this and the code looks fine, but I'm getting errors when I attempt to update the module:

Warning: array_keys() expects parameter 1 to be array, null given in drupal_schema_fields_sql() (line 6969 of /Applications/MAMP/htdocs/ordertypes/includes/common.inc).

Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /Applications/MAMP/htdocs/ordertypes/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1300 of /Applications/MAMP/htdocs/ordertypes/includes/database/select.inc).

Seems like the updates taking place after the table has been renamed think the table doesn't exist. I've been playing around with it, but so far no luck.

I got the same error while updating. After two cache clears, though, the errors disappeared and the update seemed to work.

Sorry, been out of town. Will review ASAP!

Thanks again for the updated patch and sorry for the delay. I've reviewed and found a few issues:

commerce_order_types.admin.inc, line 47:

'exists' => 'commerce_order_types_order_types',

I believe this callback should be 'commerce_order_types_order_type_unique'.
commerce_order_types.module, line 259:

function commerce_order_types_order_type_unique($type) {
  // Look for a match of the type.
  if ($match_id = db_query('SELECT type FROM {commerce_order_types_order_types} WHERE type = :type', array(':type' => $type))->fetchField()) {
    return FALSE;
  }
  return TRUE;
}

I believe the return values should be switched here and the table needs to be renamed; I was unable to create a new order type with this code.


More importantly, I was not able to get order type cloning/exporting/importing/creating to work properly. For me, new order types were created without their default fields and exporting did not preserve any custom fields. Also, Features exporting does not seem to anymore, though that could probably be solved with some additional integration.

This is great!

I am merely providing some testing and encouragement as a newbie. I get the same errors about failing on machine readable name non-uniqueness.

I could really use the patch...so keep up the good work.

Hey, so I played with this a bit. Im a terrible developer and don't know how to post a patch to a patch yet :-) I did get this to work with the following changes:

- I changed line 47 in .admin.inc to: 'exists' => 'commerce_order_types_order_type_unique',
I made the following 2 updates to .module:

function commerce_order_types_order_type_unique($type) {
// Look for a match of the type.
if ($match_id = db_query('SELECT type FROM {commerce_order_types} WHERE type = :type', array(':type' => $type))->fetchField()) {
return TRUE;
}
return FALSE;
}

and

function commerce_order_types_commerce_order_type_save($order_type, $skip_reset = FALSE) {
$op = drupal_write_record('commerce_order_types', $order_type, empty($order_type['is_new']) ? 'type' : array());

I verified that I could create new types, not overwrite existing types and export a feature module.

hope that helps anyone else in need...

---------- UPDATE -----------

while this fixed the type entity itself...creating an order of a custom type is not working.

Hmmm some progress

Managing fields/displays doesn't appear to work

I can go to create an order at the proper path, but the fields aren't there.

Hi guys
Refactoring of module and made order types exportable.
Managing fields/displays - now works too.
Please test it.
thanks

Thanks for the patch AndrewsizZ . There seems to be a few comments/variables related to the ERPAL project - could you reroll the patch without those in there?

Nice catch. Thanks!!
Fixed. New patch added.

1. +++ b/commerce_order_types.admin.inc
   @@ -0,0 +1,83 @@
   + * Generates the profile type editing form.
   

   Comment needs updating.

2. +++ b/commerce_order_types.admin.inc
   @@ -0,0 +1,83 @@
   +      'exists' => 'commerce_order_types_order_types',
   

   Shouldn't this be commerce_order_types_order_type_unique?

3. +++ b/commerce_order_types.admin.inc
   @@ -0,0 +1,83 @@
   +    '#value' => t('Save order type'),
   

   Do we want to make 'order type' capitalised? i.e. "Save Order Type" (also elsewhere).

4. +++ b/commerce_order_types.entity.inc
   @@ -0,0 +1,26 @@
   +  public $type;
   

   We should probably define the other properties for consistancy, i.e. $id, $help, and $data.

   Preferably with docblocks.

5. +++ b/commerce_order_types.entity.inc
   @@ -0,0 +1,26 @@
   +  public $label;
   

   This should be $name not $label.

6. +++ b/commerce_order_types.entity.inc
   @@ -0,0 +1,26 @@
   +  public $weight = 0;
   

   We store no weight value so this can be deleted.

7. +++ b/commerce_order_types.entity.inc
   @@ -0,0 +1,26 @@
   +  function isLocked() {
   +    return empty($this->is_new);
   +  }
   

   Is this the best way of determining whether to lock this type? Would an !empty($this->id) be better?

8. +++ b/commerce_order_types.info
   @@ -4,3 +4,5 @@ package = Commerce (contrib)
   \ No newline at end of file
   

   Needs newline

9. +++ b/commerce_order_types.install
   @@ -31,9 +40,58 @@ function commerce_order_types_schema() {
   +    ) + entity_exportable_schema_fields(), ¶
   

   In my experience using this function here can be problematic as hook_schema can be run at times where the bootstrap level is very low.

   Can I suggest we put these fields in manually.

10. +++ b/commerce_order_types.module
    @@ -11,78 +11,22 @@
    +  foreach (commerce_order_types_order_types() as $type => $info) {
    +    $items['admin/commerce/orders/add/' . $type] = array(
    +      'title' => 'Add order @type',
    +      'title arguments' => array('@type' => $info->name),
    +      'description' => $info->help,
    +      'page callback' => 'commerce_order_ui_order_form_wrapper',
    +      'page arguments' => array(commerce_order_new(0, NULL, $type)), //type
    +      'access callback' => 'commerce_order_access',
    +      'access arguments' => array('create'),
    +      'type' => MENU_NORMAL_ITEM,
    +      'file' => 'includes/commerce_order_ui.orders.inc',
    +      'file path' => drupal_get_path('module', 'commerce_order_ui'),
    +    );
    

    We need to check if commerce_order_ui is enabled or this can cause issues.

Seems good to me. Above points need tweaking.

Nice hints. A lot of thanks!!

2) not sure if needed commerce_order_types_order_type_unique because it will be duplication of commerce_order_types_order_types. Because now it works as needed. And I reviewed how it works in other exportable contrib entities.

9)Not sure. In CRM core identical. And not have any troubles.

All another are added to new patch.

rerolled patch

OK! I've tested and committed #19 with a slight modification to fix an update error.

I don't have any real projects to test this on at the moment, so I'd appreciate some feedback from anyone with real data to test this on before pushing a release.

This will also require a patch to commerce_features to remove the duplicate features implementation.

Hi there, not sure if it is related to this particular issue but it may well be from the drush errors, I just tested the latest dev on a real project and it's broken the site completely...
More info here: #2435081: Update to dev completely breaks site...

This breaks features integration provided by Commerce features module #2486921: Does not work with commerce_order_types dev release

it should be fixed in Commerce features module

+++ b/commerce_order_types.module
@@ -95,6 +40,7 @@ function commerce_order_types_menu_local_tasks_alter(&$data, $router_item, $root
       $type_arg = strtr($type, '_', '-');

What is the us of this? Create action link does not work properly if commerce type name contains underscore.