Account created on 1 May 2010, almost 15 years ago
#

Merge Requests

Recent comments

🇬🇧United Kingdom nlisgo

Leaving as needs work because tests are requested but it appears as if the MR is passing so no current regressions detected. Let's get the test in!

🇬🇧United Kingdom nlisgo

This seems to be clearly described. Tagged as Needs tests and it should be easy to add a test.

🇬🇧United Kingdom nlisgo

@mgifford I see you have tagged this issue wcag331 are you happy with this outcome?

🇬🇧United Kingdom nlisgo

@Lendude. Thanks for the quick followup. I was scratching my head on what the obvious next step was. I agree with outcome.

🇬🇧United Kingdom nlisgo

Since we have focused in on the handling of setting a uid which doesn't correspond to a user on Node, I thought I would see how the same scenario is handled for comments.

drush ev "\Drupal::entityTypeManager()->getStorage('comment')->create(['entity_id' => 2, 'entity_type' => 'node', 'field_name' => 'comment', 'comment_type' => 'comment', 'uid' => 12345, 'comment_body' => ['value' => 'This is the comment body', 'format' => 'basic_html']])->save();"

The result of this is to store the uid is given:

SELECT * FROM comment_field_data;
+-----+--------------+----------+--------+-------+------+-----------+---------+------+------+----------+----------+------------+------------+--------+-------------+------------+------------------+
| cid | comment_type | langcode | status | uid   | pid  | entity_id | subject | name | mail | homepage | hostname | created    | changed    | thread | entity_type | field_name | default_langcode |
+-----+--------------+----------+--------+-------+------+-----------+---------+------+------+----------+----------+------------+------------+--------+-------------+------------+------------------+
|   1 | comment      | en       |      0 | 12345 | NULL |         2 | NULL    | NULL | NULL | NULL     | NULL     | 1719581477 | 1719581477 | 01/    | node        | comment    |                1 |
+-----+--------------+----------+--------+-------+------+-----------+---------+------+------+----------+----------+------------+------------+--------+-------------+------------+------------------+

It seems there is a desire to not allow the storing of nodes if a specified uid does not match a stored user. See #9. But, if this is expensive perhaps it is better to just allow the storing of the uid as provided. This could be achieved by removing the following:

From \Drupal\node\Entity\Node::presave()

// If no owner has been set explicitly, make the anonymous user the owner.
      if (!$translation->getOwner()) {
        $translation->setOwnerId(0);
      }

Is there any appetite to just remove this code and not throw an exception at all?

🇬🇧United Kingdom nlisgo

I can recreate the issue in 11.x.

drush ev "\Drupal::entityTypeManager()->getStorage('node')->create(['title' => 'test', 'type' => 'article', 'uid' => 12345])->save();"

SELECT * FROM node_field_data;
+-----+-----+---------+----------+--------+-----+-------+------------+------------+---------+--------+------------------+-------------------------------+
| nid | vid | type    | langcode | status | uid | title | created    | changed    | promote | sticky | default_langcode | revision_translation_affected |
+-----+-----+---------+----------+--------+-----+-------+------------+------------+---------+--------+------------------+-------------------------------+
|   2 |   2 | article | en       |      1 |   0 | test  | 1719579473 | 1719579473 |       1 |      0 |                1 |                             1 |
+-----+-----+---------+----------+--------+-----+-------+------------+------------+---------+--------+------------------+-------------------------------+
🇬🇧United Kingdom nlisgo

@Lendude, since you marked this issue as postponed in #3 the only comment that possibly calls for any next steps are in #7. And the next steps are not clear to me, could you perhaps update the issue summary?

🇬🇧United Kingdom nlisgo

Drupal\field_ui\Form\FieldStorageAddForm is in the field_ui module. Therefore, any use of $this->config('field_ui.settings')->get('field_prefix') should be expected to be valid. The config/install and config/schema should be relied upon to set the default of field_ui and to ensure that any change to that matches the schema of string with regex of /^[_a-z]+[_a-z0-9]*$/.

I think given these conditions there is nothing to fix here. If somehow this error is triggered then we need to diagnose and fix the problem not address the symptom.

There is a case where $this->config('field_ui.settings')->get('field_prefix') can be expected to be null in core and that has been handled: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/media...

The above case is justified because field_ui module may not be installed. The same condition is not true with code in the field_ui module.

