🇮🇳India @mukhtarm

Hi @sébastien-fr

Can you please mention from which version you upgraded to 4.0.0-alpha6? 

I followed these steps and couldn't reproduce the issue you stated. 


1. Installed dev version dev-4.x
2. Created some conditional fields.
3. Upgrded to 4.0.0-alpha6 - No errors
4. Refreshed the conditional fields => Content (Any Type) page - No errors

Please review the patch. Likewise, I also created the content from devel and the padding applied for both mobile and desktop.
I am also not sure about the file (which the correct place to modify or not).

Ah! , that was crazy 😄. hopefully you can check the release plans in git or so (https://git.drupalcode.org/project/drupal).

hi @jrockowitz Can you please check if this issue is related?

https://drupal.stackexchange.com/questions/320938/webform-confirmation-p...

Patch #4 ✨ And search and filter functionality to the dashboard Needs review applying cleanly on 2.x-dev. But why you removed translations for the form element's title?

The rector patch was not applied cleanly. Please check the patch below.

hi @Anybody whenever I create the MR, many changes are coming along with that. I'm not sure why, Can you please check?
I followed the command given in the issue fork only.

@Anybody Sure.

@TR can you please mention the status change to closed also? Why is it not there in the latest version as the OP mentioned the issue version as 8.x-3.0-beta4

hi @bajah1701, There is already an MR for this and it's merged in the dev version. please use votingapi:3.x-dev@dev.

Maybe this needs to be ported to the Beta version.

Same issue here. I am posting two images. One is the original image uploaded and the other is WebP converted.
I set the Image quality in the webP configuration as 100.

As I can not upload the webP image here, I am posting the webP image uploaded in a image hoster(https://i.postimg.cc/sgWsrrFp/webp-converted.webp)

I am getting an error like as follows when connecting to the db: 

TypeError: Unsupported operand types: MongoDB\Model\BSONDocument + array in Drupal\migrate\Plugin\migrate\source\SourcePluginBase->next() (line 400 of /var/www/html/web/core/modules/migrate/src/Plugin/migrate/source/SourcePluginBase.php)

Any idea? 

Why is this not there in the core yet? I am using D10.2.4 and Patch #6 works for me and resolved my problem.

Can somebody review this please.

Please review the patch. thanks

MukhtarM → created an issue.

Created an MR to Hide and show the Scroll to top link . Please review.

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

Can you reiterate your issue? I am getting the MediaWiki Filter API form in the text formats . Attaching ss.

Hi, @Marcus sent you that mail, and as suggested by @sandy we could start with a simpler one :)

@jcnventura you can consider granting credits to the people who have contributed :)

@Marcus_Johansson I DM' ed you.

Hi, @Marcus_Johansson thanks for the detailed response. I like to work on the tasks you mentioned, But probably I need to get more on the module workflow and related modules (Also I might need a test API key to test things out). Thanks.

Here is a patch if you are still getting error on config page.

@nicxvan Created an MR to address the changes. Please review.

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

@poker addressed #16 🐛 PHP 8.1 compatibility issues: passing null to strlen() and strpos() is deprecated Needs work

Hi, resolved the MR to apply the patch #9. Please review, thanks.

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

sorry about that @anybody I was trying to fix the config error, rather not checked the usage in the code. +1 for MR 👍

After removing the theme_display: null from the config (layout_paragraphs.modal_settings), import it again (drush cim -y), run the config-inspector report it worked for me. Attaching the screenshots.

Actually there is no way to provide a patch a MR for this, as the particular configuration is over rided after making the changes in Layout Paragraphs Modal Settings from layout_paragraphs Configuration settings.

Please review the patch, thanks.

MukhtarM → created an issue.

Thank you @omrmankar it worked. postman things :)

Hi, please review the patch. thanks

Please review the patch

MukhtarM → created an issue.

its because the module is trying to connect to the telemetry default endpoint specified in the opentelemetry.settings.yml (http://localhost:4318). Either need to disable it or enable the server and try.

Please review the patch. thanks

MukhtarM → created an issue.

Actually i was working on the MR at the same time :) .. checked in local and its working fine. attaching screenshot. Thanks

Thank you @VinmayiSwamy for noticing it. Here is the corrected patch.

Thank you @VinmayiSwamy for noting it. Closing it now.

Please review the patch, Thanks

MukhtarM → created an issue.

Please review the patch. Thanks

MukhtarM → created an issue.

Please review the patch. Thanks

MukhtarM → created an issue.

Hi @Anaconda777 Please check the patch. And it is always recommended to use latest package of the module on latest Drupal version :) if you upgrading PHP to the latest.
As D7 support is already ended.

Tested the patch and its working fine. I guess in that case we can remove the hardset initilization too.

Can you please make the post to English as drupal.org served in english language :)

Please review the patch, thanks.

MukhtarM → created an issue.

@lolgm Actually the patch didn't included the new plugin file (my bad :( ). Corrected it and included your changes also. thanks.

