Een hart voor de Drupal Community

After a lot of debugging I think I found the issue.

When I set

options.headingsOffset = 1;

in the tocbot-init.js file just before tocbot.init() everything works great. Looks like it gets passed as text instead of a number and Tocbot doesn't throw an error and just doesn't work well then.

I'll dig deeper and look for a patch but if anyone else has this issue in the meantime this information could be helpful.

Tested with some older Tocbot libraries but all three instances have the same issue.

I have already debugged so much that I don't know where to look anymore to be honest.

Will look into the tocbot-init.js once more. If I don't find anything there I think a fresh pair of eyes/someone smarter than me is needed.

I'm now testing with the latest Tocbot library version, I perhaps could test with older library versions and see if it's library specific or not to rule that out.

f0ns created an issue.

Problem/Motivation

I've noticed a problem with Tocbot when using it in Drupal 11.3, I first thought it were my settings or theme specific css but that doesn't seem to be the case.

I could reproduce this in three different environments, with different theming and tocbot settings:

• My own environment
• A clean Drupal 11 install
• A clean Drupal 11 install with the umami profile installed

I also tested this with tocbot from CDN and tocbot installed locally with composer (latest version).

I've recorded 3 videos to illustrate.

Steps to reproduce

Install Tocbot, set it up as you would and touch the scroll.

Problem/Motivation

This module requires the symfony_mailer module. Refactor the logic so it supports core mail by default. Only if symfony_mailer module exist, build the email that way. Or provide a configuration page to select the email sending method.

Problem/Motivation

Keep track of the process in #3255444: Events on job states, to make sure this module uses the events that will eventually be added to the advancedqueue module.

Add Gitlab CI integration, for code quality checks.

Here an example of translation submissions that are fetched in tmgmt_smartling_cron.

{"response":{"statusCode":200,"headers":{"Content-Type":@"0":"application\/json;charset=utf-8","Date":@"0":"Fri, 12 Sep 2025 12:31:04 GMT","Server":@"0":"Apache-Coyote\/1.1","set-cookie":@"0":"_csrf=IzDlPv20Y1Uo1Y1iDIcnvWeV; Path=\/","Vary":@"0":"Accept-Encoding","X-Application-Context":@"0":"api-gateway:aws,redis:8443","X-Content-Type-Options":@"0":"nosniff","X-Frame-Options":@"0":"DENY","X-SL-RequestId":@"0":"2ab19f80-e5e6-4731-8f4a-5f2528811308","X-XSS-Protection":@"0":"1; mode=block","1":"1; mode=block","transfer-encoding":@"0":"chunked","Connection":@"0":"keep-alive"},"body":"{\"response\":{\"code\":\"SUCCESS\",\"data\":{\"items\":[{\"translationRequestUid\":\"67d3ed0b5adb\",\"percentComplete\":100,\"lastErrorMessage\":null,\"state\":\"Completed\",\"projectId\":\"60ab0f659\",\"bucketName\":\"66d7fbbb9e401\",\"version\":1058,\"translationSubmissionUid\":\"2ec5a5e47526\",\"targetAssetKey\":@\"tmgmt_job_id\":\"12786\",\"customTranslationData\":@\"batch_uid\":\"25kbxi9abdba\",\"batch_execute_on_job\":\"13320\",\"targetLocaleId\":\"fr-BE\",\"localeLastModifiedDate\":\"2025-09-01T10:18:52Z\",\"submitterName\":\"cron\",\"lastExportedDate\":\"2025-09-12T12:16:08Z\",\"submittedDate\":null,\"createdDate\":\"2025-08-25T08:31:03Z\",\"modifiedDate\":\"2025-09-12T12:16:08Z\"},{\"translationRequestUid\":\"67d3ed0b5adb\",\"percentComplete\":100,\"lastErrorMessage\":null,\"state\":\"Translated\",\"projectId\":\"60ab0f659\",\"bucketName\":\"66d7fbbb9e401\",\"version\":10,\"translationSubmissionUid\":\"fd58627cb484\",\"targetAssetKey\":@\"tmgmt_job_id\":\"12783\",\"customTranslationData\":@\"batch_uid\":\"25kbxi9abdba\",\"batch_execute_on_job\":\"13320\",\"targetLocaleId\":\"fr-BE\",\"localeLastModifiedDate\":\"2025-09-01T10:18:52Z\",\"submitterName\":\"cron\",\"lastExportedDate\":\"2025-05-27T06:55:11Z\",\"submittedDate\":\"2025-08-25T08:31:05.000Z\",\"createdDate\":\"2025-05-27T06:52:05Z\",\"modifiedDate\":\"2025-09-01T10:18:53Z\"}]}}}"}}

We haven't digged deeper, but we see that the file_id is not set and there are no other related entries in the logs. Do you have an idea what this could cause?

bceyssens created an issue.

@loparev where are these audit logs used for anyway? Is it necessary for Smartling's handling? I suppose it belongs to https://help.smartling.com/hc/en-us/articles/26782577087771--Introductio... but I can't seem to find it in the Smartling backend nor in the API documentation.

To prevent locking the process: isn't it possible to do the upload, capture the processUuid from contexts/upload-and-match-async and put that in another queue so we can use DelayedRequeueException to "wait" for the process to finish?

@loparev, we noticed not all API endpoint are documented here: https://api-reference.smartling.com Missing resources, logs, audit log, ... Where you look for documentation?

bceyssens created an issue.

We noticed that disk usage keeps growing for tmgmt_* folders. Aside from tests there are 3 places where managed files are written to disk and their usage is not updated or set. This will result in files that will never be automatically cleaned by Drupal.