My strong recommendation is that this issue be "closed (works as designed)".

For those that are experiencing this deprecation warning it is best to create an issue and provide the specific steps to reproduce and we can offer support on ensuring that the field_ui settings are available for you when the field_ui module is installed.

🇬🇧United Kingdom nlisgo

I just had it happen on a test project as well, the field_ui.settings config was missing. It shouldn't happen, but it can happen. Might as well deal with it since the fix isn't that complicated anyway, right?

To respond to #3. If this is genuinely a case of "it shouldn't happen" then "might as well deal with it" is not a great approach. If the absence of field_ui.settings config is a condition we want to handle then that may affect the solution. I will try and write a test only MR so that we can agree on the target solution.

🇬🇧United Kingdom nlisgo

The reason we do not experience the issue in claro is because they have a workaround since before it was brought into Drupal core.

This is when the workaround was introduced: https://git.drupalcode.org/project/claro/-/commit/3bb63fdf6ecadd9a9ba87d...

The fix for this should also include removing that workaround code.

🇬🇧United Kingdom nlisgo

I can confirm this is happening whether or not client side JS is running.

🇬🇧United Kingdom nlisgo

I have been able to recreate the issue in 11.x

I would like to take this on.

🇬🇧United Kingdom nlisgo

We still need clear steps to recreate the conditions which expose this issue. This should pave the way to a test and fix.

