beta10 never got released apparently; can't pull it in via Composer or see it on the module page.
Here's a patch in case anyone else needs to get by without for now.
Still an issue in 8.x-1.6 ... in fact, it doesn't even work after a second save. I can't get this to work at all.
This other old task, which was postponed: https://www.drupal.org/project/entity_embed/issues/3060397 → seems to imply that you used to be able to edit in both the dialog pop-up and directly in the WYSIWYG, but the latter isn't even possible now by the looks of it. There's no interacting with the caption outside of the dialog.
Tagged multiple other issues about the same subject. I'm kind of amazed they've sat around this long without activity (but, I'm just now getting around to CKEditor5...).
To anyone still coming across this... I was able to fix the problem by reordering my "filter processing order".
Specifically, if you have "Limit allowed HTML tags and correct faulty HTML" enabled, then it must come before "Align images" and "Caption images". Looking at the filter details, I think the problem is that the IMG element allows all the needed "data-" attributes for align/caption, but does not allow the "class" attribute. So you don't want to convert the data- attributes to classes and then get them stripped out.
If for some reason you have to bypass this instead of reordering you could probably add to your manually editable tags, but I doubt that's right for most scenarios. If you have any other data-* filters to process, they should probably go after the HTML filter too.
TLWatson → created an issue.
TLWatson → created an issue.
Rewrote the patch from #2372173. I couldn't quite take the simplified route that was done in 7.x upstream, because the view rendering did not respect exposed filters just being "not exposed" anymore; the user inputs weren't actually in those filters' values.
The approach I did was to cycle through all the filters, look for provided exposed filter values, and implement them. I don't promise it to be foolproof since there isn't any standard sort of "setValue" method, we're just toying with arrays; but for my purposes it works for references and text (direct assignment of ['value']), and dates (if ['value'] is array, set ['value']['value']). Hopefully there is a more foolproof way out there to assign values.
TLWatson → created an issue.
For anyone else trying to do this, yes it's possible with Custom Text. First make sure that the fields are currently outputting a Twig-readable date format (the HTML full date/time worked best for me). Then use the date filter to convert to UTF format, so Twig knows what it's doing "math" on. Like:
{{ field_cp1_time_out|date('U') - field_cp1_time_in|date('U') }}
What you'll get here is a UTF-dated value difference in seconds. You can then reformat it back to whatever you want with the date filter, such as minutes / seconds:
{{ (field_cp1_time_out |date('U') - field_cp1_time_in|date('U'))|date('i:s') }}
I tend to write this out in a longer form in the view to make it more legible, but there's the gist of it. You may have to specify timezone if it's not cooperating.
Rerolled #5 patch.
Duplicate of https://www.drupal.org/project/bibcite/issues/3323887 →
A patch for citeproc is in that issue.
Attaching reroll of patch for version 8.x-2.0-beta8.
This patch does get the page working again, but I still get some trailing cruft in the URL that sticks around via the "q" parameter. This stacks if, say, I click on a couple facets to get the q parameter, press the reset/clear button on the Facets Summary or un-check all the selections (at which point we see the "q" parameter is still there), then start making new selections.
+1 to patch #29 as a solution; I am using this.
Note in addition to applying this patch, I needed to follow the README instructions of adding the citation-style-language/locales package to my composer repositories list, and then run `composer require citation-style-language/locales seboettg/citeproc-php`. (I also had to make sure that the 'intl' extension was installed in global PHP, in order to get a new enough version of seboettg/citeproc-php to resolve all the PHP 8.1 errors.)
Hopefully if/when this patch gets merged in, we shouldn't have to run `composer require`, as this ought to handle its own composer requirements... but it's necessary for now, so hopefully this comment helps someone else wanting to patch.