Sync module name with d.o namespace

I think that renaming everything to node_clone is better solution. We can do this as major release, since renaming can break something on updates. We should do this as soon as possible - before releasing stable version.

This inconsitency also breaks some drush workflows. (and maybe d.o namespacing convetions?)

My case:
in dependencies I found "clone"
drush dl clone - does not work
clone lives on node_clone
drush dl node_clone - ok
drush en node_clone - does not work
drush en clone - finally! :)

Making clone a dependency of itself would be silly. There is some unfortunate naming, but with the number of users this module has, it's probably stuck.

This threw me off too!
In my .make file I have to reference the module as "node_clone"
projects[node_clone][version] = "1.0-rc2"

but in my installation profile .info file I have to reference it as "clone"
dependencies[] = clone.

At the very least I recommend this being added to the README.txt file This is the first module I've come across that doesn't use the normal naming conventions.

I'm changing the status of this because the person that marked this as "Closed - won't fix" seems to have misunderstood the problem. No one is saying that node_clone needs to make clone a dependency of itself. They are saying that the module's official project name, "node_clone", does NOT match the file names which are all called clone.* (clone.info, clone.module, clone.install, etc).

So when creating make files, installation profiles, or using drush to download and enable, people are caught off guard (rightfully so).

The previous suggestion of fixing this in a major release, is the correct one.

I just noticed the date of the OP. I'm so surprised this was never done. Hmmm guess it may never actually get fixed... I guess me changing the status to needs review will not likely help it happen.

Alright, I was wrong and https://drupal.org/project/clone seems to be reserved to resolving this.

I've been thinking about a kind of hacky solution:

1. create one release with some warning shown to uid 1 with link to this issue informing admins about our plans (idealy with dates of future releases and code prepared in git for testing)
2. • next release containing two modules: node_clone and clone
   • both with same code
   • clone could have update function with code to enable node_clone, migrate settings and disable itself
3. next release with just node_clone

Or just freeze 7.x-1.0-rcX right before releasing 7.x-1.0 and release renamed 7.x-2.0 instead. Or some combination of those two.

Referencing other issues, better title and issue summary.

Yay! I'm not sure which solution is the best, but I wanted to say THANK YOU for looking into this again. Much appreciated! As stated the plan is a little hacky, but workable I think!

I'd love to hear other's feedback on the best solution. It's a tough one because people utilize the module in so many different ways and I know you want something that will work for the majority of users. I wonder if another module owner has already dealt with this sort of situation and can provide confirmation of what works best for them. I'm still a bit of a newbie in the module writing department so I'm not the best person to ask, but again, thanks for bringing this to the community!

I just stumbled upon same problem with google_analytics module and found this comment:

... But think about how you install cck modules...

( https://drupal.org/node/913664#comment-3462976 )

This comment got me thinking and I have to admit, that I had no problems (except drush dl / en confusion) with this since posting my first comment here.

I still don't like it. Maybe leave it until D8?

@ladybug_3777: You are welcome :-)

The google analytics module is fixing its namespace with the D8 version of the module
https://www.drupal.org/node/427770

I disagree with hass on this one. It is an issue, especially for beginning drupal users/developers. We have these naming conventions for a reason.

This issue blocks the inclusion of the node_clone module in an installation profile. drupal_verify_profile() fails due to the inconsistent naming of this module.

That's not entirely true. I've worked around that problem by doing the following:

In my make file I use:

projects[node_clone][version] = "1.0-rc2"
projects[node_clone][subdir] = "contrib"

But then within my install profile I do this:

;note clone = node_clone. They are using different naming conventions in the module 
dependencies[] = clone

I agree it's not pretty and it can get confusing, but it will get your install profile running.

The real fix is to fix the namespace.

Either, change modules name in the code or change the project over to a new project with the correct namespace.

I have updated the summary to match what this issue is about to stop confusion. Also, this is a task or a feature request --not a bug.

This won't be fixed for 7.x.

For 8.x I will look at fixed the module's actual name.