[consulting] Planning for future versions

[Kieran Lal]

On 8/17/07, Boris Mann <boris at bryght.com> wrote:
>
> On 8/17/07, Kieran Lal <kieran at civicspacelabs.org> wrote:
>
> > 2) Extend the services in Drupal module so that hosting companies could
> get
> > remote information from all their sites.  We used to configure
> CivicSpace
> > distro to ping back to CivicSpace.  Drupal.org used to do this as
> well.  It
> > would be good if service providers could get information from their
> sites.
> > It would be helpful if distribution profiles maintainers could know what
> > sites are using their distribution.  If this was extensible so that
> service
> > providers could also send information to site that would also help.  "We
> are
> > going to upgrade your site" "We have applied the latest security
> updates".
> > This could include OpenID login to securely transmit this information
> back
> > to Drupal.org, hosting provider, etc.  Some of this framework is in
> place
> > with updates now in D6, but it needs to be even more extensible.
>
> This is what I was talking about with a set of "dashboard" modules and
> services.
>
> And this would all be in contrib modules in any case, nothing to do with
> core, and no changes to core needed.


Unless we extended the Drupal module to do this.  But starting with a
contrib module would be a good place to begin.  Nedjo did some advanced work
for the Drupal module back in 4.7.  It should be revisited.


> Right now, having multiple versions of modules in the bootstrap path can
> > cause conflicts.  It also means a server side OS process must remove old
> > modules or a system administrator must do this.  My preference would be
> to
> > make this all configurable through the web interface or server side
> policy
> > and avoid additional server side processes.  Basically, you could
> obsolete
> > modules, and even non bootstrap core code, in place.
>
> This is Apache configuration. Hostmaster upgrades by switching a base
> drupal core to include from, so every upgrade is, in fact, a separate
> docroot. More than one way to skin this cat, no changes needed to
> Drupal core as far as I can see.


If you have Drupal version 1 in /var/www/version1 and your required modules
are in /var/www/version1/modules then the filename values in the system
table will be modules/modulename/modulename.module.

When you change document_roots the new version of the required module will
be found at modules/modulename/modulename.module but it will now be pointing
to version2 of that required module.

If you have Drupal version 1 in /var/www/version1 and your required modules
are in /var/www/version1/sites/domain/modules/ then the filename values in
the system table will be /var/www/version1/sites/domain/modules/.  When you
switch document_roots to do an upgrade you will encounter a problem.

Your version2 of Drupal will have a hard coded system table filename path
(/var/www/version1/sites/domain/modules/modulename/modulename.module) and
will be pointing to the wrong version of the required module.  When you try
to bootstrap version2 drupal for the first time you'll get an error.
Therefore automated upgrading will require both a check and possibly a
change to the filename value in the system table.

If the bootstrap was lighter weight you would not have to worry and the
system.module could refresh the filename's for the newly upgraded document
root.

For now, you are required to keep the 6 required modules in
drupal_root/modules.  It's not worth changing on it's own, but this problem
would be solved by greater control over bootstrapping.

Kieran



--
> Boris Mann
> Office 604-682-2889
> Skype borismann
> http://www.bryght.com
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>



-- 
To strive, to seek, to find, and not to yield.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20070817/19f39ba9/attachment.htm