🇺🇸United States @Dave Kopecek

>> I didn't expect that someone still uses it.

Me neither, but here we are! :-)

dave kopecek → created an issue.

This patch against applies against 1.1.2 and incorporates my 2 commits to the issue fork.

I received an error cloning variations: SKUs needed to be unique.

Resolved in #2 by appending incrementing integer to the SKU, i.e. my-sku, my-sku-1, my-sku-2.

dave kopecek → made their first commit to this issue’s fork.

dave kopecek → created an issue.

dave kopecek → made their first commit to this issue’s fork.

dave kopecek → created an issue.

Merge request !2 resolved the issue for me. Marking RTBC.

dave kopecek → created an issue.

I created an issue fork that updated the require in the project's composer.json as suggested by @socialnicheguru in #2.

Dave Kopecek → made their first commit to this issue’s fork.

Thanks!

See:  Update documentation for drupal 10? [#3437441] | Drupal.org 🐛 Update documentation for drupal 10? Active

"uses &$form_state instead of $form_state; which will not work with Drupal 10."

Dave Kopecek → created an issue.

>> Can you elaborate? "selected_variation" isn't set in this case

In my use case we have a custom my_module_form_commerce_order_item_add_to_cart_form(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id that has:

    $vid = $form_state->get('selected_variation');
    $variation = \Drupal\commerce_product\Entity\ProductVariation::load($vid);

This broke when a new product with only a single variation was created. Is there a better way to get the current variation from the passed parameters?

Dave Kopecek → made their first commit to this issue’s fork.

I can confirm that #6 works for me as well.

Dave Kopecek → created an issue.

Thanks, Jurriaan! I'm happy to test and/or contribute to your efforts.

Dave Kopecek → created an issue.

I got the above error when upgrading 2.0.0-rc1 => 3.0.0. Prior to the upgrade I uninstalled and drupal/recurring_period (1.2.0). Recurring_period was previously blocking the upgrade.

Dave Kopecek → created an issue.

Patch for D10 compatibility.

I can also confirm that 3311063-42.patch worked.

I was able to `drush config:export` and manually update views.view.calendar.yml from:

          right_buttons:
            agendaWeek: agendaWeek
            agendaDay: agendaDay
            listYear: listYear
          default_view: month

to

          left_buttons: 'prev,next today'
          right_buttons: 'dayGridMonth,timeGridWeek,timeGridDay,listYear'
          default_view: dayGridMonth

after importing the config I manually edited and re-saved the settings in the view, cleared the cache and the error resolved.

I believe the issue is with $options['right_buttons']. Using xdebug I see the value below at FullcalendarViewPreprocess.php line 170"

$options['right_buttons'] =
array(7)
0:"dayGridMonth"
1:"timeGridWeek"
2:"timeGridDay"
3:"listYear"
agendaWeek:"agendaWeek"
agendaDay:"agendaDay"
listYear:"listYear"

Dave Kopecek → created an issue.

>> I wanted to say you need to remove all EBT blocks and then EBT block types manually, run cron, remove all other EBT modules and then you will be able to remove EBT Core module.

This happens on a clean D9 install after just installing ebt_core & no other modules. Once it's installed it can't be uninstalled. No content has been created. EBT_core installs block_content.field_ebt_settings. It shows up in the field list, but not in the block UI.

Where exactly to I remove the block_content.field_ebt_settings? I don't see it listed anywhere. Am I missing something?

Dave Kopecek → created an issue.

#3 worked for me.

Dave Kopecek → made their first commit to this issue’s fork.