In the current version you are limited to placing the editors in a install profile or the sites folder. In our company SVN based distribution system we are unable to place these items in either areas 1) we have multiple install profiles so it would require duplicating code 2) our base drupal repository does not include the "sites" folder. Instead we need to place it somewhere in the root, we decided that the (root)/libraries folder would be the best place as it doesn't depend on anything else. The attached patch adds this as a searching directory, hopefully we can get this into the next release as I see it may be useful for others using the module.




rickvug’s picture

I work with Rob and asked him to write this patch, which is now in use with our internal base Drupal install. This issue was raised earlier at The install profile option was given does not work in our case. We have 3 install profiles so we'd have to duplicate code or use symbolic links in place of this patch.

It would be great to get this patch (or a variation) committed so we don't have to maintain it separately over the long term. We will be available to revise the patch and/or apply to the Libraries API if needed.

sun’s picture

Please explain why sites/all/libraries does not work.

rickvug’s picture

"sites/all/libraries" does not work for this case because the sites directory does not exist in our internal Drupal distribution (think of Acquia Drupal as a parallel). "/sites" is completely different for every site/install and is normally checked out from a separate code repository than the base Drupal distribution. Since we use WYSIWYG on most sites, it makes sense to include the module and necessary editor libraries directly in the distribution.

I understand that this is an edge case but I'd assume that we're not the only shop needing something like this. Also, this patch would make the libraries directory follow the override convention set in core for modules and themes. Example: /modules, /profiles/example/modules, sites/all/modules or sites/

sun’s picture

Title:Allow placement of editors in (root)/libraries» Allow placing libraries in root directory
Project:Wysiwyg» Libraries API
Version:6.x-2.0» 6.x-1.x-dev
Status:Needs review» Needs work

ok, let's do this - however, not for Wysiwyg, but the new Libraries API, Wysiwyg module requires in 3.x.

sun’s picture

Issue tags:+Libraries


rickvug’s picture

@sun - I missed your earlier comment. Thanks for accepting the change for Libraries API / WYSIWYG 3.x. We'll maintain this patch for the 2.x life-cycle (unless the patch magically gets committed of course).

tstoeckler’s picture

Status:Needs work» Needs review
new955 bytes

Updated / rerolled patch for Libaries API.
I added an extensive code comment and changed the order to match the core module/theme lookup pattern.
Tested it to work as intended.

tstoeckler’s picture

I just realized that a drupalroot/libraries folder would actually be the correct place for the core jquery / jqueryUI libraries instead of that crazy mess of a /misc folder. Since I guess the goal is for Libraries API to end up in core.
(Yeah, I know, it's really just a bump...)

sun’s picture

Status:Needs review» Fixed

+++ libraries.module 23 Feb 2010 07:42:27 -0000
@@ -71,6 +71,11 @@ function libraries_get_libraries() {
+  // Similarly to Drupal core providing modules and themes in the 'modules' and
+  // 'themes' directories in the Drupal root directory, certain distributions may
+  // want to place libraries in a 'libraries' directory in the Drupal root directory.
+  $searchdir[] = $directory; ¶

Note: Comment exceeds 80 chars and trailing white-space.

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Powered by Dreditor.

Status:Fixed» Closed (fixed)
Issue tags:-Libraries

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