Hiya Is there best practice for 3rd party plugins? Recently a tiny site was upgraded, the fckeditor module was updated but the dev didn't re-add fckeditor. The owner didn't notice for ages and eventually I have to work backwards through backups to make sure I get the right (possibly customized) package. So I've started creating a sites/all/plugins folder for all the fckeditors / swfobject / jqueryplugins / pdfwriters / etc that I need for a job. I then use symlinks, so in the scramble the fix is simple. It's nice too I can put different versions of tools side by side, and the symlink just points to the desired one. In theory it would be great if modules expected a plugin folder. For non-professionals we put them under duress with install instructions that tell them to clutter their modules with plugins, making upgrades harder for them, and I think we send the message that altering modules is ok. Thoughts or guidance? Thanks Simon Hobbs / sime
I think a lot of amatuers would overwrite the existing module folder with the updated version (or use plugin_manager - which does the same thing) - that way any plugin folders inside the module folder should remain intact.
Hi Simon, Separate location for editor libraries http://drupal.org/node/320562 investigates exactly this issue. Of course, that is closely tied to Wysiwyg API - but from all contrib modules out there, I assume that Wysiwyg API is the one that needs this most. Let's discuss on-issue. sun
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Simon Hobbs Sent: Wednesday, May 13, 2009 2:24 AM To: development@drupal.org Subject: [development] 3rd party sites/all/plugins
Hiya
Is there best practice for 3rd party plugins?
Recently a tiny site was upgraded, the fckeditor module was updated but the dev didn't re-add fckeditor. The owner didn't notice for ages and eventually I have to work backwards through backups to make sure I get the right (possibly customized) package.
So I've started creating a sites/all/plugins folder for all the fckeditors / swfobject / jqueryplugins / pdfwriters / etc that I need for a job. I then use symlinks, so in the scramble the fix is simple.
It's nice too I can put different versions of tools side by side, and the symlink just points to the desired one.
In theory it would be great if modules expected a plugin folder.
For non-professionals we put them under duress with install instructions that tell them to clutter their modules with plugins, making upgrades harder for them, and I think we send the message that altering modules is ok.
Thoughts or guidance?
Thanks Simon Hobbs / sime
sun FWIW, I felt that SWF Tools, which has heaps of plugins, also suffered from this (swfobject, flash players, etc). Thanks for the thread link. Simon On Wed, May 13, 2009 at 4:28 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
Hi Simon,
Separate location for editor libraries http://drupal.org/node/320562
investigates exactly this issue. Of course, that is closely tied to Wysiwyg API - but from all contrib modules out there, I assume that Wysiwyg API is the one that needs this most.
Let's discuss on-issue.
sun
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Simon Hobbs Sent: Wednesday, May 13, 2009 2:24 AM To: development@drupal.org Subject: [development] 3rd party sites/all/plugins
Hiya
Is there best practice for 3rd party plugins?
Recently a tiny site was upgraded, the fckeditor module was updated but the dev didn't re-add fckeditor. The owner didn't notice for ages and eventually I have to work backwards through backups to make sure I get the right (possibly customized) package.
So I've started creating a sites/all/plugins folder for all the fckeditors / swfobject / jqueryplugins / pdfwriters / etc that I need for a job. I then use symlinks, so in the scramble the fix is simple.
It's nice too I can put different versions of tools side by side, and the symlink just points to the desired one.
In theory it would be great if modules expected a plugin folder.
For non-professionals we put them under duress with install instructions that tell them to clutter their modules with plugins, making upgrades harder for them, and I think we send the message that altering modules is ok.
Thoughts or guidance?
Thanks Simon Hobbs / sime
FWIW, I felt that SWF Tools, which has heaps of plugins, also suffered from this (swfobject, flash players, etc). Thanks for the thread link.
Simon
I see. I know that there are thoughts and approaches for Drupal core already. But I really think this is something we have to iron-out in contrib, because core on its own does not ship with functionality that depends on external libraries. It would be great if we could standardize on something, maybe starting with SWF Tools and Wysiwyg API. So, let's discuss on-issue, please. sun
I'm in favor going forward of using sites/all/plugins for third party plugins. First, it's a centralized location, and the convention is being adopted throughout contrib, and even core (http://drupal.org/node/315100). Secondly, as you note, it discourages the practice of directly modifying a module directory structure. Thirdly, it allows for drupal_get_path('plugins', 'foo'), if a foo.info file exists (i.e., /sites/all/plugins/foo/foo.info). Aaron Simon Hobbs wrote:
Hiya
Is there best practice for 3rd party plugins?
Recently a tiny site was upgraded, the fckeditor module was updated but the dev didn't re-add fckeditor. The owner didn't notice for ages and eventually I have to work backwards through backups to make sure I get the right (possibly customized) package.
So I've started creating a sites/all/plugins folder for all the fckeditors / swfobject / jqueryplugins / pdfwriters / etc that I need for a job. I then use symlinks, so in the scramble the fix is simple.
It's nice too I can put different versions of tools side by side, and the symlink just points to the desired one.
In theory it would be great if modules expected a plugin folder.
For non-professionals we put them under duress with install instructions that tell them to clutter their modules with plugins, making upgrades harder for them, and I think we send the message that altering modules is ok.
Thoughts or guidance?
Thanks Simon Hobbs / sime
-- Aaron Winborn Advomatic, LLC http://advomatic.com/ Drupal Multimedia available in September! http://www.packtpub.com/create-multimedia-website-with-drupal/book My blog: http://aaronwinborn.com/
Hi Aaron I've posted some ideas on sun's link http://drupal.org/node/320562 would love your comments there, as WYSIWYG could be a great leader in establishing a convention. Simon On Thu, May 14, 2009 at 1:14 AM, Aaron Winborn <winborn@advomatic.com> wrote:
I'm in favor going forward of using sites/all/plugins for third party plugins. First, it's a centralized location, and the convention is being adopted throughout contrib, and even core (http://drupal.org/node/315100). Secondly, as you note, it discourages the practice of directly modifying a module directory structure. Thirdly, it allows for drupal_get_path('plugins', 'foo'), if a foo.info file exists (i.e., /sites/all/plugins/foo/foo.info).
Aaron
Simon Hobbs wrote:
Hiya
Is there best practice for 3rd party plugins?
Recently a tiny site was upgraded, the fckeditor module was updated but the dev didn't re-add fckeditor. The owner didn't notice for ages and eventually I have to work backwards through backups to make sure I get the right (possibly customized) package.
So I've started creating a sites/all/plugins folder for all the fckeditors / swfobject / jqueryplugins / pdfwriters / etc that I need for a job. I then use symlinks, so in the scramble the fix is simple.
It's nice too I can put different versions of tools side by side, and the symlink just points to the desired one.
In theory it would be great if modules expected a plugin folder.
For non-professionals we put them under duress with install instructions that tell them to clutter their modules with plugins, making upgrades harder for them, and I think we send the message that altering modules is ok.
Thoughts or guidance?
Thanks Simon Hobbs / sime
-- Aaron Winborn
Advomatic, LLC http://advomatic.com/
Drupal Multimedia available in September! http://www.packtpub.com/create-multimedia-website-with-drupal/book
My blog: http://aaronwinborn.com/
I'm in favor going forward of using sites/all/plugins for third party plugins. First, it's a centralized location, and the convention is being adopted throughout contrib, and even core (http://drupal.org/node/315100). Secondly, as you note, it discourages the practice of directly modifying a module directory structure. Thirdly, it allows for drupal_get_path('plugins', 'foo'), if a foo.info file exists (i.e., /sites/all/plugins/foo/foo.info).
Aaron
I specifically did not point to that core issue, because the way "plugins" are discussed there is something completely different. Modules don't ship with external libraries and external libraries do not ship with .info files. Period. The entire proposed design for "plugins" does not apply. Luckily, sime already followed up on the other issue and added valuable thoughts about requirements of SWF Tools and potential other use-cases. sun
participants (4)
-
Aaron Winborn -
Daniel F. Kudwien -
Naheem Zaffar -
Simon Hobbs