kcfinder libraries is missing files

changed the description

@karunadev what exactly is broken in your civicrm installation? And what version are you on and what cms? Did you also chekc whether this is still broken on https://dmaster.demo.civicrm.org?

I will close this issue as it is unclear whether this a bug in civicrm or whether something is wrong on this particular installation.

closed

I'm re-opening this because I'm seeing (what I believe is) the same error on d8-master and on a live d8 site, specifically as the OP says:

the functionality to find and upload images in CiviMail or CiviEvent does not work and produces a 'page not found' error Here's a screenshot:

I have not yet begun debugging in CiviCRM, just reporting that this is indeed an issue in d8-master.

reopened

changed the description

added git:civicrm-core sig:bug triaged labels

At this moment, this problem currently does NOT appear on https://dmaster.demo.civicrm.org/. Is anyone here aware of a code change that would have fixed this issue? I hesitate to close this without at least having evidence that it was intentionally (or durably) fixed.

Please ignore this comment, as it refers to dmaster, not d8-master.

I don't think anything's changed. It does still happen on d8-master (Drupal 8).

Oh, I'm silly. My comment referenced dmaster, not d8-master. Yes, it's still an issue in D8.

I'm seeing this same issue in a test upgrade of a D8/Civi site. Site is based on the old Roundearth D8 project template, but the new asset-plugin is in use. Target upgrade versions: Drupal v8.9.11, Civi v5.32.1.

Manually copying over the kcfinder files from the vendor folder seems to get the browser working, but I'm unsure what else might be broken at this point. It's obvious, however, that the asset plugin isn't copying over the right files to make things functional.

The asset plugin doesn't copy php files, just typical front-end assets like jpgs and js files (see default-config.json), because otherwise it would be insecurely making all the php files available. But kcfinder requires its php files to be web-accessible for this popup to work.

I haven't tested this but if you edit default-config.json to add something like this to the "include" section (not sure of the right syntax) then run composer civicrm:publish, it might work:

