I am working on a module (plugin manager) that will allow new modules and themes to be installed directly from d.o. That much works fine. I am hoping to give the user a better experience however, by being able to provide them with descriptions of the modules, along with screenshots when available.

I have created a patch which adds description and screenshots to the project-list.

CommentFileSizeAuthor
#1 create-history-200808141420.patch1.66 KBAnonymous (not verified)

Comments

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new create-history-200808141420.patch1.66 KB

For some reason konqueror wouldn't upload the patch. Trying again in opera.

aclight’s picture

aclight commented

The code looks good to me, though I haven't tested it.

You are aware that the URL a project maintainer enters for the screenshots field might not actually lead to an actual image file, right? Instead, it could just be a web site with several images, for example. I'm guessing you're just going to put this same link in the plugin manager module and not try to fetch an image and display it directly, right?

Anonymous’s picture

Anonymous (not verified) commented

In reality, that didn't occur to me. I think I'll pretend like it did though (and just give the url.) I guess I had assumed it to be the location of theme thumbnails. (Since that is what I really wanted access to.) ;) Would you happen to know which fields that would be? Granted, I still believe that this would be of use.

dww’s picture

dww
we/he/they
commented

My concern about this patch is that it's yet more data for update_status to download and parse.

a) The update_status XML parser is notoriously fragile. :( Even seemingly benign changes from #157514: Add possibility to retrieve a list of projects from the server ended up breaking it.

b) We're trying to find ways to make sure update_status consumes less RAM and time when downloading/parsing everything. Of course, for better functionality, we need more data, so we can't have a moratorium on adding anything. However, things like the project teaser could add up to significant amounts of data that might exacerbate problems like #232041: Fatal error: Maximum execution time of 60 seconds exceeded (when fetching update status data) and #238950: Meta: update.module RAM consumption.

So, before we commit this and deploy it on d.o, we need to test it carefully, make sure update_status continues to work, and ideally, see about doing some RAM benchmarking to make sure we're not adding significant cost for functionality not everyone is going to use.

Oh, and the images attached to project nodes on d.o are via the image_attach.module. So, you'd just have to figure out how that module does its thing if that's the data you really want to provide.

Cheers,
-Derek

Anonymous’s picture

Anonymous (not verified) commented

You have a very good point.

I suppose I could write the patch for the creation of a new url, much like project-list did, though I think that level of redundancy would likely bring most (including me) to tears. Granted it would have it's advantages. If we know what version of drupal we are running (which we obviously do) then we wouldn't have to include projects/themes/etc that are not compatible with our version, just get the list for 6.x or 7.x... Compatibility terms as a whole wouldn't really be needed. I mean, we could even compress the file. (A quick gzip brought the project-list xml from 1.5Mb to 107Kb.)

I'd better end my wishful thinking before I talk myself into it. :P