🇮🇳India @vinayakmk47

Hi @torfj, This issue proposes adding a logo for the Menu Fast Edit module to improve its branding and visual identity.

**Proposed Logo**:
Attached is a logo that visually represents the module's purpose by combining speed (lightning bolt) and menu elements in a clean, minimalistic design.
the logo designed for the "Menu Fast Edit" module. It incorporates speed and menu elements in a modern and clean style.

**Design Details**:
- Colors: Shades of blue (aligned with Drupal's theme) and subtle grays.
- Style: Flat design with soft gradients.
- Purpose: Enhance module identity and usability.

Please review the logo and suggest any modifications needed.

This issue proposes adding a logo for the Menu Fast Edit module to improve its branding and visual identity.

**Proposed Logo**:
Attached is a logo that visually represents the module's purpose by combining speed (lightning bolt) and menu elements in a clean, minimalistic design.
the logo designed for the "Menu Fast Edit" module. It incorporates speed and menu elements in a modern and clean style.

**Design Details**:
- Colors: Shades of blue (aligned with Drupal's theme) and subtle grays.
- Style: Flat design with soft gradients.
- Purpose: Enhance module identity and usability.

Please review the logo and suggest any modifications needed.

Hi @sirclickalot check the changes i made and review please let me know if there are any changes required.

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

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

Hello @drupol,

I tried to replicate the issue you reported after clicking the "Add field group" button (Structure > Content Type > Manage Form Display), but I couldn't reproduce it on my end.

Here’s what I tested:

Cleared caches using drush cr and cleared browser cache.
Tested with both field_group versions: 3.6 (stable) and 4.0.0-alpha1.
Verified compatibility with Drupal Core (10.4.1 in my setup).
Checked for any JavaScript errors in the browser console, but found none.
The functionality worked as expected without throwing the rowHandlers[data.rowHandler] is not a constructor error.

If the issue persists for you, it might be related to your environment or customizations. I recommend:

Clearing caches again (drush cr).
Checking for JavaScript conflicts caused by other modules or custom scripts.
Verifying that all module files are installed correctly by running composer install.
Testing in an incognito/private browser window to rule out cache issues.
If the problem continues, it could help to share more details, such as your exact Drupal version, enabled modules, or any customizations applied to the field UI.

Let me know if you need further assistance!

Hello @drupol,

I tried to replicate the issue you reported after clicking the "Add field group" button (Structure > Content Type > Manage Form Display), but I couldn't reproduce it on my end.

Here’s what I tested:

Cleared caches using drush cr and cleared browser cache.
Tested with both field_group versions: 3.6 (stable) and 4.0.0-alpha1.
Verified compatibility with Drupal Core (10.4.1 in my setup).
Checked for any JavaScript errors in the browser console, but found none.
The functionality worked as expected without throwing the rowHandlers[data.rowHandler] is not a constructor error.

If the issue persists for you, it might be related to your environment or customizations. I recommend:

Clearing caches again (drush cr).
Checking for JavaScript conflicts caused by other modules or custom scripts.
Verifying that all module files are installed correctly by running composer install.
Testing in an incognito/private browser window to rule out cache issues.
If the problem continues, it could help to share more details, such as your exact Drupal version, enabled modules, or any customizations applied to the field UI.

Let me know if you need further assistance!

I've fixed the issue and implemented the functionality to unlock all entities or bundles with a Drush command. A merge request has been created for this. Please review it and let me know if any further changes are needed. Thanks!

Thank you, @niharika.s, for working on this issue and applying additional changes. I’ll review your modifications to see how they align with the current implementation. Let’s ensure the solution works seamlessly across all scenarios. I’ll provide feedback after testing your changes.

Fixed Issue: When adding the User account menu to TB Mega Menu, it threw an error:
TypeError: Illegal offset type in template_preprocess_tb_megamenu_subnav().
Resolution: Ensured $title is cast to a string before using it as an array key.
Testing: Verified with User account menu, rendering correctly without errors.
Created a merge request please review and let me know if there are any changes.

changed the title

I have fixed the problem and created a merge request kindly review and merge.

Introduction

The Podcast Publisher module allows users to generate RSS feeds for podcasting using Drupal's Views module. This document outlines how the feed is generated, the settings available for adjustment, and how to customize the feed's output according to Drupal's documentation standards.

Generating the RSS Feed Using Views

Prerequisites

Ensure the Podcast Publisher module is installed and enabled.

Verify that the Views module is installed and functional.

Have content types and fields related to podcasts set up in your Drupal site.

Steps to Generate the RSS Feed

Create a New View:

Navigate to Structure > Views.

Click Add view.

Provide a name for the view (e.g., "Podcast RSS Feed").

Choose the relevant content type (e.g., Podcast Episodes).

Select "Provide a page" and set the format to RSS Feed.

Configure Feed Path:

In the view configuration, define the RSS feed path (e.g., /podcasts/rss).

Add Relevant Fields:

Add fields such as title, description, and media URL.

Ensure the fields comply with podcasting standards (e.g., iTunes requirements).

Set Field Format Options:

Click on the settings for each field to customize its output (e.g., use tokens for dynamic values).

Save and Test the View:

Save the view.

Test the RSS feed by accessing the defined path in your browser or feed reader.

Adjusting Feed Settings

RSS Feed Configuration

To customize general RSS feed settings:

Navigate to Configuration > Web Services > RSS Publishing.

Update the global feed settings such as the number of items to display, default feed title, and description.

View-Specific Adjustments

In the view configuration:

Filter Criteria: Use filters to control which podcast episodes appear in the feed (e.g., by publish date or taxonomy term).

Sort Criteria: Define the sorting order for feed items (e.g., newest first).

Feed Style Options:

Adjust title, link, and description fields.

Include additional namespaces (e.g., itunes:) for compatibility with podcast platforms.

Customizing the Feed Output

Custom Fields and Tokens

Add custom fields to the view to include additional metadata (e.g., episode duration, author).

Use the Rewrite Results option to modify field output using tokens.

Theming and Templates

To customize the feed's HTML/XML structure:

Locate the RSS feed template file in your theme (e.g., rss-view-feed.tpl.php).

Override the template by copying it to your theme’s templates directory and modifying it as needed.

Clear the cache to apply changes.

Hook-Based Customization

For advanced modifications, use Drupal hooks:

Implement hook_views_pre_render() to adjust the feed data programmatically.

Use hook_preprocess_views_view() to preprocess data before rendering.

Best Practices

Validate the RSS feed using tools like W3C Feed Validation Service to ensure compatibility.

Follow podcast-specific guidelines, such as those for iTunes and Google Podcasts.

Regularly test the feed to confirm its functionality.

Hello, I have made the necessary CSS changes to address the issue where the .social-sharing-buttons component in the sidebar does not wrap correctly when all share buttons are enabled. Previously, the buttons were displayed in a single row, exceeding the container's boundaries. After applying the CSS updates, the wrapping functionality is working as expected, and the buttons now align within the container without overflowing.

While the CSS changes resolved the wrapping issue locally, the changes are failing in the pipeline when I push the code. I would like someone to review the updated CSS to identify any potential mistakes or areas for improvement to ensure it passes validation and follows best practices.

Check the screenshot of before and after difference

When the AI module is installed and Anthropic is configured as the provider, the Max Tokens setting can be adjusted directly in the admin interface. Navigate to the following URL to access this setting:

URL: admin/config/ai/explorers/chat_generator

On this page, under the Provider Configuration section (as shown in the screenshot), you will find the Max Tokens input field. This field allows you to specify the desired maximum token limit for chat completions. For example, you can input 4096 to accommodate your requirements.

This ensures flexibility and control over the token limit for your specific use case without requiring any code-level changes.

Thanks, @leo pitt, for your feedback and for making the indentation update! I appreciate your review and confirmation that the changes are good. Let me know if there's anything else you'd like me to address.

Hi @l-laziz I followed the same steps as above but for me its working fine can you check again by installing that module with all the dependencies and submodules you can check the screenshot i have attached please let me know if i am missing anything.

@leo pitt I have made changes according to the above mentioned comments Please review it and let me know if there are any further changes i have to make.

@t_d_d @gábor hojtsy I am also facing issue when installed upgrade status 4.1 version for Drupal 9.5.3, PHP 8.1.25. Module installed via composer and enabled with drush. getting InvalidArgumentException: Class "\Drupal\upgrade_status\Form\UpgradeStatusForm" does not exist. in Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (line 24 of C:\xampp\htdocs\legal\web\core\lib\Drupal\Core\DependencyInjection\ClassResolver.php). error

Added live mode configuration option with checkbox in admin settings. When disabled, donations will be processed in test mode. Implemented as requested.

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

I have thoroughly tested the described issue and found that the functionality is working as expected. Here are the details:

Steps Taken:

Configured the site to allow both email and username as login identifiers.
Created two users with the following details:
User A: Username user_a, Email test@example.com.
User B: Username user_b, Email test@example.com.
Submitted the password reset form with the email test@example.com and username.
Observed the email-sending process in both the logs and at the code level.
Verified at the code level that the system correctly matches the email and username and sends the reset link to the appropriate account.
only single account not multiple with same mail addresses
Environment Details:

Drupal Version: 9.5.11
PHP Version: 8.1.25
Mail Handling: Using DDEV's Mailpit for local testing.
Debugging Tools: Used var_dump to check the user account being processed during the password reset. (See attached screenshot for verification.)
Results:

Only one email is sent to the user matching the provided email and username.
No duplicate emails are sent.
Suggestions for Further Investigation:

Verify if any custom modules, hooks, or workflows are interfering with the password reset process.
Confirm the settings in /admin/config/people/accounts for account login options.
Test the issue on a clean Drupal installation to rule out configuration or module conflicts.

The error indicates a conflict between the Image Effects module (version 4.0.0) and the Color Backport module (drupal/color, version 1.0.3). This happens because the two modules have incompatible dependencies or explicitly declare conflicts.

Steps to Resolve
1. Identify Compatible Versions
Check the release notes and documentation for both modules to identify compatible versions.
Visit the module pages:
Image Effects module
Color Backport module
Determine if downgrading or upgrading either module resolves the conflict.
2. Resolve the Conflict with Composer

Option 1: Use an Alternative Version If there is a known compatible version of the Color Backport module that works with Image Effects 4.0.0, specify it in your composer.json:

composer require drupal/color:1.0.2

Then, retry installing Image Effects:

composer require drupal/image_effects:^4.0

Option 2: Temporarily Remove the Conflicting Module If the Color Backport module is not critical, uninstall and remove it before updating Image Effects:

drush pmu color
composer remove drupal/color
composer require drupal/image_effects:^4.0

After updating, check if you can reinstall a compatible version of Color Backport.

@dxvargas fixed the lint errors can you please review it

@dxvargas Thank you for the feedback!

I'll address the lint errors flagged in the job results.
I'll also add a test case to ensure the widget functionality is robust and restricts submissions exceeding the allowed member count.
Once these are resolved, I’ll update the MR for further review. Let me know if there’s anything else to consider.

Hello @vistree,

I’m glad the explanation was helpful! 😊

You’re correct that when using the Group module, group access typically overrides global permissions for content associated with a group. This means:

Users who are not members of a group will generally not have access to edit nodes within that group, even if their global role allows editing.
However, if a user has both a global role and a group-specific role, their effective permissions will depend on how those roles are combined. Group-specific roles take precedence within the group context.
If you’re experiencing any unexpected behavior with permissions, it’s worth double-checking the group and global role configurations to ensure there’s no conflict or unintended overlap.

Let me know if you have any further questions or need clarification!

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

The issue was caused by the wrapper key being accessed without ensuring its existence in the field value, resulting in a "Undefined array key" error during form validation.

I updated the validateElement() method to use null coalescing (??) to check if the wrapper key exists before accessing it. If the wrapper key is not present, the logic now defaults to handling the field's value directly. This ensures robust validation and prevents runtime errors.

The changes involve validating the structure of $form_state->getValue() and avoiding assumptions about the presence of the wrapper key in the datetime field.

I tested the fix by creating and updating scheduled records. The form now works as expected without errors. Both valid and invalid inputs are handled correctly, and the error messages display as intended.

Please review the changes and let me know if any additional adjustments are required. I'm happy to make further improvements if needed.

Duplicate entries for all day events with multiple standard (non smartdate) date fields

Please use this patch DuplicateAllDayEvents-3480947-15.patch for the Duplicate entries for all day events with multiple standard (non smartdate) date fields issue.

Sorry for the comment #14 please look into this patch.

Here is the patch if you want to test and check the unique events for the same.

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

Hello @vistree, The key difference between using Content Moderation with global roles and the Group module lies in scope, permissions granularity, and context-specific control.

1. Content Moderation with Global Roles

How It Works:
Global roles apply permissions across the entire Drupal site, regardless of the context (e.g., groups, sections).
When used with Content Moderation, global roles define:
Who can access specific moderation states (e.g., Draft, Needs Review, Published).
Who can edit, delete, or view content globally based on permissions.
Advantages:
Simpler and faster to set up for site-wide workflows.
Best for sites that don’t need distinct content ownership or isolated workflows.
Limitations:
No Context-Specific Control: Content Moderation workflows are global. For example, an "Editor" with the ability to "Publish" can publish any content on the site, regardless of its group or section.
No Content Isolation: Users cannot be restricted to specific groups, teams, or sections.
Example:
If an editor role has the "Publish content" permission, they can publish content across the entire site, even if it doesn't belong to their group or team.

2. Group Module

How It Works:
The Group module creates isolated containers for content, users, and permissions.
Each group has its own roles, permissions, and memberships, which override or complement global roles.
Advantages:
Context-Specific Control: Permissions and workflows are isolated per group. For example, a "Marketing Manager" can moderate and publish only within the "Marketing" group.
Better Content Ownership: Content is tied to specific groups, making it easy to enforce boundaries.
Limitations:
More complex to configure compared to global roles.
Requires additional modules or customization to integrate group-specific workflows with Content Moderation.
Example:
An "Editor" role in the "Marketing" group can "Publish" only Marketing content, while a "Sales Manager" in the "Sales" group has similar permissions for Sales content.

3. Do Global Role Settings Have an Effect When Using Group Module?
Yes, global roles still have an effect when using the Group module, but with some nuances:

Group Membership Restriction:

If a user is not a member of a group, their global role permissions won't apply to that group.
For example, a "Content Editor" with global edit permissions cannot edit content in the "Sales" group unless they are added to the group.
Global Role Permissions Extend to Groups:

If a user is assigned both a global role and a group-specific role, their permissions are a combination of both.
Example: A global "Admin" role may bypass group-specific restrictions because their global permissions override group-level settings.
Content Ownership:

Global roles do not inherently understand group ownership. This can lead to unintended permission leakage without careful configuration.

Key Differences Between Global Roles and Group Module
Feature Content Moderation + Global Roles Group Module
Scope Entire site Group-specific (isolated contexts)
Content Isolation No isolation (permissions apply globally) Full isolation (content is tied to specific groups)
Permission Limited (global control) Fine-grained (group-specific roles and permissions)
Granularity
Workflow Site-wide workflows only Requires customization for group-specific workflows
Integration
Use Case Small/medium sites with universal workflows Larger/multi-team sites needing content isolation

When to Use Which?

Global Roles + Content Moderation:

Best for sites where all users follow the same workflows and there’s no need to separate content or users into distinct groups.
Examples: A blog, a corporate site with simple workflows.

Group Module:

Ideal for multi-team environments, where different groups manage their own content and workflows.
Examples: University sites, media platforms, or intranets with distinct departments.
Conclusion
If you’re using the Group module, global roles still matter but act more as a baseline. Group-specific roles add another layer of control for isolated contexts. Content Moderation on its own doesn’t provide the isolation needed for complex workflows, so using it with Group (or similar modules) enables context-specific workflows and permissions.

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

@darvanen Yes I found That let me provide documentation step by step

Advanced Email Validation: Webform Integration Guide
Overview
The Advanced Email Validation module provides advanced email validation features, such as validating MX records, blocking disposable or public email providers, and supporting custom validation rules. This guide explains how to integrate the module with a Webform email field in Drupal 10.

Pre-requisites
Drupal 10 installed and running.
The following modules enabled:
Webform (v6.2 or later)
Advanced Email Validation (v2.0.2 or later)
Steps to Integrate Advanced Email Validation with Webform
1. Install and Enable Required Modules
Ensure both Webform and Advanced Email Validation modules are installed and enabled.

To enable modules via Drush:

ddev drush en webform advanced_email_validation -y
ddev drush cr

2. Create or Edit a Webform
Go to Structure > Webforms.
Create a new Webform or edit an existing one:
Click on the Build tab of the Webform.
Add an Email or Email Confirm field if it is not already added.

3. Add the Advanced Email Validation Handler
To integrate Advanced Email Validation:

Navigate to the Handlers tab of your Webform:

Example URL:
https:///admin/structure/webform/manage//handlers
Replace with the machine name of your Webform (e.g., registration_form).
Click the Add handler button.

From the list of available handlers, select:

Advanced Email Webform Validator.
Click Add handler to configure it

4. Configure the Validation Handler
In the handler configuration form:

Select the email fields where validation should be applied (e.g., "Email" or "Confirm Email").
If needed, enable Override site defaults to customize the validation rules for this specific Webform.
Customize the following validation rules as required:

Validate email format.
Check MX records (to ensure the domain has valid mail servers).
Block disposable email domains (e.g., mailinator.com).
Block public/free email domains (e.g., gmail.com, yahoo.com).
Use a custom list of banned email providers.
Save the handler configuration.

5. Test the Webform
Open the Webform in Preview mode.
Enter invalid email addresses (e.g., incorrect format, disposable domains).
Submit the form to ensure the validation rules are enforced.
Confirm the error messages appear as expected.

6. Customize Validation Error Messages
If you want to customize the error messages:

Go to Configuration > Advanced Email Validation:

Example URL:
https:///admin/config/system/advanced_email_validation
Modify the error messages for:

Invalid email format.
Disposable email domains.
Public email domains.
Custom banned domains.
Save the changes.

I am using Drupal 10 with the Advanced Email Validation module (v2.0.2) and Webform (v6.2). I want to integrate the Advanced Email Validation module with a Webform email field, but I don’t see any option for the validation handler under the Form Validation section in the Webform field settings.

Hello,
I am using Drupal 10, the Advanced Email Validation module (v2.0.2), and Webform (v6.2). I am trying to validate a Webform email field using the Advanced Email Validation module but cannot find the validation handler in the Webform field settings.

What I’ve Tried:

Installed the module via composer require drupal/advanced_email_validation.
Enabled the module with Drush: ddev drush en advanced_email_validation -y.
Cleared caches using ddev drush cr.
Configured the module under Configuration > Advanced Email Validation.
Expected Behavior:
I expected to see the Advanced Email Validation handler listed in the Form Validation section of the Webform field settings.

Actual Behavior:
I can only see default options like Required, Unique, and Pattern.

Environment:

Drupal: 10.x
Advanced Email Validation: 2.0.2
Webform: 6.2
Request:
How can I integrate the Advanced Email Validation module with a Webform email field? Am I missing a step?

Thank you for your assistance!