🇮🇳India @sumit-k

sumit-k → created an issue.

sumit-k → created an issue.

MR !2 is fixing the issue. MR !1 is breaking functionality hence merging MR !2. Thanks.

Raised MR !47 for moderation state handler.

sumit-k → made their first commit to this issue’s fork.

sumit-k → created an issue.

sumit-k → created an issue.

As part of the Drupal core changes, it's important to verify the modifications with thorough testing. I've submitted a Merge Request (MR) !6910 containing the necessary test case to ensure that the changes are properly validated.

sumit-k → made their first commit to this issue’s fork.

sumit-k → created an issue.

Thanks @thampiajit verified the changes. Looks good.

Thank you for the review, @Jasjeet. I've verified the issue on the latest release and it seems to be resolved. Your confirmation confirms that it has been addressed in the latest release. Seems Pr is merged on the latest release. In my opinion, this ticket can now be closed.

Updating the status to "Needs Review" to gather feedback on the patch and gather opinions from others who might be experiencing the same issue.

Fixed core commit check issues. Changing status to Need Review.

Raised MR !6804 of patch #13.

sumit-k → made their first commit to this issue’s fork.

Thanks for clarification Joy. It appears that I'm unable to replicate this issue on the same version. It's possible that there might be conflicts with other modules causing this behavior. Can you please share the URL where the error is coming?

sumit-k → created an issue.

Verified the changes, and everything seems to be working fine on my end. I've also attached a screenshot for reference. Joyceflorenc3, could you please provide more details such as the version of Drupal core and PHP you are using? This information will help us troubleshoot any potential compatibility issues. Thanks!

After module installation encountered the following error. Raised MR!3 to fix the following issues.

TypeError: Drupal\nitropack\EventSubscriber\NitropackSubscriber::onRespond(): Argument #1 ($event) must be of type Symfony\Component\HttpKernel\Event\FilterResponseEvent, Symfony\Component\HttpKernel\Event\ResponseEvent given in Drupal\nitropack\EventSubscriber\NitropackSubscriber->onRespond() (line 134 of modules/contrib/nitropack/src/EventSubscriber/NitropackSubscriber.php).

The website encountered an unexpected error. Try again later.

Error: Call to undefined method Symfony\Component\HttpKernel\Event\ResponseEvent::isMasterRequest() in Drupal\nitropack\EventSubscriber\NitropackSubscriber->onRespond() (line 136 of modules/contrib/nitropack/src/EventSubscriber/NitropackSubscriber.php).

sumit-k → made their first commit to this issue’s fork.

sumit-k → created an issue.

Thank smustgrave for providing clarification on the scope. I've removed the strict type declaration and made some adjustments to adhere to coding standards.

sumit-k → created an issue.

I've added a simple functional test to validate the changes made to the label.

sumit-k → made their first commit to this issue’s fork.

Certainly, it does make sense to use the "overridden" keyword instead of a symbol like a sign. This change can enhance clarity, especially for new Drupal users who may not be familiar with the significance of certain symbols.

Raising a merge request (MR) and providing a screenshot for reference is a proactive approach to communicate the proposed change effectively. It helps stakeholders visualize the suggested modification and provides context for the decision to use the "overridden" keyword.

sumit-k → made their first commit to this issue’s fork.

Upon analysis of the addLink() function in the modules/contrib/group_content_menu/src/Controller/GroupContentMenuController.php file, it appears that there is an issue with loading the menu entity, resulting in a null value for the menu. This occurs because the entity type and menu ID are not correctly specified.

public function addLink(GroupContentMenuInterface $group_content_menu) {
    $menu_name = GroupContentMenuInterface::MENU_PREFIX . $group_content_menu->id();
    $menu_link = $this->entityTypeManager()->getStorage('menu_link_content')->create([
      'menu_name' => $menu_name,
      'bundle' => 'menu_link_content',
    ]);
    return $this->entityFormBuilder()->getForm($menu_link);
  }

addLink function is calling

/core/modules/menu_link_content/src/Form/MenuLinkContentForm.php