Drupal has 2 seperate settings to control this functionality: - Set file to temporary when usage becomes 0 file.settings.yml: make_unused_managed_files_temporary - Timeframe after which temporary files can be deleted system.file.yml: temporary_maximum_age

There are 2 ways we can solve the issue:

1. usage is set correctly for all of these files
2. do not store files which are needed afterwards

For example: context upload. I don't think we need to keep the files stored locally, isn't it possible to generate the HTML and send it directly to Smartling API?

You can also briefly explain what the uploadContextMissingResources method in ContextUploader.php should do? If I understand the code correctly, we send context HTML and Smartling ask for missing resources (assets) which we upload afterwards? If that's the case, I also think it's not needed to save these files to disk in another folder which is not cleaned automatically.

I think uploading all of these assets one by one also makes the process incredibly slow. Why not use Guzzle http client instead of curl commands directly after which you could easily execute async upload commands for all of those assets: https://docs.guzzlephp.org/en/stable/quickstart.html#concurrent-requests

Let me know how you think about it, we can help writing the code. I can also split this ticket as it contains multiple different subjects.

We often see these type of errors in the logs. I'm trying to capture more information about the request, hoping to send that tomorrow.

As they are internal server errors on Smartling side, I'm not sure if we can do something about them. Maybe you can see what's going wrong based on the project ID in the URL?

Guzzle:RequestException: Server error: `POST https://api.smartling.com/audit-log-api/v2/projects/60ab0f659/logs` resulted in a `500 Internal Server Error` response: {"response":{"code":"GENERAL_ERROR","errors":[{"key":"error","message":"Request Timeout after 30000ms","details":null}]} (truncated...) .

Guzzle:RequestException: Server error: `POST https://api.smartling.com/audit-log-api/v2/projects/60ab0f659/logs` resulted in a `500 Internal Server Error` response: {"response":{"code":"GENERAL_ERROR","errors":[{"key":"error","message":"[cluster_block_exception] blocked by: [FORBIDDEN (truncated...)

bceyssens created an issue.

@loparev,

We've read the code and understand that this is the flow that needs to be followed, but what's the benefit of waiting on the Smartling matching process to finish? In our case we already increased the timeout to 30 seconds, and even then it's sometimes not enough.

Is there other functionality depending on these processes to finish correctly? Or is it only a log that needs to happen on Drupal side?

Thank you loparev! Closing

@loparev, yes the method is called from tmgmt_smartling_tmgmt_translator_update. Our project also has an integration with Lokalise (https://www.drupal.org/project/tmgmt_lokalise) which doesn't have an update hook in place. But we also don't receive messages from the getSupportedRemoteLanguages function when updating the configuration.

Where do you think the config syncing check should happen? We can start a patch on tmgmt itself when we agree on a solution.

@loparev, looks like our messages crosses while writing. Installing another module just to disable cron for this module just feels wrong, if you think it's OK we prefer to keep our existing queue_info_alter hook.

This ticket is related to https://www.drupal.org/project/tmgmt_smartling/issues/3125696 We already use the drush commands but we don't want cron to interfere with these separate drush commands.

Patch attached for reviewing. It removes the hardcoded entity type list and replaces with automatic entity type excludes when entity type:

• has no canonical
• canonical is the same as edit page
• is not translatable

Cleaned the config from still included (not excluded) items. We also added to ability to exclude an entire entity type. Comes in handy when there are a lot of bundles, or they keep growing during development.

The only thing still missing might be an update hook to save all existing providers to apply new rules.

bceyssens created an issue. See original summary.

We're in constant active development for one client where entity types and bundles keep growing. During initial setup the massive 200+ item list is a pain to configure for multiple providers and it now hard to maintain as well. It would be nice to improve this functionality to keep context upload as performant as it should be.

@loparev if you agree, the user switching part can be removed completely.

The only additional thing that needs to happen is to properly check the job and job item statuses to prevent requests that will result in a 403 anyway. Attached patch is based on logic from Drupal\tmgmt_content\Access\KeyAccessCheck. There's one other place where the queue is injected (SendContextActionApproveForm.php) but it isn't used yet, so didn't touch that code.

@loparev,

We still run into these issues today. Correct responses are received, with content like this:

    [processUid] => 3107a0c4-954d-4db5-ac48-ae07f0e8f598
    [processState] => IN_PROGRESS
    [processType] => MATCH_CONTEXT
    [createdDate] => 2025-09-10T14:10:46Z
    [modifiedDate] => 2025-09-10T14:10:46Z
    [result] => Array ...

Until it switches to state COMPLETED, so the functionality works as designed but it sometimes just takes to long. We tried increasing the time-out to 30 seconds, but it still happens to often. I'll try to capture some of the problematic process ID if you can use those the check logs or something?

Is it really necessary to wait for the matching to complete processing? Edit: If I read the code correctly the response is only used to log a message? I assume it's enough to wait for the upload to complete and continue on Drupal's side?

From time to time queue items are building up rapidly because a lot of translations are being requested (campaign season for our client). We already disabled cron processing to not disturb other processes. See https://www.drupal.org/project/tmgmt_smartling/issues/3545995

bceyssens created an issue.

In our case we disabled cron processing due to large amount of translation requests building up queue items and holding back other cron processing tasks (more info here https://www.drupal.org/project/tmgmt_smartling/issues/3454628).

For now we do it this way and run the queue worker via Drush in an infinite running script:

function hook_queue_info_alter(&$queues) {
  $queues['tmgmt_extension_suit_download']['cron'] = NULL;
  $queues['smartling_context_upload']['cron'] = NULL;
}

Would it possible to incorporate that into a Smartling module feature instead?

Drupal integration for Dalton.

Dalton makes your website self-enhancing.

Visit Dalton for more information.

This module is still under development.