Remote Installation of Drupal Modules is now Possible!

Already got it planned!

Once this module becomes a stable, off-the-shelf item, for example, does not cause problems like it did for Martin and CiviCRM then I am going to look into this because I would love to be able to add a button on the Install pages that says 'Check For Updates and Install Them Right Now'. Well, the button text may be shorter!

I think that calling the Update modules, grabbing the output and then presenting a list of modules that needed updating, along with a checkbox and a GO button would be a very nice feature. Potentially I can hook it inas a cron job so that your site always updates automatically. The other alternative is that the Update output screen has an 'UPDATE NOW' button that calls my module instead, whatever people feel is the grooviest solution.

I just installed (effortlessly of course) the Update Module using my module with a view to making them play nicely together. I can see some road ahead where the Release Monitor, Update Module and the Remote Install Module become a single lump of code called 'Your Name Here' to provide an all encompassing site module management package.

Personally the thought of a live web-site automatically updating scares the crap out of me. :-)
Let's get it stable first!

Security Considerations...
I too would be interested as I did consider it before I started. Like I said,I was going to ask for the admin password on the install page but presumably the admin is already logged in at this point. It would be useful for example, if the admin has wandered off leaving the admin user logged in (sack him!) and a malicious person came along...

From a scripting attack / SQL injection etc perspective, I am using ZERO SQL and I have made full use of the Drupal API so on the surface of it, it's as secure as any other Drupal 5 module. What that means in reality I have no idea.

Apart from that I can't really think of any other vulnerabilities. If the tar.gz file contained a malicious module that was unpacked and installed then, on hitting the modules page and executing any install code I guess it could trash the database or do something nasty with unlink() but that would not be the fault of the Remote Install, it would be the module, which, however it was installed would still have done the same thing.

The security black-hats have us all running scared!

Sean Charles

Martin,

OK, maybe I was a little presumptuous about it being the last installation the hard way! I am a little confused about the error though. The ISP that I use *does* provide a PEAR installation to use but I didn't want to take the chance that some other ISP may not have it which is why I included the files.

However, I have used the 'require_once' approach to do so as I did consider that they may already have been dragged in somewhere along the chain before my module gets a shout.

reminst.module --> require_once('obj_remoteinstall.php');
obj_remoteinstall.php --> require_once('Tar.php');
Tar.php --> require_once('PEAR.php');

My conclusion is that, and somebody please tell me I am wrong on this, that the CiviCRM file set must be using files and *not* using the require_once tactic and thus causing a re-definition.

If that is a correct deduction then I can emit a smug grin and say 'Not my fault' and ignore your problem. However, if it is incorrect and it is my fault, then I'll fix it ASAP as I want this to be a *really useful engine* of a module for Drupal 5. It absolutely kicks butt for an open source CMS. I use Joomla a lot because Virtue-Mart 'feels better' than the current e-commerce module set but I have just completed a Drupal e-commerce site and it wasn't that bad either.

So, somebody tell me my mistakes and I will fix it as soon as I can and update the download or downdate the upload or whatever it is we do.

It's a shame it didn't work out of the box thought because I have been using it a day or two and I can't beleive how much time I have saved myself!

Thanks for the feedback,
Sean Charles

Martin.

Essentially, NOT GUILTY!!
I have been doing some reading around and this page sheds some light on the issue you had with getting the error message:

Fatal error: Cannot use string offset as an array in ........../public_html/drupal/modules/system/system.module on line 1431

Have a read, it's dated 2004 but it got me started: http://bugs.php.net/bug.php?id=28107 for some background, eventually I devised a solution.

The 'fix' is to replace the function in system.module, "system_module_build_dependencies()" in two places:

FROM:

      if (!$module->status && $form_values['status'][$name] && isset($module->info['dependencies'])) {

TO:

      $temp=$form_values['status'];
      $temp=$temp[$name];
      if (!$module->status && $temp && isset($module->info['dependencies'])) {

and...FROM:

    if (!$form_values['status'][$dependency] && isset($modules[$dependency])) {

TO:

          $temp1=$form_values['status'];
          $temp1=$temp[$dependency];
          if (!$temp1 && isset($modules[$dependency])) {

This notation could/must be used in all sorts of places so I think that the issue is more to do with PHP 5 than anything else, better minds than me can comment on it.

I am going to make a post on this issue and see what comes out of the woodwork.

Sean Charles.

Wow, time flies!

I thought I'd check out my old module contribution and your comments about me ignoring advice are probably true for the simple reason that I never knew anything about the information you refer to, and in addition as I stated in the intro, it was intended for development mode only.

So, right on both counts but I already knew that!

:)
Sean Charles.