🇺🇸United States @joelsteidl

@mohit_aghera No problem and thank you!

Sounds good. You can open up a merge request and we can iterate from there.

Got it, so it might contain a submodule that adds SDK support? zoomapi_sdk for example?

What would be a good next step here?

@socialnicheguru Thanks for reaching out.

Do you have an pseudo code or ideas around how Zoom API module would need to change to support Zoom SDK credentials? I'm a bit unfamiliar with it and why someone would need that over the authentication we are already supporting.

I think if we could support it without causing regressions, I'd definitely entertain the idea.

@jrockowitz - Confirming that the Lingotek MR solved the issue. Thanks!

I wanted to see if there was anything I could do to help get a D11 release up.

I wanted to see if there was anything I could do to help get a D11 release up.

This simple patch seems to do the trick. Let me know if I can do anything to help get a D11 release up.

I wanted to see if there was anything I could do to help get a D11 release up.

joelsteidl → created an issue.

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

Thank you! https://drupal-colorado.org/sessions/mercury-editor-single-directory-com...

In case this bites anyone else.

/libraries/ckeditor5-anchor-drupal/.gitignore has it's own .gitignore file ignoring the /libraries/ckeditor5-anchor-drupal/build directory. We are running a build step in a pipeline and the .gitignore was preventing the javascript to land on the server.

In my case, composer.lock was still maintaining a reference to the older https://registry.npmjs.org/@northernco/ckeditor5-anchor-drupal/-/ckedito...

Once that was removed, the issue resolved. Worth looking at.

I'm experiencing the same issue. Any thoughts on troubleshooting?

@steffenr

I can confirm this is working. On a clean D10 version:

1. I installed version 2.1
2. I installed version 3.0.0 with your patch
3. I ran database updates successfully.

I did have to run a drush cr to get database updates to run properly through the UI.

I repeated the process without issue running database updates with drush. No cr required.

Thanks for the patch! I'll get a new release cut ASAP.

joelsteidl → created an issue.

I can confirm that the patch fixed things for me as well.

My paragraph had an entity reference, so that checks out for consistency.

joelsteidl → created an issue.

joelsteidl → created an issue.

joelsteidl → created an issue.

I was checking out the patch for Drupal CMS and wondering if it would be better to include the following as part of the Dashboard module. If this has already been discussed, please just point me towards it. I'd be happy to open a new issue and create a MR but wanted a bit of direction.

/**
 * Implements hook_block_alter().
 *
 * See https://www.drupal.org/project/drupal_cms/issues/3474262.
 */
function dashboard_block_alter(&$definitions): void {
  // Extending navigation_block_alter().
  $hidden = [
    'navigation_dashboard',
  ];
  foreach ($hidden as $block_id) {
    if (isset($definitions[$block_id])) {
      $definitions[$block_id]['_block_ui_hidden'] = TRUE;
    }
  }
}

/**
 * Implements hook_plugin_filter_TYPE__CONSUMER_alter().
 *
 * Curate the blocks available in the Layout Builder "Add Block" UI.
 * See https://www.drupal.org/project/drupal_cms/issues/3474262.
 */
function dashboard_plugin_filter_block__layout_builder_alter(array &$definitions, array $extra) {
  if (($extra['section_storage'] ?? NULL) instanceof NavigationSectionStorage) {
    // See navigation_plugin_filter_block__layout_builder_alter();
    $navigation_safe = [
      'navigation_user',
      'navigation_shortcuts',
      'navigation_menu',
      'navigation_dashboard',
    ];
    $definitions = array_filter($definitions, static function (array $definition, string $plugin_id) use ($navigation_safe): bool {
      [$base_plugin_id] = explode(PluginBase::DERIVATIVE_SEPARATOR, $plugin_id);
      return in_array($base_plugin_id, $navigation_safe, TRUE);
    }, ARRAY_FILTER_USE_BOTH);
  }
}

FYI, I created http://drupal.org/project/zoomapi/issues/3510991 for the db update issue

joelsteidl → created an issue.

I do think there is something to look into with the "There is currently no session available." error when doing database updates.

I was able to successfully do the following though:

Fresh install of Drupal 10.4.3
composer require 'drupal/zoomapi:3.0@alpha'
Installed Zoom API 3.0@alpha3
composer require 'drupal/zoomapi:^3.0'
ddev drush updb
No pending updates.

Fresh install of Drupal 10.4.3
composer require 'drupal/zoomapi:^2.1'
Installed Zoom API 2.1
composer require 'drupal/zoomapi:^3.0'
ddev drush updb (had to run twice...failure the first time)
ddev drush cr (for the new configuration page to appear)

Hi @andrerb sorry you are having issues.

