🇧🇷Brazil @joaopauloc.dev

joaopauloc.dev → changed the visibility of the branch 3239535-no-data to hidden.

Happy to help with this great module :)

Updating Release notes snippet

Thanks @nod and @joachim for the feedbacks.
I guess we fixed all points mentioned, moving back to needs review.

Hey @ivnish, any update on this?
thanks.

joaopauloc.dev → created an issue.

Thank you so much guys!

I tested the latest changes of the merge request and works as expected.
I follow this steps.
- Create a new instance of Drupal
- Add in the basic page content type a list text field with 3 options and make it required field.

Without the changes, the required is in incorrect position and there is no validation after submit.

Wrong required attributes.

After changes applied.

Required attributes in the correct elements

joaopauloc.dev → changed the visibility of the branch drupal-3387665-3387665-dpi-rework to hidden.

joaopauloc.dev → changed the visibility of the branch 3387665-drupal-should-warn to hidden.

I confirmed that still working.
Without the fix getting access denied.

With fix applied.

Thank you @orkut-murat-yılmaz
It's already applied https://www.drupal.org/project/projectapplications/issues/3436287 📌 [1.0.x] Calculation Fields Active

Hey guys, any update on this? I would appreciate that.
Thanks in advance.

Toolbar working properly after applied the fix of the pull request.

joaopauloc.dev → created an issue.

joaopauloc.dev → changed the visibility of the branch 3239535-refactor-if-feasible to hidden.

I confirm that after the code review changes the issue still fixed.

Same steps followed of comment #5

Access denied in without the fix.

Could access with the fix applied.

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

Thanks for the clarification, @vishal.kadam!
A friend had explained it to me, but I had already opened the task by then, my bad!

joaopauloc.dev → created an issue.

Thank you for reviewing this issue and the feedback @avpaderno
Both comments above regarding getting the service and error message translatable were fixed.

Some of the TODO comments were outdated.
For those that still make sense, I create a new task 📌 Improve validation methods and make some of them extendable Active to address these improvements in the next release.

joaopauloc.dev → created an issue. See original summary → .

joaopauloc.dev → created an issue.

I can confirm that the fix works.

I followed these steps.
Install Drupal 11
Create a custom module test link
Create the route and the menu link files as mentioned above.
Enabled the module.
Access the following url: /admin/test-link

Without the fix, I couldn't access the page.

After the fix was applied, I could access it.

Hey @kpaxman.
Sorry for the late response.
But it's possible, you can subscribe to the event webform_remote_fields_alter_response_element and do whatever you need.
Take a look at this example

But will check a way to do that by the webform ui API stuff settings.

Thanks @vishal.kadam for the feedback.
I remove all the mentioned information from the info modules.

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

I can't reproduce the PHPunit error locally, maybe it's something intermittent in the CI.

Hey folks.
Sorry for the late response.
All PHP-CodeSniffer issues fixed and README file updated.

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

Added form context to change lookup field elements and do the calculation.

New task to addrees the Radio Other elements.
https://www.drupal.org/project/calculation_fields/issues/3523735 ✨ Add support for Radios Other element Active

joaopauloc.dev → created an issue.

joaopauloc.dev → created an issue.

Fixed the radio or any other input not triggering the calculation when the page loads with values pre-populated.
You can't see the refresh page in the image below because it's too fast, but I set the default values to the form and the calculation works.

Hey @frankdesign,
I'll check today the issue with a radio with a default value.
We could address the Radio other in another issue to move this one forward.

Since we have a new form alter hook class https://www.drupal.org/node/3499495 →
I changed the attribute class on MenuUiEntityDeleteFormHooks to use the FormAlter instead of Hook class.

I’d like to propose a new variable: has_required_children.
Since the required attribute applies only to individual form elements and not to the fieldset itself, we can’t rely on it directly for fieldsets. This new variable would allow us to handle required state information at the fieldset level, particularly for radio buttons and checkboxes.

With this variable in place, we can also properly manage the required and aria-required attributes for fieldsets used in checkbox elements.

Hi folks,
I’ve updated the merge request to remove the required attribute from the fieldset for the radio buttons — the aria-required attribute is no longer present, as expected.
I also updated the CSS to ensure that the asterisk (*) still appears in the fieldset legend for radios, even without the required attribute.

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

Hey @ivnish, I can create a test for this one.

I’ve never written a test specifically for a view relationship. Do you happen to have an example you could share?
I looked at some examples in Drupal core, but they weren’t very helpful.

I did write a test for a view once — I exported the view and installed it in the test environment. Then I created the required entities, loaded the view programmatically, and executed it. But I’m not sure if that’s the best approach for this specific case. What do you think?

Hey @smustgrave.
Thank you for reviewing this one.
I followed your steps, and I could see the warning messages.
Do you remember where you were when you tried to remove the node?
Follow the images.

Node page

Delete from node edit page

Delete action on content list page

All the messages above also appear on the menu delete page/action.

Thanks for the quick review @ivnish.
PHPCS issues fixed.
Thanks.

