🇺🇸United States @ddavisboxleitner

benjifisher → credited ddavisboxleitner → .

benjifisher → credited ddavisboxleitner → .

benjifisher → credited ddavisboxleitner → .

benjifisher → credited ddavisboxleitner → .

I have come up with an initial and unsophisticated solution to the problem. In the UrlGenerator class (core/lib/Drupal/Core/Routing/UrlGenerator.php).

On line 364 we see the following:
$base_url = $this->context->getBaseUrl();

When a user requests the homepage using 'www.yoursite.com/index.php' we are getting '/index.php' as the base URL. This is a special case where we are on the homepage and we can safely disregard this base URL. The unsophisticated solution is to simply empty this $base_url variable.

if ($base_url === '/index.php') {
      $base_url = '';
}

There may be a smarter way to handle this special case. For now, this code will prevent the bug from appearing.

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

benjifisher → credited ddavisboxleitner → .

No meeting happened on 2024-03-14, closing issue.

benjifisher → credited ddavisboxleitner → .

benjifisher → credited ddavisboxleitner → .

On version 8.x-2.0-beta7 of the module, this change is introduced as a separate field formatter:

https://git.drupalcode.org/project/viewsreference/-/blob/8.x-2.0-beta7/s...

To enable it (and potentially resolve the issues mentioned in the ticket) you have to select 'Views reference (lazy builder)' as the format for your Views Reference field under Manage Display.

benjifisher → credited ddavisboxleitner → .

0️⃣ Who is here today?

1️⃣ What should we talk about today? Suggest topics here and I will add threads. I will also check for comments on the issue for today’s meeting.

2️⃣ Action items. To be added later.

3️⃣ Statistics

4️⃣ Comment in this thread if you are looking for ways to contribute. Give us some idea of what you would like to do: documentation, code review, testing, project management, ...

5️⃣ Previous minutes.

6️⃣ Announcements

7️⃣ Develop Drupal 7 end of Life Landing Pages with concise library of resources

8️⃣ migrate mapping & messages table names are truncated, can lead to incorrect mapping lookups

9️⃣ Wrap up

Participants:

dinarcon, smustgrave, mikelutz (he/him), benjifisher, Stephanie, quietone

I can confirm your changes result in passing phpcs tests. I also reviewed the code. Looks good.

PHPunit tests are now passing.

I had to add some error checking in DomainPathHelper class on the alterEntityForm() function. We can't assume pathauto will be installed.

      if (array_key_exists('pathauto', $form['path']['widget'][0])) {
        $form_state->addBuildInfo('pathauto_checkbox', $form['path']['widget'][0]['pathauto']['#type'] === 'checkbox');
      }

I resolved the first error by adding some /etc/hosts entries for the test queries to target.

The second error will need an update. The function drupalPostForm() is being used and is being deprecated.

Details about the change heeded described here: https://www.drupal.org/node/3168858 →

ddavisboxleitner → created an issue.

The eslint errors were coming from empty values in the drupalci.yml configuration file. I'm going to leave this file in place for now and remove the problem entries.

In the future this file can be removed when we are exclusively using Gitlab CI for automated testing on this module.

ddavisboxleitner → created an issue.

The current issue seems to be that we cannot get the SIMPLETEST_BASE_URL value set properly before the phpunit tests are run. The subdomain registration section of the tests are failing.

Err.. it seems my information was a little out of date. I think all the eslint tests are passing now.

I did catch one comment line that seems too long.

ddavisboxleitner → created an issue. See original summary → .

As discussed elsewhere, we will create separate issues to resolve the JS linting and other issues which are now visible with gitlab CI testing turned on.

We currently have 4 phpunit errors:

