Available on Current Domain doesn't instantiate

What version of PHP is this? What version of Drupal?

Drupal 10.0.9 and PHP 8.1.20 - thanks fer' askin!

This looks like strict type checking for two parameters that were added in Drupal 10.

Sounds good to me - thanks for the response!

UPDATE: If you try invoking on all displays in a given view, it instanciates on only the targeted view and content fails to display. If you invoke on individual displays, though, it seems to work fine.

I'll take it. Thanks!

Patch #4 fixed the issue.

Patch #4 works for me.

Confirm it as RTBC. Apart from that a notice of importance: in circumstances it can become a deal-beaker for updating Drupal from 9 to 10 since the database update required will trigger this issue and break the final db update. Applying the patch and re-trying to update database after core and modules update runs complete without flaws. 1+ for this issue fixed so quickly!

+1 for RTBC fixed problems with D10 upgrade

+1 RTBC

While patch #4 works fine, I think we don't need to re-declare properties again.
Updating patch, hope it works!

I needed patch #15 in order to get it run after Drupal 10 Upgrade.
Patch #4 is also working.

The two patches need to be reconciled, since #15 is actually a different issue.

Tested on Drupal 10.1.6 after upgrade from Drupal 9.5.11 and patch #4 worked
Php version 8.1.18
10.3.27-MariaDB
nginx/1.17.10

Both patches will work fine.
#4 was created before base class is updated
#15 is created after base class is updated

So as per latest base class change we need patch #15, we don't need to re-declare base class properties.

I'm looking for one clean patch.

I see the problem.

https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/modules/view...
https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/modules/vie...

This was fixed in Drupal core, v 10.x (patch 15). If we commit that, we may break BC with Drupal 9.5, which does not have that (patch 4).

I think the best option is to commit #15. But that might throw some warnings on PHP 8.2 / Drupal 9.5. Not sure we can do anything about that.

Hello.
+1 RTBC for patch #14 and MR !56 on Drupal 10.

Thanks for all the work in here. But - Please do not review your own work. First of all patches and merges should be made against latest dev. Second, there are no further comments if anything of #20 & #21 has been addressed yet. Also I would like to read opinions if the attempts here overlap somehow with: 🐛 Fatal error: Type $value_value must be string DomainAccessCurrentAllFilter.php on line 0 RTBC

I'll try to summarize the current status.

I'm hiding the patches to avoid confusion going forward.

The current MR just applies the patch from #15 and moves it into a MR. That should address #20 "one clean patch." I'm assuming that the comment meant one clean patch/MR, but if it literally meant "patch," then my apologies for muddying the issue.

RE: #21 I agree with this. It might throw warnings (on EOL D9), but it shouldn't break things.

I think the best option is to commit #15. But that might throw some warnings on PHP 8.2 / Drupal 9.5. Not sure we can do anything about that.

RE: #24, you're right, this issue definitely overlaps with 3413610. It's the same problem, and they addressed it in the same way as #4 in this issue.

I'm closing the other as a duplicate.

I've successfully used the MR so I'm setting to RTBC.

added a fix for an error in the same file during a D 10.3 update but there is also the same fix in 3456123

should I revert my commit ?

reverted my commit to keep thing sepperate

This needs a refactor against 2.0.x

https://git.drupalcode.org/project/domain/-/merge_requests/85 is ready.

This was fixed in Drupal core, v 10.x (patch 15). If we commit that, we may break BC with Drupal 9.5, which does not have that (patch 4).

I think the best option is to commit #15. But that might throw some warnings on PHP 8.2 / Drupal 9.5. Not sure we can do anything about that.

In this case (#21), the best solution is to use a separate main tag to ensure backward compatibility.

The main problem is the changed scope of the options method. If we remove the override of this method in the filter, we can forget about the backward compatibility issue.

The interface difference is small and may be worth ignoring to forget about the backward compatibility issue at this point:

• with override
• with override

However, MR 85 looks good to me

The problem with the operator selection is that the query does not support the "!=" option. Therefore, "=" must always be selected.

Now I wonder if this causes any changes to configuration of existing views.

Testing.

This threw an error on 10.3.

Object { message: "\nAn AJAX HTTP error occurred.\nHTTP Result Code: 200\nDebugging information follows.\nPath: /admin/structure/views/ajax/add-handler/duplicate_of_content/page_1/filter\nStatusText: parsererror\nResponseText: \nFatal error:  Access level to Drupal\\domain_access\\Plugin\\views\\filter\\DomainAccessCurrentAllFilter::operators() must be public (as in class Drupal\\views\\Plugin\\views\\filter\\BooleanOperator) in /var/www/html/web/modules/contrib/domain/domain_access/src/Plugin/views/filter/DomainAccessCurrentAllFilter.php on line 22", name: "AjaxError", stack: "@https://example.local/sites/default/files/js/js_CvjJwztkp7NtVTxtZWNJm8stD9baau_A9bcQr6PPVOw.js?

Investigating.

I have updated MR 85 to use a public method for function operators().

This should be RTBC; Drupal 9 support was dropped last year.

https://www.drupal.org/docs/understanding-drupal/drupal-9-release-date-a... →

Merged

Automatically closed - issue fixed for 2 weeks with no activity.

Patch for the current 2.0.0-beta1, awaiting the next release.

ash2303 → closed merge request !56