Problem/Motivation

Currently, there is no way to use this module as a dependency in a profile. Working with OpenY we faced to a problem that when libraries folder is locating in a profile this module does not work, because of the path to the library is using only libraries folder in the root directory and module does not expect that libraries could be located in other places.

Proposed resolution

Add supporting module libraries in a case when this module installed, to be sure module will find needed library even if it is locating in a profile.

Remaining tasks

Review patch.

User interface changes

None.

API changes

None.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ddrozdik created an issue. See original summary.

ddrozdik’s picture

Status: Active » Needs review
FileSize
1.39 KB

Here is a patch.

ddrozdik’s picture

FileSize
1.57 KB

Here is updated version of the patch.

hamrant’s picture

Status: Needs review » Reviewed & tested by the community

Looks good for me

ddrozdik’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
1.55 KB

I found an issue with the latest patсh. Here is update version.

  • ddrozdik committed 64bcd28 on 8.x-1.x
    Issue #2881822 by ddrozdik: Module can't find library in profile...
ddrozdik’s picture

Status: Needs review » Fixed
finne’s picture

This fix breaks the loading of the js file when you deploy to a subdir of the server document root (when the base path is not just "/"). It hard-codes the base path as "/".

finne’s picture

Added fixed patch that uses base_path() instead of "/".

finne’s picture

Status: Fixed » Needs review
ddrozdik’s picture

Assigned: Unassigned » ddrozdik
kevinquillen’s picture

This was previously removed because it was breaking for others who had different configurations, like subdirectory installs of Drupal.

As much as I don't want to drag in the dependency, it seems unavoidable now to use the Libraries API so that all cases can be supported (where people are storing their libraries).

I've hesitated because it has no beta/stable release, but issues like this continue popping up on all CKEditor based plugins.

finne’s picture

Are we talking about the same thing here?

Unpatched the path would be a relative path starting with "libraries/...".
Patch #5 adds an optional check on the Libraries module, but defaults to a hard coded path starting with "/libraries/...".
Patch #9 adds base_path() instead of "/" to the default option.

This way you don't depend on the Libraries module, but you can use it if it's present.
(yes a universal Libraries based solution would be ideal but as kevinquillen says it's not stable yet)

kevinquillen’s picture

Yeah. I believe I had base_path in at one point, and removed it (could have been another CKEditor module) because it was not satisfying everyone. I think eventually we will need Libraries API to cover every possible use case, and have one common function for obtaining its location instead of assuming. But we need a somewhat stable release, first..

SylvainM’s picture

CKEditorPluginInterface::getFile() doc says: "Returns the Drupal root-relative file path to the plugin JavaScript file."
So, when adding base_path() or "/", it becomes an absolute, and wrong, path: "/libraries/colorbutton"

I think it should be "libraries/colorbutton".
README says: "Place the plugin in the root libraries folder (/libraries).", so you can't place the library elsewhere.

attached patch

holist’s picture

It seems to me also that @SylvainM is correct; using "/" in the beginning gives file system root, not Drupal root.

holist’s picture

Status: Needs review » Reviewed & tested by the community

Latest patch applies fine and does what it is supposed, I propose RTBC.

XTaz’s picture

Warning : file_get_contents(/libraries/colorbutton/plugin.js): failed to open stream

#15 works fine for me. Thanks

rooby’s picture

Note that there seems to be some roadblocks with the libraries module, so I would +1 kevinquillen in not using that just yet. See #1704734: [master] Libraries API 8.x-3.x

Krzysztof Domański’s picture

Assigned: ddrozdik » Unassigned
Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

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