drush updatecode should fork to a backend process to avoid problems

I am getting the exact same error on all 3 of my sites.

Same here.

I will look into it later, but please use 3.0.

This is a Drush bug. It complains that the hook_requirement function is declared in line 219 and this was the case in GA 2.2, but I have moved the requirement hook in 2.3 to .install file as it need to be. This was not an important GA bug, but it was a minor code change that has been made.

Please change the version number of Drush to your version. I'm only changing the queue now. Also higher the priority as I do not like to get my GA queue flodded with this Drush issue.

Looks to me like this site has copies of both the old and new code. how could it be drush's fault if a site has duplicate functions?

subscribe

If 3 people have the same issue I would really wonder if they all have the module twice on their box. I thought that Drush may load the .install before removing the old module directory. Does it really delete the old version and copy than the new version on the box?

I see what you are saying. There are a lot of permutations for updating modules using drush (i.e. different version control strategies). I do think we have open bugs already here.

If you would like to close this as a duplicate, please identify the original.

I've found #781040: Drush is not removing old files when updating modules with svnsync, but i'd like to remark that filenames have not changed in GA 3.0 nor have files removed. I have only moved a few functions from the .module into .install file. To clarify - this cannot be a "leave behind" issue!

I am by no means an expert, but I solved the problem for my site by:

- checking and saving my google analytics key
- disabling and removing the google analytics module
- downloading the module again using drush
- updating the site using drush (no errors this time)
- enabling the module
- putting back in the correct google analytics key

I have no idea what the cause of the problem is but I had the same error (fatal, in my case) when updating my site and this seems to have taken care of things.

Deleting the old directory and uploading the new version is enough. NO need to disable the module.

I can confirm the same problem has consistently come up on all 5 of the sites I manage. Each is a different Drupal install with dramatically different sets of modules on two different web servers.

Initially saw this problem with Drush 3.0rc4 so updated to 3.3 and symptoms didn't change.

I tried deleting the google_analytics folder as suggested above and it did solve the problem... sortof...

Instead I had error come up with the forum_access module - Cannot redeclare forum_access_enable()

I can say for sure that this is not a duplicate of #781040 as none of these sites are managed under SVN Control.

I will test to see if I can reproduce consistently on a clean install using out of date versions of both of these two modules.

Update - just tested on a clean install with only google analytics installed - could not reproduce. I'll keep poking around, see if I can track down some further specifics about what is creating the problem.

Marked #926024: Error updating via Drush as a duplicate. Hell - could not someone of the maintainers repro and FIX this issue, please?

Same issue, Drush 3.3. It does appear to be a Drush issue because a quick grep shows the function is only in the install file.

$ grep -ri googleanalytics_requirements httpdocs/
httpdocs/sites/all/modules/google_analytics/googleanalytics.install:function googleanalytics_requirements($phase) {

Drush must load up something prior to updating and somehow it stays in memory when the files are replaced.

If it helps I'm running it via FastCGI on Apache 2.2, PHP 5.2.4.

Same problem here.

Problem is that in the same process updatecode does a full bootstrap (loading .module of 2.2), then download 2.3 and then load .install of 2.3. To avoid this the upgrading should be invoked in a backend process.

oh damn, this sucks. the backend process is easy to implement but so many people forget to do --php and their systems are setup strangely. This is going to cause even more bug reports.

i do agree that backend is the way to go here.

To solve #19, please review and commit #918468: drush.ini or php.ini? [Drush should use php.ini files in drush conf folders + some fixes for drush paths that contain spaces], which correctly handles --php for Linux and greatly reduces the need to run drush via an alias. Windows users will need a similar patch for drush.bat.

This would make #855860: Option for pm-update/pm-updatecode to remove existing files before installing new ones easier to implement too.

+

Tracking.

#18 is correct. patch welcome.

It was easier than what I figured out at a first glance.

Looks good to me. If you have tested this, then feel free to commit.

commited.

When are you going to create a new release?