Finally working on a D6 port

Any update on this?

I second this. I see there's a request for a co-maintainer, I probably don't have the technical chops for that, but I'd be happy to help out with as much bugtesting and bugfixing as I can!

No update! Will have to look at an alternative. Any suggestions?

The multigroup module, a sub-module of CCK in development, may replicate some of the features. For instance, one could create fields for prefix, given names, surname, and suffix and group them together as a name "multigroup" which would behave as a single field, but retain the granularity of its components for use views, searches, and the like. See http://drupal.org/node/119102 .

Would it copy over (i.e. update the db) for any existing content, or would that have to be done manually?

No, it is a completely separate project and someone would need to build an import mechanism, or the tables would have to be manipulated manually. The project is still unstable, so I wouldn't rely on it yet whether for new site or an upgrade, but threw it out as something to watch for those looking for this kind of functionality.

Hi Choster,

Thanks for that. I wont bother writing any import code, there is not that much so will probably be quicker just to re-do those few bits.

Cheers,
Nick

I used Deadwood to update this module. There were a number of places where the Fullname has a message that a field is required that Deadwood swapped out with commands that caused errors, but I got them ironed out so that the module could load. However, the moment I tried adding a FullName field to my content type, I got a slew of MySQL errors, the first of which was:

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'NOT NULL DEFAULT '''', `field_bkauthor_first` NOT NULL DEFAULT '''', `field_b' at line 5 query: CREATE TABLE content_field_bkauthor ( `vid` INT unsigned NOT NULL DEFAULT 0, `nid` INT unsigned NOT NULL DEFAULT 0, `delta` INT unsigned NOT NULL DEFAULT 0, `field_bkauthor_last` NOT NULL DEFAULT '''', `field_bkauthor_first` NOT NULL DEFAULT '''', `field_bkauthor_middle` NOT NULL DEFAULT '''', `field_bkauthor_prefix` NOT NULL DEFAULT '''', `field_bkauthor_suffix` NOT NULL DEFAULT '''', `field_bkauthor_last_preferred` NOT NULL DEFAULT '''', `field_bkauthor_first_preferred` NOT NULL DEFAULT '''', `field_bkauthor_middle_preferred` NOT NULL DEFAULT '''', `field_bkauthor_prefix_preferred` NOT NULL DEFAULT '''', `field_bkauthor_suffix_preferred` NOT NULL DEFAULT '''', PRIMARY KEY (vid, delta), INDEX nid (nid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in /Applications/MAMP/htdocs/includes/database.inc on line 515.

There is obviously a problem with the MySQL, since the table and fields didn't get changed in MySQL. There were more MySQL errors that followed this, but which appeared to stem from this first failing (since you can't alter a table that didn't get made in the first place).

Perhaps someone else can use this file to get a D6 version working...

David

Thanks for the alpha. I have finally been able to begin working with Drupal again, so I am going through and updating my old modules. I'm starting with the cck_address module because the addresses module doesn't meet my needs. 'nuf said. After the cck_address module, I'll be updating this one.

Why not just use the multigroups cck module (included in cck and being patched/improved now)? I am one of the guys working on the new patch, but there's one drawback to using separate fields in a multigroup rather than a multi-field cck field - namely, storage and query load. Separate fields in a multigroup are stored in separate tables. So a first, middle, last name multigroup would take three tables. That also means that you have three queries and Drupal already has high DB loads.

There is talk of patching multigroups again once the latest patches are in, in order to remedy the storage issue, but that probably won't happen until after D7 comes out.

I will go through the issue queue and make sure that any big, and hopefully most or all of the little problems are resolved in the D6 version. I will likely abandon the D5 version.

I would still like to get a co-maintainer that can at least handle small stuff. But I think that if I address the outstanding issues here, that the module will be solid enough to not really need frequent attention.

Sorry it has taken so long.

great to hear about a D6 port - this module is a "critical path" for my transition from D5 to D6 - sure could use it... NOW!

Was looking at Realname mod, but doesn't appear to do the trick - any testing needed for Fullname for D6, count me in.

sunfish62,

In cck_fullname_field_settings() > case 'database columns': change all longtext to text, remove all default elements from string and set all 'not null' to FALSE. That should solve your problem with the database.

@maijs - not a coder - could you supply a patch, or short of that, explain "remove all default elements from string" - what (exactly) do I remove?

Thanks

@maijs - made changes you suggested in #11 - and "removed all default elements" by changing " ' ' " to just " " after each "'default' =>" - hope that's what you meant

Though "module" seems to have been enabled, as field type Fullname shows up ok (see attachment Fullname1) and successfully created 2 fields - one required, one optional (see Fullname2 img) - both in a Content Profile type node and both under a fieldgroup (Basic info, as seen in img), but neither the required field nor the optional is included at EITHER the node edit form, nor at the new user registration (have optional content_profile_registration.module enabled) (see Fullname3 img)

Any clues?

rhimes, I'm sorry, I haven't dug deeply into this module. I used it a template for a custom module I needed to make therefore I have just scratched the surface of Fullname field for CCK and the answer I gave in #11 was just my quick observation which I though could someone give the right direction.

any progress on the D6 port? I would like to take a look at this...

Really, the Deadwood module will be of almost no help in converting this module, since Deadwood has no functionality for converting CCK (or Views) based modules. Almost all conversions being done on this module will have to be done by hand, as there is not only a Drupal 5 to Drupal 6 conversion to be done, but also a CCK 1 to CCK 2 conversion to be done.

Subscribing. If no upgrade is available, I may go with a CCK "field group" module of some sort. But which one will continue to see life into Drupal 7? Always the dilemma!

thought I'd post this heads-up for all concerned here -

a bounty has been offerred to port to D6 - at least my particular portion of fullname (without the preferred relation):

http://drupal.org/node/616192

only need functionality as in the attached D6-hack-cck_fullname.module.text with (all?) "preferred" removed - but a full D6 port is ok too.

attached unhacked ver as well to compare - @ 800 lines less in my ver

any takers?

The current maintainers want to maintain the existing legal / preferred features.

But are you looking for a Drupal 7 version? With Profiles going to be ported to fields, I started on a simple Name module, as every site that we develop would have required it (100+ sites and counting). It is a simple title+name or title+first+middle+surname+credentials combo. Now I am wondering if the overlap is too great with this module, even if every site we would use it on would never use the legal / preferred features found in this module.

If the community does think that the overlap is too great I will transfer the project to the maintainers here if they want it or abandon the Name project if they don't. (They will need a new module name come D7 anyway).

If not, then I could consider a backport to Drupal 6. Sadly the Profile port to fields has not happened, so my personal interest in the project has dropped off significantly - track #301071: New Profile module leveraging fields API and #394720: Migrate profile module data to field API for Drupal 8.

@Alan -

I'm looking for this module (cck_fullname, Fullname field for cck) to be ported (complete as is, or just my "no preferred name" version) to D6.

If the entire module with preferred name gets prted to D6, then I could remove those portions (as I did for D5 use) that I don't want or use for myself.