🇨🇦Canada @jodavidson

jodavidson → created an issue.

Thanks @scott_euser.

If I understand the summary notes. I create a basically empty custom module that really only has the hook_views_data_alter() snippet in its MODULE.module file. And the patch should take effect once the custom module is activated?

Hello all,

With all the twists and turns this issue has taken I wonder if there is a current solution to getting the Settings option back in place for exposed entity reference filters?

For 10.2.7 the patch here: https://www.drupal.org/files/issues/2021-12-02/2429699-453-9.3.x.patch → worked well. In 10.3.1 I've made a local patch from MR !4053 mergeable (above) and applied it. Unfortunately it does not return the Settings option. Looking at the past few comments maybe it is not supposed to by itself?

Reading through these issue chains is pretty confusing for me, (and many others I imagine,) so I thought it best to ask for some clarification. Personally my site is frozen at 10.2.7 until there is a solution for this issue.

Thanks for your time and work on this issue, it sure looks like a big can of worms that has existed since D8.

After applying the patch of #7 (which fixed the 'type' issue, well done.) I found this error:

Warning: Undefined array key "value" in Drupal\views\Plugin\views\filter\Date->acceptExposedInput() (line 153 of /var/www/html/web/core/modules/views/src/Plugin/views/filter/Date.php)

Looking into the code it seems that $operators[$operator]['values'] can be 1 without $this->value['value'] being set.

Perhaps we can add an isset test to the if statement in this block like:

if (!isset($this->value['value']) || $this->value['value'] == '') {
    return FALSE;
}

I'm suggesting this as a todo for you, as you already have the code and the existing patch available to you for tweaking. If it's preferable for me to try putting the combined patch together I can give it a shot. I hope this isn't too much of an imposition on your time.

Ultimately this issue was created by a local patch introduced to our site by a contractor. I'll be fixing this locally.

We recommend checking your configs for any containers created in the old version of the module and try removing those config files, then re-import.

Daniel, that seems reasonable. I've reverted to get things going again (marketing gets a little huffy when their tracking isn't working.)

I'll give it a go on a dev site and report back. If this is the fix the doumentation should be updated to note the process.

Closing as I subsequently discovered another part of the view which was overriding the obvious setting.

jodavidson → created an issue.

jodavidson → created an issue.

Giving this a test using the plain diff as a patch. In Drupal 9.5.9 with CKeditor5 enabled the Special Chars does not appear in the plugins area of the Text Format configuration as it does with CKeditor4.

I may be missing something in the implementation, and there may not yet be enough mods for it to work, but I thought you'd appreciate the feedback.

Unfortunately my coded editor respected the Symfony standard rather than the Drupal one. Oops. Fixed and re-pushed.

This seems like a situation that should be handled in the custom hook. If something goes wrong during the update/install process that process should be rolled back. Ie, the module that is being installed should then be uninstalled. Unless I'm missing something.

Confirmed that TypedDataManager::createInstance() does not gracefully handle the missing name and parent parameters.

Added some code to set those elements of the array if not present.

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

Unfortunately I have not been able to create a situation where this code fires and a .htaccess file is created so testing is still required.

Looking at the crucial method writeFile($directory, $filename, $contents, $force) the code as included in the #42 patch is complete.

All cases are handled and the method will always return a boolean. The additional tests from #34 ((file_exists($directory) && is_writable($directory)) are implied in the @file_put_contents() call.

This should work fine as written.

I'm now looking at how to efficiently test that it is indeed working in the DrupalPod environment.

Going to take a swing at this one at the Mentored Contribution session at DrupalCon2023 Pittsburgh

I'm having similar issues, but it happens only for one user at a time with no warning on various pages. Clearing caches does nothing, I need to use the "Drastic Measures" option in the AdVAgg Operations panel to rebuild all the files to fix the issue.

I've successfully implemented the patch from #100 for 4.0.3 on Drupal 9.5.5 PHP 8.1.13

Great work @hanoii

Confirmed what @heddn said in #5. The jquery_ui_accordion was stuck at version ^1.0 in composer.json. Updating that entry to

"drupal/jquery_ui_accordion": "^2.0",

allowed the views_accordion update to proceed.

This necessary step should be noted in the release notes.