integrate with ctools exportable api

dk129,

Thanks so much for your work. I'm thrilled that you've added this feature- it's something that I've been meaning to do.

However, it looks like the patch that you've attached was not rolled against 7.x-1.x-dev from the git repository. It failed 2 out of 3 hunks.

I'm granting you commit access to the repo so that you can apply your changes directly.

I've re-rolled dk129's patch from #1 against the 7.x-1.x branch. Seems to mostly work for me, except for a weird bug which I believe is a quirk with my local setup, where profile2_regpath settings don't get properly *reverted* (ie. from a features module, either on first being enabled, or --force reverted via drush).

Anyone interested in testing this new version of the patch to confirm it works as it should, and maybe we can get this committed?

This patch still needs a lot of work.

• dd() left in code
• Some aspects of module disabled, e.g.,
  

  # Not sure how to handle this..
  #  if ($groupby) {
  #    $query->groupBy($groupby);
  #  }

• No hook_update_n() added to accommodate schema change in install file
• Modifications to profile2_regpath_get_profiles() do not seem very well optimized. The function has been changed to always load all profile types, and then walk through the result to filter out rows. It doesn't seem like any of the new functions even use profile2_regpath_get_profiles(), so I'm not sure why it has been changed.
• Maybe this patch is missing a file or has undocumented hooks? I see no ctools hook or ctools plugin files in the patch.

Is there no reason to store this information in simple variables? The data is just a flat array with no real relationships.

Added db schema migration and removed dd().

change status for test

Applicable patch for current 1.x-dev.
Fix a small typo.

Add ctools as a dependency.

Make the patch compatible with features module.

I don't know how to store the roles in profile2_regpath table, 3 choices:
1. serialize(array($rid => $rid));
2. serialize(array($rid => $role_name));
This is what I am using in this patch. (Note: I store only enabled roles).
3. serialize(array($role_name));
I think this is best for exporting to feature. (Note: Only store enabled roles)

I don't know how to test rebuild a feature.

Another thing is: I can't revert profile type (an entity type provided by profile2 module) using feature.

Sorry for my English :)

Fix minor bug.

Remove trailing whitespaces.

I applied the patch in #16 to 7.x-1.x-dev. The is an entry for p2 regpath, but the label is missing. See screen grab.

Correct hook_update_n. Please try again.

I applied the patch in 18 to a clean version of 7.x-1.x-dev, which applied successfully. However, now when I go to features, I do not see an option for profile2 regpath.

Thanks for your testing. Fixed no options in features page. Please try again. Don't forget to run database update scripts.

Fix error: Field 'profile_id' doesn't have a default value.

I am happy to report that testing of the patch in #21 seems to work perfectly for me. I was able to add a profile2_regpath item to my feature, export it, have it take effect when enabling the feature, and change/revert it through the features mechanism (adjusting the url path).

As such, I think this patch is ready to be committed, and I will incorporate it into the project I used this for originally.

Re-rolling patch.

Thanks to everyone who's been working on this.

I'm looking to commit it ASAP. However, after some preliminary testing, I've found that this patch breaks the 'role assignment' functionality.

K, figured out the issue and fixed. Patch has been committed to 7.x-1.x. Next up, port to 7.x-2.x?

Ack, just realized that the changes prevent multiple profiles from being attached to a single path, which is a major regression. Might have been too hasty with accepting the patch. Dev branch is a bit FUBAR at the moment.

After more refactoring, this patch has been applied to both 7.x-1.x and 7.x-2.x. Please test functionality to confirm.

I just did a drush up and did not see any updates for this module. That is probably because I am using 7.x-1.12+10-dev. Are all of the changes from 7.x-1.12+10-dev in the 7.x-1.x branch now? Is it just for dev or the recommended version?

Additionally, if I go to 7.x-2.x, does any existing functionality fundamentally change or is just new features?

@madmatter23: I've tested from a clone of the latest 7.x-1.x branch, and your newest commits appear to have achieved the goal here effectively. As with the patch above, I can update/revert a feature incorporating profile2_regpath settings, and have them take effect whether the change happens through the web interface or adjusting the features code directly. Hooray!

@RobKoberg Please pull from git repo branch 7.x-1.x.

@spiderman thanks!

I updated do the dev version today so that Features would remember my unique registration path as well as the default role for that profile. It did remember the settings but when I logged out and went to the registration url I got the WSOD.

Is this working?
Im not getting any regpath settings in my Feature.

Tried with the beta version also
thanks

This is not work, profile2_regpath_features_revert() function delete all profile2_regpath settings in database.

I'm reading through the thread and it looked like this patch was good to go, but is actually not quite there yet? I think this status should be set to "needs" review instead of "needs work" because the latest patch hasn't passed the simple test, but maybe that patch isn't finished?

Okay, go to testing! :)

Patch from #35, helped. I used it in a custom install profile, and everything works well...

Shoot! I was going to test this then I realized I'm using version 7.x-1.12 and this is against version 2 dev. I'll have to come back to testing it when I have time to get the dev version of 2 installed. :-(

This patch seems to work well, however upgrading from 1.12 to 2.0-dev caused new errors to popup (such as the title of the unique page not changing and other db issues) so I'm not sure that I want to trade one fix for a potentially buggy dev version :-(

The patch itself looks decent though! Now to decide if upgrading to 2.0-dev is worth the risk or not.

I installed version 7.x-2.0-beta3+12-dev, and added profile2_regpath feature components to a feature module. When enabling the module in a different environment, the settings did not stick. In addition, the install profile would error out because there was no value for profile id. Applying patch #35 solved those issues.

I have been having lots of success with #35 as well over quite a few of the past few features and ctools versions. It works well, and so far, the only issue reported over a year seems to be with upgrading from 1.x, which might not have been related to the patch.

I'm using the release Profile2 Registration Path module (version 7.x-1.12) and have recreated patch #23 so the profile2_regpath ctools exportable patch can be applied to it.

The patch is working great so far.

It is not working for me (7.x-2.0-beta3+14-dev).
The profiles still show up as "Overridden" after "drush fu" on the respective feature.
And after a "drush fr" on the destination site, the " Enable this profile on a registration form" checkbox is unchecked, and a lot of the settings are wiped.

I am having the same issue as mentioned in #49.
On Feature Revert the "Enable this profile on a registration form" becomes unchecked and disables the functionality.

My patch in #48 can't be applied to the updated module version 7.x-1.13. I'm attaching a new patch for the updated module (i.e. recreating patch #48 which was already a recreation of patch #23).

Patch in #51 worked for me also for version 7.x-1.13, but did not assign roles, therefore attached a patch to realize it.

New patch for version 7.x-1.13