Closed (fixed)
Project:
Role Export
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
22 Oct 2011 at 04:29 UTC
Updated:
6 Mar 2012 at 22:40 UTC
Jump to comment: Most recent file
I've attached my initial attempt at porting this module to Drupal 6.x.
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | role_export-6.x-all-03.diff | 14.57 KB | smokris |
| #20 | role_export-6.x-all-02.diff | 7.14 KB | smokris |
| #19 | role_export-6.x-all-01.diff | 7.14 KB | smokris |
| #18 | role_export-6.x-all-00.diff | 4.64 KB | smokris |
| #16 | role_export-feature-enable-00.diff | 1.64 KB | smokris |
Comments
Comment #1
Steven Brown commentedThank you for the port patch I will review it this weekend.
Comment #2
Steven Brown commentedI'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 ;)
Comment #3
Steven Brown commentedA 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 ;)
Comment #4
Steven Brown commentedI'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.
Comment #5
smokrisThanks. 6.x-1.x-dev is working for me so far.
Comment #6
smokrisCorrection: 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.
Comment #7
Steven Brown commentedRight 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.
Comment #8
Steven Brown commentedLooks 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
Comment #9
Steven Brown commentedA 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.
Comment #10
Steven Brown commentedSmokris, 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.
Comment #11
Steven Brown commentedNeither Klausi or I have interest in creating the D6 version. So until more help or volunteers are available I am postponing this port.
Comment #12
jarodms commentedI 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.
Comment #13
Steven Brown commentedI 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.
Comment #14
smokris@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:
In Drupal 6:
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.
Comment #15
smokrisOK, 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).
Comment #16
smokrisOne 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.
Comment #17
smokrisHere's what I see as the checklist for releasing a "stable" version of role_export-6.x-1.x:
@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.)
Comment #18
smokrisHere'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.
Comment #19
smokris#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.
Comment #20
smokrisFixed db_query() when reverting.
Comment #21
Steven Brown commentedYou 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
Comment #22
klausiDo we really want hook_init()? This is really a performance issues, as it is called on literally every page request.
Do we need that cache? We have removed to role cache in the 7.x branch, as this function is not called that often.
Why can't you use drupal_write_record() here?
should be "Implements"
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 :-)
Comment #23
smokrisI'm thinking that the following triggers would be sufficient:
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.
OK, I removed it.
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).Changed.
Revised patch attached, now with a (passing) SimpleTest.
Comment #24
klausiI 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).
Comment #25
smokrisThanks, @klausi and @FatGuyLaughing!
I've committed the patch in #23, and tagged a 6.x-1.0 release.