By davidm on

Hi all,

I'm working with a client who has tens of thousands of records for import for one of about a dozen data types. Each of these records might have dozens of associated records. This is a non profit client and they want to have a mainstream, public facing CMS that isn't a support or dependency nightmare going forward, so we've settled on Drupal and I had hoped to use CCK, so I can avoid creating custom modules. We'd also like to support community proposed versions of content, with versioning.

Does anyone have experience using CCK under these conditions? I understand that CCK is not considered "done" and may change, and that its performance is highly dependant on how data is designed and usage patterns, but before we go ahead with the import I'd like to hear any comments on this plan.

Regards,

David

⋅ Categories: Drupal 4.7.x

Comments

snelson’s picture

snelson commented

If you want to avoid those "nightmare" scenarios altogether, you should probably go with custom node modules. It really doesn't take that long to code a custom node module (can be done in as little as a couple of minutes), and this way, you will have full control over the content. Its more likely that you might spend an hour or two on your custom node, as most custom nodes will probably require additional data and is own database table complete with CRUD operations in the module, but worth the extra time in the long run.

Correct me if I'm wrong, but I think even JonBob himself, creator of CCK and the earlier Flexinode, mentioned in this Lullabot podcast that he has neither used flexinode nor CCK on any of his live projects. I think that these modules are geared towards scenarios when there is not a developer at hand, or new node types will need to be created often.

This is just my opinion ... you should definitely wait to hear from more people on this.

Module Builder will provide you with a template for your new nodes if you want to speed up the process a little.

Good luck!

davidm’s picture

davidm commented

Hi Scott,

My thought was to avoid some of the dependant (on me) maintenance so the client can be self sustaining (they do have their own tech, just not development). For example, if a security or bug fix comes along, it may require changing a custom module, whereas with a "standard" module there will be a patch the client can run themselves. This is even more extreme for new versions of Drupal. However, since CCK isn't even officially released and there's a lot of uncertainty about it, I've been having second thoughts.

I have developed custom modules in the past, and the modules have to be hand edited every time there's a new release.

More opinions & discussion welcome! I think a lot of people could be in this boat.

David

snelson’s picture

snelson commented

Scary thought, leaving an update up to a client. If it ends up breaking a bunch of things they come to you to cleanup, and you are left to figure out what happened, while a frantic client wants their site back up immediately.

I could imagine this scenario:
Three months from project launch, client gets a security update email from Drupal. So, they attempt to patch the site, and they accidently overwrite the files directory or the sites directory with the default, bringing their whole site down and losing all their uploads / modules / config etc. Or, they see that there is a new CCK and try to upgrade but there is a major schema change which breaks a lot of things. You, are onto the next project and working under a tight deadline with little time to spare when you get the call from the frantic client in need of your emergency services. Sounds like a nightmare to me.

Personally, I would rather set up an upgrade schedule where I spend a few hours every few months doing upgrades and security patches for the client, first on a testing server and then live, backing up all data first of course. I don't see anything wrong with maintenance. It's a nice source of residual income, and allows you to keep in touch with your client, who may need additional development services down the line. If you have to change some lines of code on your modules, well, at least you're getting paid to maintain some functionality that you can reuse in the future. Plus, I don't think we will see anything as major as Forms API on upcoming new releases. I think core has learned from the 8 month release delay of 4.7 that such a drastic change is not the best idea, even though in this case it was well worth the wait.

Again, just my opinion.

snelson’s picture

snelson commented

Plus, I don't think we will see anything as major as Forms API on upcoming new releases.

I wanted to correct myself before I started getting barked at. Obviously, we will see major improvments in new releases. I'm just saying this kind of major change will likely span over multiple releases and will likely be executed with more emphasis on backwards compatibility.

davidm’s picture

davidm commented

and I've done things that way in the past, but in this case, I want to make the solution as much "off the shelf" as possible for various reasons so was hoping CCK would be the solution, but am starting to doubt it.

snelson’s picture

snelson commented

Why don't you send a message to JonBob and see if he can guide you?

davidm’s picture

davidm commented

that's a great suggestion, I sent JonBob a note and hope he replies. :)

sepeck’s picture

sepeck commented

While not addressing your issue, I would strongly suggest you look at the CivicCRM module which is designed for contact managements with an eye towards non-profits.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide