I searched for updates using the update manager. It found updates for Entity and Rules. I used the automatic method for updating these two APIs. When I tried to navigate back to my website, I was told that the site could not find an include file for Rules. I looked at the directory under SSH, and I found out that Rules had been installed to sites/all/modules/rules/rules instead of sites/all/modules/rules. After I fixed that, I found out that Entity had been installed to sites/all/modules/entity/entity instead of sites/all/modules/entity. In both cases, Drupal was looking for files in sites/all/modules/X and not finding them because the updated files had been in stalled in sites/all/modules/X/X. This suggests this is a problem that is generic (the update manager) and not specific to the packages.

Files: 
CommentFileSizeAuthor
#74 drupal_986616_74.patch7.1 KBXano
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch drupal_986616_74.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#72 drupal_986616_72.patch6.59 KBXano
FAILED: [[SimpleTest]]: [MySQL] 57,987 pass(es), 50 fail(s), and 1 exception(s).
[ View ]
#64 drupal-root_path-986616-64.patch11.92 KBmbrett5062
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-root_path-986616-64.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#63 drupal-root_path-986616-63.patch11.91 KBmbrett5062
PASSED: [[SimpleTest]]: [MySQL] 48,166 pass(es).
[ View ]
#61 drupal-root_path-986616-61.patch11.67 KBmbrett5062
FAILED: [[SimpleTest]]: [MySQL] 48,122 pass(es), 1 fail(s), and 0 exception(s).
[ View ]
#56 986616-56-root_path.patch1.79 KBdanielhonrade
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 986616-56-root_path.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#31 986616-31-simple_solution.patch2.16 KBbfroehle
PASSED: [[SimpleTest]]: [MySQL] 31,546 pass(es).
[ View ]
#28 1016892-2-hacky-solution-but-needs-work.patch1.34 KBbfroehle
PASSED: [[SimpleTest]]: [MySQL] 31,461 pass(es).
[ View ]

Comments

kylethaynes’s picture

I just updated Views using the update manager. It installed correctly. I used the exact same series of steps that I used to update the other modules.

There are only two differences between how I updated Views and how I updated the other two modules.

1. When I updated Views, I updated the Views module alone (no other modules upgraded at the same time).
2. When I looked under the sites/all/modules/views directory, I noticed that views does not have a subdirectory of itself named itself, i.e. views. In the case of Rules and Entity, there was a subdirectory with the name of the module directory. For instance, Rules had a subdirectory named rules. The resulting incorrect install directory was sites/all/modules/rules/rules/rules (one layer deeper than it should have been). I corrected this by renaming the previous rules directory to rules2, and then copying the rules directory within rules2 to the parent directory of rules2. After copying rules to the correct location, the module worked properly (minus the other bugs with the current development implementation of Rules).

dww’s picture

Component:update system» update.module
Issue tags:+Update manager

I know it's confusing, but "update system" is for update.php and the DB update system. You're talking about the Update manager that checks for available updates to your modules and themes (and can install them for you in D7), which is provided by the "update.module".

Anyway, this sounds bad, although I don't have time right now to investigate and test it myself. Can anyone else reproduce this?

kylethaynes’s picture

Sorry about posting in the wrong location. Thank you for the clarification...

DamienMcKenna’s picture

I verified this happens when updating Rules v7.x-2.0-alpha1 to v7.x-2.0-alpha2, it installed the new Rules module into sites/all/modules/rules/rules rather than sites/all/modules/rules.

The problem boils down to the following line in system.updater.inc:

<?php
   