**kcfinder/**

If it does maybe we could add that to the default-config.json permanently.

for a client we put this in their composer.json in the extra section

        "civicrm-asset": {
           "path": "htdocs/libraries/civicrm",
           "url": "/libraries/civicrm",
           "assets:packages": {
             "+include": ["kcfinder/**"]
           }
        },

Also had to apply the following patch before running the composer civicrm:publish

--- a/vendor/civicrm/civicrm-packages/kcfinder/integration/civicrm.php
+++ b/vendor/civicrm/civicrm-packages/kcfinder/integration/civicrm.php
@@ -42,7 +42,7 @@ function checkAuthentication() {
     $current_cwd   = getcwd();
     $civicrm_root  = dirname(dirname(getcwd()));
     $authenticated = false;
-    require_once "{$civicrm_root}/civicrm.config.php";
+    require_once "{$civicrm_root}/../../vendor/civicrm/civicrm-core/civicrm.config.php";
     require_once 'CRM/Core/Config.php';

     $config = CRM_Core_Config::singleton();

Thanks for adding the tips, everyone. I found that this simple addition to the composer.json extra section does the trick for my site upgrade, at least when it comes to kcfinder:

"civicrm-asset": {
  "assets:packages": {
    "+include": ["kcfinder/**"]
  }
}

I have no idea what else might be broken at this point. But kcfinder is a typical issue. Note that Apache2 still requires a .htaccess file addition to the kcfinder folder (and the the civicrm/extern folder as well), to allow it to work. I wonder if there's a way to get the plugin to add those, as well.

With all due respect to those working hard on this excellent tool, if this is the standard installation experience, then pushing it as an upgrade to the roundearth composer plugin, which appears to do the job properly, is probably not a wise thing until this bug is corrected. Requiring an undocumented composer.json fix just to get Civi to fully install isn't going to inspire confidence.

Note that Apache2 still requires a .htaccess file addition to the kcfinder folder (and the the civicrm/extern folder as well), to allow it to work.

@jptillman Can you provide more detail on this requirement? I'd like to try this approach on a site where we're seeing the problem.

It appears I may have been working with old information. Not sure how I missed this. It looks like my current installation works without the .htaccess files being needed!

I notice that the extern folder's php files aren't even being used at this point but an alternative router path is being used (great job folks!) Don't know how kcfinder's browse.php is working, but it is.

This is excellent! No more post-install copying.

@jptillman just wondering if you have tried the ckeditor5 extension at all? https://lab.civicrm.org/extensions/ckeditor5

I have not. Didn't know it was a thing! I'll certainly have to give that a try.

Are we able to resolve this by adding the relevant "extra" section to a composer.json in either civcirm-drupal-8 or something similar? Or does this need to be added at the root level?

@luke.stewart AFAIK it has to be at the root level,

@jptillman It looks like roundearth plugin was doing this:

$this->filesystem->mirror("{$source}/extern", "{$destination}/extern");
    $this->filesystem->mirror("{$source}/packages/kcfinder", "{$destination}/packages/kcfinder");
    $this->filesystem->copy("{$source}/civicrm.config.php", "{$destination}/civicrm.config.php");

In case this helps with identifying other likely broken things.

mentioned in issue drupal#144

This still doesn't work in D9 environments. I see from debugging, that the KCFinder configuration (disabled=false etc.) ist stored into the $_SESSION object directly, but Drupal starts its own session, initiated here - that's when the $_SESSION variable is overwritten, discarding previously set values.

According to this change record, relying on session IDs, as is done in the KCFinder CiviCRM integration, is not correct, so the code here will either have to be adjusted for using a Drupal/CiviCRM session for storing KCFinder configuration, or the ID of the session to store KCFinder configuration in can not be identified using CiviCRM/Drupal code.

Is anyone successfully using KCFinder with CiviCRM on Drupal 9? And what's the plan for this issue currently?

@jensschuppe I'm facing the same issue. I've opened a PR with a proposed fix: https://github.com/civicrm/civicrm-packages/pull/342

Your PR resolves the session issue () but we still need to adapt things ...

In the civicrm.config.php file in civicrm_conf_init() we need to add ../../../../sites/default as a candidate directory for finding the site directory, as this code runs from path/to/doc_root/web/libraries/civicrm/packages/kcfinder, which is one level deeper. So this would require another PR, this time to https://github.com/civicrm/civicrm-drupal-8
We'll have to just chdir($civicrm_root) before ~~and chdir($current_cwd) after~~ the require_once "{$civicrm_root}/civicrm.config.php"; in web/libraries/civicrm/packages/kcfinder/integration/civicrm.php for the civicrm.config.php to include the settings file.
In the global .htaccess file, all the PHP scripts inside /libraries/civicrm/packages/kcfinder need to be explicitly excluded from denying access with RewriteCond rules.

Can you confirm this is what you also have adjusted?

Yes, I did exactly those steps (I copied civicrm.config.php to web/libraries/civicrm/civicrm.config.php and adjusted $candidates so it finds civicrm.settings.php), along with adding

"civicrm-asset": {
  "assets:packages": {
    "+include": ["kcfinder/**"]
  }
}

to composer.json extra section as it was mentioned above: #4 (comment 51455).

I just haven't reported it...

In a D9 install we came across the same issue. We installed ckeditor5 and updated the display settings under administer. We can now upload the images using the traditional Template. So this is a good work around in our situation.

Though functionally it is working, it looks quite different from the previous one. When you create a new template, the body of the template is shown as a small box only. The icons are relatively big. All not a big deal, since it is working, but the previous editor looked as if it was part of CiviCRM, and this one looks indeed as 'added functionality'.

Still an issue: Uploading images when creating a name badge still does not work in D9. I get the message 'The requested page could not be found'. It is looking for this path: *yourwebsite/libraries/civicrm/packages/kcfinder/browse.php?cms=civicrm&type=images

mentioned in issue core#3419 (closed)

mentioned in issue drupal#179 (closed)

Has this been fixed for d9 in latest version of CiviCRM?

Apparently not, there's still https://github.com/civicrm/civicrm-packages/pull/343 for making the civicrm.config.php discoverable, and there's still the need for adjusting the composer.json as described above. Seems this won't make it completely before CKEditor 4 will be EOL.

following since we observed this on d9 Master and on our new d10 sites. Have switched one site to https://lab.civicrm.org/extensions/summernote but while it works it fails the test (thus far) of providing the same features.

Also experiencing this bug with a brand-new Drupal 10 & CiviCRM site configured directly via plain Composer config. In case it helps anyone, the .htaccess changes mentioned by @jensschuppe above were specifically changing web/.htaccess lines from:

  # Copy and adapt this rule to directly execute PHP files in contributed or
  # custom modules or to run another PHP application in the same directory.
  RewriteCond %{REQUEST_URI} !/core/modules/statistics/statistics\.php$

to:

  # Copy and adapt this rule to directly execute PHP files in contributed or
  # custom modules or to run another PHP application in the same directory.
  RewriteCond %{REQUEST_URI} !/core/modules/statistics/statistics\.php$
  RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/browse\.php$
  RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/index\.php$
  RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/js_localize\.php$
  RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/upload\.php$
  RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/css/index\.php$
  RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/themes/default/css\.php$
  RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/js/index\.php$
  RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/themes/default/js\.php$

Also, the described steps for fixing kcfinder/integration/civicrm.php didn't work for me, possibly the configuration files have moved in recent versions of CiviCRM? I had to change this file from:

require_once "{$civicrm_root}/civicrm.config.php";

to:

chdir("/var/www/html/web/modules/contrib/civicrm");
require_once "/var/www/html/web/modules/contrib/civicrm/civicrm.config.php.drupal";

KCFinder browse.php not accessible after upgrade to Drupal 10 and CiviCRM 6.1 (multisite + composer)

I’ve recently completed an upgrade from Drupal 7 + CiviCRM (non-composer setup) to a Drupal 10 + CiviCRM 6.1 multisite setup, using Composer. The CiviCRM database remains separate from the site databases (same as in the old D7 setup). Everiting ok

I'm now facing a problem with KCFinder not working properly when trying to insert or browse images in rich text editors like CKEditor. Specifically, accessing:

/libraries/civicrm/packages/kcfinder/browse.php?cms=civicrm&type=images …results in a 404 error or broken link and if I copy inside folder not change (permission error appear)

In my project is structured with not inside web/ (standard but for future multisite necessity (one of sites I will use open social, but this is in influent another argument). :

drupal-10/ ├── composer.json ├── libraries/ │ └── civicrm/ │ └── packages/ ├── vendor/ │ └── civicrm/ │ └── civicrm-packages/ └── sites/ └── sportforma.it/ └── (multisite site config and settings) In my root composer.json, I have this configuration:

"extra": { "drupal-scaffold": { "locations": { "web-root": "./" } }, "installer-paths": { "core": [ "type:drupal-core" ], "libraries/{

name}": [ "type:drupal-library" ], "modules/contrib/{

name}": [ "type:drupal-module" ], "profiles/contrib/{

name}": [ "type:drupal-profile" ], "themes/contrib/{

name}": [ "type:drupal-theme" ], "drush/Commands/contrib/{

name}": [ "type:drupal-drush" ], "modules/custom/{

name}": [ "type:drupal-custom-module" ], "profiles/custom/{

name}": [ "type:drupal-custom-profile" ], "themes/custom/{

name}": [ "type:drupal-custom-theme" ], "recipes/{

name}": [ "type:drupal-recipe" ], "libraries/civicrm/{

name}": [ "type:civicrm-asset" ], "libraries/civicrm/ext/{

name}": [ "type:civicrm-ext" ], "libraries/civicrm/tools/{

name}": [ "type:civicrm-tool" ], "libraries/civicrm/packages/{$name}": [ ] },

I tried "extra": { "civicrm-asset": { "path": "libraries/civicrm", "url": "/libraries/civicrm" } } but I think not necessary n new versions.

I run the command:

composer civicrm:publish Which outputs:

Publishing CiviCRM assets to libraries/civicrm Generating CiviCRM asset map However, not all assets are actually copied. The packages/ folder appears, but many subfolders are incomplete — for instance, kcfinder/ is missing the critical browse.php and other PHP files.

This results in editor integrations breaking (like when trying to insert an image via CiviMail or CKEditor).

I tried Temporary workaround by manually copying:

cp -r vendor/civicrm/civicrm-packages/* libraries/civicrm/packages/ but not fix... just another different errors, so I step back .

Any idea to help me ???

kcfinder libraries is missing files

Designs

Child items 0

Activity