So, are you trying to upgrade from 2.x to 3.x? I just want to make sure I'm clear on your issue.

@fathershawn thanks for your help with these tests. Everything is passing now with Gitlab Pipelines.

https://git.drupalcode.org/project/search_api_coveo/-/merge_requests/22

joelsteidl → changed the visibility of the branch 3451400-missed-composer-dot-json to hidden.

Awesome! Thanks for jumping in.

You've been added. I'm happy to review any changes if helpful.

Hi,

Are you actively using the module or Cdnetworks?

Thanks,
Joel

Following up here.

Since the module is currently not throwing exceptions, it would be a breaking change to start throwing them. What if we made the config option to throw exceptions?

One more update. I noticed that the default composer download is still 2.0.x. This is due to the `apitools` requirement that has an alpha release. If your root composer.json has "minimum-stability": "stable", it will try and grab the 2.0.x version. Change that to dev and it gets the right version

@aaronbauman

I added a stable 3.x and got Gitlab pipelines setup with automated tests running again.

Sorry that took so long, and let me know if that is working for you.

Added gitlab pipelines support and made minor adjustments.

joelsteidl → created an issue.

I created a new branch on the MR 3434369-manual-drupal-11

I probably went a bit wide with D11 fixes as I started addressing coding standard issues trying to get all the Pipelines tests to run. We are down to 4 PHP Unit tests that aren't passing.

https://git.drupalcode.org/issue/search_api_coveo-3434369/-/jobs/4414965

Happy to dig in further on why those tests aren't passing if I can get a bit more context.

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

Huge shoutout to @dww for tagging a new release! Thank you.

Hi @pcambra!

Thanks for all the work going into 3.0.x! I came looking for D11 support and I'm happy to report that the 3.0.x dev version is working well. I'm curious if you are targeting a non-dev release of 3.0.x anytime soon.

Thanks!

The MR is working well on a D 11.x site.

1. I created a new block
2. I installed Condition Query module (from the MR)
3. I limited the block to appear based on a condition query
4. The block appeared when the condition query matched and didn't when it wasn't present.

I setup a stock D11 site to test this MR.

1. I installed Webform and Webform Javascript Setting modules
2. In a custom module I added a new property to drupalSettings
3. I setup a new Webform Javascript Setting configuration option to target the above drupalSettings property.
4. I created a new Webform with a Javascript Setting element targeting the above setting.
5. I submitted the Webform
6. The value from my custom drupalSettings property was properly set in the Webform result.

Is there anything else I should test before we consider cutting a D11 release?

@fathershawn

I tested your MR on a D11.x site with Drush 13.x and was able to successfully run a generate command.

The bump to PHP 8.3 and Drush 13.x in composer.json look good.

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

At a minimum we could adjust `composer.json`

Here is the changelog for Drush 13.0.0 https://github.com/drush-ops/drush/releases/tag/13.0.0.

{
    "name": "drupal/data_structures",
    "description": "Generators and utility classes for typed collections",
    "homepage": "https://www.drupal.org/project/data_structures",
    "license": "GPL-2.0-or-later",
    "require" : {
        "php": ">=8.1",
        "drush/drush": "^12 || ^13"
    },
    "support": {
        "issues": "https://www.drupal.org/project/issues/data_structures",
        "source": "https://git.drupalcode.org/project/data_structures"
    },
    "type": "drupal-module"
}

joelsteidl → created an issue.

I can confirm that this patch solved the issue of a View block with empty output. I will take a look at the approach and see if it can be improved.

@anairamzap Thanks for the re-roll. I tested and it solves the related error.

Merge request is ready.

joelsteidl → created an issue.

Fixing a potentially confusing example without the JSON key.

Sorry it took some time for you to find that.

The documentation example shows it with the JSON key.

https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

That's more Guzzle than anything. Please let me know if there is a better place to document this.

@mherchel

Have you tried the workaround mentioned in #29. I know it's not the long-term fix, but want to know more out of curiosity.

@socialnicheguru -- Did you already have the module installed when you applied the patch? If so, you may need to clear cache since the services were getting updated.

I completed the survey :)

joelsteidl → created an issue.

I feel like throwing exceptions by default could be a breaking change, so what if we just make it so throwing exceptions is optional. Would that still work for your needs?

joelsteidl → created an issue.

joelsteidl → created an issue.

joelsteidl → created an issue.

joelsteidl → created an issue.

Thanks @aaronbauman.

I made some headway today. If you wanted to review the MRs for

https://www.drupal.org/project/zoomapi/issues/3489251 📌 Deprecate Event Verification Token Active
https://www.drupal.org/project/zoomapi/issues/3408495 🐛 Deprecated function: Creation of dynamic property Drupal\zoomapi\Plugin\ApiTools\Client::$id is deprecated Active

