🇺🇦Ukraine @vitaliyb98

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.

Fixed, thanks!

@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.

Added new functionality and provided tests for it.

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.

Provided test for the new functional

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.

vitaliyb98 → created an issue.

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.

Hi, I'm interested in helping as a co-maintainer. For example,
I can assist with reviewing issues and adding test coverage. As a reference, I've already provided basic test coverage for the main functionality: https://www.drupal.org/project/epp/issues/3547247 📌 Introduce test coverage for existing functionality Active

Merged https://www.drupal.org/project/yearonly/issues/3548622 📌 Introduce tests for module and configure pipelines Active into this task to have pipelines configured.

vitaliyb98 → created an issue.

vitaliyb98 → created an issue.

Hi @alae.akalay

I tried to reproduce your issue with core versions: 11.2.2 and 10.5. But without success.

Could you please check if my reproduced instructions are correct? Maybe I missed some important step for reproducing?

1. Enabled the Permission by Term module.
2. In the Article content type, added the field field_tags (Entity reference: Taxonomy term, Vocabulary: Tags).
3. Created two terms in the Tags vocabulary: Test 1 and Test 2.
4. Created a Viewer role without any permissions.
5. Created a Taxonomy Editor role and granted permissions to: View/edit/delete any article, Create/edit/delete terms and Administer vocabularies and terms
6. Created an Article node with the tag Test 1.
7. On the Test 1 tag, assigned the allowed role Taxonomy Editor.
8. Verified that a user with the Taxonomy Editor role can view and edit the node created in step 6.
9. Added Viewer and Authenticated user to the allowed roles for the Test 1 tag.
10. Logged in as a user with the Viewer role, opened the node from step 6 — user had view access but not edit access.

vitaliyb98 → created an issue.

I would appreciate it if someone else could also test this solution.

Merged into 8.x-1.x, thanks

vitaliyb98 → created an issue.

If this problem really exists, it should be fixed on the core level https://www.drupal.org/project/drupal/issues/3362740 🐛 renderPager() in DisplayPluginBase.php always return TRUE Needs work

Hi @kevin w,
I investigated this issue, and I have also taken into account your other issue related to this problem: https://www.drupal.org/project/drupal/issues/3362740 🐛 renderPager() in DisplayPluginBase.php always return TRUE Needs work

First, I tried to reproduce the issue using a combination of EVA and Search API. I configured an indexed entity rendered as full HTML, which included an EVA attachment. Indexing it manually or via cron did not produce any errors.

I also debugged the functionality and analyzed the potential improvements if the patch changes were applied. In this case, it only reduces the execution of $exposed_input = $view->getExposedInput();, which is unlikely to significantly improve performance. Therefore, I believe that changes in public function renderPager() should be made at the core level.

If this issue is still relevant to you, could you please provide more detailed steps how to reproduce it?

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

vitaliyb98 → created an issue.

Added functional and kernel tests.

I merged https://www.drupal.org/project/views_ajax_history/issues/3547650 📌 Add .gitlab-ci.yml to run gitlab pipelines Needs review into this task to have ability execute pipelines with tests.

vitaliyb98 → created an issue.

Hello @manthan.chauhan, сould you please describe in more detail which problem you want to fix and include step-by-step reproduction steps? I applied your patch and saw two potential issues:

1. When I perform an AJAX submit for filters, addState is called twice: once in Drupal.Ajax.prototype.beforeSerialize = function (element, options) and again in Drupal.Ajax.prototype.beforeSubmit = function (form_values, element, options), thats looks incorrect.
2. When I navigate pagination, the URL passed into addStateno longer contains the &page=1 param in the URL, but before this fix, it had it.

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

Added GitLab pipelines and fixed the cspell pipeline.

Hi @lostcarpark, could you please provide some instructions for testing, which will help people to test it?

vitaliyb98 → created an issue.

Adjusted changes in the MR according to the last changes from 8.x-1.x and fixed the MR conflict.

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

Tested these changes, worked on my side, also moved changes from the patch to the MR.

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

I'd appreciate it if someone else could test this as well.

I'd appreciate it if someone else could test this as well.

Could someone else also test this solution?

Added functional test to cover main functionality

Hello,

