[consulting] New project drupal workflow
George
g at 8vue.com
Sat Mar 7 00:18:03 UTC 2009
so it's a terrible idea troy? well, it's kinda impossible to run
multiple sites from one installation, when it's for different clients on
different hosts (but you realise that is essentially what i'm doing by
checking out the dirs). and please explain, why it'd be already out of
date? it's easy to upgrade drupal + modules in repos as no db has been
built yet - heck i could set up a script to auto-update the repos daily!
yet you go on to explain you do the same by cloning a site
installation profiles are VERY difficult to code quickly and also poorly
documented (that's why they're covered in the back of drupal books in a
short chapter!). some drupal functions are available, some aren't and
you need to include the relevant files as necessary. though there's the
installation profile api which i haven't got around to testing yet, but
apparently offers a lot of helper functions. but as for enabling
modules, from what i remeber, just specifying the modules in the profile
will ensure they're enabled. simply copy the default profile to a new
dir, modify and test.
i just hunted through the installation profiles and haven't found a base
profile to work with, but take a look, there may be something there for
your needs already.
or, maybe someone here has a base profile they'd like to share?
Christian Pearce wrote:
>
>
> On Fri, Mar 6, 2009 at 6:08 PM, Troy Arnold <troy at zenux.net
> <mailto:troy at zenux.net>> wrote:
>
> On Fri, Mar 06, 2009 at 11:30:24PM +0100, George wrote:
> > I'm testing the idea of having a local repos of drupal and the
> essential
> > module (and some not so essential modules) and checking out when
> i start
> > a new drupal project, and installing. of course this has the
> negative
> > that modules and drupal slowly fall out of date, but i find it
> > incredibly quick just to checkout, and start with the all the
> modules,
> > and take away what i don't want.
>
> It sounds to me like a pretty terrible idea to start with
> something that is
> already out of date. If you want a rapid start, why not just run
> multiple
> sites out of one Drupal install?
>
> Also the drush module is pretty darn spiffy for quick module installs.
>
>
> Do you have an example of this?
>
>
>
> > i'm thinking about combining this with an install profile to
> > automatiically enable the core essential modules cck / views etc to
> > remove an extra layer of module enabling!
>
> > do any of you do anything similar? or do you have a different
> system?
>
> I have a Drupal project that periodically needs to get cloned into
> a new
> instance. I ended up writing a Perl script to handle the tedious
> parts of
> cloning the database, copying over and resources, erasing the
> un-needed
> content and writing a new settings.php. That's probably a raunchy
> hack,
> but it was easier (for me) than learning the install profile
> system. It
> does require that you understand Drupal's database schema very well.
>
>
> It's a slightly different question than what you're asking, but for
> maintaining Drupal sites with a minimum of hassle I use a method
> largely
> based on David Grant's writeup:
> <http://www.davidgrant.ca/maintaining_vendor_sources_with_subversion>
>
>
>
> I pretty much do the same thing, but end up doing a bunch of
> configuration by hand. I too was hoping to learn the install profile
> to create a baseline of modules I want all the time.
>
>
>
> -t
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org <mailto:consulting at drupal.org>
> http://lists.drupal.org/mailman/listinfo/consulting
>
>
>
>
> --
> Christian
> ------------------------------------------------------------------------
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
More information about the consulting
mailing list