joaopauloc.dev → created an issue.

Forgot the patch :)

After patch applied

The filter was executed and wrapped the table with success.

joaopauloc.dev → created an issue.

Before the patch:

After patch:

joaopauloc.dev → created an issue.

Patch #20 worked for me. Thanks

ckrina → credited joaopauloc.dev → .

Hi folks,

I’ve been working on this issue for a while, and it’s almost complete. However, I’m facing a challenge in the final stages and would appreciate any suggestions, ideas, or feedback to help resolve it.

We developed a new Top Bar plugin to display the Preview Editable Areas, which toggles the contextual links on the page if they exist.

The problem:

There is no straightforward way to determine on the backend whether contextual links are present on the page. That’s why we are handling this logic in JavaScript—the same approach used by the Contextual module to decide whether to display the Edit button in the toolbar.

Our current implementation adds the button to the Top Bar as hidden by default. Then, the navigationToggleContextualLinks behavior determines whether the button should be displayed based on the presence of contextual links on the page.

Additionally, there is a CSS rule that changes the display property of the Top Bar to block if the section is not empty. Since :empty considers spaces as valid content, I updated this rule to check for any actual elements instead.

Here’s the updated rule:

.top-bar:has(.top-bar__tools *),
.top-bar:has(.top-bar__context *),
.top-bar:has(.top-bar__actions *)

Everything works fine, but there’s a flickering issue on the screen.

The flickering occurs because the CSS rule initially displays the Top Bar as soon as there is content in the tools section—in this case, the Editable Areas button itself. However, when the JavaScript behavior runs and detects that there are no contextual links on the page, the button is removed. This results in a brief unintended appearance of the Top Bar before it disappears again.

Possible solutions:

I can think of two potential approaches:

1. Prevent the PagePreviewEditableAreas from rendering the button initially. Instead, only add the behavior that checks for contextual links, and then dynamically insert the button if needed. This approach eliminates flickering since the toolbar will only appear after the behavior adds the button.

2. Make the Top Bar “smart” enough to update its display to block only when there is visible content. However, I lack the CSS expertise to determine whether this is possible. Implementing this logic via JavaScript would likely result in the same flickering issue as the current approach.

Any insights or alternative suggestions would be greatly appreciated!

Updating patch to make the mail_login_password_only_description optional as well.

Hi everyone,

Thanks for this great module! As mentioned in the description, whether or not users need to see that message depends on the site’s context. For example, if the site is new and has never allowed username-based logins, there’s no need to display the message at all.

What do you think?

joaopauloc.dev → created an issue.

Hello folks.
I created an issue to make it easy to extend the MultistepController for another reason. https://www.drupal.org/project/simple_multistep/issues/3501547 ✨ Make MultistepController easy overrided Active
but I also had to implement the navigation between the steps.
So, this is how I did.
Apply my patch in the issue above.
Extends the MultistepController creating your custom controller.
Inside this class override the addStepIndicator.
In my case I created another Step indicator extending from StepIndicator and this is the result.

/**
 * The ResourceStepIndicator class.
 *
 * @package Drupal\uwas_resource\SimpleMultistep
 */
class ResourceStepIndicator extends StepIndicator {

  /**
   * Render the step indicator.
   *
   * @param array $form
   *   The form array.
   */
  public function render(array &$form): void {
    $form['steps_label'] = $this->createStepsIndicator();
  }

  /**
   * Create steps indicator.
   *
   * @return array
   *   Returns the steps label.
   */
  public function createStepsIndicator(): array {
    $data = [
      '#type' => 'container',
      '#weight' => -100,
    ];
    foreach ($this->getSteps() as $step_number => $step) {
      $format_settings = $step->format_settings;
      if ($format_settings['show_step_title']) {
        $button = [
          '#type' => 'button',
          '#value' => $step->label,
          '#validate' => [self::class . '::moveStep'],
          '#step_number' => $step_number,
        ];
        if ($this->currentStep === $step_number) {
          $button['#disabled'] = TRUE;
          $button['#attributes']['class'][] = 'active';
        }
        $data[] = $button;
      }
    }
    return $data;
  }

  /**
   * Move step.
   *
   * @param array $form
   *   Form array.
   * @param \Drupal\Core\Form\FormStateInterface $form_state
   *   Form state object.
   */
  public static function moveStep($form, FormStateInterface $form_state): void {
    $multiStep = $form_state->get('multistep_controller');
    $triggering_element = $form_state->getTriggeringElement();
    $step_number = $triggering_element['#step_number'] ?? -1;

    $entity_form = $form_state->getFormObject();
    if ($entity_form instanceof EntityFormInterface) {
      $entity_updated = $entity_form->buildEntity($form, $form_state);
      $entity_form->setEntity($entity_updated);
    }

    $form_state->set('step', $step_number);
    $multiStep->updateCurrentStep($step_number);
    $form_state->set('multistep_controller', $multiStep);
    $form_state->setRebuild();
  }

}