Enable auto-discovery of module locations and module information screen
dsantangelo - November 23, 2008 - 02:20
| Project: | Patterns |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Description
This patch is twofold:
1) Enables and finishes the stubbed-out patterns modules page: patterns_modules_page(). Link added to the main patterns page, underneath the existing "View Details" link
2) If a module included in the pattern does not exist on the site, Patterns will attempt to auto-discover the URL to the modules included in a given pattern. If found, links are created on the patterns modules page. Clicking the download link will download the module, untar it, and delete the tarball.
| Attachment | Size |
|---|---|
| patterns_auto_download.patch | 6.09 KB |
#1
Heh, #2 is worded weirdly. Let me try again:
"If a module included in the pattern does not exist on the site, Patterns will attempt to auto-discover the URL to each missing module."
#2
Hi Domenic,
Thanks for submitting the patch.
I just made initial release of D6 port of patterns, so I re-rolled your patch against current D6 version (DRUPAL-6--1). The idea is to continue with new development on Drupal 6 version and backport to D5 if that makes sense and is required. Re-rolled patch also includes few minor changes and fixes. There are few issues that still need to be addressed:
- path to modules directory is hard-coded (sites/all/modules). This may work in most common cases but will fail for any multi-site setup or non-standard installation.
- broken download link should not be shown if download link auto-discovery fails
- downloaded module is unpacked as apache user (www-data, nobody) with permissions 755. That makes it impossible for site admin to edit/delete module folder afterwards when logged in as a regular FTP user
- maybe check for the write permissions on modules directory before building the modules page and skip calculating download links if directory is not writable
- Unix commands (tar, rm) don't work on Windows so it would be good to check for OS and take appropriate action. It's probably easiest to disable auto-download on Windows (at least for now) with appropriate message displayed to user.
- path to modules directory may not be calculated properly if site is hosted in subdirectory
- what were your ideas about improving the method of determining URL of missing module's project page? Currently, it fails for CCK (it looks for "content" instead of "cck") and any sub-module (module packaged within another module - like nodereference, date_timezone, etc)
We should also think about alternative approach for this functionality, since it is very uncommon to have write permissions on modules folder. But in any case, I would like to get this patch in and move forward from there.
Thanks,
Vaish
#3
And here goes the patch :)
#4
Yesterday I overlooked one very important aspect - security. In its current form, this patch is vulnerable to CSRF attacks.
Under certain conditions, malicious user could load "get_module" page and download some malicious code to your system (instead of Drupal module).
This should definitely be taken care of.