As far as I can tell (and I seriously worked on them very recently), current releases of the mentioned CCK file fields (filefield, imagefield, imagecache, and mediafield) are nice, and the future without doubt, but not yet ready for mass consumption.

It may only be a small effort missing for them to be great (and, in this respect, I hope dopry and quicksketch apply my patches soon), but at the moment they suffer from database inconsistencies (leftover entries, no entry in the {file_revisions} table), no support for node revisions, not-working private downloads, and a few annoying bugs (files don't upload, images don't get resized, octet-stream download starts) when used together with other modules.

So, we might be getting there, maybe in two or three months already, but those fields are not quite there yet. Soon. (Let's hope dopry finds a bit more time.)

Nice job, excellent cast.... I stayed till the end, but that may be cause I've got the flu. Not upset but.... a couple of things to ponder.

A properly used taxonomy should span content types, work for a movie, and audio snippet ,etc. Given the future of key word media keyword tagging, I don't see this module dissapearing any time soon. I agree people (including myself) have used taxonmy to track attributes of a particular content type. Cause I didn't have views (and cause flexidnode wouldn't coexist with ckk.

Node access is the only value based security we have in drupal that I'm aware of. (not field based, but value based). In the example you used you'd have to give the user access to all of the original pictures resolution. Combinations between value based and field based and security seem expensive. Why not instead think of it as anode access module that implements security in terms of the existence of another related content type (e.g. an order content tpe.) You might even be able to write a node_access module today that does this. I agree the way forward involves making node_acess useful for more than crud, but action based security. (e.g. publish a node).

Finally rather than making everything a node, maybe the views module and ckk need to combine with the data API, such that creating leveraging ckk and views for orther table structures just meant creating a table of the right type, and calling the views and ckk apis telling it which table the field data landed in. That lets nodeId and relational constructs apply without the overhead of ckk. But ckk still gets used to store all of the static attributes of an object. Heady, but your podcast made me think.... a dangerous thing at best.

Nice flashing! I'm sure it was worth the effort.

In the podcast Angie discussed something like an outline module and features that Plone has for organizing a site hierarchy.

I use the Category module for that purpose. What it does for me is allow me to create containers, hidden containers, and categories (different node types can be categories). The power of this for me is that Menu entries are created automatically (if I choose), and bread crumbs are maintained. I use the views insert module on my Container pages instead of the views feature of Category module.

I keep hearing how CCK and Views is nirvana, but how does CCK allow one to maintain proper bread crumbs and automatically populate the menu? I would love to hear this discussed on a podcast.

I'll keep using Category module.

BTW, thanks for the this great forum. I never miss it.

Rich

I had an adverse reaction to most of what was discussed on the Podcast, as it seems that everything I've already implemented in my simple personal site is already being deprecated — but these are the features I chose Drupal for in the first place. That's why I thought it was important that Jeff brought up the topic of individual users who just want to create a blog … Drupal lets me do a blog plus.

I think as we as a community discuss these features and set direction for them, we have to understand what made the older features valuable in the first place.

For taxonomy, I'm glad it spans content types. I'm glad it's global. I'm glad I can edit it standalone, without having to go to each node to make changes or additions. I'm glad it's hierarchical. I also am very very very happy — and this point should not be lost — that it works with BlogAPI.

I just started my first book, literally the night before I listened to the Podcast. Books are one reason I was interested in Drupal, I finally created one, and now I'm being told that they might be deprecated. Urgh!

For event, although I don't use it currently, it seems like we really need a content type that mirrors the iCalendar format. There is a reason why everything has a start and end time, for example — events and time and calendaring and so on are a complicated human construct, when you get down to time zones and daylight saving time and atomic clocks — what I'd like to see are user interfaces for quickly creating certain kinds of events so that you don't always have to go through the mental hurdle of specifying a start and end for, say, an all-day event. Desktop calendar apps have gotten over this hurdle long ago, why can't Web apps?

Overall, my take on this Podcast was that it was the first one in a long time that made my head hurt. I don't want to develop with Drupal, I just want to use it. Publish with it. I'm willing to let others do the development and make hard choices, but don't lose what makes the software great now.

As it is, for an individual running his or her own site, Drupal is very hard to keep up with. My biggest problems are keeping up with modules and updates and migrating from one version to another. Modules I want to use may never even make it to Drupal 5.1 — I'm on 4.7 — and that's exceedingly frustrating. It seems like we could begin making some hard choices to prevent the whole system from being quicksand for module developers and especially for module users.

This has got to get simpler for noobs to get into, and there has to be an easy migration path from the deprecated to the new. It feels like more commercial vendors than open source projects realize this.

I speak as an interested party, but I'm rather happy with the way that profile.module stores data in the database. I'm the author of site_user_list.module, which is a module for moderate sites (say, < 1000 users), which provides a directory of users (searchable and sortable), displaying data from their profile. For my sites (both of them), this is a major feature that we need.

Because of the way that profile.module stores data, I can make a database view (not to be confused with a views.module view) which is always up-to-date with the data from the profile. Because I'm letting the database do the hard work, it's _much_ faster than trying to user_load every user at the site to get this information. Yes there are some weird edges (if the data stored in the profile field is serialized, well, things don't really work). But it does the job.

Last year (mid-2006), I looked into making a CCK plug-in. From what I recall of that, it would be much harder to extract the data from a CCK-type bio node as an SQL query that could be turned into a CREATE VIEW statement...

in the end, what would you recommend ?

podcast and comments seem to agree that core profile module is deprecated.

however, what solution do you recommend ?

i would have used cck in this general tendency to avoid using any content type implemented as a module.

however jeff mentioned bio module and robert mentioned nodeprofile.

Great podcast.

Less modules that do more (and that are preferably in core) seems to me the perfect solution for the big problem of updating contributed modules.

Just now when I feel that the many very interesting contributed modules are finally upgraded to be compatible with Drupal 5, there will soon be a Drupal 6...
If there is half a year between two main versions of Drupal core, but on the other hand it takes also half a year for the contributed modules to upgrade to be compatible with the new release of Drupal core there is a problem.
If you are using a lot of contributed modules, you always have to choose for the previous Drupal version, which doesn't feel right.

Maybe there should be some kind of voting option for the modules on drupal.org so the most interesting/used ones float on top.

And hopefully contributors will still have the same spirit when they would have to cooperate on a larger module rather than having their own little baby.

I'm rather frustrated because mediafield doesn't seem to be working for me and I would like to use the latest future-looking modules but if they don't work, then I am forced to use the less-desirable video module that is deprecated. I have a support request posted on mediafield, btw. I am not yet at the level that I can easily debug someone else's module, although I am busy reading the Pro Drupal book.

I am curious whether the flashvideo module would also be considered deprecated. I know it does have a non-standard install and requires a host that provide the FFMPEG service. It also supposedly works as a CCK field, so that might indicate that it is future-looking and therefore not deprecated or in imminent danger of being D'd.

(my homepage is not YET a drupal site. I am currently developing a drupal site that will be using video very extensively for education and social networking)

Taxonomy is - of course - not deprecated!

I dont like the way the category module is doin it, I think this is a crappy trend. Okay, it has some interesting effects, but the whole concept - to handle categories as nodes - is not a beautiful way. It confuses a lot more than the word "taxonomy".

Count me as one of the newer users to Drupal who isn't convinced that deprecating other, fully usable modules with CCK is such a great idea.

To me, it strikes me as trying to build sites out of lego blocks when there are nice specific metal parts in place that have been tooled directly to fit a purpose. For a lego enthusiast, it's very easy to get into the mindset that everything should be lego. The other parts seem so rigid. But you cannot build a well-oiled machine out of lego.

I'm mostly concerned that applying CCK as the solution to everything could lead to a great deal of backend bloat. Considering how Drupal for many is used in shared hosting situations, the SQL side of things especially could get very taxing. Drupal already IMO makes an absurd amount of queries per page and it seems the trend for the future is more, not less.

I agree with Robert but on the multilingual sites when you are need to make you shre when you are need to have the exact translation.
When you need to made breadcrumbs or "taxonomy" classification visual you need to know what term you are translate. Is not the same when you are translate words thanwhen you translate terms in a specific location on the page.
I'm say taxonomy is not deprecated because the object is diferent than CCK, but if CCK add that distinction is great. In other thougth I think is great for programmers but not for the content user, always we need to think on the people who will use what are not programmers. This last comment is because the great of DRupaL I think is what we programers do to have a simple CMS to maintaine.