🇧🇷Brazil @joaopauloc.dev

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();
  }

}

Attaching the patch.

Hi folks.
First of all, great module, save-me a lot of time.
I pushed the changes that I suggested.

What do you guys think?

joaopauloc.dev → created an issue.

+1 for RTBC
Worked well for me too.
Core version 10.4.1
PHP version: 8.3
Field Group version: 3.6.0

Hi folks, as @michaellander mentioned I also think this one can benefit many modules or some menu customization.
Following the same idea of ✨ Allow modules to hook into top of content/footer sections of new core navigation Active I've replicated the idea for the footer top section.

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

Hey @plopesc.

I was investigating how the contextual module adds the Edit button and the contextual link on the pages.
The Edit is added by the hook toolbar(ContextualHooks:19), by default this link is hidden, and then a javascript is responsible for showing or keeping it hidden. If I'm not wrong, the behavior checks if there is any contextual link on the page, and if the Edit is toggle to visible, otherwise keeps hidden. The contextual_preprocess function adds the contextual links if I'm not wrong.
Please, anyone, correct me if my understanding is wrong.

Based on that, for the entities we already have a solution, since the user is accessing an entity page the local tasks will appear and we add the Preview editable areas. Since this is a temporary solution, I don't think it's feasible to implement a "complexity" custom logic just to make this work for other pages. We probably need a javascript code to check if there are contextual links on the page and then control the top bar items. We probably will add a custom logic just for a temporary solution.

So, here is my suggestion. Based on the "complexity" that can be to adding the Preview editable area for non-entities pages, and this is a temporary solution. I would like to suggest that we could move forward with the current solution, displaying the feature only for entity pages.

What do you guys think?

Thanks for report this issue @igorbiki.
I pushed the fix. Good catch.
I changed the round stuff to use the correct PHP function.
Thanks.

After |, the value must be a number, not a calculation expression like 0 * 3.

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

Hey @kpaxman, thanks for the report.
I pushed the fix to the issue.
I fixed the help text missing the {{ }} that needs to be added to the expression.
Regarding your example: Total is {{ :number|0 * 3 }}
This expression is not valid, you are using an expression in the default value that is not supported, you can defined any number as default value.
Like: Total is {{ :number|1 }}
Total is {{ :number|0 }}
Total is {{ :number|100 }}

Could please check if the fix works for you?

Thanks

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

Hey @pfrenssen, what do you think about changing the places field to be required only if the waitlist is checked?

Hey @plopesc, thanks for the review.
I'm having a look at the way that the Edit button appears. In the contextual module, they implement the hook toolbar. For the navigation we don't show that toolbar as the other modules do, so the only way that we currently display something similar to the toolbar hook is the top bar item, am I correct? please correct me if I'm wrong.
Since the PageActions plugin displays the Local tasks, how can we implement the edit button without using the local tasks? Should we create another plugin, for example: ToolbarActions, then we could add actions that are similar to the toolbar hook.
Thanks.

Hi @benjifisher and @rkoller, thanks for reviewing this issue.

These are my suggestions for the points Suggest changing the parent, Special treatment when deleting custom menu links.
For the Suggest changing the parent

The link will be opened in another tab. What do you guys think?

Regarding the Special treatment when deleting custom menu links
I changed the text message as you guys suggested.

Hi folks.
I updated the issue summary adding a screenshot with the User interface changes as recommended in comment #37.
Also, when I tested the MR I found the following issue.

Finally, update the modal message with the comments suggested in comment #37. Regarding this message, I would like to suggest another one when there is only one item, for the singular message we could use something like:
Deleting this @singular_label will move its child menu item to the top level:
What do you guys think?

Hey @pfrenssen, I'll push the changes.

I'm attaching the patch with the implementation of @carolpettirossi suggestions.