Comments

Steven Brown’s picture

Thank you for the port patch I will review it this weekend.

Steven Brown’s picture

I've reviewed the port and I see some errors due to functions not existing in D6 and also form elements not existing in six. These should be easy to fix. I'll do my best to work on this for this weekend.

I will make a D6 branch so if you want to check out the files and make git patches to what you currently have you are more than welcome. In fact encouraged ;)

Steven Brown’s picture

A 6.x-1.x branch has been made. I believe Drupal still does a midnight process. So it will be there tomorrow morning at the latest. Or you can check it out via git ;)

Steven Brown’s picture

I've converted everything except the hook_user_role_insert() function from D7. This doesn't exist in D6. Also there's not a hook to insert a role into the system in D6. However, features is handling this and would like to at least support features. Any other module that is doing it a round about way will more than likely not be supported.

Also, the machine name field hasn't been javascripted yet. Which will need to be done.

smokris’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev

Thanks. 6.x-1.x-dev is working for me so far.

smokris’s picture

Status: Needs review » Needs work

Correction: not quite working.

If I create roles through the UI, the roles correctly get their hashed RIDs and machinenames.

If I then export those roles as a feature, then activate the feature on another site (which already has role_export.module enabled), the imported roles don't get hashed RIDs or machinenames.

Steven Brown’s picture

Right currently working on a solution. We need a post processing hook for the D6 version of features. I'm going to try and team up with some maintainers of features to tackle this. At the very least learn features enough to create my own post processing hook and see if I can send it to features as a patch.

Steven Brown’s picture

Looks like there has been a lot of talk looking for some type of post processing hook on the features queue. Look here http://drupal.org/node/981248

Steven Brown’s picture

A possible way around this could be to cache the current roles. Then when a feature is installed I believe it clears all cache. Then if cache doesn't exist, go to the database modify any roles to have the current machine name and rid. Next create the new cached version of the roles. Only issue is what hook to use to fire this off after modules are installed.

Possibly hook_init(), this happens during each page load. I believe this would work just find but it seems like a serious work around.

Steven Brown’s picture

Smokris, I have just committed to the 6.x branch (Will be Oct 25 dev version). So far from what I can tell this should be a solution. Please test this and let me know if it also works for you.

NOTE:: Make sure to fill in the Machine Name field on the roles page when creating a new role. The function for generating the Machine Name uses this fields input like the D7 version.

P.S. Let me know asap if you can. If all is well I will start on making the Machine Name field act like the features machine_name field.

Steven Brown’s picture

Status: Needs work » Postponed

Neither Klausi or I have interest in creating the D6 version. So until more help or volunteers are available I am postponing this port.

jarodms’s picture

I tried the latest DEV release and from my testing it looks like Smokris #6 issue is resolved.

I'd be interested in helping or testing.

Steven Brown’s picture

I know I've taken this a long way already. However, there are some downfalls in D6 that I don't have in D7. Mainly all the role hooks :). I'll review what I have and try to move this forward.

smokris’s picture

Assigned: Unassigned » smokris
Status: Postponed » Active

@FatGuyLaughing: Sorry I didn't get back to you a few months ago — I got diverted to some other projects. Back to looking at drupal-6.x role exporting now.

Another issue: role machine names aren't making it into the exported Feature.

In Drupal 7:

$ drush fe blah user_role:blah
$ cat blah/blah.features.user_role.inc 
[...]
  $roles['blah'] = array(
    'name' => 'blah',
    'weight' => '3',
    'machine_name' => 'crazy_machine_name',
  );
[...]

In Drupal 6:

$ drush fe blah user_role:blah
$ cat blah/blah.features.user_role.inc 
[...]
  $roles['blah'] = array(
    'name' => 'blah',
  );
[...]

No machine name is exported, so if the machine name differs from the machine name automatically generated from the display name, the hashed rid will be incorrect on the destination site.

I tried implementing hook_features_export_alter() to add the machine name in, but features.user.inc implements its own custom hook_features_export_render() which hardcodes a single value into the exported object. I don't see a way to override this, so I think I'll need to patch Features.

smokris’s picture

StatusFileSize
new995 bytes

OK, I patched Features — http://drupal.org/node/1437778. The patch attached here, after the previously mentioned Features patch is applied, includes the machine_name in the exported role data, so now it more closely matches the Drupal 7 output (except that 'weight' is missing, but that doesn't matter in Drupal 6 anyway).

smokris’s picture

Status: Active » Needs review
StatusFileSize
new1.64 KB