There were 4 errors:
1) Drupal\Tests\domain_alias\Functional\DomainAliasActionsTest::testDomainActions
Behat\Mink\Exception\ExpectationException: Current response status code is 404, but 200 expected.
/builds/issue/domain-3388682/vendor/behat/mink/src/WebAssert.php:794
/builds/issue/domain-3388682/vendor/behat/mink/src/WebAssert.php:130
/builds/issue/domain-3388682/domain_alias/tests/src/Functional/DomainAliasActionsTest.php:59
/builds/issue/domain-3388682/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
2) Drupal\Tests\domain_alias\Functional\DomainAliasEnvironmentTest::testDomainAliasEnvironments
Behat\Mink\Exception\ExpectationException: The string "four.example.com" was not found anywhere in the HTML response of the current page.
/builds/issue/domain-3388682/vendor/behat/mink/src/WebAssert.php:794
/builds/issue/domain-3388682/vendor/behat/mink/src/WebAssert.php:324
/builds/issue/domain-3388682/web/core/tests/Drupal/Tests/WebAssert.php:540
/builds/issue/domain-3388682/web/core/tests/Drupal/Tests/WebAssert.php:528
/builds/issue/domain-3388682/domain_alias/tests/src/Functional/DomainAliasEnvironmentTest.php:93
/builds/issue/domain-3388682/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
3) Drupal\Tests\domain_alias\Functional\DomainAliasListHostnameTest::testDomainAliasEnvironments
Behat\Mink\Exception\ExpectationException: Current response status code is 404, but 200 expected.
/builds/issue/domain-3388682/vendor/behat/mink/src/WebAssert.php:794
/builds/issue/domain-3388682/vendor/behat/mink/src/WebAssert.php:130
/builds/issue/domain-3388682/domain_alias/tests/src/Functional/DomainAliasListHostnameTest.php:70
/builds/issue/domain-3388682/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
4) Drupal\Tests\domain_alias\Functional\DomainAliasWildcardTest::testDomainAliasWildcards
Behat\Mink\Exception\ExpectationException: The string "four.example.com" was not found anywhere in the HTML response of the current page.
/builds/issue/domain-3388682/vendor/behat/mink/src/WebAssert.php:794
/builds/issue/domain-3388682/vendor/behat/mink/src/WebAssert.php:324
/builds/issue/domain-3388682/web/core/tests/Drupal/Tests/WebAssert.php:540
/builds/issue/domain-3388682/web/core/tests/Drupal/Tests/WebAssert.php:528
/builds/issue/domain-3388682/domain_alias/tests/src/Functional/DomainAliasWildcardTest.php:82
/builds/issue/domain-3388682/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
ERRORS!
Tests: 93, Assertions: 3231, Errors: 4.

It is possible the tests themselves need a fix.

In 9.1 the order of the arguments to dispatch() changed, and so the previous patches stop working in those higher version of Drupal. In testing, just re-ordering the arguments in all calls to dispatch() works to restore this feature to functioning.

I have reviewed your configuration file and it looks correct. I do see that there are some errors now being reported from the automated testing.

I have reviewed your .gitlab-ci.yml template file and it looks correct.

I also observed the Gitlab CI automated testing results appearing on your Merge Request.

The changes are passing my review.

A .gitlab-ci.yml file has been created for the project following the template provided in the referenced article.

https://git.drupalcode.org/project/gitlab_templates/-/blob/1.0.x/gitlab-...

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

These changes are ready to be reviewed. All Gitlab CI tests are passing. See report:

https://git.drupalcode.org/issue/workbench_tabs-3401877/-/pipelines/5031...

ddavisboxleitner → created an issue.

I have created the .gitlab-ci.yml configuration file from the d.o template.

ddavisboxleitner → created an issue.

benjifisher → credited ddavisboxleitner → .

benjifisher → credited ddavisboxleitner → .

On our project the issue appeared to be a container configuration file which was created using the 1.x version and when imported into the 2.x version caused the problem. After importing the 'stale' config the GTM snippet no longer appeared on the page.

The problem file was named like `google_tag.container.your_container_name.yml` and deleting the file, then uninstalling/re-installing google_tag module and importing config again resolved the issue.

We recommend checking your configs for any containers created in the old version of the module and try removing those config files, then re-import.

For anyone else who is updating their D9 site to D10 and ran into an error running 'drush migrate:status' :

source_langcode configuration key should not be an empty

Your existing migrations should be updated to include the source_langcode key in the source section.

