Advanced Forum and Advanced Profile Kit integration

I don't think we need this to be in Userpoints itself.

We are moving this module to be an API, and pushing module-specific integration outside of it.

We plan to take out the rest of stuff (userpoints_basic, workflow-ng, ...etc.)

So, either you add it as a separate module in its own project, or have it as a submodule in userpoints_contrib. Or more simply, why don't you add them into the respective module, with a if (function_exists('userpoints_blah')) ?

I want to mark this as won't fix, but will wait for jredding's input and possible further notes from Michelle too.

Michelle,

The attached file is a hook_ so it can be implemented in just about any module. Please correct me if I'm wrong in my assumption it sounds as if
1) There are lots of module that can provide hooks into advanced forum
2) you would rather people hook into your module instead of you hooking into them, as its a more sustainable model for your module. You can't possibly anticipate all the various items need to be put into a forum or profile.

If that's true then its the same model as userpoints ;) so we would rather you hook into us than the other way around. I say we settle it in a wrestling match. How about at Drupalcon D.C! ;) ha ha..

OK down to business. I had a vision to separate out UI elements from the core API and this might fall in perfectly. its a small piece of code and most likely won't get that much bigger. So we can make this a part of the UI module and leave it out of the core module. This is particularly nice since the same hook works for both advanced forum and advanced profile.

or in less words... we'll figure out what to do with it.

Can we still wrestle at Drupalcon?

Thanks for the followup, I think there is some mutual benefit here so we'll come up with a plan.

What if there were daycare/nursery options at Drupalcon? Maybe there are other like you and we can pools things together? Not to drag on this thread just want to get more peeps out by breaking down possible barriers.

If has not be done yet as I'm still working on getting 6 out into stable. Give me until this weekend and then ping me.

Michelle

I still don't see why this should be part of userpoints. We are trying to cut away integration pieces into their own modules. So userpoints basic will be spun off on its own, and so will the rest of the modules. The API will just be an API.

So, the logical place for them would be in a directory under your project, called userpoints, with a README.txt with instructions on how to use them.

eh, its only a hook. At the very least we can include it as part of the contrib modules, since people generally get both packages anyhow.

That is what I meant. Provide the integration as a separate module, or as part of your own project.

See examples in userpoints_contrib. Yours can be one of those, or can be a separate project that depends on both AF and UP.

Saying we don't want it in the API does not mean we don't want it ever. It just says it is not part of the API, and can be elsewhere.

Michelle

Please understand that we are trying remove stuff from the Userpoints module and evolve it into an API only.

This applies to your module and others too, and it is taking time.

Your module's integration with userpoints can

1. Live in the http://drupal.org/project/userpoints_contrib set of modules,
2. Be its own integration module (see the Other modules section on that last link), or
3. Live with the original module.

Those are your options, pick any of them. It is not hard ...

I don't see why you would not create a module that has a dependency on yours and on userpoints and include it in a contrib directory with your project.

This way the module could not be enabled without userpoints being enabled, and you keep updating it as/when you wish.

Voting API integrations works that way, in a module that is separate from either userpoints or voting API. Other modules do the same.

But, you seem to have made up your mind, so whatever works best for you.

I can't talk for other modules.

But the same argument you have made from your project's point of view can be made the other way : are we supposed to include modules/includes for everything that needs userpoints integration?

Initially, we did that, all in the contrib directory with a directory for each module. Then we found that as people contributed stuff and went missing in action, we were left with code that we did not write and cannot keep up with and maintain in the long term with only a couple of active maintainers.

So we started splitting stuff off in userpoints_contrib. We are taking that further in the future by splitting off Userpoints Basic, Workflow/Rules integration and the rest of the stuff. Others have taken the correct path by creating projects for their integration.

Views did this with splitting the "bonus pack" modules into their own modules. We will do this with Rules/Basic and the rest of the non-API. Voting API does not include any voting applications and leaves that to other projects like vote up/down, five star, ...etc.

This is what I encourage you to do: either create a new project for integrating with each module or one "integration pack" project with all of them. If it is too much work (and it probably is for a one person maintainer team), then try to find if some of those who like your module and want to integrate it with other modules rather than you ending up with "owning" everything and having to take it forward through release and API changes.