please review the patch.

MukhtarM → created an issue.

The states API have a change recently in core, see this: https://git.drupalcode.org/project/drupal/-/compare/308e696f76fc33d6a5d8... on issue: https://www.drupal.org/project/drupal/issues/1149078 🐛 States API doesn't work with multiple select fields Needs review . Idk conditional_fields making use of states API, but posted if that helps.

Thanks for the update @lolgm

$entity->access('permission') has been deprecated since D10 and gives the warning( https://www.drupal.org/node/3201242 → ).

Relying on entity queries to check access by default is deprecated in  
         drupal:9.2.0 and an error will be thrown from drupal:10.0.0. Call      
         \Drupal\Core\Entity\Query\QueryInterface::accessCheck() with TRUE or   
         FALSE to specify whether access should be checked.

Anyway to check explicit access for the entity in getDefaultOperations?

for eg:

public function getDefaultOperations(EntityInterface $entity) {
    $exists = isset($this->templates[$entity->getGathercontentTemplateId()]);
    $operations = [];
    if ($exists && $entity->access('update') && $entity->hasLinkTemplate('edit-form')) {
      $operations['edit'] = [
        'title' => $entity->hasMapping() ? $this->t('Edit') : $this->t('Create'),
        'weight' => 10,
        'url' => $entity->toUrl('edit-form'),
      ];
    }
    if ($entity->access('delete') && $entity->hasLinkTemplate('delete-form')) {
      $operations['delete'] = [
        'title' => $this->t('Delete'),
        'weight' => 100,
        'url' => $entity->toUrl('delete-form'),
      ];
    }
    return $operations;
  }

here i think its explicitly checking access for 'update' or 'delete'. So the entityQuery->accessCheck(TRUE) would work? as its for the whole access right?

Please review the patch. thanks

MukhtarM → created an issue.

Thanks for the update @agentrickard.

I am working on this. will raise a new MR for coding standard and modify the current one.

Please review the MR. thanks

hi @AstonVictor the translation string can be corrected, and i couldn't see any error if by default i am not selecting any permission or roles assigned to it (If that is meant by validation returns FALSE if the admin doesn't add configurations on the settings page.).

yea didn't added the new permission but thought to manage in the configuration form itself (Not sure about this).

But your way works too 👍. rather than these this workflow need to be confirmed to be correct by @aronne. Thanks

MukhtarM → created an issue.

Please review the patch.

MukhtarM → created an issue.

@codesquatch I wonder why the hook_update is used in place for to add these fields? drush updb created the fields for me.

Way to go. This patch is not yet available in '2.0.0' version. The installation still fails on D10 :(

@geocalleo i raised against 2.0.0 now. First i tried to raise in the git UI itself (as there no code change), but it didn't worked. Thats why there is a intermediate MR :)

Yea sure @geocalleo i will do that

@mahyarsbt sure i am interested to contribute. Hope you don’t mind giving credits:)

@aronne thats correct. I also think creating a new configurable permission, that can be assigned to a role by an administrative role user.

I think you have to typecast to string in this case along with the empty check. Please check: https://github.com/symfony/symfony/issues/45179
I have updated the MR, please check.

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

MukhtarM → created an issue.

I am too not geting this reproduced in local. In fact i wonder when i enable Enable/Disable local tasks display what are the changes would effect? As node edit and delete already there. (may somebody point here would help)

Thanks @geocalleo.

Please review the patch, thanks

Hi I am using D9.5 and here is the patch that works for the custom date fields (I combined the #18 and #3 basically, but there were some tweaks needed as #18 was not applying cleanly). It works well to apply the custom SQL format to the custom field. Thanks

@sandipta There are some Eslint and phpcs errors in the pipeline. Can you please check?
https://git.drupalcode.org/issue/select2_all-3399753/-/jobs/285274

MukhtarM → created an issue.

I think it would make sense. If that is here is the patch :)

Please review the patch

MukhtarM → created an issue.

Please review the patch. thanks

MukhtarM → created an issue.

MukhtarM → created an issue.

Hi @solarDog You have to change the cocoen_beforeafter.js to

(function ($, Drupal, once) {

  Drupal.behaviors.beforeafter = {
    attach: function (context, settings) {
      once('.cocoen-beforeafter-container', context).cocoen();
    }
  }

})(jQuery, Drupal, once);

As well as point the core/once library in cocoen_beforeafter.libraries.yml (Which will remove the once error for you). I will provide a patch soon.
As jquery.once is deprecated in favour of core/once as you said.

Hi @clarkssquared The patch from MR is applying fine for me. Please follow this instruction to apply the patch MR: https://drupal.stackexchange.com/questions/303436/how-do-i-apply-patches...

Ok here is a workaround that is serving the private blob files directly using SAS token (We don't need to save locally to save the storage). Also resolves #15 📌 Support private containers and try to serve locally from the server Needs review . Thanks