Welll Features may never export namespaces correctly? But six years on we may as well do it correctly ourselves.
This is an accessibility issue, that the descriptive label (say, "Date of birth") is not connected to the form label immediately connected to the form field for a screen reader (will only say "Date").
OK this is 100% cosmetic changes to the code formatting.
Seems the best solution, despite adding one more nested div, is to add the form-element template as a wrapper, which should let all themes treat form items as they thing they should be treated.
Happy to add a configuration option for this, disabled by default, if at most we want an optional change that does not impact existing sites at all.
mlncn → created an issue.
Confirming the code quality and functionality of this patch. Also think that it is the right solution, and a good one. In particular for a vocabulary where a user does not have edit permissions for the terms, the inapplicable operation link to "Add child" is very in-the-face and distracting.
Back to needs review at the very least, for the patch in #14 as per #20
It was RTBCd (comments #15 and perhaps #18) and it still works 7 years later! To address #16 the module could offer an interface for capturing keycodes but clearly that is not needed to address the immediate pain of Coffee stealing a common browser shortcut. And there is no need to prompt administrators to configure the keys because there is an update hook to assign all the currently available keys by default.
Improvements that could be made in follow-ups but should be considered out of scope for this patch which allows site administrators to making Coffee more compatible with browsers and more usable for more people:
- Allowing any key code to be used.
- Providing a helper for capturing keycodes.
- Allowing individual users to set their own keycodes.
Changing the issue title to make clearer that last one in particular was never the intent of any of the patches contributed here.
Thank you so much! It definitely was not healthy there for a minute and very much needed this report!
Thanks! Are you using the module actively in Drupal 11 or simply helping out here? Thanks!
Tested, fixed follow-up error, and tagged a release, 8.x-1.3.
Thank you for the report, so sorry for releasing a Drupal 11 version that was not actually compatible.
Gentle reminder that rather than proclaiming a module "dead" this is a golden opportunity to contribute a fix → . Although, on second thought, that is thousands of words making clear how complicated it is to contribute what should be the simplest of things. Ah well. Fix coming shortly.
mlncn → changed the visibility of the branch 2906496-give-media-a to hidden.
This problem of the Drupal\pathauto\PathautoItem object (contrib, i know, but it extends Drupal\path\Plugin\Field\FieldType\PathItem with minimal changes not relevant here) having an alias property of NULL is also an issue for validation even when automatic aliases are enabled.
The updated workaround/fix is now in a brand new branch with a merge request that has only what it should have.
Still do not know how the alias property can end up NULL in the first place – when the values array has the alias correctly in the very same object – so not sure how to add a test, but the fact that all existing tests pass indicates that it is a harmless failsafe.
mlncn → changed the visibility of the branch 3535695-url-alias-field to hidden.
mlncn → created an issue.
mlncn → created an issue.
mlncn → created an issue.
Thanks ultrabob! Yeah, the Trash module is really the only contender out there now i think (and it is in Starshot / Drupal CMS) but it still has some edge cases with … content moderation … that have some sites avoiding it right now: ✨ Trash is not compatible with Content Moderation Active
Probably Trash will become 'the' solution and maybe even get into Drupal core, but building on Workflows to introduce a 'deleted' (trash) state still seems more core-compatible and future-safe right now.
We'll remove it from 2.0.x and put the change in the release notes.
It is of course unlikely to get these variables into core quickly so we should create a contrib module, but should also file a core issue in the Workflows queue like beunerd suggested.
To belatedly provide the use case for this variable, in a node--full.html.twig:
{% if not node.isPublished() %}
{% if current_revision_state == 'trash' %}
{% set version_state_message_title %}
{% trans %}
This {{ content_type }} has been deleted.
{% endtrans %}
{% endset %}
{% set version_state_message_subtitle %}
{% trans %}
You can restore it by editing.
{% endtrans %}
{% endset %}
{% elseif node.isDefaultRevision() %}
{% set version_state_message_title %}
{% trans %}
This {{ content_type }} is not yet viewable by the public.
{% endtrans %}
{% endset %}
{% set version_state_message_subtitle %}
{% trans %}
Please complete and publish it soon!
{% endtrans %}
{% endset %}
{% else %}
{% set version_state_message_subtitle %}
{% trans %}
This {{ content_type }} {{ current_revision_state }} has not yet been published.
{% endtrans %}
{% endset %}
{% set version_state_message_subtitle %}
{% trans %}
An older version is published; please complete and publish this latest {{ current_revision_state }} soon!
{% endtrans %}
{% endset %}
{% endif %}
<section class="hero is-danger is-bold">
<div class="hero-body">
<div class="container">
<p class="title">{{ version_state_message_title }}</p>
<p class="subtitle">{{ version_state_message_subtitle }}</p>
</div>
</div>
</section>
{% endif %}
Applied to both (in progress, somewhat disruptive) 2.0.x and 8.x-1.x (we should tag a point release there soon) branches.
Fix looks correct. Thanks!
mlncn → created an issue.
This latest, greatest, and i hope final update to the merge request shows the label (when it exists, which in my testing is always) and what bundle it came from, and if there are more bundles.
field_example "Example" on node:page & 1 other
Also, it sorts by field machine name within entity types, but leaves fields grouped by entity type. We now show the entity type with the bundle (media:image, node:article, user:user - in the same manner displayed in the Bundles field below) so it should become evident quickly that all the media fields are first, then node fields, then user, for example.
For me, definitely the most confusing thing was not knowing what entity type each field name was on, since fields are not shared across different types of entities, so the exact same name can appear twice. Showing the entity type as well as the bundle definitely helps but i still think grouping by entity type is clearer.
As a follow-up we may want to add help text that the label may vary on the additional bundles (where we note "& 1 other" or "& 2 others" etc for each field), but putting "label may vary on Y other bundles" made the already-long option text too long.
The other follow-up that could improve UX is reminding people they can filter for which bundles will have CER active for below. (So field_media_image "Image" on node:page & 5 others can be synchronized with media:image for node:article only.) Also, that saving the form after selecting the fields will update the autocomplete options in Bundles to only the relevant ones (i don't think it works the other way around, but a way to filter the first and second fields by bundle would be nice).
Back to RTBC since it was only me with the problem for quite an edge case and the fix is tiny and safe.
All right, by default user in core is an entity type without bundles, definition getKey('bundle') returns an empty string. That will always work if an entity does support bundles so we can simply not add the bundle restriction on an empty string.
(Alternatively, we could change the UI to not offer "user:user" etc for entity types that do not support bundles; but i think the fix here in the sync is better and more straightforward.)
Update to the merge request in a minute.
Retroactive updates for past, already saved, previously existing content is a huge feature. Took me a while to find this issue and i was surprised the question of what happened with past (when the form field for A to B is empty only because it had not been synced when A was updated because CER was not configured yet, will it clear B to A when B is saved?)
Unfortunately in testing this merge request with the 5.x branch of the module, for a node to user entity reference with corresponding user to node entity reference, i get this error:
Drupal\Core\Entity\Query\QueryException: '' not found in Drupal\Core\Entity\Query\Sql\Tables->ensureEntityTable() (line 373 of core/lib/Drupal/Core/Entity/Query/Sql/Tables.php).
Drupal\Core\Entity\Query\Sql\Tables->addField() (Line: 58)
Drupal\Core\Entity\Query\Sql\Condition->compile() (Line: 177)
Drupal\Core\Entity\Query\Sql\Query->compile() (Line: 82)
Drupal\Core\Entity\Query\Sql\Query->execute() (Line: 145)
Drupal\cer\Form\CorrespondingReferenceSyncForm->getEntityIdsToSync() (Line: 72)
Drupal\cer\Form\CorrespondingReferenceSyncForm->submitForm()
call_user_func_array() (Line: 105)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 43)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 589)
Drupal\Core\Form\FormBuilder->processForm() (Line: 321)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::wrapControllerExecutionInRenderContext():121}() (Line: 622)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::onController():96}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
Drupal\Core\DrupalKernel->handle() (Line: 19)
Essentially the fix by wojtha in this issue 13 years ago and richthegeek and cvangysel in #873070: When an image button appears after another button in a form, the wrong triggering element and #submit handlers are detected → 14 years ago remains correct and needed.
When image buttons are clicked, browsers do not set NAME in the POST, instead setting NAME_x and NAME_y (with x and y the coordinates of the click). To get the clicked button we need to test for these parameters instead of the presence of value— that is, equally . (Damien's suggestion of using #value for image buttons also does not work, whether the button is pressed or not, whether it has a value or not, the value gets set anyway, and set to "true", presumably because of how image buttons are treated by the browser— the only thing that is safe to check are if coordinates were set.)
And yes (replying to 13 year old comments from another issue now, but the same feedback will come up) these changes make the alternative condition specific to image buttons, but i'm fairly certain that is because that is all there is— the only other element in core which uses #has_garbage_value is Radios, which aren't ever going to be triggering a form submission.
So, yeah, image buttons are ridiculous and Drupal core could totally deprecate them and not support them since basically nobody has cared for a decade (especially if we finally do 📌 Use form element type instead of Needs work ), but as long as we have ImageButton extending Submit we need to support it properly as an alternative to Submit, that works alongside Submit buttons.
The merge request is ready and works, but leaving Needs work as it needs a test showing that this fails even when value is not set in the initial form element definition. As my use case is altering an existing button there is some possibility that something about that is adding 'value' back, but definitely unsetting value is not enough.
The merge request fixes the Gin display issue reported.
Note image buttons do not work the same as regular submit buttons in core. Right now, the image button always steals the submit handler! So maybe this cannot work, so although the display and the functionality are distinct issues that can be handled independently leaving this as active rather than needs review until there is a core fix / workaround (to address core functionality re-opened ✨ UX when using gin with Contnet Moderation and Workflows Active ).
And it is not a duplicate with changing values client side; although that may be related, this is being caused with alteration in a Drupal form/widget alter.
This is absolutely still a bug in Drupal 11.
Button Field module documents:
Important note
Due to #1452894: Elements with #has_garbage_value and #value are always set as a triggering element you can not use image buttons on edit forms when there are any other buttons. Non-editable displays are unaffected.
And where i'm coming from, i confidently told Gin in 🐛 Image buttons cannot be kept in Gin's sticky form actions Active that core's image button form element is a valid alternative to a standard submit input form element:
As noted in ✨ UX when using gin with Contnet Moderation and Workflows Active , Workflow Buttons module pairs very well with Gin for improving the experience of using content moderation workflows, and the 2.0.x branch of Workflow Buttons' "Trash workflow" submodule switches to using the image button to have a trash icon for the soft-delete, similar to the trash icon Claro/Gin add to core's delete link. […]
But in short swapping the submit button out and substituting an image button for it works, and Gin should support this core form element when adding Gin attributes and looking for the
#gin_action_itemflag.
And i get it working perfectly and then discover that no matter which button i press, the image button (soft delete!) is the one that gets incorrectly identified as the trigger button.
Thanks Arun!
Did you enable Admin Toolbar Extra Tools? drush -y en admin_toolbar_tools
Back to needs review then, this looks like. Great work, thanks!
Updating Drupal 11 status of modules in table, start to make other version headlines clearer.
mlncn → created an issue.
If you don't scroll back further in the code for the root error, TypeError: $(...).fitVids is not a function is probably the error you will see in your console for this problem.
The patch fixes FitVids.
mlncn → created an issue.
Thanks— i had followed the issue fork commands to make https://git.drupalcode.org/issue/drupal-3535695/-/tree/3535695-url-alias...
But when i went to submit the merge request, it said 178 commits, 0 changes, so that means i did something wrong and need to try again, yes?
This fixes it but no i have no idea why it would be broken in the first place.
Noticed when making this patch i do still have a core patch in the vicinity: "Path module calls getInternalPath without checking if the url is routed #3342398": "https://git.drupalcode.org/project/drupal/-/merge_requests/9209.diff", from 🐛 Path module calls getInternalPath without checking if the url is routed Active but it does not look like it intersects.
Likewise looked at #2484411: Manual path aliases are not the same as aliases on the node form → but could not see a connection.
Meant to mention the site has no multilingual or translation set up at all (at least not currently, it is possible it did at one point long ago and they were disabled) so 🐛 If you don't want to translate your URL alias, the original URL alias won't work with your translations Needs work should not be the issue.
Also meant to mention explicitly that this does not pose a problem as long as automatic aliases are turned on; our internal tracking issue once we realized the problem was not, say, a contact form no longer existing, only losing its alias, went from being titled "Issue with URL Alias" to "Content that had a manual (rather than automatic) URL alias has no alias shown in the form when edited, so on save the alias is lost" with the deathless description "Manual URL Alias are being forgotten.".
mlncn → created an issue.
Thought i should report
🐛
Remove last facet fails
Active
as related to here— TLDR i think the "prettiest" paths (no query string at all, /view/category/foo-258 in the example above) seem a little incompatible with Facets via Better Exposed Filters or Views itself.
This issue was filed first, but the same solution is already RTBCd in 🐛 Function maxlength_field_widget_third_party_settings_form() should return array, not null Active
These issues are duplicates but whichever is marked as fixed should give credit to the contributor(s) of the other.
The patch is straightforward and very needed.
Marking as major because it can cause a fatal error when you try to go to the manage display form of a content type (for example /admin/structure/types/manage/article/form-display). And there is no easy way to figure out that maxlength is to blame without a debugger (or searching the web now that i'm dumping the entire error message here):
The website encountered an unexpected error. Try again later.
TypeError: Unsupported operand types: array + null in Drupal\field_ui\Form\EntityFormDisplayEditForm->{closure:Drupal\field_ui\Form\EntityFormDisplayEditForm::thirdPartySettingsForm():129}() (line 131 of core/modules/field_ui/src/Form/EntityFormDisplayEditForm.php).
And the stacktrace:
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 127)
Drupal\field_ui\Form\EntityFormDisplayEditForm->thirdPartySettingsForm() (Line: 459)
Drupal\field_ui\Form\EntityDisplayFormBase->buildFieldRow() (Line: 40)
Drupal\field_ui\Form\EntityFormDisplayEditForm->buildFieldRow() (Line: 213)
Drupal\field_ui\Form\EntityDisplayFormBase->form() (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm()
call_user_func_array() (Line: 528)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::wrapControllerExecutionInRenderContext():121}() (Line: 622)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::onController():96}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
Drupal\Core\DrupalKernel->handle() (Line: 19)
To very belatedly report back, we are using (and struggling with ✨ Make compatible with Facets Pretty Paths Active Entity Reference Filtering Link.
Separately from my specific, messy issue fork above, the feature (for Entity Reference Filtering Link) of being able to automatically get the right pattern from the Views Exposed Filter configuration the way ERFL does from Facets configuration would be really amazing.
mlncn → created an issue.
This probably will not help 5½ years later but you were almost there— for entityQuery's purposes the column is not the full column name as it appears in the database table but only the part not redundant with the field name— so in the original post's example the field plus column indicator is not field_date_range.field_date_range_end_value but rather field_date_range.end_value, used like this:
->sort('field_date_range.end_value');
This does not seem documented for sort() nor condition(), at least not in the docblock, and it really should be i think.
Yes it was! And then in 📌 Clean up any remaining code issues for a Drupal 11 Release Active the @var line with a missing asterisk was removed, and i think is redundant with the assertion in most IDEs.
mlncn → created an issue.
Fairly certain this is not unique to my setup (note: using Facets 3) and it is pretty major.
Link are 'non-pretty' (?focus[1330]=1330) but i guess redirects to the pretty link. These are tacked onto the current path, including the pretty paths if there. The "non-pretty" overrides but for removing the last facet there is no "non-pretty". If Facet Pretty Paths could be done without the intermediary non-pretty facet links this inability to remove the last item would (have to) be solved.
Found 📌 Unhelpful PHP error with NULL type property Needs review while looking for similar issues and realized that my Drupal 11 was not up to date; a bizarre interaction with Drupal lenient plugin and a patch had left it at a release candidate. Completing the upgrade to Drupal 11.2 resolved this problem.
mlncn → created an issue.
And given that the above workaround has been working for us on a site for a long time, allowing Extra Field 3 in Extra Field Configuration's composer.json like this should be all that is needed.
This truly is blocking Drupal 11 compatibility (because only Extra Field 3.x is D11 compatible) so i think this is major.
A workaround, in the require section of your project root composer.json claim that Extra Field 3 is actually version 2:
"require": {
"drupal/extra_field": "3.0.x-dev@dev as 2.3",
Hi summit, bit late on the reply but you can use:
"repositories": {
"drupal/location_migration": {
"type": "git",
"url": "https://git.drupalcode.org/issue/location_migration-3288357.git"
},
with
"require": {
"drupal/location_migration": "1.0.x-dev",
or the Drupal lenient composer plugin - https://www.drupal.org/docs/develop/using-composer/using-the-drupal-leni... → - to allow composer to install the regular module and then add this patch as you were.
As updated in issue description and can be seen in the issue fork i think the most expedient solution is to avoid false negatives in the URL check by converting it to a string first.
(crosspost)
This is great! Works and the code change is straightforward. I would change to RTBC except for the decision on how to commit and release.
My 2¢ is to do the new major with different version constraints— and hope CKEditor does not make a habit of this level of breaking change!
Does anything happen with the module, or is the included library the only thing that needs changes?
(And any tips for swapping or patching plugins in the project composer.json to test this more easily?)
This is fixed for real in commit f27dd51d6a2c46ee6a2d577d1ad8fc8f7bf9cc65
No idea why the merge button would not work, not a month ago (apparently) and not now either. And no idea why the commit is not showing up here after doing it manually and pushing.
But it really is there: https://git.drupalcode.org/project/tomselect/-/commit/f27dd51d6a2c46ee6a...
The merge request deletes the built file, resulting in an unsurprising error of this kind: The requested URL /modules/contrib/ckeditor_abbreviation/js/build/abbreviation.js was not found on this server.
Given that it was committed before i presume there is a step committers should take to generate the file and then commit it?
And agree that a new major version release makes sense and we can have it version 6 require Drupal core 10.5 / 11.2 or later.
Really rotten of CKEditor to fail this badly on a breaking change; one thing for the plugin or even CKEditor to not work but for it to blank out all text on save is the worst possible behavior.
Precise error in console that i was getting with Drupal 11 and CKEditor 45.2:
"TypeError: e.icons is undefined"
Given that the icon package is at play here, that i'm not finding that error message on the internet anywhere, and that CKEditor Abbreviation is the only extra module for CKEditor we have, i think it has to be related.
"entity.$entity_type_id.edit_form.{$this->formModeManager->getFormModeMachineName($form_mode['id'])}"
looks like it, but we'd want to document the easiest way to get the form mode machine name and how to pass in the individual entity (ID) as a parameter when using the route to get a link to the entity's edit form mode.
mlncn → created an issue.
Needs at the very least an off-by-default toggle on the settings page.
Reported by a colleague on Drupal 11:
Warning: Undefined array key "override" in entity_reference_override_validate_custom_text() (line 59 of modules/contrib/entity_reference_override/entity_reference_override.module).
entity_reference_override_validate_custom_text()
call_user_func_array() (Line: 281)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 118)
Drupal\Core\Form\FormValidator->validateForm() (Line: 585)
Drupal\Core\Form\FormBuilder->processForm() (Line: 321)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 124)
Drupal\cloudflare\CloudFlareMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)
With a follow-up note:
Looks like it doesn't throw the error only if 'single line no markup' is used as the custom text format!?
mlncn → created an issue.
That last commit had a merge/rebase problem:
ParseError: syntax error, unexpected token "<<", expecting ")" in web/modules/contrib/give/src/Plugin/Field/FieldType/PaymentMethod.php).
It's not too bad for this use case! And on further inspection, this covers one of three to four effective outputs of the six configurations that Facets Pretty Paths offers.
In Entity Ref Filtering Link terms, the other options are:
/$view_url/$argument/$id
/$view_url/$argument/$pathautod_label-$id
(With URL-encoded raw value as an option for the first one, but as long as that is an integer ID i don't see how that could effectively matter.)
The option this merge request covers:
/$view_url/$argument/$pathautod_label
is certainly the prettiest. In Facets Pretty Paths this is the Taxonomy term name option, "Use term name, e.g. /services/blue"
Huh i'm not really sure facets pretty paths, where there is no query portion, fully makes sense with this module… well, it should work fine but as i mused above the sheer number of possible configurations for pretty paths seems not a great match to the current configuration approach of entity ref filtering link.
The above is one particular configuration of Facets Pretty Paths, i should note. Not sure if there is any reasonable way to support all the configurations without doing what Entity Reference Facet Link does and interrogate the facet itself for its configuration, and i am over here because seems that would be very hard to do for Facets 3— 💬 Facet links created perfectly except with a colon rather than Active
But making this one way possible will be very helpful i think and make it more possible for others to riff on this.
It works great!! Thank you chrisolof!
c_archer you need to do the configuration of Facet Pretty Paths on the View that has the facets, in the Filter criteria section, presented as (for an 'example' facet name) "Facet: Example (example)" — you need to press that name to configure Pretty paths coder, not the Settings link as we all would usually expect.
mlncn → created an issue.
The 4.0.x merge request (!18) is working perfectly. No code changes needed other than the declarations that it is Drupal 11 compatible.