ckeditor + Drupal9 gives 403 Forbidden when browsing server

Question

I migrated a D7 site + civi to Drupal 9.

Everything works fine except in the CKEditor when I click on "browse server": I get the error 403 Forbidden. (the URL is MYSITE/libraries/civicrm/packages/kcfinder/browse.php?cms=civicrm&type=images&CKEditor=html_message&CKEditorFuncNum=0&langCode=en)

I upgraded today to 5.40.2, but I get the same error.

I tried CKEditor 5 (https://civicrm.org/extensions/ckeditor-5), but then I get the error: Invalid backend response. Error occurred on the server side. HTTP error 500.

Does anybody know what the issue could be? htaccess? Folder permissions?

How can I further debug this?

Thanks!

Answer 1

To get ckeditor 4 working in Drupal 9, you have to look at the http error you get:

• 404: means the library cannot be found
• 403, 500: means an access / permission problem

Personally, I had the 404 error first.

When I tried to browse for an image on the server, the url in the window was:

libraries/civicrm/packages/kcfinder/browse.php?cms=civicrm&type=images&CKEditor=html_message&CKEditorFuncNum=0&langCode=en

But looking at the files on the server, there was no browse.php file in libraries/civicrm/packages/kcfinder

However, in my installation I could find it in vendor/civicrm/civicrm-packages/kcfinder

So I copied the kcfinder directory from vendor to libraries:

cp -r vendor/civicrm/civicrm-packages/kcfinder web/libraries/civicrm/packages

Now, the browse.php file could be found, but I got an access error.

I solved this by adding the following lines to the .htaccess file.

  RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder.*$
  RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern.*$

Add these lines above the line:

  RewriteRule "^(.+/.*|autoload)\.php($|/)" - [F]

Next issue was that the civicrm configuration file could not be found. The installation tries to locate the file civicrm.config.php but it was not available.

You should copy this file from a Drupal7 installation to the directory:

  web/libraries/civicrm

This file tries to fill in the variable $settingsFile with the exact location of civicrm.settings.php.

For some reason, the code could not locate my file. Because I ran out of patience, I replaced:

  $settingsFile = civicrm_conf_init() . '/civicrm.settings.php';

with the hard coded path of my settings file:

  $settngsFile = '/var/www/ (...etc...) sites/default/civicrm.settings.php';

I would like to hear from Drupal 9 experts how this can be improved!

Answer 2

For two days, i couldn't get kcfinder working. After clicking on "browse server" it tries to load the link below and then gives http 403 forbidden.

libraries/civicrm/packages/kcfinder/browse.php?cms=civicrm&type=images&CKEditor=crmUiId_1&CKEditorFuncNum=0&langCode=en

Yes, i tried putting code under "composer.json in the extra section", followed by "composer civicrm:publish" as suggested here: https://lab.civicrm.org/dev/civicrm-asset-plugin/-/issues/4

While, it did copy the files to libraries/civicrm/packages/kcfinder, it didn't solve the 403 issue.

Note: kcfinder isn't maintained (last update 2014 according to links below)

My solution is TO move to ckeditor5 and its fileManager.

From the docs

An ongoing challenge with ckeditor4 as implemented with CiviCRM is that the filemanager (kcfinder) is pretty hard to work with and requires some hacks to be able to figure out paths.

Integrations. The integration that currently looks most promising is elFinder This is currently being maintained (as opposed to kcfinder which is not). See under fileManager https://lab.civicrm.org/extensions/ckeditor5

Steps to get ckeditor 5 working:

• cd to your ext dir, then.

• wget -vv https://lab.civicrm.org/extensions/ckeditor5/-/archive/1.5/ckeditor5-1.5.zip

• unzip ckeditor5-1.5.zip

• chown and chmod to set permissions on the downloaded ckeditor5 extention

• cd to your [project-root] where you have composer.json, then

• enable the ckeditor5 extention (cv -vv ext:enable ckeditor5)

• setup the new ckeditor5 extention as per "usage section" of : https://lab.civicrm.org/extensions/ckeditor5

• Then get the elfinder (file upload manager to work. look at Wiki pages!) https://github.com/Studio-42/elFinder

more on docs: https://civicrm.org/extensions/ckeditor-5

If you're using Drupal, you may try this old docs of getting Drupal file manager (IMCE) to work for civicrm.

**haven't implimented this myself.

https://civicrm.org/it/blog/kurund/enable-image-uploads-and-server-browsing-for-ckeditor

Answer 3

I had exactly the same issue and solved the problem with the new Summernote extension.

We needed for various reasons to have access to the underlying code (the old 'Source' toggle to see the underlying HTML) and the current version of CKEditor5 available via the CKEditor5 extension did not support it. There was discussion about merging the newer CKEditor5 code in, which does now have a source editor, but as of writing this it was not yet there.

Installation of Summernote is via the command line, but is very straight forward:

1. Go to your current extensions directory

2. Download the url defined in the download link. For me this was: wget -vv https://lab.civicrm.org/extensions/summernote/-/archive/1.2.2/summernote-1.2.2.zip

3. unzip summernote-1.2.2.zip

4. enable the extension either through the UI or just run

   cv en summernote if your setup requires you to run this as a particular acount use the --user=my_user option

5. Go to Administer -> Customise Data and Screens -> Display Preferences and select Summernote as your WYSIWYG editor:

6. Check it works as exepected and then clean up by deleting the downloaded Zip file

That's about it - there are some more options available to look at, but we are using successfully straight out of the box with the defaults. This is where to find the other settings in case you need them.

Administer -> Customise Data and Screens -> Summernote

So now we have a source editor and the elFinder file browser (this replaces kcfinder) working perfectly under Drupal 10 and CiviCRM 5.66.2 (as of writing). Hope this helps as I suspect many will run into this when upgrading to the latest Drupal.