Could you please provide more details about how to reproduce the issue? Also, could you double-check that you don’t have any custom changes in the module code locally? Based on your other issue ( https://www.drupal.org/project/permissions_by_term/issues/3547522 🐛 PHP Fatal error - AI modules installed Active
), it looks like there might be additional modifications in your local copy of the module.

On my side, I re-tested the scenario and confirmed the following steps:
1. Installed the module.
2. Configured access for nodes via taxonomy.
3. Verified that certain users did not have access.
4. Uninstalled the module. node permissions were rebuilt.
5. Node access returned to match the original configuration.

Hi, it looks like you have some local changes in the module. The file var/www/html/web/modules/contrib/permissions_by_term/src/Entity/Config/AutomatorPluginDeriver.php does not belong to this project.

I merged changes from https://www.drupal.org/project/epp/issues/3349197 📌 Add a proper test Active into this task, to verify that tests passed correctly, the tests pipeline should be configured properly.

Thank you!

Thanks for the review! I’d really appreciate it if you could assign credits)

There is a similar issue described at https://www.drupal.org/project/html_title/issues/3537729 🐛 Error within views plugin renderText method Active with steps to reproduce and covered with functional tests. This fix covers both scenarios: when link_to_entity is disabled and when it is enabled.

Issue with $this->options['settings']['link_to_entity'] === TRUE was fixed in https://www.drupal.org/project/html_title/issues/3547205 🐛 Bug with "Link to the Content" option on node_html_title view field Active

It would be great if someone could review this as well.

Merged into 8.x-1.x, thanks

Merged into 8.x-1.x, thanks

When I followed all the steps described in the issue, I was able to reproduce it. However, in this case the Token module was not installed, and the [current-page] token is not available by default.

So, if the Token module was not installed in your setup, that would explain why pre-population failed. After enabling the Token module, pre-population started working correctly.

If the Token module was already enabled on your site, please provide more detailed instructions on how to reproduce the issue, along with the Drupal core version you are using.

vitaliyb98 → created an issue.

I also enabled:

  OPT_IN_TEST_PREVIOUS_MAJOR: 1
  OPT_IN_TEST_MAX_PHP: 1
  OPT_IN_TEST_PREVIOUS_MINOR: 1
  OPT_IN_TEST_NEXT_MINOR: 1
  OPT_IN_TEST_NEXT_MAJOR: 1

As this module widely supported by ^8.7.7 || ^9 || ^10 || ^11

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

vitaliyb98 → created an issue.

This issue could not be reproduced on a "fresh install" without other modules. However, one possible cause is the order in which hook_preprocess_breadcrumb functions are executed. In this module, html_title_preprocess_breadcrumb is hardcoded to run after all other preprocess functions.

As a result, this problem can occur if a contributed module or custom code does something like the following:

function boo_preprocess_breadcrumb(&$vars) {
  $vars['breadcrumb'] = NULL;
}

In my opinion, committing this fix will improve the stability of the module.

I’ve tested this fix on my project, and it works correctly with Drupal 11.2. It would be great to include it in the next release.

Tested this fix, added schema for new field formatter, cover it with functional test.

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

This issue is still relevant. While it can be avoided by enabling "Require this relationship" on the relationship, I recommend applying this fix to prevent unnecessary errors.

I’ve also added a test to cover this fix.

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

At first, I tried to move each hook into a separate service (separate file). However, I noticed that our hooks don’t contain much code, so the benefit would be minimal. I also saw that in core, hooks are usually kept in a single file, and only large ones with many dependencies on other services are separated. So I split only hook and theme hook into separate files.

Also:

Object oriented hooks are fully supported in Drupal 11, but there are backwards compatible using the #[LegacyHook], but only as far as 10.1, as that they require service autowiring, which was introduced in that branch.

version 4.x requires core ^10.2

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

vitaliyb98 → created an issue.

vitaliyb98 → created an issue.

Hi, this issue is still relevant. The solution provided in the patch is very close to the core view template, so I believe it's safe. However, for some reason, the {{ pager }} was removed in the patch.

I've submitted a merge request with the fix and also added a functional test.

vitaliyb98 → changed the visibility of the branch 3111965-rendering-empty-text to hidden.

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

Committed and pushed to 3.1.x-dev Thanks!

I extended the existing kernel test to cover the case of state label translations.