public function form(array $form, FormStateInterface $form_state) {
    $form = parent::form($form, $form_state);

    $parent_id = $this->entity->getParentId() ?: $this->getRequest()->query->get('parent');
    $default = $this->entity->getMenuName() . ':' . $parent_id;
    $id = $this->entity->isNew() ? '' : $this->entity->getPluginId();
    if ($this->entity->isNew()) {
      $menu_id = $this->entity->getMenuName();
      $menu = $this->entityTypeManager->getStorage('menu')->load($menu_id);
      $form['menu_parent'] = $this->menuParentSelector->parentSelectElement($default, $id, [
        $menu_id => $menu->label(),
      ]);
    }
    else {
      $form['menu_parent'] = $this->menuParentSelector->parentSelectElement($default, $id);
    }
    $form['menu_parent']['#weight'] = 10;
    $form['menu_parent']['#title'] = $this->t('Parent link');
    $form['menu_parent']['#description'] = $this->t('The maximum depth for a link and all its children is fixed. Some menu links may not be available as parents if selecting them would exceed this limit.');
    $form['menu_parent']['#attributes']['class'][] = 'menu-title-select';

    return $form;
  }

$menu = $this->entityTypeManager->getStorage('menu')->load($menu_id);

menu is not getting loaded it is coming null because entity type and menu id are not correct.

To address this issue, attempted to correct the entity type and ID by directly setting them to 'group_content_menu' and a valid menu ID.
something like

$menu_id = '9'; // Check menu id in my case it is 9
$menu = $this->entityTypeManager->getStorage('group_content_menu')->load($menu_id);

IMO Instead of modifying the core files, it may be more appropriate to create a custom form function within the Group Content Menu module. By doing so, you can ensure that the correct entity type and menu ID are used without altering core functionality.

I encountered the same issue and found that Patch #2 provided in the following link: https://www.drupal.org/project/redirect/issues/3314032 → resolved the issue effectively in my case. Additionally, I contributed another approach to handle exceptions within the same discussion thread.

After replicating the issue, I can confirm that Patch #2 resolves the issue satisfactorily. Additionally, I've introduced an alternative method to handle straightforward exceptions, which has proven effective in addressing the problem in my scenario.

function redirect_entity_delete(EntityInterface $entity) {
  try {
    if ($entity->getEntityType()->hasLinkTemplate('canonical') && $entity->toUrl('canonical')->isRouted()) {

       // Generate the canonical URL after setting the required parameters.
       $canonical_url = $entity->toUrl('canonical');
      
       // Check if the canonical URL has the required parameters set.
      try {
        if ($canonical_url->getRouteParameters()) {
          redirect_delete_by_path('internal:/' . $entity->toUrl('canonical')->getInternalPath());
        }
      }
      catch (Exception $e) {
        // This can happen if some mandatory parameters are missing.
      }
      redirect_delete_by_path('entity:' . $entity->getEntityTypeId() . '/' . $entity->id());
    }
  }
  catch (RouteNotFoundException $e) {
    // This can happen if a module incorrectly defines a link template, ignore
    // such errors.
  }
}

Seems this issue is already raised in https://www.drupal.org/project/redirect/issues/3314032 → . Closing this ticket.

sumit-k → created an issue.

Per https://www.drupal.org/project/drupal/releases/10.2.0 →
Drupal core automated tests and test APIs are being converted to require strict typing in all cases. So far, Drupal core test traits, build tests, and functional JavaScript tests all require strict typing. Going forward, all Drupal core tests will require strict typing. It is recommended that contributed and custom projects use the Drupal standard for strict type declaration.

Added strict type and fixed phpcs issues.

sumit-k → made their first commit to this issue’s fork.

I believe it would be beneficial to make the "hide username from title" feature configurable, as its necessity can vary depending on project requirements. I have initiated a request MR !9 to address this option.

sumit-k → made their first commit to this issue’s fork.

Upon attempting to replicate the reported issue, I have followed the outlined steps, which involved installing both the Config Split and Conditional Field modules and navigating to the specified configuration page at "admin/config/development/configuration/config-split/add." However, I was unable to encounter the issue as described.
Should have any additional details or steps to provide.

