Provided validation for parsed configuration on the ConfigForm to avoid errors when the user submits a broken configuration.
Cover it with tests.
Could someone handle the testing based on this comment ? https://www.drupal.org/project/linked_field/issues/3446123#comment-16319425 🐛 Error Trying to access the the config page Active
There are still existing issues with the Config form.
The website encountered an unexpected error. Try again later.
TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in count() (line 88 of modules/linked_field/src/Form/ConfigForm.php).
Drupal\linked_field\Form\ConfigForm->buildForm()
call_user_func_array() (Line: 528)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Step to reproduce:
1. Open /admin/config/linked_field/config
2. Clear all data from the Configuration field
3. Hit 'Save Configuration'.
Possible solution:
Add form validation, which will check that at least one attribute exists.
@pingwin4eg, this issue, which you described, was fixed in https://www.drupal.org/project/linked_field/issues/3511020 🐛 Config form arguments error Active
Adjusted changes according to the actual code from 8.x-1.x. (it's also covered, displaying that text on the field setting summary)
For me, this isn't an ideal solution - ideally, we'd be able to translate third-party settings for the field formatter. However, I haven't found any way to do that in Drupal yet, so this seems to be the only available option for now.
vitaliyb98 → made their first commit to this issue’s fork.
I rechecked the code with PHPCS, and it passed. Since it has already been merged into 8.x-1.x by @jcnventura, I've moved it to RTBC.
Sync branch with latest changes from 8.x-1.x (which also contains tests and pipelines)
Fixed a small typo in the MR. Tested fix. Functional worked as expected. Move to RTBC.
vitaliyb98 → made their first commit to this issue’s fork.
Testing this solution works as expected. Also, test this in combination with the link_attributes modules. RTBC.
Tested new changes with Drupal 11.2, works as expect, so RTBC
Got this issue on Drupal 11.2 when adding a link field. Patch #6, works for me.
vitaliyb98 → made their first commit to this issue’s fork.
I tried to reproduce this issue using EVA 3.1.1, commerce 3.2 and Drupal 10/11 versions - in such case, this issue wasn't reproduced.
Then I tried to do it with Drupal 9.5.5, EVA 2.1, and Commerce 2.33. In such a combination, this issue was reproduced (but with limitations).
Step to reproduce:
1. You should have a commerce product already configured.
2. Create an EVA view and attach it to the Product entity, near the bundle option. You will see Broken field link:
3. After that, just save the view.
4. Open the product entity page, and you won't see the EVA view.
But if you open EVA view again, click on "Broken field", select bundle, and resave view, EVA view will appear on the product entity view page.
Conclusion: It looks like this issue reproduced only in the old not unsupported version.
Please let us know if this still appears in the current version of the module.
The support for Drupal 8.x was removed for this module in this issue:
https://www.drupal.org/project/eva/issues/3430343
📌
Automated Drupal 11 compatibility fixes for eva
Needs review
Currently, is core_version_requirement: '^9.5.11 || ^10 || ^11'
I will close this issue.
I'm ready to move this to RTBC, but I'll wait another week in case someone else wants to review it.
I'll take a look at this during the next half of the week, unless someone else handles it before then.
Not sure that this part
{{- _context|filter((v, k) => k not in %s) -}}
will work correctly, because in case with
* @code
* set startDate = query['start-date']|default(now)
* set endDate = query['end-date']|default(startDate)
* set fieldValues = [
* %% 'start_date': startDate,
* %% 'end_date': endDate,
* %%}
* @endcode
during execution $this->twig->createTemplate($twigSource)->render($inputVariables) will throw error:
"An exception has been thrown during the rendering of a template (""startDate" is an invalid render array key. ...."
I'm not saying this is the right way, just a way to make the code work.
When I replaced {{- _context|filter((v, k) => k not in %s) -}} with
'{%- set filtered_context = _context|filter((v, k) => k not in ' . TwigArrayOfStrings::create(...$varNamesToExclude)->compile() .') -%}',
'{{- filtered_context|json_encode|raw -}}'
I decided to add a description to the agreement checkbox. In this description, you can include a link, for example, to the additional agreement.
vitaliyb98 → made their first commit to this issue’s fork.
Added MR with changes, tested the module with the Commerce 3.2 (Drupal 11.2).
I can change the status to RTBC myself, but since I created the MR, it needs to be tested by someone else.
vitaliyb98 → changed the visibility of the branch 3547004-upgrade-to-drupal to active.
vitaliyb98 → changed the visibility of the branch 3547004-upgrade-to-drupal to hidden.
Fixed the issue with the token not being replaced in the error message.
The issue with the duplicate error message was resolved here: https://www.drupal.org/project/commerce_agree_terms/issues/3350343 📌 Form not transmitted to ValidatePaneForm Needs review
Merged changes from https://www.drupal.org/project/commerce_agree_terms/issues/3552547 📌 Cover module with tests and add pipelines Active , which includes some tests and a pipeline to help validate these changes. This also allows updating the tests to cover the new functionality.
Added changes from the patch to the MR. Also, merge changes from https://www.drupal.org/project/commerce_agree_terms/issues/3552547 📌 Cover module with tests and add pipelines Active , which contains some tests and a pipeline, which will help to validate these changes. Also, it is a good idea to add additional tests.
vitaliyb98 → made their first commit to this issue’s fork.
I put changes in the MR.
I didn't reproduce the original issue described in this ticket, but this fix also fixed the problem with the duplicated error message. Validation works correctly, and the error message is shown.
BTW the issue with not replaced %terms in the error message is still actual, but should be fixed in the separate issue: https://www.drupal.org/project/commerce_agree_terms/issues/3114273 🐛 Duplicated error messages Active
Error message before fix:
After fix:
vitaliyb98 → changed the visibility of the branch 3350343-form-not-transmitted to hidden.
vitaliyb98 → changed the visibility of the branch 3350343-form-not-transmitted to hidden.
vitaliyb98 → made their first commit to this issue’s fork.
Issue https://www.drupal.org/project/commerce_agree_terms/issues/3350343 📌 Form not transmitted to ValidatePaneForm Needs review not completly fix current issue, error message still has "%terms" not replaced
@geek-merlin made change according to your comment, looks better:
Someone else needs to test these changes. Ideally, more than one person.
As a start, I added a draft functional which shows all available properties for the current field
Need to discuss the next thing:
- Maybe there is a better form to describe property, currently used in such a format: <b>@label</b> — machine name: <i>@machine_name</i> (type: @type) Example: — machine name: (type: string)
- Currently, all available properties of the field are displayed, even if some of them will never be used for prepopulating.
vitaliyb98 → made their first commit to this issue’s fork.
@lostcarpark I've added the Views module as a dependency, but I'm not sure if we should provide a hook_update that enables the Views module in case it's disabled.
vitaliyb98 → changed the visibility of the branch 3119199-error-on-admincontentscheduled-publish to hidden.
Hi @lostcarpark this is a different issue, so it looks like we should add Views as a dependency for this module.
Hi,
Based on your information, this issue
https://www.drupal.org/project/html_title/issues/3332119
✨
HTML Not Being Rendered For Entity Reference Labels
Needs review
should fix your problem. This fix provides a new field formatter, "HTML Title Label" for the entity reference field. But this fix is not committed yet, so you may use it like a patch for the module.
@geek-merlin would you mind merging this so we can run the test on the other issue?
Could you provide a real example of the escaping problem, including the actual result and expected result, so it's easier to understand the issue?
In my project, I use a trick that allows using Twig for prepopulation (I spotted it in \Drupal\views\Plugin\views\PluginBase::viewsTokenReplace()).
I've added this reference in the MR it might be useful for others as well. I've also added some tests for it, so we can reuse that test in the future.
vitaliyb98 → made their first commit to this issue’s fork.
I believe that for displays not extending PathPluginBase, the summary option for arguments should not be available at least until this is fixed or a better solution is found.
I've added a basic solution as a draft, and I’d be interested to hear your thoughts on it.
vitaliyb98 → made their first commit to this issue’s fork.
I investigated this issue, and in my opinion, it cannot be resolved within this module, as it's a global problem affecting all display handlers that don't extend PathPluginBase.
Personally, I believe that for displays not extending PathPluginBase, the summary option for arguments should not be available at least until this is fixed or a better solution is found.
Made testing, found issue with default value for checkbox "Set new EVA fields to "hidden" on entity displays."
How to reproduce:
1. Create an EVA view.
2. Click on "Hide by default: No" (pop-up with setting should open)
3. In the pop-up set "Set new EVA fields to "hidden" on entity displays" checkbox as checked.
4. Re-save view
5. Open the same pop-up again.
Expected result: "Set new EVA fields to "hidden" on entity displays" should be checked.
Actual result: "Set new EVA fields to "hidden" on entity displays" not checked.
I fixed this problem in my last commit
The rest of the functionality works correctly
vitaliyb98 → made their first commit to this issue’s fork.
Could you please provide more detailed steps to reproduce this issue? I tried to reproduce with the following steps:
1. Created EVA view which doesn't have a result.
2. Enabled "Hide output if no result/empty text" on the view.
3. Attached this view to the user entity.
4. Opens some entity which has attached EVA (in my case is a user entity) and ensures that $output['view_build'] is empty.
Result: user entity is shown correctly
I created a MR with hook_theme_suggestions_HOOK_alter, tested it locally, and it looks good.
vitaliyb98 → changed the visibility of the branch 3223411-add-template-suggestions to hidden.
vitaliyb98 → made their first commit to this issue’s fork.
@justcaldwell If you ever need assistance, I'd be glad to help with writing tests and reviewing issues in the future as a co-maintainer. I believe this could help speed up development and improve the overall quality of the project.
I had to merge changes from this issue as well https://www.drupal.org/project/link_target/issues/3548860 📌 Add tests for the module and configure pipelines. Active (I can't wait for these changes to be merged.), since they already include widget tests and allow extending them according to the new changes."
vitaliyb98 → made their first commit to this issue’s fork.
Added hook update, which will remove unneeded dependencies if third_party_settings.epp.value = ''
vitaliyb98 → made their first commit to this issue’s fork.
"I think an update hook can be added to convert the custom settings and provide an upgrade path from 9.x."
@justcaldwell I provided hook_update, which will adjust the configuration for:
https://www.drupal.org/project/yearonly/issues/3188139
✨
Allow substraction of years (NOW - x)
Needs review
https://www.drupal.org/project/yearonly/issues/3035638
✨
Allow add extra years (NOW + x)
RTBC
After this hook update, the functionality will work automatically, and the configuration will be adjusted automatically, even if the related patches are later removed.
This issue doesn't have a patch that works completely, so I skipped it: https://www.drupal.org/project/yearonly/issues/3380578 ✨ Allow a custom 'To' year Postponed
Any chance to review and merge this issue https://www.drupal.org/project/yearonly/issues/3548622 📌 Introduce tests for module and configure pipelines Active (it will help in future module support)
I detected a similar issue that is still actual (Although I think few people have reproduced it.)
How to reproduce:
1. You need a site without a view module enabled.
2. Add a scheduled field to the article content type (or another).
3. Open /admin/content/scheduled-publish
Next Error will appear.
The website encountered an unexpected error. Try again later.
Error: Class "Drupal\views\Views" not found in Drupal\scheduled_publish\Controller\ScheduledPublishListing::viewListing() (line 42 of modules/scheduled_publish/src/Controller/ScheduledPublishListing.php).
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 622)
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: 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)
Two possible solution
1. Add the view module as a required.
2. Built a custom alternative report and replaced the view report with it in case the view is disabled.
For me, the first option is better, because the Views module is already in core, and maintaining an alternative report would require additional effort and complicate the functionality
Fixed the failing cspell pipeline.
Note: in cases where the issue was in a variable name, for example $fieldDefinitons, I skipped those words. Directly changing them in the code could break functionality, especially if users are altering or extending that code and require more re-test
Keep the issue in "Needs review" in case someone wants to provide suggestions or feedback.
Hello @justcaldwell I checked functional/patches from related issues:
https://www.drupal.org/project/yearonly/issues/3115465 →
- functional will still works without patch from that issue.
https://www.drupal.org/project/yearonly/issues/3402231
✨
Unable to set the from year to anything before 1900
Active
- functional will still works without patch from that issue.
Won't work:
https://www.drupal.org/project/yearonly/issues/3188139
✨
Allow substraction of years (NOW - x)
Needs review
https://www.drupal.org/project/yearonly/issues/3035638
✨
Allow add extra years (NOW + x)
RTBC
https://www.drupal.org/project/yearonly/issues/3380578
✨
Allow a custom 'To' year
Postponed
I don’t think it's necessary for this issue to provide backward compatibility with all the related ones. Each of those three issues introduced their own additional field settings (yearonly_subtract, yearonly_extra, custom_value), which would only make the functionality more complex, harder to maintain, and more difficult to configure.
Moreover, the functionality from those issues can already be achieved using the features introduced in this one.
I created a new branch 3449436-flexible-ranges-with-tests and merged changes from https://www.drupal.org/project/yearonly/issues/3548622 📌 Introduce tests for module and configure pipelines Active , because it provides tests and a pipeline, which allows tests changes with tests and better review.
vitaliyb98 → made their first commit to this issue’s fork.
I have tested it in 3.1.1 Eva version and it seems to work fine for me.
What was done:
The default field formatter for the link field type already supports a 'target' setting, which is stored as a string. However, currently it can only be configured using the "Open link in new window" checkbox, which sets the target to `_blank`.
I created a new field formatter, "Link with target", based on the default formatter. This new formatter allows selecting any target value, not just through the "Open link in new window" checkbox.
If a link already has a target stored (for example, via the "Link with target" widget), that stored value will take precedence, even if a different target is selected in the field formatter.
This formatter can also be used in Views.
I have included tests in the MR, and I would appreciate it if someone else could review and test it as well.
It seems we also need to update the already stored configuration for the widget.
In my case, the field widget had the following available targets: New window (_blank), Parent window (_parent), and Topmost window (_top).
After applying the fix from this issue (the hook update ran successfully), the add/edit form with the "Link with target" widget only allowed selecting _blank as the target (probably because we changed the keys for parent and top).
P.S. Existing content was updated successfully.
@divya.sejekan, Thank you for reviewing and testing. I've resolved the merge conflict, but will keep the issue in Needs review, hoping that someone else can also verify it.
Configured pipelines, fixed failed pipelines and tests.
Implemented functionality that generates a description based on the available targets selected in the widget settings.
I tried outputting a link that has a saved target using a View with the default View field formatter for links, and in my case, the target is displayed correctly.
The default View field formatter for links has an option called "Open link in new window," which essentially adds target="_blank" to the link. In this case, the only solution I can see is to create a new View field formatter based on the default one. It could replace the "Open link in new window" option with a select list to choose the target, and add a checkbox to force replacing the target already set in the link field.
What do you think about this solution?
In my opinion, this doesn't feel like a fully polished feature yet, at least for now, since it's a bit rough and has limited view functionality. In my case, I'm using it as a patch, but if anyone needs it, or has ideas on what else could be added to support Views, feel free to reach out.
vitaliyb98 → made their first commit to this issue’s fork.
Tested this solution, created an MR with it, and added a Unit test for it.
vitaliyb98 → made their first commit to this issue’s fork.