everything is great about this module - the great promise and utility. But it simply doesn't work. I tried the latest and then even the dev version. Searched for the autosave module and it didn't list anything. Simple enough I got rid of this hoax.

Comments

kbahey’s picture

kbahey commented

Call it as a hoax is an insult to the authors and mentors of this project.

You will get better answers if you ask politely.

Anonymous’s picture

Anonymous (not verified) commented
Title: Doesn't work at all » Project XML feed needs work

The Plugin Manager gets its list of available pages modules from http://updates.drupal.org/release-history/project-list/all. It's an xml feed on drupal.org that (in theory) contains a list of all themes and modules on the d.o website, the versions of drupal that they are compatible with and so on.

Unfortunately, there is a problem with this. http://drupal.org/node/157514 documents it fairly well. Long story short. The file isn't being updated because it was producing incorrect results.

I just grabbed the hosted xml file. Here is the section for autosave:

--Start--
<project>
<title>Autosave</title>
<short_name>autosave</short_name>
<link>http://drupal.org/project/autosave</link>
<dc:creator>edkwh</dc:creator>
<terms>
<term><name>Projects</name><value>Modules</value></term>
<term><name>Projects</name><value>Content</value></term>
<term><name>Projects</name><value>Utility</value></term>
</terms>
<project_status>published</project_status>
<api_versions>
<api_version>5.x</api_version>
</api_versions>
</project>
--End--

The key is api_versions. Drupal's XML feed only lists 5.x compatibility. You aren't running Drupal 5.x, so the plugin manager won't give you the option of installing an incompatible module. The problem with the hoax is with the information that is given to it. (Oh, and I understand the frustration that can be felt when something doesn't work the way you want it to. I don't take "hoax" personally. Humorously perhaps, but not personally.)

Edit: Fixed a typo.

Anonymous’s picture

Anonymous (not verified) commented

This actually brings up a point I've been wondering about. Instead of using the project list (which contains 90% unneeded data) would it be possible to create our own repository? The result would be a much smaller, much simpler (and potentially more useful) file.

The current file looks something like this (for every single project):
<project>
<title>S5 presentation player</title>
<short_name>s5</short_name>
<link>http://drupal.org/project/s5</link>
<dc:creator>greggles</dc:creator>
<terms>
<term><name>Projects</name><value>Modules</value></term>
<term><name>Projects</name><value>3rd party integration</value></term>
<term><name>Projects</name><value>Content display</value></term>
</terms>
<project_status>published</project_status>
<api_versions>
<api_version>6.x</api_version>
<api_version>5.x</api_version>
<api_version>4.7.x</api_version>
</api_versions>
</project>

It contains a potluck of projects for every api_version and projects with no official releases.

Ideally this could be rewritten
<repository>
<version>6.x</version>
<link_base>http://drupal.org/project/</link_base>
<term_def><term>Modules</term><id>1</id></term_def>
<term_def><term>3rd party integration</term><id>2</id></term_def>
<term_def><term>Content display</term><id>3</id></term_def>
<project>
<title>S5 presentation player</title>
<short_name>s5</short_name>
<term>1,2,3</term>
<screenshot>This would mainly be used for themes<screenshot>
</project>
</repository>

It would be addressed by drupal.org/***SOMEADDRESS***/**api_version**. No need to list all of the versions that it would work on (because we only care if it works on our version). No need to display unpublished projects, or projects with no releases. It would certainly cut down on the work/time/bandwidth of having to parse the current project_list. I estimate it to be well under half the size of the current feed.

kbahey’s picture

kbahey commented
Priority: Critical » Normal

I don't think we can "create our own" independently of the project module.

But what we can do is create patches for the project module and instead of http://updates.drupal.org/release-history/project-list/all we have http://updates.drupal.org/release-history/project-list/all/VERSION/short (not the VERSION and "short" qualifier) at the end. That would have the short format you suggested.

If the patch gets accepted we get what we want.

I think this is where the code is:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/project/rel...

Perhaps in the project-release-create-history.php or project-release-serve-history.php files.

Anonymous’s picture

Anonymous (not verified) commented

I actually wasn't aware that they would let us do that. To be honest, that group intimidates me just a little bit. :P Why is it that I've never told you you're a genius?

kbahey’s picture

kbahey commented
Title: Project XML feed needs work » Create a shorter project XML for plugin_manager
Version: 6.x-1.1 » 6.x-1.x-dev

There is other good reasons for us NOT to build our own repository:

1. Security and trust. Having the repo on d.o itself means it cannot be independently poisoned with trojans or other malicious code.

2. Centralization and Infrastructure: d.o is where all the modules get committed, so it is only logical to have a list of modules reside there too.

Having a shorter XML feed will also benefit Drupal.org itself as usage of plugin_manager grows: less data to be transferred (bandwidth), less memory usage for users, ...etc.

Just look into the code and see if you can create a patch.

kbahey’s picture

kbahey commented

One more benefit to a shorter XML file is that we can separate accesses from update_status.module and plugin_manager.module from a d.o statistics point of view.

So, we can see how much usage it is getting this way.

jabapyth’s picture

jabapyth commented

while were at it, could the xml file include a little blurb about each module? (it could just be the description in the .info file). It would be really helpful in the search/selection interface to be able to tell the users *what* the module is actually going to do -- often names just aren't enough.

Anonymous’s picture

Anonymous (not verified) commented

That would be nice, though it was pointed out in the project module that this could make the XML feed extremely large.

kbahey’s picture

kbahey commented

This is a good feature to have, and I think that the shorter XML would more than make up for the bloat caused by it.

However, there are issues, the .info is not a 1:1 per project. It is 1:M, i.e. each project can contain more than one module, and hence more than one .info file. Which one do we use?

Ideally, it should be the first line of the project's node's body, but many project maintainers don't know this guideline, let alone abide by it. The Druplicon bot in the IRC channels warns about this, but other than that, it is freeform.

jabapyth’s picture

jabapyth commented

i think that *most* modules have one .info file (at least in the base directory of the module), and that can be the one that we use.
For the few exceptions....i dont know. could we just pick one? or find the .info that lists the "Name" as matching the project name.

wait -- each project has only one .info, right? thats the one to use.

kbahey’s picture

kbahey commented

No, each module has its own .info file. It is not per project.

You can check out contrib for 6.x, and then using some find/grep commands find out how many are 1:1 and what percentage are those that have more than one .info in the main directory.

jabapyth’s picture

jabapyth commented

arrg ;) i wrote <short_name>.info, but the <short_name> part got filtered out ;)
-- each project has only one <short_name>.info, right?

Anonymous’s picture

Anonymous (not verified) commented
Title: Create a shorter project XML for plugin_manager » XML feed for d.o not working
Status: Active » Fixed
Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Active

Oops. Turns out that that was a but premature. It seems that the CVS version is working. I assumed the live version was working also.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Fixed

It seems that it has been fixed now. :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.