Change project shortname to field_extract

+1 seconded.

This module is going to be pure awesomeness for Drupal 7.

There's gotta be an easier way then having to re-upload... (after all, its just a path alias based on a single field, right)?

Have you tried asking in IRC #drupal-infrastructure, if there is a way to fix this without re-upload?

Just cleaning the title up.

#facepalm

Thanks guys. It is slightly embarrassing to appear to be a complete klutz when creating a project.

But I was :-)

My time is short which is why I've not done anything about it (well, I did send an email to someone but I got no reply).

I'll leave this open for now.

Steve

THIS MODULE IS AWESOME BTW, THANKS!!

... just fyi i've been using this module since I read about it on your blog or something months ago ... eg, before/when you moved it to D.o

I am building site(s) with Drush makefiles and install profiles. Clearly, for the project page they made /project/field_extract redirect to /project/1158878 ... but it has a meaningless short name.

For instance when I use www.drupal.org/project/profiler I cannot list it in my install profile .make file as:
projects[1158878][subdir] = "contrib"
projects[1158878][version] = "1.0"

because it wont enable correctly ... because profiler assumes that the module name is what it is enabling in its automated download/install process, which isn't the case here.

I have to use a bash script or additional drush make file to:
drush dl 1158878; drush en field_extract -y;

I'm just bumping this ticket and voicing you could get larger adoption if you fix the naming on this project .... just create a new project page correctly and point everyone there ...

thanks again for the cool project.

thx for the module
should be in core ;)

I love how the module is named. I bet no one could remember that name. :D

Greggles has responded in the other thread that the module can't be renamed, a new project will have to be created and then this one deleted.

So he did. Oh well. I'm currently on holiday so it won't be happening this week.

adaddinsane, are you still on holiday?

I don't check why other users say that this module should be in core, I think this is much overhead but I think you should pay attention with your branches, adaddinsane. There should be only a 7.x-1.x branch and you should tag releases instead of creating a new branch for it.

No I'm no longer on holiday. What I am is really busy.

I keep seeing a light at the end of the tunnel but it's always a train coming the other way.

As far as versions go, I don't use Drupal's Git versioning enough to get used to how it's supposed to work. So I make mistakes.

Like the short name problem that this issue is all about.

Please follow the route http://drupal.org/project/BookMadeSimple did .. they changed their project name finally :p

You don't have to clean up your git repo. You can just create the new project and place the dev versions in it. History is kept in this project.

Now that the project has a proper name, when can we expect that you'll be moving things over to the new project?

Note: a follow-up task after the move will be to update all the issues in the queue to the new project. busywork-- good thing there are only 20.

Any update on moving the project to its new home? Anything I can do to help with the move?

I would be very happy for you to help get this shifted. Unfortunately I am seriously tied up producing a drama webseries (my other "hobby") and the only Drupal I get to do is my current contract.

If you can give me commit rights on the new project I would be happy to move it over, set up the project page, and get a release up.

Well that was easier than it used to be :-) you have all rights on drupal.org/project/field_extract

(And thanks - he said, pitifully.)

I've copied across the project description from here and imported the code from the dev version as of 2012-Jul-22 and (fingers crossed) triggered the build of a development package.

Before I tag the 7.x-1.x branch and get a v1 release up, would people like to devote some time to testing it first?

@garrettc, thanks for your work on this! I'm not sure what needs to be tested. field_extract 7.x-1.0 has been out for over a year, I think you just need to create the exact same 1.0 release in the new project.

There were a couple of changes made to this repository after the 1.0 release which cleaned up some left over CVS fluff and added support for entityreference fields, so I thought it better to start the new project based on that rather than 1.0.

If you decide do that, please call it something other than 1.0 :)

I see no harm in re-releasing 1.0 then taking some time to test and create the next release.

Due to existing project work I won't have a great deal of time to devote to this after today, so I was hoping to just tag what's in there now as 1.1. I know adaddinsane is short of time too, so I'm wondering if we need a third maintainer to help steer future development?

Shouldn't all issues moved over to http://drupal.org/project/field_extract then close down the issue queue for this project?

^ yes.

Updated issue summary.