I haven't looked at https://www.drupal.org/project/zoomapi/issues/3402268 🐛 Throw exceptions on errors Needs review so if you wanted to, that would be cool, but I also don't think I'd let that stop me from a stable release.

If you need 11.x support, that one might take a bit longer due to the reliance on Apitools module.

D11 is paused until we can get Apitools upgraded. It will be a bit heavier lift.

https://www.drupal.org/project/apitools/issues/3438140 📌 Automated Drupal 11 compatibility fixes for apitools Needs review

hi @boinkster,

Ignore my previous comment...potentially still relevant in some instances but this is really a dumb thing with the Zoom API.

After the meeting has passed, the meeting gets assigned a new UUID. This may not be that helpful in your situation if you are storing the original UUID.

<?php

// Meeting ID, not the UUID.
$meeting_id = '1234567890';
$client = \Drupal::service('zoomapi.client');
$endpoint = "past_meetings/$meeting_id/instances";

// This returned an array for me, but it contained UUIDs I could use for past meeting details.
$results = $client->get($endpoint);

// Now you can use your UUID to get what you need.
$uuid = 'YOUR_NEW_UUID_HERE';
$endpoint = "past_meetings/$uuid/participants";
$results = $client->get($endpoint);

Marking as closed won't fix for Zoom API since the config piece is part of Apitools, but please keep us updated on what folks are seeing.

On 10.3.10 I had no issues but the patch in apitools referenced above seems like the right approach.

The merge request removes the deprecated verification and writes an update hook to remove it from active config.

joelsteidl → created an issue.

The major issue here was trying to handle the use case where a user was coming from 2.x to 3.x and did not have apitools enabled . They couldn't get past the whitescreen of death.

I think the merge request handles that and the original issue reported.

I'd love any testing that folks can offer.

ahh...good to know!

Let me try to fix a couple issues in the queue and then get a stable out the door.

hi @boinkster,

Sorry you have having that issue. Add the end of the day, we are just using Guzzle for making the request. You could try something like this though....

function doubleEncodeMeetingUUID($meetingUUID) {
    // Check if the meeting UUID begins with a '/' or contains '//'.
    if (strpos($meetingUUID, '/') === 0 || strpos($meetingUUID, '//') !== false) {
        // Double-encode the meeting UUID.
        $meetingUUID = rawurlencode(rawurlencode($meetingUUID));
    }
    return $meetingUUID;
}

// Example usage:
$meetingUUID = '/example//uuid';
$encodedUUID = doubleEncodeMeetingUUID($meetingUUID);
echo $encodedUUID; // Output: %252Fexample%252F%252Fuuid

Completely untested, but maybe try a single or double rawurlencode before you concatenate your endpoint string. I'm happy to try and test further if that doesn't work.

Thanks for the patch @alexharries

Just noting that this solved the used for me as well. I agree with @erik.erskine wondering what purpose the added use statement serves.

@greg.1.anderson The patch in https://www.drupal.org/project/pantheon_advanced_page_cache/issues/3478153 🐛 Syntax error breaks all image uploading. Active fixed the issue for me. Thanks!

Just noting that the patch worked for me and will grab the new release shortly.

Interesting, I'm getting a similar error, but from a very different action.

Error: Undefined constant "ImageStyle" in pantheon_advanced_page_cache_file_update() (line 22 of /code/web/modules/contrib/pantheon_advanced_page_cache/pantheon_advanced_page_cache.module).

In my case, I have a Feeds module import running that is trying to create/update images and it is hitting the snag during image creation and make the feed import fail.

I have the Webp module enabled and will test if that may be the culprit.

This is linked on the module homepage too! https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Thanks Jennifer!

joelsteidl → created an issue.

This made it into 2.0.1.

Overall the automated fixes are fine. I'm updating to not drop 9.x support as it still works fine.

2.x is no longer maintained.

The JWT app type will be deprecated. We recommend that you create Server-to-Server OAuth or OAuth apps to replace the functionality of a JWT app in your account. See the JWT app type migration guide for details.

On June 1, 2023, Developers will not be able to create new JWT app types.
On September 1, 2023, Zoom will disable JWT app type authorization. Contact Developer Support for details.

I am scheduled to be a speaker on Friday!

I am volunteering both days

Here!

joelsteidl → created an issue.

Thanks @SocialNicheGuru! So just confirming that this is a PHP 8.2 issue?

Additional edits

minor edit

further examples

updating examples

I need more information. Can you post a code example that was causing the deprecated function? Zoom API Module and APITools are not setting an $id property. Are you setting one?

I just updated the mergevars description in the merge request. Happy to make that change elsewhere if it makes sense.

FYI, I'm on Drupal 10.1.x where I was having that issue.