🇺🇸United States @coupertrouper

#6 led me down the right path and #8 led me to the correct file. I had a similar issue when trying to save permissions (and I can also confirm that #9 is true... can't save permissions with the stale permissions stuck in the config).

I had a Paragraph type that I had created a few weeks ago then recently deleted because I didn't need it any more. The permissions tied to that Paragraph type were still in the config. I'm assuming that patch that others have provided solves this issue? I haven't applied the patch yet though. I just edited the necessary .yml files manually (luckily I hadn't created all of my user roles yet so only had to edit 'config/sync/user.role.admin.yml').

My scenario (running D10.2.2):

1. Went to do a permissions audit on my site prior to launch
2. Checked through my admin permissions, checked boxes where appropriate
3. Saved
4. Encountered a big ugly Drupal error screen indicating the permissions. Error message looked like: "RuntimeException: Adding non-existent permissions to a role is not allowed."
5. Googled... found this thread
6. Located my config/sync/user.role.admin.yml file and removed the necessary permissions (just did a ctrl-F for those permissions that were in the big ugly Drupal error and deleted them, then saved the file)
7. Cleared Drupal cache
8. Tried to save the permissions again... got the error again
9. Did a 'drush cim' and accepted the changes
10. Did a 'drush cr' then checked the permissions again on the Admin role for other stuff I needed grant the Admin role
11. Saved successfully

I'm not advanced enough to know how to apply a patch but can go the manual route. Hopefully the patch alleviates the need to do it manually in the future

Just commenting here to let others know that @srdtwc's solution worked for me. With YML files, from my understanding, syntax is really important otherwise they won't work correctly.

In @Ryanm81's code, everything under "theme" needs to be indented one more time so that it matches @srdtwc's example.

After implementing the 'libraries-override' bit in my theme's mytheme.libraries.yml file, all styling was basically removed that comes with CKEditor Accordion and I was able to add my own styles, bit by bit.

I'm not sure if this is sustainable longterm because if the module changes, my CSS will probably break. But until then... this will have to do in my case.

@Ryanm81, hopefully you were able to override it successfully!

Just to follow up here for the sake of brevity...

I ended up abandoning my attempt at creating a views twig template file ("views-view--block_1.html.twig" above) in favor or using the views interface and overwriting the output using a Global: Custom text field. I don't like relying on the interface for stuff like this but I couldn't figure out another way even after hours and hours of Googling. I like having my template related stuff neatly contained in tpl files but I think I'll just have to make an exception here.

Maybe it's just too many layers deep within Drupal's data to create a template without some fancy PHP functions.

This worked for me: {{ view.field.field_name.original_value }}

I'm not sure what the "original_value" is and I'm not familiar with the array that views spits out for Twig to interpret but it worked. Usually, in non-view Twig templates like node.html.twig, the thing that is the original value is captured with the ".0" at the end. I tried that but it didn't do anything in my view's Twig template.

I'm sure this is in the documentation somewhere but it's not easy to find for us non-programmer designer/front-end dev types.

Thanks @lrous for the easy to copy/paste syntax.