Features integration not working

Ah, interesting.

I'm not using LDAP for Authentication, only for Authorization. Therefore I don't see an ldap_authentication_conf var that I can strongarm. Is this var needed for Authorization as well?

Ok, well, things are certainly not quite right. I just went with a new install, and I can't get it to work out of the box. I'll dig in a bit, and hopefully have a patch to fix it.

Update:

It seems that the ldap_server isn't getting imported correctly, which causes the authorization to fail. I'm still getting my head around why, but if I create a ldap_server, export it to a feature, delete it, then enable the feature, it shows up immediately as overriden. It then will not revert. This is what's showing up as overridden:

  $ldap_servers_conf->type = 'Normal';
// ^^ This is in the feature
  $ldap_servers_conf->type = 'Default';
// ^^ This is what it's getting translated to

Nothing is being inserted into the DB. I'll keep working on it, any pointers are welcome.

Well, I've made some progress.

1) There should be no references to the string 'features' in the core module files. Doing so makes it so that upon installation of ldap_servers, you have a feature listed and it gets into an overridden state the minute you create your own.

2) This one took *FOREVER*: http://drupal.org/node/1094014. After setting $schema['ldap_servers']['export']['export type string'] = 'ctools_storage_type'; in ldap_servers.install, I was able to get rid of the problem where it was showing up overridden all the time.

So now, everything looks like it's okay, only I don't have a server defined after I visit the configuration page. I've got a few more things to try, but if you don't hear back from me today, I didn't discover anything more.

One more update. Implementing the changes in #7, here's some reproducible steps:
1) Implement changes in #7 above
2) Create a new ldap_server
3) Create a feature containing the ldap server defined in 2), and strongarm'ing the ldap_* vars
4) Install and enable the feature. Note that it says the feature is in a Default state. This is good.
5) Go to the ldap server admin page, and change something, e.g. disable the server
6) Revisit the features page, note that it's overridden. Download and install the diff module, and you can see that it's detecting the right change as well. This is good.
7) Go back to the configuration for the ldap server, and completely delete it.
8) In the features admin panel, note that the feature is in default state. This is good - this means that there is no object in the DB, and the file is taking over.
9) The problem is that both the admin UI and the ldap_servers module don't fall back to looking into the ctools exportable file if what it finds isn't in the db.

The remaining problem is in the module itself. You need to modify the loader of LDAP server objects so that it calls ctools_export_load_object() as shown by example at http://www.sthlmconnection.se/tips-and-tweaks/exportable-configuration-c....

If you don't have time tonight, I can whip up a patch for review tomorrow. Bumping this over to a bug report as there's code that will need to be changed.

Wow. Talk about a rabbit hole.

I've tested this with and without ctools/features, and I get the desired effects using both paths. I had to refactor a lot of code, so in the interest of letting you know where I'm at, I'm posting what I've got this far. Note that I've only really fixed ldap_servers.

Note that ldap_authorization and ctools is confirmed broken, and I'm assuming ldap_authentication is as well. I've just hit my limit of coding for the day.

Items of note:

-ctools isn't required -- the module behaves the same as it ever did without it
-when ctools(or features) is providing an exportable, and it's been overridden, the word 'delete' is replaced with 'revert' in the admin UI, much like views does.

To test this patch:
- install ldap_servers, ctools, strongarm, features, and diff
- Setup ldap encryption settings, setup a server using the ui.
- Visit features UI, create one feature that is a strongarm of the ldap_* vars
- Create another feature that is the LDAP Server config
- enable both features
- Note that if you 'revert' the server config, the DB is empty, but you still have a server listed. This is the one provided by the feature. If you change a property in the UI, the features module will detect it, and show you what's different

Phew!

Here it is, in all 603 lines of glory :)

There were no changes needed to ldap_authentication, as it only uses variable_get() and variable_set(), so it's implicitly supported by strongarm+features.

Can $value = $this; be removed and $values = new stdclass(); be used here, or does the $values object need to be an instance of LdapAuthorizationConfAdmin class? I fixed this by just turning it back to an array later in the save method, but I would prefer to not have all these parallel properties floating around (e.g only_ldap_authenticated and onlyApplyToLdapAuthenticated). Someone will dpm the object and start using them I'm sure.

Yes and no :). It doesn't really matter what class $value is an instance of, we just need to copy over the properties of $this that are added by ctools. Unfortunately, there's no sure-fire way to grab just those properties, because there's no API for it. I suppose one way to do it would be to create a new instance of LdapAuthorizationConfAdmin (named say $emtpy), and find all the properties that exist on $this that do not exist on $emtpy and copy those over. I'm really not for sure because I didn't really learn all of the object structure -- just the bits I needed to get ctools working.