As the request for steps to reproduce has gone unanswered for 3 years (#3). #8 seeks to answer this but it is unclear.

Marking it as Postponed (maintainer needs more info)

🇬🇧United Kingdom nlisgo

I created a MR which just introduces the change in #16.

Still needs tests and issue summary update.

🇬🇧United Kingdom nlisgo

nlisgo made their first commit to this issue’s fork.

🇬🇧United Kingdom nlisgo

I can't find where needs-data is used at all. It adds zero value currently to add this property. It's not surfaced in any UI unless some contrib is picking it up?

The case could be made to just strip out. We survived a long time without.

If we decided that we want to improve the experience for developers and merely setting this property will perform the requisite checks for the presence of a data of the declared type then we need to replace the invokeAll in token > generate() with an invokeAllWith and call the corresponding info for each hook_token and optionally call the hook_token based upon the data being present.

It would be interesting to know if there is any precedent for this type of check for other hooks in drupal.

🇬🇧United Kingdom nlisgo

I'll see if I can progress/smash this one.

🇬🇧United Kingdom nlisgo

I can't recreate this issue. Admittedly, I tried to make the least possible changes to trigger the bug.

I changed core/profiles/demo_umami/themes/umami/umami.libraries.yml and changed global > css > layout > css/layout/layout.css from:

{}

to:

{
  attributes: {
    integrity: 'sha384-6/QTUDnClbaDqDmY/+IdOyBdC18MXy//e1XXszrqxvbNxTf/bGFGu3kgbqK8FHRz'
  }
}

I install the umami profile and confirm the css/layout/layout.css is being reached and I'm not experiencing the bug on 11.x, 10.x.2, 10.x.1.

Is there something different about the circumstances described in the steps to recreate?

🇬🇧United Kingdom nlisgo

Marking as "Needs review" as I believe the concerns raised in #32 are met by the presentation of the test-only and fix-only MRs.

🇬🇧United Kingdom nlisgo

@smustgrave I was able to verify that QueryTest.php fails without the fix but SqlTest.php passed without the fix.

The SqlTest adjusts seem meaningless if they pass without the fix but the adjustments are needed after the fix.

To demonstrate this I will provide 3 PR's:

  • test-only
  • fix-only
  • test-and-fix
🇬🇧United Kingdom nlisgo

I'm going to see if I can help with this issue. I'll be starting by trying to work on a test only patch that adequately expresses the issue.

🇬🇧United Kingdom nlisgo

I have been able to recreate the issue in 11.x. Given the lack of activity on this issue we should prioritise fixing for 11.x and backport if needed.

I will adapt the steps to recreate for 11.x

🇬🇧United Kingdom nlisgo

As far as I can tell this is a bit of a minefield. The test passes when run in isolation but when run along with other tests it fails. I’m worried that this is a case of "test order dependency".

I’m not quite at the point where I have proof that this is the case but to prove my point I will attempt to trigger that CI only run this 1 test.

Would appreciate extra eyes on this please.

🇬🇧United Kingdom nlisgo

Locally on the same commit the same test is passing:

phpunit app/core/modules/system/tests/src/Functional/System/SiteMaintenanceTest.php 
PHPUnit 9.6.10 by Sebastian Bergmann and contributors.

Testing Drupal\Tests\system\Functional\System\SiteMaintenanceTest
..                                                                  2 / 2 (100%)

Time: 00:44.704, Memory: 10.00 MB

OK (2 tests, 68 assertions)

HTML output was generated
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-261-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-262-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-263-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-264-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-265-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-266-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-267-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-268-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-269-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-270-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-271-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-272-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-273-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-274-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-275-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-276-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-277-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-278-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-279-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-280-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-281-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-282-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-283-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-284-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-285-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-286-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-287-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-288-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-289-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-290-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-291-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-292-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-293-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-294-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-295-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-296-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-297-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-298-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-299-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-300-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-301-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-302-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-303-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-304-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-305-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-306-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-307-37384944.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-308-44249763.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-309-44249763.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-310-44249763.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-311-44249763.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-312-44249763.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-313-44249763.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-314-44249763.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-315-44249763.html
http://127.0.0.1:8080/sites/simpletest/browser_output/Drupal_Tests_system_Functional_System_SiteMaintenanceTest-316-44249763.html

Have hit test rerun.

🇬🇧United Kingdom nlisgo

Slight improvement, imo. Not a deal breaker for me.

public function routeExists(string $name): bool {
  return !empty($this->getRoutesByNames([$name]));
}

Unless we anticipate a lot of calls to routeExists with an empty string then let's just assume the supplied string is a potential route and then explicitly declare true if not empty rather than casting.

🇬🇧United Kingdom nlisgo

Hitting retest to see if we can display a green run.

The random test failure has already been logged: 🐛 Random test fail in Drupal\Tests\Component\Utility\RandomTest::testRandomMachineNamesUniqueness Needs work

🇬🇧United Kingdom nlisgo

Not sure I understand how linting will help here. If you create a component named foo_bar the SDC will only look for foo_bar.css file, not for foo-bar.css file. Is it correct?

I'm getting ahead of myself, I apologise. I may suggest linting again but rather than me telling you what the "solution" is let's understand the problem. Thanks for reopening, I want to help here.

In order for this to be a bug there must be a specific or multiple files which do not conform to the naming convention already in core. Can you surface which ones they are. In the sdc module there are only tests. Although you point out that tests don't need to adhere to the same naming conventions surely the sdc module itself should set the example for how the components should be named and prepared.

The only other other example in core, that I'm aware of, is in the demo_umami theme.

Can you point to a js, css or twig template that is incorrectly named and then for each of those put the expected filename.

🇬🇧United Kingdom nlisgo

We do not have a unit test yet for ComponentNodeVisitor but we should add a test which exposes the bug (in theory, as we cannot reliable recreate).

🇬🇧United Kingdom nlisgo

Added a test.

Created a test-only MR and also added the test to the main MR.

🇬🇧United Kingdom nlisgo

I've added the test to the main MR and I expect that the test will fail in the test-only MR but that the same test will pass in the main MR.

🇬🇧United Kingdom nlisgo

Created a test only MR. I decided the best approach to expose this bug was to add similar extensions of test coverage to the other TypedDataDefinition tests.

🇬🇧United Kingdom nlisgo

This steps to reproduce are screaming to be converted into a test.

🇬🇧United Kingdom nlisgo

@Chi I'm not sure if you intended to link to a different related issue but this is currently linking to itself.

🇬🇧United Kingdom nlisgo

You can see that in 11.x that although the dash is dominant that the underscore is quite common so sdc seems to be using the dominant one. If you want to open another ticket to suggest that we conform on a filename convention then feel free but it should certainly be an adjustment to the linting so that it doesn't rely on best effort.

$ find ./ -type f -name "*.twig" -exec basename {} \; | grep '-' | wc -l
656
$ find ./ -type f -name "*.twig" -exec basename {} \; | grep '_' | wc -l
95
$ find ./ -type f -name "*.js" -exec basename {} \; | grep '-' | wc -l
193
$ find ./ -type f -name "*.js" -exec basename {} \; | grep '_' | wc -l
70
$ find ./ -type f -name "*.css" -exec basename {} \; | grep '-' | wc -l
300
$ find ./ -type f -name "*.css" -exec basename {} \; | grep '_' | wc -l
96
🇬🇧United Kingdom nlisgo

Is it that sdc is not enforcing a naming convention for template files that matches the current convention or are there already examples in tests or umami of component filenames that do not match the convention? If there are examples could you point to one in https://git.drupalcode.org/project/drupal, please?

🇬🇧United Kingdom nlisgo

nlisgo made their first commit to this issue’s fork.

🇬🇧United Kingdom nlisgo

A fix and a test to avoid future regression.

🇬🇧United Kingdom nlisgo

From your comments on the related issue I'm assuming no test in needed here. But introducing the first dependency feels a little strange. What other modules, if uninstalled, would cause an error with demo_umami?

sdc is also an experimental module but this might actually be a bug with sdc? Shouldn't uninstalling sdc result in the single directory components fail more gracefully?

🇬🇧United Kingdom nlisgo

nlisgo made their first commit to this issue’s fork.

🇬🇧United Kingdom nlisgo

I'm struggling to recreate this test failure locally. Could someone who can help me understand what the problem is and how I might recreate it? I am using PHP 8.1 but not the correct version of MySQL. It is not very clear from this error what is wrong.

fail: [Other] Line 0 of sites/default/files/simpletest/phpunit-614.xml:
PHPUnit Test failed to complete; Error: PHPUnit 9.5.28 by Sebastian Bergmann and contributors.

Warning:       Your XML configuration validates against a deprecated schema.
Suggestion:    Migrate your XML configuration using "--migrate-configuration"!

Testing Drupal\FunctionalTests\Installer\InstallerUseDependenciesTest
.                                                                   1 / 1 (100%)

Time: 00:08.212, Memory: 6.00 MB
🇬🇧United Kingdom nlisgo

Update from @catch on slack:

You can drop the tables on uninstall. In ModuleInstaller, it calls removeBin when a module providing a cache bin is uninstalled, and the database backend drops the table in ::removeBin()

🇬🇧United Kingdom nlisgo

Update from @catch on slack:

You can drop the tables on uninstall. In ModuleInstaller, it calls removeBin when a module providing a cache bin is uninstalled, and the database backend drops the table in ::removeBin()

🇬🇧United Kingdom nlisgo

I reached out for some support on slack regarding an approach to tear down tables when modules are uninstalled. This process needs to be clearer before we progress. The current implementations of this approach have all been for core services so we don't need to support tear down. This is obviously a necessity for any implementations within a module.

Hat tip: @berdir (for your support on slack)

🇬🇧United Kingdom nlisgo

I've started on 📌 Replace ban_schema() implementation with ::ensureTableExists() Needs work .

It would be great to get some help on this one and then we have a template on how to approach the others. I need a little support to understand how to hook up the process to delete the table once the module is uninstalled.

🇬🇧United Kingdom nlisgo

The ban_ip table is being created when the ban module is installed but it is not being deleted when it is being uninstalled. I can't find a module which uses this approach to know how to hook this up correctly.

🇬🇧United Kingdom nlisgo

Moving back to 9.5.x-dev as before. Patch was successfully applied to 9. We need to address CC failure.

🇬🇧United Kingdom nlisgo

Well, that didn't go so well. I think we need to do a re-roll of this patch. I would suggest that we switch to 11.x and see if we can recreate the issue there.

🇬🇧United Kingdom nlisgo

I'm going to trigger a retest as the previous run is no longer available.

🇬🇧United Kingdom nlisgo

nlisgo made their first commit to this issue’s fork.

🇬🇧United Kingdom nlisgo

nlisgo made their first commit to this issue’s fork.

🇬🇧United Kingdom nlisgo

Once 📌 Move BrowserTestBaseTest tests checking WebAssert methods to WebAssertTest Fixed is in we will have coverage for the following methods in WebAssertTest:

  • addressEquals
  • addressNotEquals
  • assertEscaped
  • assertNoEscaped
  • buttonExists
  • buttonNotExists
  • elementTextEquals
  • linkExists
  • linkExistsExact
  • linkNotExistsExact
  • pageContainsNoDuplicateId
  • pageTextContainsOnce
  • pageTextMatchesCount
  • responseContains
  • responseHeaderDoesNotExist
  • responseHeaderExists
  • responseNotContains

We are still lacking tests for the following:

  • assert
  • buildXPathQuery
  • fieldDisabled
  • fieldEnabled
  • hiddenFieldExists
  • hiddenFieldNotExists
  • hiddenFieldValueEquals
  • hiddenFieldValueNotEquals
  • linkByHrefExists
  • linkByHrefNotExists
  • linkNotExists
  • optionExists
  • optionNotExists
  • responseNotContains
  • selectExists
  • statusMessageContains
  • statusMessageExists
  • statusMessageNotContains
  • statusMessageNotExists
  • titleEquals

We should create an issue for these but I suggest that it will be easier to get them in if we break them down into a few MR's.

🇬🇧United Kingdom nlisgo

I've moved all of the appropriate tests from BrowserTestBase to WebAssert

Some of the tests mentioned in #7 are for Behat\Mink\WebAssert assertions:
- testXpathAsserts
- testFieldAssertsForTextfields
- testFieldAssertsForCheckbox

Cannot locate testFieldAssertsForOptions

🇬🇧United Kingdom nlisgo

Would be easy enough to add a test to Drupal\FunctionalTests\WebAssertTest. There is an issue to move tests from BrowserTestBaseTest to WebAssertTest so it might be a good idea to add to WebAssertTest. 📌 Move BrowserTestBaseTest tests checking WebAssert methods to WebAssertTest Fixed

The test for ::linkByHrefExists is missing and there is an issue to address that and the other missing tests: 📌 [meta] Add tests for the WebAssert class Active

🇬🇧United Kingdom nlisgo

🐛 on Long Text/Multiple value, html default value doesn't appear in new items Closed: works as designed

Revisited this issue that was already tagged and believe it should be closed.

🇬🇧United Kingdom nlisgo

It is my understanding that the expected behaviour is different from what is described in the issue summary.

When you have a multi value field and you choose a default value then the first entry for the default value is for the first item and you can create subsequent default values:

The html field is broken because you cannot supply multiple values for it.

The behaviour in #14 is also expected beahviour. When you have a multi value you field then empty fields are ignored so you would find that if you returned to the interface for the default value that the second empty entry has been removed.

The bug I am experiencing is that I can not seem to set a second (or third and so on) default value for formatted text fields.

I am going to close this ticket as working as expected and open another issue to document the bug that I am experiencing which triggers the following error:

Error: Cannot use object of type Drupal\Core\StringTranslation\TranslatableMarkup as array in Drupal\text\Plugin\Field\FieldType\TextFieldItemList->defaultValuesFormValidate() (line 24 of /data/app/core/modules/text/src/Plugin/Field/FieldType/TextFieldItemList.php).

🇬🇧United Kingdom nlisgo

nlisgo made their first commit to this issue’s fork.

🇬🇧United Kingdom nlisgo

nlisgo made their first commit to this issue’s fork.

🇬🇧United Kingdom nlisgo

I've added a test and changed the target to 11.x we can backport afterwards. I've also adjusted the order that the new replace is introduced to the list so that the granularity order is maintained.

🇬🇧United Kingdom nlisgo

nlisgo made their first commit to this issue’s fork.

🇬🇧United Kingdom nlisgo

I've addressed the CC failure and also now use LoggerTrait.

🇬🇧United Kingdom nlisgo

The tests added cover my understanding of the expected behaviour. I have made the minimum changes to fix the failing tests.

🇬🇧United Kingdom nlisgo

I've created a test which expresses my understanding of the expected behaviour of CssCollectionRenderer.

I will look at the AssetResolver and CssCollectionGroup a little closer to understand what the expected behaviour of those should be.

🇬🇧United Kingdom nlisgo

nlisgo made their first commit to this issue’s fork.

🇬🇧United Kingdom nlisgo

Without clear steps to recreate we only have the fix to guide what a test might look like.

I tried to recreate the issue by injecting the same library twice on the same page but it didn't trigger the TypeError:

function olivero_preprocess_html(&$variables) {
  $variables['#attached']['library'][] = 'olivero/nlisgo';
  ...
}

function olivero_preprocess_block(&$variables) {
  if (!empty($variables['elements']['#id'])) {
    if ($variables['elements']['#id'] === 'olivero_page_title') {
      $variables['#attached']['library'][] = 'olivero/nlisgo';
    }
    ...
  }
  ...
}
Production build 0.71.5 2024