Prevent namespace conflicts with other modules

I really don't think this is critical.
'content' is the name of cck's main module, so it is rightfully occupying it's own namespace.
I'm not sure I see how two css files with the same name but in differen folders could conflict ?

It seems to me that the problem is that IMCE used content module's namespace, and it looks like they have corrected it. I see no reason for the 'Content' module not to be able to use its own name in css. We don't use 'cck' anywhere, that is not the name of this module, but it is the name of dozens of other CCK contrib modules, and if we start using 'cck' that could create other name conflicts with those modules. Now that IMCE has renamed its css, the original issue should not be a problem any more.

The only remaining reason for changing the name that 'content' is already used by Drupal as a class and id name, and I can see there could be confusion there. And that might be a valid reason to make a change.

But if we make a change, we should use the right namespace, not 'cck'.

Or change the folder name to 'content', which would make more sense. I don't know why it was ever named 'cck' since 'cck' was never intended to actually be used anywhere. We now have dozens of contrib modules names 'cck_' something or other, I would more worry about namespace conflicts if we suddenly rename all our files to use the 'cck' prefix.

And it sounds to me like it's a bug for a theme to use 'content.css' as a file name. That name does not match the theme's namespace and everyone knows that CCK has been using that name for several years.

So now we're discussing renaming modules and/or paths. That's why this is 'code needs work', I don't know what we want to do with this, it needs to be discussed and decided.

Picking up on my previous thought, we can't change the module names. I tried to do that in another place once and it won't work because there is absolutely no way to make the upgrades work right if you do that. A new module cannot pick up any information about the update state of another module, the update system just won't support it. And our update process is already complicated enough with lots of places to break.

A new module named 'content_fieldgroup' cannot retain database information from a previous but no longer there module named 'fieldgroup', and has no way to realize that enabling the new content_fieldgroup module should not run the install process as usual but should instead run the update process using update status data from the old fieldgroup module. It would be a nightmare to make this work and would take many many hours of testing and debugging, and would probably still be broken.

Changing the path could be done without breaking updates, but would create chaos if people leave the old files in the old location and try to use both new and old files together.

So I think we have to say "what's done is done", the current path and module names must remain as they are. The main way there would ever be namespace conflicts is if someone else creates a module that lives in a path called 'content', and if they do that, shame on them for asking for trouble, knowing that we already have a widely-used module called 'content'.

If we agree that file and path names will remain as they are, then I guess the original patch may be as much as we can do.

@yched, any thoughts?

The upgrade path is already exceedingly fragile and easily broken, we already get dozens and dozens of upgrade problem issues. Adding this kind of complication to it would practically guarantee that I would be spending the next few months fixing problems it creates, and I don't have time to do that.

Renaming 'content.module' would also break every one of the hundreds of contrib CCK modules, since they all include content.module in places in order to use the content module code in installs and elsewhere, and they would have to fix their code.

The less destructive change would be to change the path from 'cck' to 'content'. If we do that, content, content_copy, and content_permissions are properly named. Any new modules we add can be properly named, and only fieldgroup, text, number, nodereference, userreference, and optionwidgets are mis-named. Those are all going into core in D7 (probably), so I think we can defer worrying about those since they will get re-named or re-organized at that point.

Er, we're definitely *not* changing modules names - especially not if the original issue is merely over a css file. Anyone willing to do so is welcome to take over CCK maintainership :-)

About the problem at hand, I'd rather go with content-module.css. -1 for introducing cck as a namespace.

I'm going to commit a change to make it content-module.css and leave the namespace issues alone. Trying to fix those will introduce a host of other problems we don't need and there is no evidence it has actually created any problems for anyone.

I removed the old content.css file, that was still present.

Oops! I thought I had done that :)