Active
Project:
jQ
Version:
5.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
24 Jan 2008 at 21:32 UTC
Updated:
1 May 2008 at 22:36 UTC
Jump to comment: Most recent file
Im really glad someone finally took the time to this, from a pure developer standpoint I think it would be so great if when you invoke jq_add(); if it would copy the latest version from the repo, and then mark it downloaded to which point then it must manually be updated ( via UI ), and then supply jq.module with an array of common jQuery plugins. I would prefer something like this over adding additional 'plugin' modules
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | jq_media.png | 150.21 KB | aaron |
Comments
Comment #1
mfbThree caveats:
Comment #2
tjholowaychuk commentedTrue, I do agree with your statements, but I also do think that this functionality is something Drupal really does need as we integrate more and more core code with jQuery plugins.
1. The latest version may not work with the version of jQuery currently installed on the Drupal site;
The jQuery version should be a global that is accessible to the system IMO.
2. A plugin module is still sometimes useful, e.g. to provide a settings page, load CSS files, etc.; and
This is true, perhaps a function such as jq_require($plugin, $version) would allow for the module to still include the appropriate files/code of its own while still having the central repo for these plugins
3. When automatically fetching executable scripts, some security procedures are called for, such as use of signature verification, checksumming and so forth.
No arguments here :)
Something to think about! I just think it would be a great step for Drupal 7
Comment #3
aaron commented1. we've already had problems with this in the past -- jquery 1.2 itself broke fieldsets in drupal 5, thus we needed jquery_update to fix.
2. it might also be a nice feature to at least show any other available plugin modules that might not yet be installed. if someone wants to know what bling they're missing...
as far as 3, i've heard about work being done for modules with this, with interested folks well aware of security concerns. i'm going to leave it up to them. if this happens, it will happen automatically for us, since we're just using wrapper modules.
Comment #4
tjholowaychuk commentedI have started my 'vision' of what a plugins module may function like. http://drupal.org/project/plugins
After discussing with others we may also benefit from using this module with abstracted filetypes not just javascript/jQuery plugins. Ideally nearly any 3rd party project could potentially be a 'plugin'. As of right now there is no support for archived plugins, but this is in the plans.
Security will be relatively low on this modules behalf as it will simply be fetching/managing the plugins, not adding them via drupal_add_js etc.
Comment #5
aaron commentedhmmm... interesting idea. i'm still not completely keen on the automatic fetching, and i see you have versioning on your todo (which is another important piece, and reason for this idea).
Comment #6
tjholowaychuk commentedCertainly, the jQuery world seems a little messed up in regards to normalizing version/packaging conventions, which is really to bad that would make things muuuch more efficient. It is defiantly just at a prototype stage right now, hour or two of work but hopefully soon I will have more time.
The thing I like about the fetching method is that by abstracting out these plugins into their own specific directory, modules can truly 'share' plugins of the same type/version, eliminating wrapper modules.
Comment #7
mfbI would definitely be interested in some system to make the latest working version of any jQuery plugin easily available to drupal sites. Having one plugin aggregator/publisher site with a database of stable versions and a standard packaging script would help. Infrastructure for this perhaps could/should be built in to the plugins.jquery.com site itself, which after all is a drupal site, although at the moment you cannot always find the latest versions there. Otherwise building something akin to freebsd ports may be needed...
As far as installing and updating plugins on a site, typically I am not usually willing to have code (including javascript and css) dynamically downloaded, I want it to be incorporated into the code repository for the project I'm working on. So I'm not sure the Plugins module idea works for me.
Comment #8
tjholowaychuk commentedTrue that is a very valid statement, and I do agree. Although 'installing' them after a site has been moved or what have you, would be a single click. Not to mention versioning them almost has no point since they are purely 3rd party.
Comment #9
mfbFor me and I'd guess most development shops, everything including 3rd party is versioned because there are multiple instances -- developer sandboxes, QA sites, staging, production -- and new instances have to be created all the time.
Comment #10
tjholowaychuk commentedThere is no reason you could not version these plugins though. Your initial instance could install them as required, then commit and bam no problems. Not saying I dont agree, because I really do but I am trying to think about the 'non-developer' end-user as well.
Comment #11
aaron commentedA compromise might be to have the plugin module interface with jq, so it's not duplicating functionality, but also stands out by providing this service to administrators interested in that.
the plugin module could implement hook_jq, which simply lists all the plugins installed through that module. in d6, that would be place in plugins.jq.inc to make the module lighter in weight.
in fact, jQ has a settings hook, so you could just put the 'upload new version' info straight on the jq plugin admin page within the plugin info sections, to keep things consistent. and just modify the form or add a tab to that settings page to list the available but uninstalled.
the jquery_media module implements that hook already, to give additional functionality for that plugin (visible as 'extra settings', but you can add any form elements). screenshot included.