I was look at extending password policy, and also making it work with features. And it seem like a heavy lift so I thought i would take a shot a writing it.
the current code is in http://drupal.org/sandbox/e2thex/1380342

The basic idea was to make the policy a ctool exportable (this got use a user interface for it as well as features integration) and to make the constraints and conditions, ctool plugins.

I think this will reduces the amount of code that is need to run the module and in general brings it up to more modern drupal standards.

The proposed still has lots of holes but I think that it is complete enough for someone to look at it.

I would love if it could turn in to the 2.0 version of password policy, but if it seems like this is not the direction that you all want to go in, please let me know.

Comments

erikwebb’s picture

erikwebb commented
Assigned: Unassigned » deekayen
Priority: Normal » Major
Status: Active » Needs work

I'm usually not a fan of introducing a dependency on CTools to this level, but I think you're right in this case that a plugin architecture makes a lot of sense here.

+1 from me, but I want to get a 2nd maintainer to agree. Then we can open up a 7.x-2.x branch and get started!

deekayen’s picture

deekayen commented

I won't be writing any such functionality myself and I should hope that at least e2thex has a need to have so many policies that adding features and ctools actually makes sense. I don't want to add all that junk just because everyone else is doing it. I won't stand in the way.

e2thex, how many policies are you needing to maintain to make you want to put in this effort?

erikwebb’s picture

erikwebb commented
Assigned: deekayen » Unassigned

I think I ultimately agree. I haven't done a ton with CTools plugins, so I'm not educated enough to really know the implications other than adding a new dependency. Is there a middle ground - could we support CTools plugins as constraints while still keeping the current simple constraint model? I'm not sure how much work it is to support CTools plugins. I'd be much more comfortable with a soft dependency like this.

e2thex’s picture

e2thex commented

The ctools dependency comes from exportables (it give the whole admin interface, menu hooks and all) so using the plugins was just a plus.

Ctools really is handy for plugins, and I think it is one of those things where one ends up writing a lot of the same code when making modules that are going to be extendable (at least i did before i found ctools)

We are not adding a lot of new plugins, over what is available in the current version (I think only two).

I think we could change and not use ctool plugins but, we get a good amount of code with it that does not then have to be maintained in password_policy.

It is worth noting that with both export and plugins there is very little code overhead, as the code is only loaded when used.

erikwebb’s picture

erikwebb commented

I'm starting to agree with e2thex. With CTools now a requirement for any D7 site using Views, I don't think we're creating any sort of additional dependency. Also with the likely move in D8 to plugins, I think this may be our chance to get ahead of the curve as well. I think I'm comfortable moving in this direction. As much as I'd like to make CTools a soft dependency, it wouldn't make much sense to maintain two entirely separate sets of code for the UI and plugin architecture.

Once we have a stable 7.x-1.0 release (#1387588: Create stable 7.x-1.0 release), I'll open a 7.x-2.x branch and we can start coming up with a new feature list.

e2thex’s picture

e2thex commented

So I am going to need to have a non sandbox for this in the next few days, Do you think we could make a 2.0 branch?

erikwebb’s picture

erikwebb commented

Is there any particular benefit to using CTools for this integration rather than Entity API? I'm just wondering as an Entity API Implementation may make more sense with the redesign of this module.

e2thex’s picture

e2thex commented

I think of using Entities for data that is content, and I think that password policy stuff is configuration. While there is always a grey line between the two, I think that password policies clear fall in to the kind of data that I would want to export to code, and deploy. As opposed to data which i expect to change are create new.

I think that the Entity API is great for data, but not as good for configuration.

And with the D8 config initiative, I would see PP moving to that data store, in D8 not to entities.

erikwebb’s picture

erikwebb commented

That's fair, but I think that rewriting the policies in a more OO pattern (as I'd like to do for 7.x-2.x) fits well enough into the Entity API model that we would be recreating too much by adding our own structure. Then Entity API gives us the easy ability to also do exporting by nature of making this design decision.

erikwebb’s picture

erikwebb commented
Status: Needs work » Postponed

For temporary organization, I'm marking as "postponed" and we'll re-open when 7.x-2.x is opened.

erikwebb’s picture

erikwebb commented
Version: 7.x-1.x-dev » 7.x-2.x-dev
erikwebb’s picture

erikwebb commented
Status: Postponed » Active
e2thex’s picture

e2thex commented

here is my sandbox http://drupal.org/sandbox/e2thex/1380342 that might be a good starting point for 7.x-2.x

febbraro’s picture

febbraro commented

Any progress on this?

erikwebb’s picture

erikwebb commented

No, I haven't had a chance to get to this one (forgot for a while to be honest).

At first, there are a lot of stylistic things I'd like to change from the current version, but it's overall the structure I was thinking. Because of the size of this move, does it make more sense to move in these pieces one-by-one? It seems too easy to miss something if we just pull in as is (the old version of this module has so much cruft that I'd like to avoid that as much as possible going forward). Honestly looking for feedback on this one, never had to deal with a complete rewrite before.

e2thex’s picture

e2thex commented

Erikwebb,

Well we have a working module (in the sandbox) I think it would be reasonable to pull it in as 7.x-2.x and then set some feature goals for it that would make it be a replacement for 1.x. There might be possibilties for pulling in chunks of code from 1.x, but in general I think we would just be pulling in consepts.

The sandbox is getting quite a bit of use, I would like to get it out of sandbox to get more eyes on it, sooner rather then later.

Maybe along with the list of feature that need to be reproduced we could start making test. That would be another good way to insure that we do not miss something.

Finally requiring a conversion of old data to the new system should also help insure that there is good coverate of ideas from the 1.x version.

e2thex

e2thex’s picture

e2thex commented

Erik Webb,
I am on irc as e2thex, almost always in the #drupal-apps room if you want to chat.

erikwebb’s picture

erikwebb commented
Status: Active » Fixed

Sorry for the massive delay, I've imported your sandbox as the new 7.x-2.x branch. I'll mark this issue as closed and we'll start working through fixing any issues.

Status: Fixed » Closed (fixed)

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