if ($relative_path = drupal_get_path('module', $this->name)) {
?>

and:

<?php
   
if ($relative_path = drupal_get_path('theme', $this->name)) {
?>

The key issue is that running drupal_get_path() for the Rules module, i.e. drupal_get_path('module', 'rules') will always return the path of the subdirectory where rules.module is stored rather than the parent directory.

Honestly this is not a core bug but rather a problem in Rules module itself, the primary module files should be stored within the main module directory, not a subdirectory.

DamienMcKenna’s picture

Title:Update Manager Installs Under Wrong Subdirectory» Module directory structure causes Update Manager to fail
Project:Drupal core» Rules
Version:7.0-rc1» 7.x-2.x-dev
Component:update.module» Rules Engine

The problem is with the Rules module, not Drupal core, so I'm reassigning it.

Summary:

  • The Drupal norm is that a module's main module files should be stored within the main module directory.
  • The Rules module stores its main module files within a subdirectory rather than the main directory, i.e. instead of it being rules/rules.module it is in fact rules/rules/rules.module.
  • The extra subdirectory causes Update Manager to download it to the wrong location.

Solution:

  • Move the main module files to the module's main directory so that e.g. rules/rules/rules.module would become rules/rules.module.
  • This will cause problems for anyone who has the module already installed as the new files will be suddenly be in the wrong location and key system tables will be out of sync ('system', 'menu_router').

Moving the files is the right thing to do, the question is whether it's worth doing sooner or later.

fago’s picture

Title:Module directory structure causes Update Manager to fail» Update Manager fails with modules containing subdirectories
Project:Rules» Drupal core
Version:7.x-2.x-dev» 7.x-dev
Component:Rules Engine» update system

># The Drupal norm is that a module's main module files should be stored within the main module directory.
Lots of modules have sub-directories with more modules. Similarly, Rules and the Entity API have separate directories for each module which is part of the project - that worked and works fine with Drupal. It's odd that the update-manager fails with that now.

I dislike bringing chaos to the established order, but I see this is hard to fix for the update-manager? Would renaming the "rules" folder help?

I move this back to Drupal core, as it's problem with the update manager which appear for more modules (at least entity+rules).

fago’s picture

klausi’s picture

dww’s picture

Title:Update Manager fails with modules containing subdirectories» Update Manager fails when the primary module for a project lives in a subdirectory
Component:update system» update.module

I know it's confusing, but "update system" is for update.php and the DB update system. You're talking about the Update manager that checks for available updates to your modules and themes (and can install them for you in D7), which is provided by the "update.module".

Automatically yours,
-Derek

p.s. It's not that update manager fails when there are subdirectories at all. The problem is when the primary module for a project lives in a subdirectory. But yeah, I think it's probably safe to call this an update manager bug, not a problem in Rules or Entity. We should really look more closely at how Update manager is trying to figure out where to upgrade stuff, and see if we can do anything about it. Unfortunately, it's a tricky problem. We can't just assume sites/X/modules/Y -- since some people (and some distributions) like to put things in sites/X/modules/contrib/Y etc. Anyway, it might be possible to fix this in Update manager, so we can leave the issue here for now.

fago’s picture

@component: I see, sry. I was not sure whether this is done by the update.module.

Unfortunately, it's a tricky problem. We can't just assume sites/X/modules/Y -- since some people (and some distributions) like to put things in sites/X/modules/contrib/Y etc.

Indeed. Perhaps it would be a good heuristic, to take the relative module location, strip known paths to the sites|profiles/*/modules subfolder and then take the first occurrence of the project name? This would be problematic though for modules "contrib" in a "contrib" folder.

DamienMcKenna’s picture

Project:Drupal core» Rules
Version:7.x-dev» 7.x-2.x-dev
Component:update.module» Rules Engine

This is not a bug in Update Manager. Update Manager uses the core drupal_get_path() function to identify where the primary directory for the given module is. It's only now that we're running into a tangible problem because some developers don't store their primary module in the main module directory, something that really should be added to the developer's guidelines.

@dww The problem is not where site builders store their module but where the module developer chose to store it. There are a limited number of modules which are affected by this problem, it'll be easier, simpler and cleaner to fix them than try to add crazy logic for a few fringe use cases.

@fago: What about modules that don't use the same directory name as their module name, e.g. "cck" and "content"? What if someone created a subdirectory in sites/all/modules called "content" for all of the field-related modules?

fago’s picture

Project:Rules» Drupal core
Version:7.x-2.x-dev» 7.x-dev
Component:Rules Engine» update.module

No, the problem is not drupal_get_path() - I know this is working fine. The problem is that the update-manager is assuming the modules directory is equal to the project's directory.

Still the problem is a general one, so let's discuss and solve it here once and not in the queue of each affected module. Thus moving back to Drupal.

If possible, I'd really prefer to keep a subdirectory (at whatever name), as things are organized well that way.

>What if someone created a subdirectory in sites/all/modules called "content" for all of the field-related modules?
Indeed, I guess content module violates the project namespace but that's another issue. But I see that's a problem.

I had a short look at the code gather projects for modules and it looks like it assembles the paths of all included modules:

      $projects[$project_name]['includes'][$file->name] = $file->info['name'];
//..
     $projects[$project_name]['disabled'][$file->name] = $file->info['name'];

So, if one would take the longest-common path-prefix for all the modules, this should work - right? The only situation it would not work, would be if one creates sub-directories and place all modules into a single sub-directory. So well, ..

DamienMcKenna’s picture

@fago: and again, you end up with having to either a) account of who-knows what sort of directory structures that a site builder could validly build (especially taking internationalization into consideration), and the simpler solution is to fix the limited number of modules with broken directory structures.

Dave Reid’s picture

I strongly feel that we need to make it an official standard of putting your root module files in the root module directory. It also messes up drush cli and drush cdd when trying to patch modules because you get moved not to the CVS root directory.

DamienMcKenna’s picture

I'm working on getting an official guideline into the Coding Standards to rule that modules must have a module file in the main directory: http://drupal.org/coding-standards#comment-3793440

fago’s picture

ad #13: The suggested approach should work with any directory structures. Also, moving everything around for modules like Rules is for sure not simple.

But while it would certainly create quite some pain to follow that with Rules and the Entity API, it sounds like something that makes sense, as the drush examples show it would help others too and simplify things. But for that, this really needs to become an "official", documented standard / rule.

ronald_istos’s picture

Re: smart code Vs coding standard/guideline would just like to add that we already got told off by Rasmus at Copenhagen for doing way too much searching through directories to figure things out - adding some more will certainly not help with that. I think #11 is spot on - these are fringe cases and writing all the code necessary to take care of just a few cases seems like overkill.

BenK’s picture

Subscribing

DamienMcKenna’s picture

@fago: while not necessarily simple, making the change now before D7.0 is released (soon!) and starts getting large amounts of use is the best approach.

Also consider it from the POV of total amount of time to build a core patch that resolves as many fringe cases that can be thought of, reviewed and committed, vs the time to move files around on a few contrib modules.

dww’s picture

I'm happy to see this fixed via standards and conventions.

But, for the record, Drupal has a bit of an identity crisis about projects (collections of modules) vs. individual modules. Some things operate on modules, others on projects. It's confusing. It's especially confusing in the update manager code. The most obvious alternative would be worse (forcing every single module to have a separate project), but we're sort of just dancing around a deeper problem here by saying "it's the fault of rules and entity for not following the (not-yet-agreed-upon-nor-documented) standard". drush is making the same (at times false) assumptions that update manager is, that's why it's also broken by these cases. If we're going to keep the project vs. module thing (and I believe we must) we should probably spend some effort in D8 seeing if there's a more sane way to codify this stuff so that we're not just guessing and assuming all the time. The packaging script is automatically appending the "project = foo" line to all .info files inside the foo project. Perhaps we could do more to help our code do the right thing. For example, #914284: Update packaging scripts to create some sort of MANIFEST could really help here. If we always knew there was an auto-generated MANIFEST file at the root of each project's directory (ugh, except when you checkout from version control *sigh*) we could search for that, instead of assuming that the module-the-project-is-named-after always lives at the project root (unless the module is called "content" and the project is called "cck", in which case, who knows WTF Update manager is going to do?).

Point being, this is a crappy problem... ;)

Enjoy,
-Derek

amitaibu’s picture

subscribe (since also og's module are in og/og/og.module)

DamienMcKenna’s picture

@amitaibu: I added a task for OG: #990634: Move og.module into main project directory :)

DamienMcKenna’s picture

@dww: I completely agree with finding a way of improving the core functionality for D8.

DamienMcKenna’s picture

Project:Drupal core» Rules
Version:7.x-dev» 7.x-2.x-dev
Component:update.module» Rules Engine

FYI Entity API has been fixed, which just leaves Rules.

fago’s picture

Project:Rules» Drupal core
Version:7.x-2.x-dev» 7.x-dev
Component:Rules Engine» update.module

As noted above, I've created per-project issues. See #990198: Updating with the Update-manager fails.

DamienMcKenna’s picture

Status:Active» Fixed

With the main affected modules fixed, this is no longer an issue.

dww’s picture

Version:7.x-dev» 8.x-dev
Priority:Major» Normal
Status:Fixed» Active

I disagree. ;) This is stupid. We should have a better solution someday.

bfroehle’s picture

Version:8.x-dev» 7.x-dev
StatusFileSize
new1.34 KB
PASSED: [[SimpleTest]]: [MySQL] 31,461 pass(es).
[ View ]

In #1016892-2: Updated module installed in the wrong folder I posted a somewhat hacky solution which changes Updater::getProjectName() to first consider the project field of a .info file, and then the basename of the directory.

Then, in ModuleUpdater::getInstallDirectory() rather than just considering the directory the MODULE.module lives in, we iteratively go to parent directories until the project name differs.

This does impact the Date module the last I checked.

Patch is attached here for review. A similar routine would need to be written for ThemeUpdater as well, before this would be ready to go. I think this would be okay for inclusion in a later 7.x release, as it isn't really changing any API's or function behavior.

bfroehle’s picture

Status:Active» Needs review
jzornig’s picture

The Date module also has this problem. After using update manager you end up with the new copy of date module in a subdirectory of the last version. This repeats for each update so you end up with a chain /sites/all/modules/date/date/date/date/date/date of recursive directories. See reports http://drupal.org/node/1014118 and http://drupal.org/node/1017938

bfroehle’s picture

StatusFileSize
new2.16 KB
PASSED: [[SimpleTest]]: [MySQL] 31,546 pass(es).
[ View ]

I've fixed up my own complaints in #28 and am included a revised patch for review.

Modules and themes that would work with this patch have .info files of the form:

.../MODULE/my_module.info
.../MODULE/MODULE/my_module.info
.../MODULE/MODULE/MODULE/my_module.info

.../THEME/my_theme.info
.../THEME/THEME/my_theme.info
... etc

In the code, we choose the installation path by repeatedly ascending through directories until the directory name differs.

This abandons the proposed change to Updater::getProjectName(), which attempted to get the project name from the .info file (as might be included by the drupal.org packaging script) before falling back on the directory name.

Tested manually on the Date module and a more normal "conforming" module.

bfroehle’s picture

himerus’s picture

I do see this as a major issue... Not as much on the module side as I do for themes...

Advanced base themes like my Omega base theme, Fusion, Genesis, and Adaptive themes all use a setup where the directory structure would be similar to the following.

  • /sites/all/themes/omega/
    • omega
      • omega.info
    • starkerkit
      • starterkit.info
    • assets
    • README.txt

The reason behind this for themes would be that if your root base theme had it's template.php and .info file in the root directory, and you wanted to store your templates in a folder called "templates" it can have issues respecting those templates in the base theme/subthemes if you have subthemes (starterkit) in the same directory as the primary files for your base theme. I ran across this heavily in my two versions of Omega for D7, and decided to adopt the same structure other (popular) base themes are using.

There must be a way that this can be defined differently, as I think for modules AND themes, there are many potential reasons that the root install directory would only contain a set of directories for sub-modules/themes.

I consider this a bug that should be resolved in D7, NOT D8... and also that the priority should be higher than "normal", as it DOES affect many major projects in D7.

DamienMcKenna’s picture

@himerus: could the directory structure be changed around to be like this (not sure of the theme's exact directory structure, this is a rough estimate):

  • omega
    • css
    • images
    • omega.info
    • README.txt
    • subthemes
      • starterkit
      • example2

?

bfroehle’s picture

himerus: An other major problem is that when you go and do the upgrade it'll erase the entire omega directory (including any custom subthemes you had installed there) before installing the new version of omega.

DamienMcKenna’s picture

@bforehle: you shouldn't be storing your custom themes in a subdirectory of a theme you downloaded.

bfroehle’s picture

Damien, yes, I know not to store my custom theme in a subdirectory of a theme I downloaded. However I suspect not all users know this. Some might just start modifying the starterkit files or put another directory in the subthemes directory you propose in #34, each of which would be overwritten by a module update. The larger solution might be something like #914284: Update packaging scripts to create some sort of MANIFEST. I think we should start another issue to discuss these sorts of things rather than add to the clutter already in this issue.

dww’s picture

I continue to believe the D7 update manager is being a bit stupid here, and we should fix this along the lines of bfroehle's patch instead of expecting every module and theme to reorganize their files. I don't have time right now to thoroughly review and test #31, so I can't set this RTBC, but I sure hope other people will do that ASAP...

Thanks,
-Derek

DamienMcKenna’s picture

The patch in #31 won't work for @himerus' theme structure.

DamienMcKenna’s picture

Status:Needs review» Needs work
bfroehle’s picture

Status:Needs work» Needs review

Yes, the patch in #31 will work for @himerus's theme structure. Did you actually try it?

himerus’s picture

I have not tried it yet, I need to duplicate a new environment as I don't have a clean install running, and have never even used this feature. I will do my best to play around as it was an issue in my own queue that brought this to my attention.

himerus’s picture

Priority:Normal» Major

I have applied the patch, and it applies cleanly, but I can't verify it works as none of my servers have FTP access available, and running drush up omega in my case didn't work. (not sure if drush uses this core functionality or it's own for the update)

This really needs some reviewers as I think the priority on this is much higher than "normal", and I'm getting many users running across this as I pass out theme updates, users are getting VERY odd behavior and I've seen some users end up with directory structures of omega/omega/omega.

With Fusion, AT, Genesis, AND Omega using this directory structure, I feel this issue is in fact quite critical, but I will promote it only to major for now (I don't want to get smacked) :)

DamienMcKenna’s picture

A related bug that shows via drush: #1081160: Updating context module breaks directory structure This bug only happens with drush, core update manager works fine, with or without the patch. Go figure.

I tested the patch with the Omega theme, updating it from 7.x-2.0 to 7.x-2.1. Without the patch it broke the directory structure and copied the whole omega package directory structure into the omega theme directory (sites/all/themes/omega/omega) as described above, with the patch it worked perfectly. Good work!

Anyone else want to test the patch so we can mark it RTBC?

DamienMcKenna’s picture

Ran into a problem. This patch makes "drush pm-updatecode" (aka "drush upc") behave incorrectly: #1081182: drush upc doesn't list themes It's an exercise left to the viewer to discover whether this is a bug in the patch or in Drush ;)

safetypin’s picture

I'd like to review the patch, but I just found out that I don't have properly configured ftp/ssh access to my server/computer (running MAMP). I also can't find instructions on how to configure this. I found a couple of handbook pages about the Update manager and installing/updating modules, but both are out of date. If someone could give me some general direction about how to configure this, I'd be glad to try to figure it out and update the handbook, and review the patch.

DamienMcKenna’s picture

The issue mentioned in #45 above, #1081182: drush upc doesn't list themes, is not because of this patch but rather a Drush bug: #1002658: Drush does not correctly handle D7 project status queries

DamienMcKenna’s picture

Drush still exhibits this bug as it uses its own code, so I opened a new ticket for it: #1098424: pm-update fails when the primary module for a project lives in a subdirectory

jonhattan’s picture

FYI: It is no longer an issue in drush. What we do to calculate the project directory is to find the common path of all of its extensions: http://api.drush.ws/api/function/_pm_find_common_path

DamienMcKenna’s picture

@jonhattan: Nice :-)

So, back to Drupal core. Has anyone else tested this successfully?

sun’s picture

Version:7.x-dev» 8.x-dev
Issue tags:+needs backport to D7
catch’s picture

Status:Needs review» Needs work

Do we really have exactly the same code in two different classes like this? Isn't there somewhere else it could live that the two classes could share it?

+      // Some modules

This should be "Some projects" - part of the issue is that project != module so conflating the project directory with the module directory in comments doesn't help.

mrconnerton’s picture

sub

dww’s picture

mrconnerton’s picture

ya I missed that by a few hours and immediately saw it after I hit the save button :-P

danielhonrade’s picture

StatusFileSize
new1.79 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 986616-56-root_path.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

#31 works, please apply it to D7, I made it simplier

catch’s picture

The comment mentioned in #52 still needs to be improved.

danielhonrade’s picture

Hi Catch,

We'll all be happy if you'll give a solution to this once and for all.

thanks,
daniel

catch’s picture

Issue tags:+Needs tests, +Novice

Tagging 'novice' for the comment change and possible re-roll to apply against 8.x.

This could ideally use tests as well, would require a test project that has the module in a sub-directory, then ensure this function finds it correctly.

mbrett5062’s picture

Assigned:Unassigned» mbrett5062

Would like to take this on.

One note, in current D8 core the update module is changed, and there are now 2 files, one for modules and one for themes.
I have made changes, and about about to test locally before uploading patch.

mbrett5062’s picture

Status:Needs work» Needs review
StatusFileSize
new11.67 KB
FAILED: [[SimpleTest]]: [MySQL] 48,122 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

Here goes for first stab. I am not familiar with tests. Have only created test for module so far, if this passes will take a look at theme as well.

Status:Needs review» Needs work

The last submitted patch, drupal-root_path-986616-61.patch, failed testing.

mbrett5062’s picture

Status:Needs work» Needs review
StatusFileSize
new11.91 KB
PASSED: [[SimpleTest]]: [MySQL] 48,166 pass(es).
[ View ]

OK missed one small edit, needed to test for 4 projects not 3 on line 342.

mbrett5062’s picture

StatusFileSize
new11.92 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-root_path-986616-64.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

And forgot to add change for #52. Here it is.

kerasai’s picture

Status:Needs review» Needs work
Issue tags:+Needs tests, +Novice, +Update manager, +needs backport to D7

The last submitted patch, drupal-root_path-986616-64.patch, failed testing.

mbrett5062’s picture

Assigned:mbrett5062» Unassigned
Xano’s picture

Status:Needs work» Needs review
Issue tags:-Needs tests, -Novice, -Update manager, -needs backport to D7

#64: drupal-root_path-986616-64.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, drupal-root_path-986616-64.patch, failed testing.

Xano’s picture

Status:Needs work» Needs review

#64: drupal-root_path-986616-64.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+Needs tests, +Novice, +Update manager, +needs backport to D7

The last submitted patch, drupal-root_path-986616-64.patch, failed testing.

Xano’s picture

Status:Needs work» Needs review
StatusFileSize
new6.59 KB
FAILED: [[SimpleTest]]: [MySQL] 57,987 pass(es), 50 fail(s), and 1 exception(s).
[ View ]

Status:Needs review» Needs work

The last submitted patch, drupal_986616_72.patch, failed testing.

Xano’s picture

Status:Needs work» Needs review
StatusFileSize
new7.1 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch drupal_986616_74.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Status:Needs review» Needs work

The last submitted patch, drupal_986616_74.patch, failed testing.

Xano’s picture

Can someone else please look at the patch? I did not experience the 50 test fails locally.

Xano’s picture

Status:Needs work» Needs review
Issue tags:-Needs tests, -Novice, -Update manager, -needs backport to D7

#74: drupal_986616_74.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, drupal_986616_74.patch, failed testing.

Xano’s picture

Status:Needs work» Needs review

#74: drupal_986616_74.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, drupal_986616_74.patch, failed testing.

Xano’s picture

Status:Needs work» Needs review

74: drupal_986616_74.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, 74: drupal_986616_74.patch, failed testing.

The last submitted patch, 74: drupal_986616_74.patch, failed testing.

Xano’s picture

Bump.

Xano’s picture

Status:Needs work» Needs review

74: drupal_986616_74.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, 74: drupal_986616_74.patch, failed testing.

mgifford’s picture

Issue summary:View changes
Issue tags:+Needs tests
Xano’s picture

Bump. This is still very much an issue.

Status:Needs work» Needs review

Xano queued 74: drupal_986616_74.patch for re-testing.

Status:Needs review» Needs work

The last submitted patch, 74: drupal_986616_74.patch, failed testing.

jonhattan’s picture

I'll reiterate what I said in #49: Drush finds the common prefix of all extensions paths. This is infalible guys. Code is now at http://api.drush.org/api/drush/commands!pm!pm.drush.inc/function/_drush_pm_find_common_path/master

Drush, succesfully updating your projects since 2009.

marthinal’s picture

I cannot reproduce for a D8.

drumm’s picture

Title:Update Manager fails when the primary module for a project lives in a subdirectory» Update Manager fails when the primary module/theme for a project lives in a subdirectory