🇺🇸United States @Dave Kopecek

Not sure if this was an unnecessary dupe of #3435382, I was unable to get that to merge per #5 and was not able to figure out how to re-fork from a different version in the same issue. This patch works against 3.0.x

dave kopecek → changed the visibility of the branch 3515771-drupal-11-compatibility to hidden.

dave kopecek → created an issue.

@lisastreeter looks like we were googling about merge requests at the same time :-)

I'm not an expert on this, but our AI overlords at ChatGPT think that with your maintainer access you may be able to merge my merge request into the 1.0.x-dev branch. The manual method in step 3 looks pretty straightforward. Here's what was suggested by ChatGPT:

It is possible to merge an issue fork's merge request into the 1.0.x-dev branch. In Drupal's GitLab-based workflow:

1. Ensure the Merge Request Targets the Correct Branch

• - If the issue fork was created against 1.0.x, check that the merge request targets 1.0.x-dev (this is typically the active development branch for that minor version).
• - If the MR targets 1.0.x instead of 1.0.x-dev, you may need to update the target branch before merging.

2. Rebase if Necessary

• If 1.0.x-dev has new changes that are not in the issue fork, you may need to rebase the fork before merging to avoid conflicts.

3. Merge via GitLab Interface

• - If everything looks good, merge the MR into 1.0.x-dev using GitLab’s merge request UI.
• - Alternatively, merge manually via the command line:

git fetch origin
git checkout 1.0.x-dev
git merge --no-ff issue-branch
git push origin 1.0.x-dev

4. Confirm Branch Policies

- In some projects, 1.0.x is reserved for tagged releases, while 1.0.x-dev is the development branch. Always check project policies before merging.

--- end of chatgpt ---

I've only ever created Drupal issue forks by clicking the "Create issue fork" on the issue. I think the only way for me to create a new fork is to open a new issue. Happy to do whatever is needed. Let me know how you want to proceed.

dave kopecek → created an issue.

dave kopecek → created an issue.

>> 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.