I am on an extended world trip, so co-maintainers to help out are wanted. The issue queue is quiet, but no upgrade path to Drupal 7 has been started yet. If no response to a request is given after a few weeks, guide the web masters here to confirm the request.

The module has moderate usage, so experienced module developers only.

Comments

EugenMayer’s picture

EugenMayer CreditAttribution: EugenMayer commented

Well i really like this module and the approach and also using it several times. Iam not sure i find time to maintain a other module, but currently i would like to learn more about CCK deeper API and thats what this module does.

What do you think Alan?

Alan D.’s picture

Alan D. CreditAttribution: Alan D. commented

I'd be happy if you would like. Deciphered has suggested that he would give the interface a major overhaul, but I haven't heard anything back since the original comment. This refactoring would be done via the FAPI mainly as the actual CCK integration is fairly trivial now, believe it or not.

Apart from this, the next big thing is the port to Drupal 7. It may be possible to use the data field again, but there is a push for a better approach. The Drupal 7 field system can not handle dynamic schama changes, which is a shame (well, it can handle new or larger fields, but not deletion or smaller fields once there is data). But since there is a much better hook system, an independent saving mechanism on top of Fields may be the best way forward, like an ImageField Extended bundle or something. This will require a good study of the Fields system before deciding on the best approach. The maintainers of Drupal are really starting to put the brakes on API changes in Drupal 7, so this port will be on the cards soon.

The two main tasks forward are fairly big ones, but a code clean-up and normalization of the key naming scheme / update script for this could be a good place to start (these are serialized values, so this could be painful). There isn't a real road map forward at this stage. Feel free to suggest other things, but I would hate to see a lot of new features added before this.

I will be working remotely in Mexico for my old job for another month, maybe two, so I will be online frequently to assist if needed, but then I'm back to traveling and will probably be out of contact range for large periods at a time as we hit Central and South America. I'm really doing a big push on my name module at the moment, a Drupal 7 port, albeit a fortnight since the CCK Fullname finally made it to Drupal 6, and the maintainer changed the way that the module worked so that the two are now equivalent. I am trying to resolve this on the side.

Let me know how you feel about things after you have a look, and we can move forward.

Cheers

Alan

EugenMayer’s picture

EugenMayer CreditAttribution: EugenMayer commented

Well it would be plain unfair to state i could help with those big task, my limitted time will simply not allow this, eventough like every single topic you talked about is interesting for me.

Esp. because of the general approach and the attempt to make it "wide useable".

I honestly think all i probably could do is helping fixing things, rather not writing new code or even rewrite (like fixing the bug that imagefield_extended does not work with video).

Iam probably not the best guy for the co-mo i guess, you probably search someone with more time.
--

I think the module will get completely rewritten to catch up with D7 newest fields API, there wont be too much share. In my content_moderation iam currently preparing a D7 port and it seems like the only way to port to D7 without forking the whole module is OOP.
- Create a DB communication classes which actually does all the queries for you (not a DAL, but simply a wrapper). You will override this class for D7.
- create a class for the whole module ( pretty much effort ) which gets called by the hooks (hooks are like wrappers here) (most probably using singleton or global)

That way you can override methods which differ. try to seperate all methods in really small chunks, esp. if you expect something to be changed for D7 later. This way you can share the maximum ammount of code and have a good maintainability for both D6 and D7.

All my recent modules are using an OOP appraoch with using Drupal`s API as a wrapper. This works pretty good and is very extendable later.

Alan D.’s picture

Alan D. CreditAttribution: Alan D. commented

Please do not think that I wouldn't accept help. I would not mind a nearly silent co-maintainer, especially if it results in some bug fixes :)

Even thoughts about the best path forward / ideas will be appreciated!

nicholas.alipaz’s picture

nicholas.alipaz CreditAttribution: nicholas.alipaz commented

I guess I would be willing to help out as time permits. I am fairly busy but just supplied you a patch in another issue. Feel free to add me if you like and I will keep an eye out for the issue queue as well as entertaining the potential of a D7 upgrade path.

Alan D.’s picture

Alan D. CreditAttribution: Alan D. commented

Hi Nicholas, any help would be fantastic! I've added you to the project with full permissions. From memory, I'm using the branch rather than head to work from, but I'm not certain on this.

Cheers, Alan

nicholas.alipaz’s picture

nicholas.alipaz CreditAttribution: nicholas.alipaz commented

Thanks Alan, I will have a look later today. I am out and about right now.

Alan D.’s picture

Alan D. CreditAttribution: Alan D. commented
Status: Active » Closed (fixed)

There are no more plans for developing this on Drupal 6.x and the module is obsolete on Drupal 7.x. As such I'm closing the existing non-bug related issues. Reopen of you want to take over and develop this further.