MR looks fine and fixes the mentioned problem. Thanks for your contribution!
kaszarobert → made their first commit to this issue’s fork.
kaszarobert → created an issue.
With patch #2 from https://www.drupal.org/project/imagemagick/issues/3123016#comment-13527639 🐛 Infinite loop when local source file missing Needs review fixes the problem for me.
I also encountered the same error. MR works fine.
We experienced this when using image mimetype, width, height in og:image metatags. This loop really made a load on the server, and we had to stop the php processes manually, so I think this fix is really mandatory in production. After applying the patch, it fixed these timeouts.
I attach a patch for this and I raise the priority of the issue since it could lead to an incorrect stock level in the reports.
kaszarobert → created an issue.
There's a cookie consent solution for this module I made for the COOKiES modules:
https://www.drupal.org/project/cookies_media_entity_facebook →
There I basically modify the script tag this way:
/**
* Implements hook_preprocess_HOOK().
*/
function cookies_media_entity_facebook_preprocess_media_entity_facebook(&$variables) {
$variables['script_attributes']['data-sid'] = ['facebook'];
$variables['script_attributes']['type'] = ['text/plain'];
}
I think a similair approach would be better to set the data-cookieconsent="marketing". Another question would be that since every cookie consent solution does things differently, should we commit to this repo as a submodule, or should we create separate module for that, or should we create a MR to include that to the Cookiebot module instead?
kaszarobert → created an issue.
kaszarobert → created an issue.
I can't thank you enough for your commitment and professionality for finding the root cause and making a fix to this problem. Who knew the protobuf extension would cause this much problem with objects.
The changes look fine, so I committed them. Now there are some weird things happening with tests which are unrelated but I will fix them in another issue.
Thank you for your help again!
kaszarobert → created an issue.
Wow, you did an amazing progress. So does the module's current codebase work with the Google libraries when no "php${DDEV_PHP_VERSION}-protobuf" is installed? Or do we need to commit some changes you did previously in the MR for fixing this problem completely?
Also, I think we should create an issue with this for the protobuf maintainers, so they hear about this, too.
kaszarobert → created an issue.
kaszarobert → created an issue.
Okay, after downgrading to 2.0.0 it works. Please remove Drupal 9 from commerce_currencies_price.info.yml, the module does not work with that anymore.
kaszarobert → created an issue.
Do the same check which views_data_export does for Search API queries.
kaszarobert → created an issue.
Okay. But I'd like to mention that the new Drupal CMS that just has its very 1st stable release created under the Drupal Starshot Initiative → uses Gin by default, so that means more and more people will have that installed, so please kindly consider the Gin compatibility in the future.
kaszarobert → created an issue.
kaszarobert → created an issue.
kaszarobert → created an issue.
kaszarobert → created an issue.
I opened a MR with a possible solution.
kaszarobert → made their first commit to this issue’s fork.
Great to hear you somehow found out new info about this problem. I was just checking if this library has some issues that's related to these segmentation faults and stack errors and I found this comment at https://github.com/googleapis/gax-php/issues/584#issuecomment-2342772917:
We also encountered this problem. PHP 8.3 has new feature and tries to detect the recursion. This feature likely doesn't work correctly with the gRPC PHP extension.
The workaround is to disable stack size checks in the PHP INI settings:
zend.max_allowed_stack_size: -1.
Can you check if this is set in php.ini, httpd.conf, or .htaccess, then what happens?
The second more work heavy option would be doing the needed Analytics API call manually without Google's PHP library with CURL or Guzzle somehow. So making a new setting in the module where you can switch implementations. These errors in the library are all related to some gRPC stuff but I wonder if the auth and the pageview query can be done via a simpler REST API call.
Those are just recommendations, and I think there are many other more important issues that need the extra work than this, so we leave the docs as is for now.
Thanks!
As a workaround, I created a new branch of Lightning Workflow that removes the Lightning Scheduler Module and creates a dependency on that contrib project.
See the 5.x branch.
According to https://www.drupal.org/project/lightning_workflow/issues/3457016#comment... 🐛 Circular reference detected for service "cache.backend.database". Active we should use the 5.0.x-dev version → now instead of patching. Still, a proper stable release would be the best.
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.