This has been an issue for us as well. Switching all private variables to protected works to preserve the data in those variables during AJAX calls.

There is documentation about the serialization issue: https://www.drupal.org/docs/drupal-apis/services-and-dependency-injectio... →

The pull request patch also worked for us with Drupal 10.1.5 and path_redirect_import 2.0.x-dev.

Our team also came to this issue looking for help on the error. We were seeing this after upgrading:

Error: Class "Drupal\migrate_tools\Commands\MigrateToolsCommands" not found in include() (line 27 of /var/www/html/docroot/modules/contrib/path_redirect_import/src/Commands/PathRedirectImportCommands.php).

We agree with #16 as well, the patch from https://www.drupal.org/project/path_redirect_import/issues/3373025 🐛 Update to support path redirect import migrate_tools 6.0.2 RTBC updates the path and resolves the error.

Regarding the file location change in migrate_tools, there is an issue with a patch that works in D10 here: https://www.drupal.org/project/path_redirect_import/issues/3373025 🐛 Update to support path redirect import migrate_tools 6.0.2 RTBC

smustgrave → credited ddavisboxleitner → .

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

I have added two PHPUnit functional tests to the project, testPermissionsPage() verifies that an administrator can see the Workbench specific permissions at admin/people/permissions/module/workbench when the module is installed on a site.

The second test testWorkbenchPermissions() creates a custom content type, then gives a user access to edit that content type and access to the 'My Workbench' page and confirms they can see the Workbench menu options on that page.

ddavisboxleitner → created an issue.

I have updated the code in gitlab with the contents of the patch file in #25.

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

I rebased the merger request in order to include a commit from branch project:2.x

I have fixed the spelling error. Proper spelling is precedence.

ddavisboxleitner → created an issue.

I have tested the patch and it works as intended. In testing, the site names and urls are in correct order.

sm_urls

array (
  0 => '//example.local',
  1 => '//one.example.local',
  2 => '//two.example.local',
  3 => '//four.example.local',
)

sm_site_name

array (
  0 => 'Domain 10',
  1 => 'One',
  2 => 'Two',
  3 => 'Four',
)

I have made an attempt to move the code from search_api_federated_solr_search_api_solr_documents_alter into an event subscriber.

Importantly, I had to use:
$documents = $event->getSolariumDocuments();

To get the list of documents, and at the end of the function I call:
$event->setSolariumDocuments($documents);

I was following the annotation in search_api_solr's Event class:

<?php

namespace Drupal\search_api_solr\Event;

/**
 * Event to be fired after all solarium documents
 * have been created for indexing.
 *
 * @code
 *   // Add a "foo" field with value "bar" to all documents.
 *   $documents = $event->getSolariumDocuments();
 *   foreach ($documents as $document) {
 *     $document->setField('foo', 'bar');
 *   }
 *   $event->setSolariumDocuments($documents):
 * @endcode
 *
 * @Event
 */
final class PostCreateIndexDocumentsEvent extends AbstractSearchApiItemsSolariumDocumentsEvent {}

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

If anyone else comes to this page and decides to add a 'twig_sandbox_whitelisted..' variable to their project, please note that the names of these variables has changed in Drupal 9.1

See https://www.drupal.org/node/3162897 →

twig_sandbox_whitelisted_classes is replaced with twig_sandbox_allowed_classes
twig_sandbox_whitelisted_methods is replaced with twig_sandbox_allowed_methods
twig_sandbox_whitelisted_prefixes is replaced with twig_sandbox_allowed_prefixes

Here is my d.o name, thanks @benjifisher

I also tested the patch from the merge request in #comment-15032950 (#6) and it worked as intended. I was able to map a Contact field (composite) Company field (sub-field) to a Salesforce Object and confirmed the data was sent correctly.

PHP 8.1, D9.5.1.

Fixing grammatical issue on sentence 

"The Webform module comes shipped with a "composer.libraries.json" file containing information about all up-to-date libraries required by the module itself, and so we will be using this file to install all libraries by merging the "composer.libraries.json" with the "composer.json" file of our Drupal website."

ddavisboxleitner → created an issue.

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