One more problem: if you restore a Feature, the machinename gets set in the {role} table, but {role}.rid is wrong.

The attached patch updates the role_export_roles() logic to also rewrite {role}.rid even if a machinename is set.

smokris’s picture

Status: Needs review » Reviewed & tested by the community

Here's what I see as the checklist for releasing a "stable" version of role_export-6.x-1.x:

  1. Commit role_export-machinename-export-00.diff (this issue, #15)
  2. Commit role_export-feature-enable-00.diff (this issue, #16)
  3. Commit the patch on #1320892: Remove "role-" prefix for machine names
  4. Indicate that the patch on #1437778: Allow hook_features_export_alter() to add attributes to exported user role Components needs to be applied to Features

@FatGuyLaughing, sound ok?

(By the way, I'd be happy to be the maintainer for role_export-6.x if you like. I'm now using it to help tame 3 different legacy Drupal 6 projects, so I'm fairly personally-invested in it.)

smokris’s picture

StatusFileSize
new4.64 KB

Here's a composite patch, including #1, #2, #3 in my above comment. Also includes an implementation of hook_drush_exit(), so that the issue on comment #16 can be fixed when restoring Features via commandline.

smokris’s picture

StatusFileSize
new7.14 KB

#4 above didn't work out — hook_features_export_alter() is more limited than I thought.

Attached is yet another composite patch, including everything in #18, plus an implementation of the Features API for a new Features Comopnent "role_export", which obviates the need to patch the Features implementation of user_role Component.

smokris’s picture

StatusFileSize
new7.14 KB

Fixed db_query() when reverting.

Steven Brown’s picture

You have a lot of time invested in this :) I appreciate the enthusiasm to get a release. I will talk to klausi about making you a maintainer. You can find me on IRC as FatGuyLaughing

klausi’s picture

+++ b/role_export.module
@@ -13,7 +13,7 @@
 function role_export_init() {

Do we really want hook_init()? This is really a performance issues, as it is called on literally every page request.

+++ b/role_export.module
@@ -100,11 +100,11 @@ function role_export_theme() {
-    if ($cache) {
+    if ($cache && !$reset) {

Do we need that cache? We have removed to role cache in the 7.x branch, as this function is not called that often.

+++ b/role_export.module
@@ -112,16 +112,16 @@ function role_export_roles() {
+          db_query("UPDATE {role} SET rid = %d, machine_name = '%s' WHERE rid = %d", $new_rid, $value->machine_name, $value->rid);

Why can't you use drupal_write_record() here?

+++ b/role_export.module
@@ -161,4 +161,107 @@ function role_export_generate_id($mname) {
+/**
+ * Implement hook_drush_exit().
+ */

should be "Implements"

+++ b/role_export.module
@@ -161,4 +161,107 @@ function role_export_generate_id($mname) {
+/**
+ * Implementation of hook_features_api().
+ */

All new code should follow the latest documentation standards, i.e. "Implements hook_features_api()."

Otherwise I'm fine with adding you as a maintainer :-)

smokris’s picture

StatusFileSize
new14.57 KB

Do we really want hook_init()? This is really a performance issues, as it is called on literally every page request.

I'm thinking that the following triggers would be sufficient:

  • upon enabling role_export.module
  • upon adding or modifying a role via the UI (submit handler)
  • upon enabling a Feature declaring role_export Components
  • upon reverting a Feature declaring role_export Components
  • upon cache-clear (since this is a typical administrative action to make sure everything's in sync)

I added the above, with the exception of the "upon enabling a Feature", since in Drupal 6, there isn't a hook for that. Which I think is what prompted @FatGuyLaughing to use hook_init() as a workaround.

Do we need that cache? We have removed to role cache in the 7.x branch, as this function is not called that often.

OK, I removed it.

Why can't you use drupal_write_record() here?

We're changing the key. As far as I can tell drupal_write_record() doesn't support that (drupal_write_record() doesn't allow specifying separate old and new keys, only a single constant key).

should be "Implements" / All new code should follow the latest documentation standards, i.e. "Implements hook_features_api()."

Changed.

Revised patch attached, now with a (passing) SimpleTest.

klausi’s picture

Status: Reviewed & tested by the community » Fixed

I have added you as maintainer of this project, so feel free to commit your stuff to the 6.x branch. Marking this issue as fixed, let's open new ones for any remaining problem(s).

smokris’s picture

Thanks, @klausi and @FatGuyLaughing!

I've committed the patch in #23, and tagged a 6.x-1.0 release.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.