justanothermark → made their first commit to this issue’s fork.
MR created to implement proposed feature
justanothermark → created an issue.
I've created an MR that prevents the issue by replacing the backslashes with pipe characters (and the reverse when accessing the route).
However, I'm not sure this should be the final fix and we should reconsider whether we want to have fully qualified namespaced classes in the URL or if other alternatives might be better.
justanothermark → created an issue.
Updated the reference.
justanothermark → created an issue.
Merge request for initial import/export created
yautja_cetanu → credited justanothermark → .
justanothermark → created an issue.
justanothermark → created an issue.
justanothermark → created an issue.
The initial work and a very barebones summary has been added. Leaving the ticket open for more details to be added.
justanothermark → created an issue.
justanothermark → created an issue.
marcus_johansson → credited justanothermark → .
Marcus_Johansson → credited justanothermark → .
andrewbelcher → credited justanothermark → .
andrewbelcher → credited justanothermark → .
andrewbelcher → credited justanothermark → .
andrewbelcher → credited justanothermark → .
andrewbelcher → credited justanothermark → .
We were also having this problem in the latest version (1.1.1) on D10. In addition, we were also seeing computed breadcrumbs coming through using the internal path instead of the alias so for a page at https://example.com/en/foo/bar we were getting breadcrumbs of:
* "Home": `https://example.com/en`
* "": `https://example.com/en/node`
instead of:
* "Home": `https://example.com/en`
* "Foo": `https://example.com/en/foo`
The attached patch uses the base field definition changes from #3 but switches to use `$url->toString()` instead of `$url->getInternalPath()`. This fixes the breadcrumb computing to give the correct links & titles and also works for translations. Additionally, this should work for sites that use translations based on domains or query strings or something other than `/[langcode]/` as the first part of the path.
A couple of suggestions from reviewing the MR:
1. Should we undo moving the `langcode` field in to the sidebar? The node form doesn't do this so doing it for taxonomy terms makes them inconsistent.
2. I think we should include the `entity.taxonomy_term.content_translation_edit` route as well.
Added patch which:
* Adds a Unit test case for this issue to `\Drupal\Tests\password_policy_length\Unit\PasswordLengthTest::lengthDataProvider()`
* Replaces the use of `strlen()` with `mb_strlen()` in `\Drupal\password_policy_length\Plugin\PasswordConstraint\PasswordLength::validate()`
justanothermark → created an issue.
justanothermark → created an issue.