🇪🇸Spain @eduardo morales alberti

The problem is that the library does not exist because it was removed or is not loaded properly, so it should be captured and trigger a warning indicating what library is failing instead of the current Deprecated function: dirname() message.

Added langcode to the methods to check the status of the right language.

While FieldsHelper->extractFields method has langcode the following methods do not have it,  so in the method shouldExtractReference, the langcode is not present.
Callstack:

FieldsHelper.php:398, Drupal\search_api\Utility\FieldsHelper->shouldExtractReference(TypedDataInterface $reference_item, ?IndexInterface $index = NULL)
FieldsHelper.php:247, Drupal\search_api\Utility\FieldsHelper->extractFieldValues(TypedDataInterface $data, ?IndexInterface $index = NULL)
FieldsHelper.php:224, Drupal\search_api\Utility\FieldsHelper->extractField(TypedDataInterface $data, FieldInterface $field)
FieldsHelper.php:185, Drupal\search_api\Utility\FieldsHelper->extractFields(ComplexDataInterface $item, array $fields, $langcode = NULL)
Item.php:275, Drupal\search_api\Item\Item->getFields()
CustomValue.php:93, Drupal\search_api\Plugin\search_api\processor\CustomValue->addFieldValues()
Item.php:281, Drupal\search_api\Item\Item->getFields()
Index.php:1000, Drupal\search_api\Entity\Index->indexSpecificItems()
PostRequestIndexing.php:92, Drupal\search_api\Utility\PostRequestIndexing->destruct()
DrupalKernel.php:723, Drupal\Core\DrupalKernel->terminate()
index.php:22, {main}() 

Method shouldExtractReference:

    if ($referenced_entity instanceof EntityPublishedInterface) {
      return $referenced_entity->isPublished();
    }
    elseif ($referenced_entity instanceof UserInterface) {
      return $referenced_entity->isActive();
    } 

eduardo morales alberti → created an issue.

A capture from the Google bots list

Update patch solving metatag schema error.

Maybe we would create a submodule called metatag_google with groups.

Common Google crawler https://developers.google.com/search/docs/crawling-indexing/google-commo... and https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag

• Googlebot
• Googlebot-Image
• Googlebot-Video
• Googlebot-News
• Storebot-Google
• Google-InspectionTool
• GoogleOther
• GoogleOther-Image
• GoogleOther-Video
• Google-CloudVertexBot
• Google-Extended
• AdsBot-Google

1. The configure key should point to the settings route of the module as mentioned in the article https://drupalize.me/tutorial/overview-info-files-drupal-modules#configure

2. Done

3. Done

4. Done

5. We choose to display the readme on the help page to avoid duplicate information on the readme and the help page as other modules do.

eduardo morales alberti → changed the visibility of the branch 8.x-1.x to hidden.

We created a different branch 3320327-documentation with the same commits, instead 8.x-1.x, updating the code.

Pending to apply tess bakker comments

eduardo morales alberti → created an issue.

File src/Commands/YotpoCommands.php

    if (empty($options['external_id'])) {
      $this->logger->notice('The external_id param is mandatory');
    }

Return after log.

    if (empty($options['external_id'])) {
      $this->logger->notice('The external_id param is mandatory');
      return
    }

File src/YotpoClient.php

There several calls to $this->logger->notice that I would say they should be info.

Notice is the minimal level of the log that is shown without specifying the verbosity.
To show info messages the command should use "-v".

This comment is mismatched:

  /**
   * Logger.
   *
   * @var \Drupal\Core\Config\ImmutableConfig
   */
  protected ImmutableConfig $config;

Updated to:

  /**
   * Yotpo settings like the api credentials.
   *
   * @var \Drupal\Core\Config\ImmutableConfig
   */
  protected ImmutableConfig $config;

