Hi
I've just been checking out the ftools and that autocreate feature is really neat. We use drupal in a multisite installation with developers only having "user 1" access in the development environment (we have the dev> staging> live implementation issue which is how I found features and ftools).
We were hoping we could let the developers use ftools to provide configuration changes via our version control, but the issue we hit straight away with testing is that the custom module path defaults to sites/all/modules rather than the sites/yoursite/modules that would ensure we don't get module name conflicts.
Would it be possible to make ftools figure out what the local modules directory would be and use that if it is writable?
Thanks
--
Stuart Crouch
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | ftools-configurableDefaultPath-1438418-7.patch | 9.26 KB | diwant |
| #3 | features_tools.module.patch | 2.35 KB | stuart.crouch |
Comments
Comment #1
perelman.yuval commentedHi Stuart Crouch.
If i understand your question.
When you recreate a feature we will used is path, your problem is when you create a new feature.
You can write in the text filed the path you want and it will be used instead of the sites/all/modules dir.
If you ask something else, please explain.
Comment #2
stuart.crouch commentedYou understood me perfectly :) but your solution doesn't help me :(
I'll try and explain why.
The problem is that we try and keep the drupal developers away from the command line. We have over 100 sites on one host and letting the developers loose on the file system via ssh would cause problems. Instead we have a script that generates them a samba share.
Because the developers don't know how drupal is structured behind the scenes they will not know the local path to enter, and instead will leave it at the default. This means the chances are good that two developers will come up with a features name of "config" and they will conflict or we will end up with config1, config2, config3
So what I'm asking is can the module offer the local site path (eg sites/my.site.com/modules/) rather than sites/all/modules.
Even better would be an admin interface where we can use %t like in CKEditor to decide the default directory structure.
Comment #3
stuart.crouch commentedAfter having written that I realized how quick a patch it would be to write. You can see the basics of what I mean here.
If this patch were implemented it would mean we could set the features output directory using drush when we create a site using our automated scripts. Every site could have a different default, and if no default was entered it would fall back to sites/all/modules.
Please consider the patch :)
Comment #4
stuart.crouch commentedHi again
I've changed the status to point out I wrote a patch.
What else can I do to get this change implemented?
Thanks
--
Stuart
Comment #5
perelman.yuval commentedhi stuart.
soory for not replay to your previous post, i am very buzy this days.
i am sure there is a way to get the site specific modules dir, so i dont think we need to use our variable.
i will get to this as soon as i can.
Comment #6
traviscarden commentedHello, @stuart.crouch. The actual status for a new patch is "needs review". See the explanation of statuses in the issue queue handbook. Another thing you can do to accelerate implementation is to roll your patch with Git so it can be tested by our automated test framework and more easily applied by other developers. Then you can help Perelman get to your patch sooner by assisting with other issues in his queue. :)
Comment #7
diwant commentedI redid #3 for the 7.x-1.x line. Attached the patch here. Take a look? I don't know why my diff shows the same lines added and removed, I'll re-roll if someone knows a config option in git diff to get rid of that.
Also, I set the version to 7.x-1.x-dev in the issue cuz this patch is for that. Should I have opened a new issue?