Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The class used to build the Wizard belongs to the Views (UI) module, so the plugin path needs to be overriden in the domain form wizard plugin declaration.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | domain_views-fix-views_form_wizard-plugin-path-1824914-1.patch | 484 bytes | B-Prod |
Comments
Comment #1
B-Prod CreditAttribution: B-Prod commentedAttached patch fixes the issue.
Comment #2
agentrickardSo this only crashes when Views UI is turned off? We had an existing issue for this. #1716470: Plugin domain of plugin type views_ui:views_wizard points to nonexistent file. I could never replicate the issue.
Comment #3
B-Prod CreditAttribution: B-Prod commentedNo, in my case the Views UI module is enabled. I can't tell you exactly how to reproduce this bug (module upgrade, command line ?) but it exists :-)
Nonetheless the cTools API (on which relies the Views wizard plugins) expects to have a overridden path if the one defined in the plug-in base (so domain_views/plugins/views_wizard in current case) does not contain the class to load. Even if the class belongs to the Views UI module that defines the plug-in type and is in most of the cases already loaded before by another process.
And in your case the "form_wizard_class" is not defined in "domain_views/plugins/views_wizard" but in the Views (UI) module. That's the reason why, to feat the cTools API specifications, the path needs to be overridden for the "form_wizard_class" element of the plug-in.
Comment #4
agentrickardComment #5
agentrickardI never could replicate this. Committed.
Comment #7
Mat77 CreditAttribution: Mat77 commentedWhy is this still not commited to the 1.5 version?
The patch fixed the problem for me.
Comment #8
andros CreditAttribution: andros commentedI just wonder why this is by now still not in a released version? The first entry for this issue was ruffly a year ago, and now there is a patch but it wont get a release.
It's sad to see so many modules on drupal.org suffering from slow to none maintenance at all...
Comment #9
agentrickardYour editorializing is not helping.
This was committed on Nov 2, 2012 and there has not been a release version since. The module is seeking co-maintainers. Are you volunteering?
If so, please open an issue asking to be a co-maintainer.
Comment #10
Exploratus CreditAttribution: Exploratus commentedThanks! Worked.
Comment #11
michielkenis CreditAttribution: michielkenis commentedI too can confirm the patch in #1 is working!
Comment #12
bendev CreditAttribution: bendev commentedalso working for me thanks
Comment #13
manish34jain CreditAttribution: manish34jain commentedPatch works!
Comment #14
aitala CreditAttribution: aitala commentedSeems to work for me too.
Thanks,
Eric
Comment #15
quantos CreditAttribution: quantos commentedOut of the blue, and after at 2-3 years without seeing this error, we've suddenly got the nonexistent file error on two of Domain-managed sites we design/maintain. I'll try the patch but we don't believe anything (any modules) or even a core update has triggered the error (which is connected to an exposed filters (with Better Exposed Filters) block view, so still trying to get to the bottom of this.
Details previously posted to the cTools module - to no avail so far:
https://www.drupal.org/project/ctools/issues/2067997#comment-13377721
I'll report back if the patch fixes our error too - thanks.
Q.
Comment #16
quantos CreditAttribution: quantos commentedPatch seems to have made no difference - but we can't obtain the same error message before either (patched or unpatched) so our problem must lie elsewhere in this case. The problem being our exposed filters (on a View table block with BEF) no longer filter. We'll keep looking - although if anyone has grappled with and solved the same error we would love to hear from you.
Q.