Additionally, the comments are not explanatory. For example,

  /**
   * Default options.
   *
   * @var array
   */
  protected array $defaultOptions = [

Changed to:

* Default options for the Guzzle's HTTP client.

I'm not sure about addDefaultOptions. The code is:

    foreach ($options as $key => $value) {
      if (isset($this->defaultOptions[$key]) && is_array($options[$key]) && is_array($this->defaultOptions[$key])) {
        $options[$key] = array_merge($this->defaultOptions[$key], $value);
      }
    }
    $options += $this->defaultOptions;

The code overrides the default options if exists on param options if matches the key, if not merge options with default options.
Refactored to:

    foreach ($options as $key => $value) {
      if (isset($this->defaultOptions[$key]) && is_array($value) && is_array($this->defaultOptions[$key])) {
        $options[$key] = array_merge($this->defaultOptions[$key], $value);
        unset($this->defaultOptions[$key]);
      }
    }
    $options += $this->defaultOptions;

Some expressions can be simplified for readability:

 $headers = isset($options['headers']) ? array_merge($options['headers'], $additional_headers) : $additional_headers;

Refactored to:

$headers = array_merge($options['headers'] ?? [], $additional_headers);

I would split callYotpoApi in two functions to lower the complexity

Done on MR https://git.drupalcode.org/project/yotpo/-/merge_requests/3/diffs#2389f1...

In several places the method callYotpoApi is called. This method can throw an exception but the calls are not wrapped in a try-catrch, is this intended? If this is only used inside drush commands I think drush catches the exception and nicely ends the command, so it would be ok.

As you said, because it is called from drush it is not necessary to catch the exception.

@tunic could you review the MR?

We saw that the module already have drupal 11 on .info, but we remove also drupal 8 and 9.

After review with Drupal rector we do not found any issue.

eduardo morales alberti → created an issue.

MR error https://git.drupalcode.org/issue/monolog_extra-3455273/-/jobs/1888312

drupal/monolog[3.0.0-beta1, ..., 3.x-dev] require drupal/core ^10 -> satisfiable by drupal/core[10.0.0-alpha1, ..., 10.4.x-dev].

Monolog is compatible with drupal 11 on 3.0.4 https://www.drupal.org/project/monolog/releases/3.0.4 →

Pending solve comments

Drupal 7 is not supported by Drupal

Maybe drupal 8 and 9 should be also removed from the .info as they are not supported.

Same error here.

Related issue with a similar approximation https://www.drupal.org/project/webform/issues/3343209 🐛 Undefined array key "#webform_key" in WebformManagedFileBase::validateManagedFile() Closed: cannot reproduce

Full stack:

Message	Warning: Undefined array key "#webform_key" in Drupal\webform\Plugin\WebformElement\WebformManagedFileBase->prepare() (line 301 of /mysite/docroot/modules/contrib/webform/src/Plugin/WebformElement/WebformManagedFileBase.php) #0 /mysite/docroot/core/includes/bootstrap.inc(166): _drupal_error_handler_real() #1 /mysite/docroot/modules/contrib/webform/src/Plugin/WebformElement/WebformManagedFileBase.php(301): _drupal_error_handler() #2 /mysite/docroot/modules/contrib/webform/modules/webform_ui/src/Form/WebformUiElementTypeFormBase.php(308): Drupal\webform\Plugin\WebformElement\WebformManagedFileBase->prepare() #3 /mysite/docroot/modules/contrib/webform/modules/webform_ui/src/Form/WebformUiElementTypeFormBase.php(246): Drupal\webform_ui\Form\WebformUiElementTypeFormBase->buildElementPreview() #4 /mysite/docroot/modules/contrib/webform/modules/webform_ui/src/Form/WebformUiElementTypeSelectForm.php(78): Drupal\webform_ui\Form\WebformUiElementTypeFormBase->buildRow() #5 [internal function]: Drupal\webform_ui\Form\WebformUiElementTypeSelectForm->buildForm() #6 /mysite/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(536): call_user_func_array() #7 /mysite/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(284): Drupal\Core\Form\FormBuilder->retrieveForm() #8 /mysite/docroot/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm() #9 [internal function]: Drupal\Core\Controller\FormController->getContentResult() #10 /mysite/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array() #11 /mysite/docroot/core/lib/Drupal/Core/Render/Renderer.php(669): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\@closure() #12 /mysite/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext() #13 /mysite/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() #14 /mysite/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\@closure() #15 /mysite/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw() #16 /mysite/docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle() #17 /mysite/docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle() #18 /mysite/docroot/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle() #19 /mysite/vendor/asm89/stack-cors/src/Cors.php(53): Drupal\Core\StackMiddleware\ContentLength->handle() #20 /mysite/docroot/modules/contrib/shield/src/ShieldMiddleware.php(263): Asm89\Stack\Cors->handle() #21 /mysite/docroot/modules/contrib/shield/src/ShieldMiddleware.php(130): Drupal\shield\ShieldMiddleware->bypass() #22 /mysite/docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\shield\ShieldMiddleware->handle() #23 /mysite/docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() #24 /mysite/docroot/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() #25 /mysite/docroot/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle() #26 /mysite/docroot/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle() #27 /mysite/docroot/index.php(19): Drupal\Core\DrupalKernel->handle() #28 @main.

On our case, we will remove the id, but it could be a breaking changing.

eduardo morales alberti → created an issue.

Added documentation on https://git.drupalcode.org/project/fastly/-/merge_requests/28/diffs#diff... issue ✨ Caclculate fastly ips dynamically Active

Ready to review

eduardo morales alberti → created an issue.

After reading some comments and issues it should be documented some points:

1. Configure the reverse proxy
   

     $settings['reverse_proxy'] = TRUE;
   

2. Configure the reverse proxy address, the problem is that the IP address from fastly are dynamic, so it should be calculate dynamically https://www.fastly.com/documentation/reference/api/utils/public-ip-list/
3. As the default header X-Forwarded-For is not secure, it should be used the header Fastly-Client-IP https://www.fastly.com/documentation/reference/http/http-headers/Fastly-... and configure the vlc
   

   if (fastly.ff.visits_this_service == 0 && req.restarts == 0) {
     set req.http.Fastly-Client-IP = client.ip;
   }
   

eduardo morales alberti → created an issue.

eduardo morales alberti → created an issue.

Ready to review.

eduardo morales alberti → created an issue.

@delacosta456 Did you clear the caches after applying the patch?

The service is defined on https://git.drupalcode.org/project/default_content/-/merge_requests/45/d...

It is possible that Drupal did not detect the service without clearing caches first.

Before continuing we should choose the best approximation or integrate and document all of them.

Reading the comments we saw multiple options:

The first one was introduced by @Joyakas, extending the metatag_firehose widget to provide an async way to load the metatags, and @chr.fritsch mentioned on comment #3057523-70: Content forms are painfully slow if multiple sub-modules are enabled → the module metatag_async_widget to use the widget https://www.drupal.org/project/metatag_async_widget →

Batkor introduce the widget "metatag_dialog" on comment #3057523-98: Content forms are painfully slow if multiple sub-modules are enabled →

Comment from @jansete about the dialog widget #3057523-103: Content forms are painfully slow if multiple sub-modules are enabled → :

Hello guys,

Sorry I'm not agree with canvas solution, improve content first load but later if you have a big bunch of metatags groups the performance is very poor, on the other hand the async solution only open the metatag group that you need, I think that solution is better and UX/UI as well.

I attach a patch working with nesting robots following #95 solving a php warning when the user doesn't have permission to access metatag fields.

@hdotnet proposes to use a different form display because Schema have too many items to load them using Ajax #3057523-106: Content forms are painfully slow if multiple sub-modules are enabled →

Documentation:

https://www.drupal.org/docs/contributed-modules/metatag/frequently-asked... →

With the schema modules enabled, every ajax request has around 800 items added to the payload. Removing metatags completely from display greatly improved our relationship with the content team. One of them even asked me out on a date.

For anyone reading this, our workaround was to have the metatag fields accessible only via a specific content form display mode [called seo].

Editing meta tags is now done via a separate local task that uses the seo form display mode. This was enabled using https://www.drupal.org/project/form_mode_control →

Our conclusions

The metatag_async could help with the performance issue, but has its limitations with too many items, for example, using Schema.
The dialog widget could also affect performance if there are too many groups.

Maybe using a different display could be the best approach as it does not affect the content editing, and does not need to make "magic" with the widget form.

Created a new MR over 2.1x-dev

Please work over the MR to follow the changes.

Ready to review.

eduardo morales alberti → created an issue.

As a "workaround" we get the real path altering the method getGlobPattern.

https://www.drupal.org/project/monolog_extra/issues/3497134 🐛 Monolog glob does not support stream wrappers Active

Ready to review

eduardo morales alberti → created an issue.

eduardo morales alberti → created an issue.

Needs review

We will commit a validation to know if the URI is set.

Ready to review

As the \Drupal\content_translation\Plugin\views\field\TranslationLink extends from \Drupal\views\Plugin\views\field\EntityLink it should have the same schema.

eduardo morales alberti → created an issue.

Ready to review!!

After installing the module Config inspector we get the following message:

"'reduce' is not a supported key."

After review that verf view filter \Drupal\verf\Plugin\views\filter\EntityReference extends from \Drupal\views\Plugin\views\filter\InOperator, the schema also should be "views.filter.in_operator".

Also, the "show_unpublished" is defined on the filter and should be added to the schema.

@omarlopesino, we can confirm that the errors are gone and the view is still working.

Added schema user_scope to MR

Ready to review!

eduardo morales alberti → created an issue.

Added config schema to the processor.

After patch:

eduardo morales alberti → created an issue.

Sorry, we upload the wrong capture

RTBC!
Tested on Drupal 10.3 using Config inspector:
Before patch:

After apply the patch #2:

RTBC!

After running the entire behat suite, the tests are stable with the Gin version dev and the patch from the merge request, we recovered the step And I press the "Save" button that failed on version rc14, so from our side, the change seems stable.

We tested the edit node form and the entity modals and seem to work.
We will update the changes and wait for CI results.
Thank you!!

Hi,

We tested it on our Drupal 10.3, on any entity form we get the following error:

It fails on media library modal, and entity browser-

  }, Drupal.ginStickyFormActions = {
    init: function(context) {
      const newParent = document.querySelector(".gin-sticky-form-actions");
      newParent && (context.classList?.contains("gin--has-sticky-form-actions") && context.getAttribute("id") && this.updateFormId(newParent, form),

Thank you @jurgenhaas

We updated the tests using the following custom steps on Behat.

  /**
   * @Given I press the submit input
   */
  public function iPressTheButtonInput() {
    $session = $this->getSession();
    $driver = $session->getDriver();

    if ($driver instanceof \Behat\Mink\Driver\Selenium2Driver) {
      // JavaScript-enabled submission.
      $session->executeScript('document.querySelector("input#edit-submit").click();');
    } else {
      $session->getPage()->pressButton('edit-submit');
    }

  }

Adding related issue that maybe could help 🐛 Automatic entity label does not take into account the field constraints Needs review

Maybe the issue 🐛 Automatic entity label does not take into account the field constraints Needs review could help

Are there any updates on it?

Same here on version 10.3.9:

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Invalid filename. in Drupal\system\Controller\AssetControllerBase->getGroup() (line 236 of docroot/core/modules/system/src/Controller/AssetControllerBas
e.php)

We test it on a simpletestme https://master-cg4lcdtc1ja3gfni2izgajxkko4dkwxp.tugboatqa.com/

Steps to reproduce:

• We installed the drupal 10.3.9
• Installed the entity browser and created a reference field to content with this widget
• Installed media and media library
• Created a content with a media and saved the content
• Edit again the content and remove the media
• Review the logs

It is tested on a clean environment so RTBC

@berdir do you need more info?

@berdir as said in the comment #3247212-6: Ajax error on delete item →

We're seeing the same issue. It doesn't actually cause a problem unless PHP has the display_errors option switched on.

Here the problem is caused by having both an Entity Browser field and a core Media Library field on the same form. When trying to remove an item from the media widget, the Entity Browser code is getting confused because the button for core Media Library is also called remove_button

Attaching patch which checks the field name on the triggering element matches the expected one for this widget. This allows both the media library and entity browser to function correctly again here.

We are unsure how to cover it with tests, but the patch #3125117-11: Remove button in entity browser field widget doesn't work → works for us.

Ready to review

Fixed MR conflicts.

The version 18 requires country codes to be lowercase.

After testing version 18, we decided that it is not stable and does not work properly with the module.

eduardo morales alberti → created an issue.

eduardo morales alberti → created an issue.