Applied the patch successfully, and the tabs are being added as expected. Attaching screenshot for reference.

sumit-k → created an issue.

verified the provided patch, and it is functioning as expected in my local environment. Raising MR !80 to fix the issues related to test cases effectively.

sumit-k → made their first commit to this issue’s fork.

sumit-k → created an issue.

sumit-k → created an issue.

Added one commit to resolve error on installation of module.

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal10.beautytips_custom_tips' doesn't exist: SELECT * FROM "beautytips_custom_tips"; Array ( ) in beautytips_manager_get_custom_tips() (line 155 of modules/contrib/beautytips/beautytips_manager/beautytips_manager.module).

sumit-k → made their first commit to this issue’s fork.

sumit-k → created an issue.

sumit-k → created an issue.

Seems it is fixed in 2.x. Closing this issue.

sumit-k → created an issue.

I've verified the changes, and it seems that the uploaded icons are now successfully visible on the user login page. This enhancement not only adds a visual appeal but also provides a more personalized and engaging experience for users.

Adding automated test patch to verify module functionality. I would greatly appreciate it if anyone could take the time to review the changes.

sumit-k → created an issue.

sumit-k → created an issue.

I have successfully replicated the issue we discussed earlier. For reference, I have attached a screenshot highlighting the specific error.
MR !13 fixing this issue.

I have successfully replicated the issue mentioned in #19 after applying the changes from #17. I'm sharing a patch that has resolved the issue for me.

Sharing patch file for test cases.

sumit-k → created an issue.

It appears that the issue encountering is related to the [current-user:roles:last] token not being supported because roles:last is not a valid field name within the user entity.

public function processToken(FieldableEntityInterface $entity, $token_entity_type, $argument) {
    // @todo $entity_type could potentially be retrieved by checking on $entity.
    $and_or = $this->options['and_or'];
    $field_names = $this->tokenScan($argument);
    foreach ($field_names[$token_entity_type] as $field_name => $token) {
      $replace_values = [];
      if ($entity->hasField($field_name)) {
        $field_values = $entity->get($field_name)->getValue();
        foreach ($field_values as $field_value) {
          $replace_values[] = array_values($field_value)[0];
        }

        // Replace and implode with , or + for multiple value management.
        $replace = implode($and_or, $replace_values);
        $argument = str_replace($token, $replace, $argument);
      }
    }
    return $argument;
  }

The provided code snippet shows the processToken function in Drupal, which handles token replacement within entities. In this function, it attempts to retrieve the field values associated with the specified field name from the entity. However, it checks if the entity has a field with the name roles:last, and since this field name does not exist within the user entity, the token replacement does not occur.

Replicated the mentioned issue, and it appears that enabling AJAX in Views is causing a conflict with the views exposed filter submit functionality. This conflict arises due to the AJAX form action path being overridden, which in turn affects the ability to perform updates.

Here are the steps to reproduce the issue:

1. Create a view page that includes the title field and select the "Formatted editable" option.
2. Add the node ID field to the filter criteria and expose it.
3. Enable AJAX for the view.
4. Visit the view page and apply filters.
5. Notice that the update functionality is no longer working due to the form action path being overridden.

I have reviewed the provided patch, It fixes the issue for the primary theme. However, it appears that there's an error persisting when it comes to the subtheme. Adding patch to fix this issue.

The raised merge request is functioning smoothly. It successfully introduces the 'core field diff' option for the weight field. To provide visual clarity, I have attached a screenshot for your reference.

Please find the patch below to enable the sound playback on cache clear using Drush. Kindly note that this approach is currently compatible with MacOS and Linux operating systems.

Replicated the same issue. #3 solution is working fine, adding a patch for the same changes.

Adding patch for OneOfSeveralValidationRule test. Please review. Thanks.

Adding patch for PatternFieldValidationRule test.

Thanks for the review and suggestion. Sharing new patches with suggested improvements. Considered points 1 , 2 and 3.

Adding patch for UrlFieldValidationRule test. Changes are

1> Created test.
2> Added dependencies module
protected static $modules = ['node', 'field_validation', 'path_alias', 'user'];

