I managed to reproduce the issue on a non English Drupal 10 site. The cause of the problem was that there was no default config values provided during install and while this is not a problem on single language sites, when config_translation is enabled on multi language sites, then it throws this as Drupal loads FALSE instead of the config object.
I put out a new release with a fix. Run the database updates or reinstall the module.
According to this a module called "blocache" is installed on the site: https://www.drupal.org/project/blocache →
call_user_func_array('Drupal\blocache\BlocacheViewBuilder::preRender', Array) (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback('Drupal\blocache\BlocacheViewBuilder::preRender', Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 870)
Drupal\Core\Render\Renderer->doCallback('#pre_render', 'Drupal\blocache\BlocacheViewBuilder::preRender', Array) (Line: 432)
@nidhish can you please check it if you can reproduce the problem after installing content_redirect_to_front and blocache, too? To detect the source of the problem we need to reproduce it from clean install.
Can we expect legal changes like this backported to versions 2.x? Or do we have to upgrade to 3.x even though it's still in beta?
I think the PR is okay.
According to the laws now they are both called "reduced tax rate". You can see as "Znížená sadzba dane 10 %" and "Znížená sadzba dane 5 %" in https://www.zakonypreludi.sk/zz/2004-222 under § 27 at (3). And the actual change still calls them the same (in https://www.zakonypreludi.sk/zz/2024-278#cl7 under Čl. VII at 2. ), so I guess they don't have a separate name. And since they are both called reduced, it makes sense to call the other one simply the Second reduced.
kaszarobert → created an issue.
Here's a quick fix we made to continue rendering when the langcode could not be detected for some reason. Maybe there's a better way to propagate this but I didn't have the time to dive deep into it.
kaszarobert → created an issue.
This is still a problem. Also, the documentation page says the following:
- Once a promotion that is not compatible with other promotions is added to an order, no other promotions will be added.
- If a promotion that is compatible with any promotion is added to an order, then any subsequent promotions with limited compatibility will not be added to the order.
Which is not true. The current behavior would be:
- Once a promotion that is not compatible with other promotions is added to an order, no other promotions will be added which are set to not be compatible with any other promotions. Promotions that are compatible with any other promotions will still be applied.
- If a promotion that is compatible with any promotion is added to an order, then any subsequent promotions with limited compatibility will not be added to the order.
kaszarobert → created an issue.
kaszarobert → created an issue.
It seems the main issue is that Chrome requires at least 4 GB of free memory to open HTML pages and generate PDFs. If you're anything under, Chrome will will sooner or later starts to be slow and eventually begins to crash the tabs you'd like to open and print and you'll see these timeouts I copied from the log here.
kaszarobert → created an issue.
I see on the screenshot that it downloaded quite a few paths someday. Did it work on the same production environment up until now? Does this crash happen constantly or just randomly? Indeed, it seems a memory related issue. But the cause of that is what's gonna be hard to tell. Here are a few ideas I'd check now:
Some limit is not enough in php.ini?
Out of physical memory?
One of the installed PHP extensions?
Or the A weird APCu bug?
Could the google/analytics-data library which this module uses cause some trouble with certain server configurations?
The debug cron logging pasted here shows that it used at some point 110.85 MB RAM which I think not that big number considering how many things the cron job is downloading and writing to db. I'd look into phpinfo on the webserver and try to compare the php ini settings with the other (probably dev) environment where you stated that this problem does not occurs if there are some major differences in some memory or cache limits.
Here's the fix for wrong method call in ViewPrintController::viewPrintDebug.
kaszarobert → created an issue.
Alright, we're experiencing constant timeouts and higher database load in production with my previous solution.
The main problem is Drupal does not generate the CSS files during generating the HTML and due to the slowness with web requests is see that only current the file:// method is viable.
I have no other idea than disabling the CSS aggregation in the parent entity_print module. And I attach my quick fix for that. But again note that this patch is for entity_print, not for entity_print_chrome!
In the meantime v3.14.2 was released. Does this problem affect that version also?
According to the https://github.com/fengyuanchen/cropperjs#checkcrossorigin by default when the JS library is loaded, it clones the image element and makes an AJAX request for the image file to do some orientation metadata checking. And in case of native S3 URLs, it will mean sending AJAX request to a different domain, so that will not work because it's a cross-domain AJAX request with missing CORS headers in S3. And the documentation states that setting checkCrossOrigin to false means that it will not do this AJAX call.
The other solution would be trying to set up the Access-Control-Allow-Origin headers in Amazon S3/Google Cloud Storage (if possible) or proxying the file URLs in the S3 storage to use the same domain which the site runs on.
I replaced the PostRenderSubscriber code with almost the same as what is used in modules/contrib/entity_print/src/EventSubscriber/PostRenderSubscriber.php and that way it starts working again.
kaszarobert → created an issue.
Well, here's a quick hotfix that does not require creating config schema definitions and config update hook for fixing the type to boolean.
For me the change does fix the issue but first you need to clear the caches and resave the form. That means an update hook will be needed that should fix the type in existing config. And a much less error prone solution would be casting the 'printBackground' setting to boolean in Chrome::getBlob().
kaszarobert → created an issue.
kaszarobert → created an issue.
We're experiencing the same. The patch fixes the issue but since the fix is already committed, why not tag a new version?
kaszarobert → created an issue.
kaszarobert → created an issue.
Looks okay. Thank you for your contribution!
I attach a patch with a simple fix.
kaszarobert → made their first commit to this issue’s fork.
kaszarobert → created an issue.
kaszarobert → created an issue.
Please remove the .idea folder from the MR. Those are PhpStorm project files and should not be committed.
Removing that invalid $multiplier variable fixes the problem and your solution with the attached module from commerce_stock_product.tar_.gz + patch #16 works fine. With needing patch #16 it seems the module is not flexible enough for setting up other entities for stock level management. There are entity_id and entity_type columns in the commerce_stock_transaction database table, so the schema can handle this use case but the module cannot.
kaszarobert → created an issue.
kaszarobert → created an issue.
There is already an issue for this: #3145148: View for listing scheduled content →
Okay, this is a multilingual issue, we will solve that in ✨ Make scheduled moderation states work with multilingual Needs work .
Okay, this is a multilingual issue, we will solve that in ✨ Make scheduled moderation states work with multilingual Needs work .
The permission check was already committed to the module sometime, so nothing to do here anymore I guess.
Needs a reroll in a MR.
Needs reroll.
I cannot reproduce this error in the latest version.
kaszarobert → created an issue.
kaszarobert → created an issue.
Great catch. The module seems to be working on Drupal 8 and 9. But 10, 11 throws this error. By adding these changes it works everywhere. I wish I had wrote tests for this module back there. Thank you for your work!
We will do that in ✨ Add pre- and post state transition events Needs work
Okay, I reroll the patch and see what we can do about multi-language use cases.
Okay, valid reasons but since the whole JS build process uses a few years old unsupported packages, the whole thing need to be redone from scratch with current tools instead.
kaszarobert → created an issue.
Oh, there's actually an older issue with the same exact thing duplicated, let's continue just there:
Needs a reroll. Also, when adding multiple transitions, this would limit editors as the list will contain only the next valid transition from the current node state. It would be awesome if the UI would enable users to select valid next states only even if multiple transitions are added.
Needs a reroll. Also, when adding multiple transitions, this would limit editors as the list will contain only the next valid transition from the current node state. It would be awesome if the UI would enable users to select valid next states only even if multiple transitions are added.
It would be better to have pre_state_change and post_state_change events instead.
This needs some work to tackle how much work would be using the current timezone and test cases for that. If it's too complicated and needs a full rewrite on the JS part, we will need to document that the module does not support this right now.
This needs a reroll and a test.
Right now the module processes all the content's latest revision where there's a transition saved and the transition date is in the past. It does not collect them to queue, during cron run it requests from the database which contents to process right now. Leaving invalid transitions there would mean the same exact contents would be loaded and skipped during cron run again and again and again with nothing happening to them.
So for your proposal to work, the module would needed to be rewritten to using queues. You might just check out other scheduling modules instead.
As I see the same exact code was already merged into the module's src/Plugin/Field/FieldWidget/ModerationStateWidget.php
The problem with this is that the text is not translatable.
After merging 🐛 Transition does not happen accurately when lightning_scheduler_cron() runs each minute Fixed I cannot reproduce the issue anymore, so I'll close this.
In the end we solved Drupal 10 and 11 compatibility without upgrading code from Lightning Workflow's Lightning Scheduler as those modules tests were breaking.
CI run length went down from 13 minutes to 4 min.
kaszarobert → created an issue.
@joseph.olstad I created the MR with the exact same changes you uploaded in a patch years ago. However, I had to change a few things:
- I fixed the proper DI in the class,
- With this change, we're now disabling the processing of older transitions than last cron run, I added a new test case for that
- During writing a test for this new behavior, I found out that in the patch you were using a timestamp in the SQL query for the lowest scheduled_transition_date.value but in the database that field contains a Y-m-d\TH:i:s formatted UTC timezoned date, so the patch by default didn't change the requested behavior the way we wanted it, so I modified the code to pass a formatted date to the query.
- this a backwards breaking change, so I'm thinking about if we should set this new 'lowest date of a state transition' thing into a setting instead. But again due to how this module was architected + with the performance issues you were experiencing indicate that this should be the default behavior to not break huge sites. So maybe we have no other choice than commit this really.
kaszarobert → created an issue.
kaszarobert → made their first commit to this issue’s fork.
kaszarobert → made their first commit to this issue’s fork.
kaszarobert → created an issue.
The fastest solution for us was remove those lines completely with an attached patch.
kaszarobert → created an issue.
I wrote about our approach in a MR.
We experienced the same with commerce_email module-defined e-mails for the Order paid event after an offsite payment gateway returned to the website. We solved that by postponing the e-mail building and sending later during cron where there are no problems with sessions.
kaszarobert → created an issue.
I looked through the workflow_buttons module quickly. They define a completely custom form widget for their functionality inworkflow_buttons/src/Plugin/Field/FieldWidget/WorkflowButtonsWidget.php. Lightning Scheduler overrides somewhat the core moderation state widget here: lightning_scheduler/lightning_scheduler.module lightning_scheduler_field_widget_info_alter()and defines its custom logic for the widget here: lightning_scheduler/src/Plugin/Field/FieldWidget/ModerationStateWidget.php. For this to work, the 2 widget's code and logic must be combined into 1 new widget.
FYI you have to turn on content moderation for node types in a workflow and only after that you can schedule moderation state changes.
The idea here is to copy the classes from other input elements. That way the select, date and time input elements in the widget would use the same styles that the other Drupal rendered input elements are using all over the Claro admin theme. This means the same padding, font-size, margin, etc. Right now, these input elements are unstyled, they don't have any classes.