The dependency on the 'update' module is unnecessary for day-to-day operation of apps-enabled Drupal sites, as installation and updates typically only occur infrequently on a production site after adequate testing. It is a reasonably common practice to disable 'update' on production sites in order to avoid unnecessary available updates error messages and reduce cron processing time.

I propose that apps.installer and apps.updater are moved into a secondary module to separate management tasks from installation/upgrade tasks.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joelcollinsdc’s picture

I agree that a dependency on update is unfortunate; especially for distributions where apps is most likely to be used, the update module is a distraction since most updates are probably going ot be distrubution updates, not module-by-module.

beeradb’s picture

Issue summary: View changes
FileSize
7.79 KB
mrP’s picture

nice!

+1 RTBC

beeradb’s picture

beeradb’s picture

I was a bit overzealous with skipping install steps initially :) This latest patch installs fine for me, and I can't find any places where apps.module is not working correctly. Eventually we'll probably want to add an access check to the "admin/apps/%apps_server/update" menu path, but that page is currently just a "CURRENTLY UNDER DEVELOPMENT" message, so I think we can skip it for now.

beeradb’s picture

Status: Active » Needs review
beeradb’s picture

Also there are a lot of whitespace changes in the file, which are all just trimming trailing whitespace (editor automatically does it). I can re-roll without those changes if necessary.

hefox’s picture

Perhaps a simplier root would be checking for update module and disabling certian functionality if it's not enabled?