It'd be a nice to use the standard "Manage Fields" page on each node type to set the "RSS Remote Enclosure" form weight, instead of having one setting for all content types.
This patch does the following
- adds a dependency on CCK for the hook_content_extra_fields hook
- Fixes a bunch of Coder module style issues
- fixes a bug where _encl_remote_is_nodetype_allowed returned true for all node types, even if the check box for that node type was unchecked
Please excuse me if I'm doing something inappropriately or if the patch is formatted wrong or if I'm submitting this suggestion wrong. I'm still _very_ new to the developer side of the drupal community! Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| add_per_node_form_weight.patch | 18.44 KB | snyderp |
Comments
Comment #1
zany commentedHi Peter,
I'm not sure if the dependency on CCK isn't a bit "heavy" for such a simple module. But then again this module is for advanced site builders anyway.
Your patch looks good and the cleanup is much welcome. Two separate patches/commits for these two issues would be better.
I'm not actively developing this module at the moment. If you like to help out please open an issue asking to co-maintain this project. It's a prerequisite for CVS access. See http://drupal.org/cvs-application/requirements and http://drupal.org/node/7765
thanks.
Comment #2
snyderp commentedHello Christian,
Thanks much for the response back. I agree that it seems a bit silly to require CCK, but at the same it almost seems like just a formality, because almost every site will have CCK installed anyway (or at least this is my experience).
I would be happy to break the patch up. Would it be best to submit one that adds in the weight functionality and cleanup, and then a second that fixes the _encl_remote_is_nodetype_allowed issue? Or would it be better to split up the changes differently?
Finally, I would be happy to co-maintain the project, though just with the warning that I don't have prior experience managing drupal projects, or even too much with CVS. That being said, if you're comfortable with that I'd be happy to apply for access and manage the project with you. I just might need a little hand holding...
Thanks again for the module too!
Comment #3
reikiman commentedChristian,
I wish to disagree with whether CCK is too heavy for this, and whether it's for advanced site builders anyway. Y'all made me a co-maintainer last year (but then I've done nothing since) in part so that I could add CCK support. I've developed a CCK version of this module but not uploaded the patch.
In any case I wrote up a few thoughts about whether to port this module to D7, and what that port should entail. Link is below. The observation is that CCK provides an easier way to theme this module and incorporate support from SWFTools to directly display the media file. Also using CCK means this module doesn't need to provide its own table definition, CCK could provide it. In a port to D7, doesn't it make sense to convert this module to be a Field type?
I don't think this module should just be for "experts". All the recommendations out there on publishing podcasts - well, they all recommend using Wordpress FWIW - is to paste in a URL provided by a service like libsyn, and host media files on external services. That's completely different from the usual Drupal way of using file upload. BUT, the RSS Remote Enclosure module is what matches the usual recommendation, meaning it's this module which is most compatible with the typical podcasting best practice, and it's the usual Drupal way that's divergent.
http://davidherron.com/content/future-rss-remote-enclosure-module-drupal
Comment #4
zany commentedPeter, David,
the general thought was to separate (whitespace / code guideline) cleanup from actual features. That way it's easier to coordinate with other patches e.g. Davids work.
The phase 2 migration to Git should be soon now. I can help with integration then. With CVS however you two would need to coordinate beforehand. Perhaps David can upload his work-in-progress and Peter can cross-check with his ideas for CCK and cleanup on top of that?
Thanks.
Comment #5
reikiman commentedYeah - one thing I've been waiting for is the git migration because the CVS tagging interface here on drupal.org completely confused me. I tried to create a -dev tag for some work, but I'm pretty sure I did something wrong.
I agree - whitespace cleanup is a separate issue from functionality changes.
I'll locate my code and upload a patch. However it almost completely gutted the module replacing it with CCK code instead. FWIW
Comment #6
zany commentedThe whitespace clean up went into the 6.x-1.x branch. The support for form weight on each node type went into the 6.x-2.x branch which will depend on/support CCK.