Image selector not working with non-admin user

[fsuter]

Bug description I have installed the extension and successfully configured it so that the "Image" button appears in the RTE. Selecting an image works fine when I am an admin user. When I try the same as a regular user, I get an InsufficientFolderAccessPermissionsException exception (see screenshot).

I dug into the code and it seems related to missing bparams query parameters sent when the element browser is called up. The fact that they are missing prevents the underlying code from identifying a folder. When I look at the Resources/Public/JavaScript/Plugins/typo3image.js file, I can see that in version 11.0.15, bparams were assembled:

        var bparams = [
                editor.name, // $fieldRef
                'ckeditor', // $rteParams
                'typo3image', // $rteConfig
                editor.config.typo3image.allowedExtensions || '', // allowedFileExtensions -> Defaults set in controller
                editor.name // $irreObjectId
            ],
            routeUrl = editor.config.typo3image.routeUrl,
            url = routeUrl
                + (routeUrl.indexOf('?') === -1 ? '?' : '&')
                + 'contentsLanguage=' + editor.config.contentsLanguage
                + '&editorId=' + editor.id
                + '&bparams=' + bparams.join('|'),
            deferred = $.Deferred(),
            $modal;

In version 12.0.2, bparams seem ignored:

    const bparams = [
        '',
        '',
        '',
        '',
    ];

    // TODO: Use ajaxUrl
    const contentUrl = editor.config.get('style').typo3image.routeUrl + '&contentsLanguage=en&editorId=123&bparams=' + bparams.join('|');

Steps to reproduce To reproduce the problem:

1. Log in as a non-admin user
2. Edit some record with a RTE having the image button
3. Click on the image button
4. See the exception

Expected behavior The user should see the element browser with the files from the folder he/she has access to.

Screenshots or logs

Environment

• TYPO3 version: 12.4.16
• PHP version: 8.2.20
• Extension version: 12.0.2

Documentation Have you checked the readme/documentation?

• [x] Yes, but I couldn't find anything helpful

[fsuter]

As a followup, I wanted to highlight the differences in URLs in version 11 and 12 of the extension (and TYPO3), in case that helps.

Here is a typical URL with TYPO3 11.5.37 and rte_ckeditor_image 11.0.15:

https://catalog3.chuv.ch/typo3/rte/wizard/selectimage?token=e446647b8a75009d82dfa0a0a932664ad035e488&mode=file&P[table]=tx_catalogdata_domain_model_gynobsprotocol&P[uid]=158&P[fieldName]=content_definition&P[recordType]=0&P[pid]=2&P[richtextConfigurationName]=images&contentsLanguage=en&editorId=cke_1&bparams=data_tx_catalogdata_domain_model_gynobsprotocol__158__content_definition_|ckeditor|typo3image||data_tx_catalogdata_domain_model_gynobsprotocol__158__content_definition_

And here is the URL with TYPO3 12.4.16 and rte_ckeditor_image 12.0.2:

https://catalog.ddev.site/typo3/rte/wizard/selectimage?token=e2205286d2bc1ca303f881f43ddf0065626c3519&mode=file&contentsLanguage=en&editorId=123&bparams=|||

[fsuter]

For information, if I manually add the query variable &expandFolder=2:/foo/ to the above-mentioned URL (a folder to which the user has access), it works. I don't know where that information used to come from in v11. What I think I am facing is that the code falls back to the default storage (in this case fileadmin) to which the user does not have access.

I have tried setting a default upload folder using TSconfig, but it does not help.

[fsuter]

The change of behavior is due to the Core having massively modified the \TYPO3\CMS\Filelist\ElementBrowser\FileBrowser::render() method. It used to take the bparams into account to identify a folder, or failing that it would consider the user settings, including TSconfig. This is not the case anymore and I can't find an entry point (event, hook, or whatever) to modify the folder.

It seems that what is needed is to pass an expandFolder query variable into the call to the element browser modal. So it's up to the extension to do this work now. Ideally it should provide a base folder resolution and provide an event to modify the folder identifier (in my case, upload folders are defined per TCA field).

I will try to work something out, because my need is urgent, but I may need help in understanding part of the code. I'm not familiar with CKEditor plugins, not how they interact with TYPO3.

[fsuter]

Hi guys, pinging you on this issue. I would welcome some feedback.

[CybotTM]

Solution Implemented ✅

I've implemented a fix for this issue in PR #374. The solution resolves the default upload folder for non-admin users before opening the Element Browser.

What Was Fixed

The root cause was that TYPO3 v12+ requires an explicit expandFolder query parameter when opening the Element Browser. Without this parameter, TYPO3 defaults to the fileadmin storage, which non-admin users typically don't have access to.

Implementation Details

Changes in SelectImageController.php:

• Added DefaultUploadFolderResolver via dependency injection
• Resolve user's permitted folder in mainAction() before calling parent
• Pass folder identifier as expandFolder query parameter
• Graceful exception handling to maintain admin workflow

Configuration Support: The fix respects your TSconfig settings:

# User TSconfig
options.defaultUploadFolder = 1:user_uploads/

# Page TSconfig  
RTE.default.buttons.image.options.defaultUploadFolder = 1:rte_uploads/

If no specific folder is configured, it falls back to the user's first accessible file mount.

What You Confirmed

Your workaround discovery was key to identifying the solution:

"if I manually add the query variable &expandFolder=2:/foo/ to the above-mentioned URL (a folder to which the user has access), it works"

This confirmed that the expandFolder parameter was the missing piece, and your investigation into the TYPO3 Core changes between v11 and v12 was spot-on.

Testing

The fix has been validated with:

• ✅ PHP linter
• ✅ PHPStan static analysis
• ✅ PHP-CS-Fixer code style
• ✅ Unit test structure updates

Backward Compatibility

• Admin users are unaffected (they already have full access)
• No breaking changes to the API
• Type-safe implementation with proper error handling

Next Steps

Please test PR #374 in your environment with a non-admin user. The fix should allow non-admin users to access their configured upload folders without permission errors.

Thank you for the detailed investigation and patience! Your thorough analysis of the issue, including the URL comparisons between v11 and v12, made this fix straightforward to implement.

[fsuter]

Thanks for the fix. When is a release planned?