Thank you for the report. There is an open issue for D11 compatibility, which I plan to work on in the next week or so. I plan to work on this using the other issue.
Looks like it's working for me!
I just updated Drupal Commerce to 3.0.1, which introduces autowiring for the CartProvider, and breaks our AdvancedCartProvider.
The fix, thanks to the friendly folks on Slack, is to change the way CommerceCartAdvancedServiceProvider::alter method adds the database service.
Before:
$definition->addArgument(new Reference('database'));
to
$definition->setArgument('$database_connection', new Reference('database'));
I didn't see this issue when I created 📌 Update Drupal/Commerce version dependency Active , even if I did, I didn't realize they're related until I updated commerce, which removes this service.
Please checkout the other issue (update to the 2.x branch).
The merge request is working on my local. Please test and let me know.
kristen pol → credited scottsawyer → .
Ok, first hitch:
The service "commerce_cart_advanced.hook.cart_item_form_alter" has a dependency on a non-existent service "commerce_pri
ce.number_formatter_factory". Did you mean one of these: "commerce_price.number_format_repository", "commerce_price.num
ber_formatter"?
This is used in Drupal\commerce_cart_advanced\Hook\CartItemFormAlter. Checking into the replacement https://www.drupal.org/node/2975672 → .
scottsawyer → created an issue.
Uploading patch for convenience. Minimal testing was done. Hopefully this is a good approach.
scottsawyer → made their first commit to this issue’s fork.
I just had a second thought. Maybe we just add a checkbox: "Ignore missing required fields", or "Skip field validation" or something that just let's the user do what they want?
scottsawyer → created an issue.
I am using this on multiple sites, seems to do the trick. Thanks
scottsawyer → created an issue.
I don't know why, but I wasn't able to get the MR to patch my local, so I am uploading a patch with the changes from the MR prior to the rebase.
I had a similar problem with jquery_ui_accordion, library not loading, missing theme extension, passing null to dirname(). I installed the patch, which did not immediately fix the problem. I disabled then re-enabled jquery_ui_accordion, and it started loading the library. I removed the patch and it still works. I think Drupal just needed a brain flush, and now I do too.
Not sure if this should be committed, but maybe keep it open for visibility?
- I totally agree with the approach. Keep it simple by default.
- This saved my butt with a race condition upgrading an old D8 site w/o salesforce enabled.
I think if the tests can be fixed, it should be committed.
scottsawyer → made their first commit to this issue’s fork.
scottsawyer → created an issue.
As @jsacksick explained, there is already a calculated price formatter, which, when the variation has a value in the price field, will correctly display the appropriate pricelist price. I did not realize this initially since I was not populating the default price field on my variations. Maybe this is a separate documentation issue? Once I populated the default price field, the correct pricelist price item displays on the variation.
This is great, however, I still think a formatter which will display a table of pricelist items for the variation would be a nice feature. If a customer sees that buy purchasing a higher quantity, they might get a lower per item price, it could encourage them to purchase more product.
scottsawyer → created an issue.
It seems the deprecated ContextAwarePluginBase is still present in Drupal\search_suggestions\Plugin\SearchSuggestions\ContainerBase. This is causing errors on a bunch of admin pages.
Error: Class "Drupal\Core\Plugin\ContextAwarePluginBase" not found in include() (line 8 of /app/web/modules/contrib/search_suggestions/src/Plugin/SearchSuggestions/Container/ContainerBase.
scottsawyer → created an issue.
scottsawyer → created an issue.
I couldn't get the patch to apply, I manually rerolled the patch, no interdiff.
I moved the FreightPlugin back to the freight submodule (along with the schema), fixed some deprecations, added docblock comments where there were none, removed unused use statements, and added ^10 to core_version_requirement. Things are working for me, but I am not 100% sure we won't have any problems with D10.
scottsawyer → created an issue.
While I think this is the right solution for this issue, I think it's a duplicate of 📌 Drupal 10 Compatibility RTBC , and while this issue is older, the other issue is tackling the bigger problem of making this module D10 compatible.
I suggest we close this issue as duplicate since downloading a patch from the MR4 will give us these changes, plus the update to core_version_requirement.
scottsawyer → created an issue.
scottsawyer → made their first commit to this issue’s fork.
We have a search api index view of commerce product variations with facets. Each user has their own prices (pulled from an API), plus a default price for anonymous users. We received a report that invalid prices were being displayed (prices from other users). Obviously very bad.
I see a bunch of these warnings, most reference the faceted URLs (/products/{product-type}?f%5B0%5D=configuration%3A1088.
I tried rebuilding cache, but I just keep seeing the same message.
What can I do to resolve this?
scottsawyer → created an issue.
scottsawyer → created an issue.
Merged
scottsawyer → created an issue.
scottsawyer → created an issue.
scottsawyer → created an issue.
There is a new option on the variant configuration form to copy properties to different sections. Yay!
scottsawyer → created an issue.
On the Breezy Layouts Variants overview page, there is a new option to duplicate layout variants.
scottsawyer → created an issue.
You can find several example layout variants in the examples submodule. Installing breezy_layouts_examples will attempt to install the examples, but if you've changed some of the ootb settings in either breezy_layouts or breezy_utility, it will fail. In that case, you can head over to the configuration and reset any changes. BACKUP FIRST.
If you munge up a variant, you can always re-import the defaults.
scottsawyer → created an issue.
scottsawyer → created an issue.
grep -rl 'tailwind' reveals the only mention is in the README.md. I'd say this is now closed.
scottsawyer → created an issue.
scottsawyer → created an issue.
I just merged some significant changes to the module, including adding a dependency on breezy_utility. This change will break everything, so please backup, export config, uninstall and remove. Require `drupal/breezy_layouts`, and you should now have breezy_utility. All of the configurations will need to be added, all variants will need to be recreated, I needed to restart my lando instance.
I apologize for any disruptions, but the changes needed to be made so we could go further with this module.
If you are going to attempt to restore your layout variants, after you install the updated version, enable breezy_layouts_ui, and configure both Breezy Utility and Breezy Layouts. Then find all of the fields you created in your breezy_layouts.variant.*.yml files, and change all of the #property keys that have underscores (_) to hyphens (-).
So, flex_basis becomes flex-basis.
Please let me know if you run into problems.
This change has been merged.
Thank you so much for your contribution. I am merging this! Please let me know what other issues you experience.
scottsawyer → created an issue.
Thank you for the patch and MR! This looks good to me, I will review later today and merge asap! I appreciate your contribution.
I added this to the info file, as well as another dependency, drupal:breakpoint. Thank you for the patch, the 2.0.x branch is now updated. Please test and provide feedback.
@aman_lnwebworks, I updated the readme, as well as the module page. Thank you for your input.
1. You are absolutely correct, I missed the dependency.
2. I am not entirely sure what is going on with the fork, but I will get this committed and give both credit.
Thanks for your help! Please let me know if you run into any other issues.
@aman_linwebworks. I appreciate the MR, but I don't actually want to make the UI submodule a dependency. I think this is actually a documentation issue, I should explain that you need the UI module for configuring the variants. Once the variants are configured, you no longer need the UI module.
@aman_lnwebworks, thank you for the report and MR, I will look at it today.
scottsawyer → created an issue.
I just wanted to follow up and report my findings. For me, and likely others, this is due to a change in Symfony\Component\HttpFoundation\Request, which, in current versions of Symfony ,throws the exception if the session can not be found when calling ->getSession(). I found an instance in one of my custom modules, and changed the code to first check ->hasSession() before calling ->getSession(), and the errors go away immediately. Likely the custom code was invoked during cron and drush operations, and causing the exception. I grepped this module for '->getSession()' and I could only find it in the tests, so simple_sitemap is definitely not the culprit.
I am increasing the priority to Major because it seems that an existing site map is deleted as part of the cron job, but then its unable to regenerate, leaving the site with 404 errors when there is an attempt to retrieve the sitemap.
I am not setting to critical, because the sitemap can be regenerated from the UI (drush fails, even though it reports completed). However, this is not a great solution.
I just installed this module, trying to figure out how it works by reviewing the repo because the scarce documentation, and I immediately get errors (fresh D10, layout_builder enabled).
Error: Call to undefined method Drupal\layout_builder\SectionComponent::getThirdPartySetting() in Drupal\tailwindcss_utility\EventSubscriber\SectionSubscriberRenderArray->onSectionComponentBuildRender() (line 19 of /app/web/modules/contrib/tailwindcss_utility/src/EventSubscriber/SectionSubscriberRenderArray.php)
Looking at the heddn/install_profile, there are several core patches that look related. Are all of the patches in composer.patches.json required to get this module to work? It would be fantastic to have any required patches listed on the module page / readme in addition to the basic setup and description of how to use it.
Also, it would be great if there were more help / descriptions on the configuration form. I am not sure why I need to add classes, are these for classes not available in TailwindCSS, or the classes in TailwindCSS that I want added to every page? An example or two to help someone get started would be nice.
Re-roll for D10.
Initially, I was seeing this error only when using Drush to index, but I just spun up a fresh environment, cloned my live database, and started indexing data via the UI. The first index completed successfully (only about 200 items), but the second index has > 8000. When the batch completed, it warned that some 700 items were not indexed. When I checked the log, I see:
Symfony\Component\HttpFoundation\Exception\SessionNotFoundException while trying to render item entity:associated_detail_products/958:it with view mode default for search index Products: Session has not been set. in Symfony\Component\HttpFoundation\Request->getSession() (line 727 of /code/vendor/symfony/http-foundation/Request.php).
But I also see:
Symfony\Component\HttpFoundation\Exception\SessionNotFoundException: Session has not been set. in Symfony\Component\HttpFoundation\Request->getSession() (line 727 of /code/vendor/symfony/http-foundation/Request.php).
Which seems to have come from simple_sitemap.
I did some searches, it looks like this SessionNotFoundException is affecting a lot of modules. I see a work around here: 🐛 Check for session before calling Request::getSession() Fixed .
I did notice that cron seems to have started too, which might be another piece to the puzzle, as mentioned here: 💬 "Session has not been set" error on drush cron Active .
Same issue, freshly upgraded to D10, indexing the site via UI. Looks like while the batch was running cron also started running, then these messages started appearing.
Type: simple_sitemap
User: Anonymous
Severity: Error
Message: Symfony\Component\HttpFoundation\Exception\SessionNotFoundException: Session has not been set. in Symfony\Component\HttpFoundation\Request->getSession() (line 727 of /code/vendor/symfony/http-foundation/Request.php).
I am also seeing similar errors with Type: search_api.
Maybe it's related to 🐛 Check for session before calling Request::getSession() Fixed ?
scottsawyer → created an issue.
I think the problem is the original poster, like myself, is not sure what this means, nor what to do about it. Do I need to change some code or configuration? If so, what? Please advise.
FYI, I think you can avoid the name conflicts by changing:
use DVDoug\BoxPacker\Packer;
to
use DVDoug\BoxPacker\Packer as BoxPacker;
scottsawyer → created an issue.
Patch works.
It works beautifully. I tested with 2 and 3 carts. Great job and thank you!
scottsawyer → created an issue.
Just wanted to report that #33 fixed this issue for us.
Just wanted to note that this patch no longer applies to 1.7.0. I am no longer experiencing a condition that causes the error, so removing the patch, and crossing fingers...
Looking at the other two issues, I agree with the conclusion of the Bootstrap Layout Builder issue. I feel like layouts should be "pure" in that there is no mixing of layout definitions and the content they hold.
Creating layouts is a fairly simple process → , I feel like what you want is a custom layout, and it would be a better idea to create a custom layout than add the layer of complexity that many users may not need (I know I am not interested in this feature). Additionally, it's totally subjective as to the exact feature set that would be desired.
That being said, I am not a maintainer, so maybe this feature is more exciting to someone who is.
You know what, I just implemented this in my own module, so right now, I don't think I need this feature baked into this module, per se. However, I'll leave the issue open and see if anyone else is interested.
scottsawyer → created an issue.
Even with these changes applied, looking at New Relic, \Drupal\permissions_by_entity\Service\AccessChecker::isAccessControlled is still taking too much time.
Looking at the code:
public function isAccessControlled(FieldableEntityInterface $entity, bool $clearCache = TRUE): bool {
if ($clearCache) {
$this->checkedEntityCache->clear();
}
if ($entity->getEntityTypeId() == 'node') {
// Make sure to leave nodes to the permissions_by_term module.
return FALSE;
}
Maybe rearranging these two so that cache is not cleared before the node check might help. Also, I am wondering if we always need to clear all the cache for every entity every time access is checked?
Also it looks like:
// Iterate over the fields the entity contains.
foreach ($entity->getFields() as $field) {
// We only need to check for entity reference fields
// which references to a taxonomy term.
if (
$field->getFieldDefinition()->getType() == 'entity_reference' &&
$field->getFieldDefinition()->getSetting('target_type') == 'taxonomy_term'
) {
// Iterate over each referenced taxonomy term.
/** @var \Drupal\Core\Field\FieldItemInterface $item */
foreach ($field->getValue() as $item) {
if(!empty($item['target_id']) && $this->isAnyPermissionSetForTerm($item['target_id'], $entity->language()->getId())) {
return TRUE;
}
}
}
...
We never cache this result whether true or not (and by extension, we never check cache).
Maybe changing to something like:
/**
* {@inheritdoc}
*/
public function isAccessControlled(FieldableEntityInterface $entity, bool $clearCache = TRUE): bool {
if ($entity->getEntityTypeId() == 'node') {
// Make sure to leave nodes to the permissions_by_term module.
return FALSE;
}
if ($clearCache) {
$this->checkedEntityCache->clear();
}
elseif ($this->checkedEntityCache->isChecked($entity)) {
return TRUE;
}
// Iterate over the fields the entity contains.
foreach ($entity->getFields() as $field) {
// We only need to check for entity reference fields
// which references to a taxonomy term.
if (
$field->getFieldDefinition()->getType() == 'entity_reference' &&
$field->getFieldDefinition()->getSetting('target_type') == 'taxonomy_term'
) {
// Iterate over each referenced taxonomy term.
/** @var \Drupal\Core\Field\FieldItemInterface $item */
foreach ($field->getValue() as $item) {
if(!empty($item['target_id']) && $this->isAnyPermissionSetForTerm($item['target_id'], $entity->language()->getId())) {
// Add entity to cache.
$this->checkedEntityCache->add($entity);
return TRUE;
}
}
}
...
This way we can short circuit the entire recursive access check.
FYI, there is nothing to test against. Please review.
Added a new MR, please review.
I think this patch breaks \Drupal\permissions_by_entity\Service\AccessChecker since the constructor changed. Anyway, it blew up on me, but I made a lot of changes, so need to do some additional testing.
I think the MR looks good, but needs to be updated against the current branch. I am not seeing the dev branch in the list of versions, so setting to the most current release.
I just wanted to pipe in, if you are using Commerce Google Analytics, you need the patch from the MR here: https://www.drupal.org/project/commerce_google_analytics/issues/3285744 →
We're running this in D9, but only for commerce data. The only configuration is to select Commerce Enhanced, make sure you enter the GA4 credentials. I just did the bare minimum to get GA4 working with Commerce Google Analytics, I am sure there is a lot of improvements that could be made.
Update status
scottsawyer → created an issue.
I just ran into this on a site that another developer installed this patch, which I removed as part of an upgrade. What I did to resolve it was set the registry installed version to 8202 and reran the database update.
drush ev "\Drupal::service('update.update_hook_registry')->setInstalledVersion('name', 8202);"
drush updb -y
Then the configs were installed, no more errors.
I am running into this problem with exposed forms in blocks, but it only surfaced when I updated to D 9.5. I was using views_block_filter_block because my views were block displays and I needed the exposed filters in separate blocks. It seems like the D9 update superseded views_block_filter_block, changing where the attributes were attached.
I patched with the MR, but it doesn't seem to be working, exposed form class attributes are still being moved to the containing block. If you have a custom block template for blocks containing views exposed forms that don't output all of the attributes, it breaks the ajax as well as the CSS in my case.
I worked around the issue by refactoring my template structure, I was fortunate to find a relatively simple solution, unfortunate that it cost me half a day to discover the problem and fix it.