3> Replaced patch validator function inside UrlFieldValidationRule.php.

-          $flag = \Drupal::service('path.validator')->isValid($normal_path);
+          $flag = \Drupal::service('path.validator')->getUrlIfValidWithoutAccessCheck($normal_path);

Sure, Adding a new patch. Thanks for the review.

Hi, Attaching the test patch for itemCountFieldValidationRule.
1> Test patch for itemCountFieldValidationRule.
2> Fixed 1x: The Drupal\Tests\field_validation\Kernel\Plugin\FieldValidationRule\EqualValuesValidationRuleTest::$modules property must be declared protected. See https://www.drupal.org/node/2909426 →

-  public static $modules = ['node', 'field_validation'];
+  protected static $modules = ['node', 'field_validation'];

Hi, sharing the patch for two changes.
1> Test patch for EqualValuesFieldValidationRule.
2> Removed 1x: The Drupal\Tests\field_validation\Kernel\Plugin\FieldValidationRule\EqualValuesValidationRuleTest::$modules property must be declared protected. See https://www.drupal.org/node/2909426 →

-  public static $modules = ['node', 'field_validation'];
+  protected static $modules = ['node', 'field_validation'];

Removed t() function. Sharing new patch. Please review.

Thanks for reviewing, recently mentioned issues are fixed in the following patch https://www.drupal.org/files/issues/2023-07-07/t_calls_should_be_avoided-3359562-11.patch. Thread - https://www.drupal.org/project/realname/issues/3359562#comment-15140770 📌 t() should not be used in test classes Needs review

IMO attaching the same patch to this thread would be redundant since it is already available in the mentioned thread.

FILE: /var/www/html/modules/real/realname/tests/src/Functional/RealnameBasicTest.php
-----------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 3 WARNINGS AFFECTING 3 LINES
-----------------------------------------------------------------------------------------------------------------------------------------

 72 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 83 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 90 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
-----------------------------------------------------------------------------------------------------------------------------------------


FILE: /var/www/html/modules/real/realname/src/Controller/RealnameAutocompleteController.php
-------------------------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-------------------------------------------------------------------------------------------------------------------------------------
 24 | ERROR | The array declaration extends to column 92 (the limit is 80). The array content should be split up over multiple lines
-------------------------------------------------------------------------------------------------------------------------------------

Time: 223ms; Memory: 10MB

Getting the following issues on running phpcs with standard Drupal and DrupalPractice. Attaching patch for fixes. Please review.

Applied patch #14. Test and functionality are working fine for me.

Thanks for the review. Sharing new patch covered point 2.
Regarding points 1 and 3.

+++ b/composer.json
@@ -18,7 +18,23 @@
+        "drush.services.yml": "^9"

It seems it will be required for Drush 10.

Based on the provided documentation https://git.uwaterloo.ca/libraries/drush/-/blob/11.x/docs/commands.md, it appears that including the drush.services.yml file and the /src/Drupal/Commands directory is indeed required

Not sure about dependency injection based on the following document it has two way to use dependency injection
https://git.uwaterloo.ca/libraries/drush/-/blob/11.x/docs/dependency-inj...

Please correct me if my understanding is not clear.

Tried to replicate the issue with the mentioned details but didn't get it. I would appreciate it if you could provide the steps to reproduce to reproduce the issue.

Trie to replicate this issue with some other field, but didn't get it.

IMO To resolve this issue, you can try the following:

Check the structure of content.field_telephone_lycee to ensure it is an array and contains the expected data. You can use kint() or var_dump() to inspect the content variable and ensure it has the correct structure.

If content.field_telephone_lycee is a render array, you should use the children function to access the child elements.

I think content.field_telephone_lycee itself is rendered directly without using an index.

{{ content }} is a render array. on dump, we can see an array

0 array:1 [▼
  0 => array:1 [▼
    "#markup" => "On"
  ]
]

{{ content.field_toggle.0["#markup"] }}

Content is not ideal for logic. use content. for rendering and node. for logic.

Sure, Sharing a new patch. Please review