The default gitlab template has been added to the latest alpha version.
gloryrose6 → made their first commit to this issue’s fork.
I hate to be the bearer of bad news on such a long sought after solution for this, but the patches above do not work for 10.3 (I can't verify for Drupal 9 and below). This is also not an ideal nor practical solution. The getBlockFromAjaxRequest() method that was added does not return the expected results. The block gets a duplicate config key and also returns null on the first ajax request via elementPreRender(). The preBlockBuild() function does not get called still because the ajax architecture only returns the view (the block is a wrapper around the view and does not get updated).
My solution for the client that needed this was as follows:
1. Add Drupal JS settings for views blocks: $build['#attached']['drupalSettings']['viewsBlock'][$this->view->dom_id] = $block->getConfiguration();
2. Add a new method to the views block display and views block plugin to add the settings to the build: alterBlockBuild(ViewsBlock $block, &$build)
3. Add an event subscriber with a that responds to the ViewAjaxResponse response and checks for the block display handler
4. Add an ajax command that responds on ajax and uses the block settings for updating the view
I really think our proposed solution should be changed to something similar to above. This way is much cleaner and follows the ajax workflow mostly with views. Any module that overrides views block settings could then implement their own subscriber and ajax commands with the new viewsBlock drupal settings in the block build.
I spent over 25 hours on this issue, and the only way I could get block settings to update the view, was via drupalSettings on the views block and an ajax command that fires on the response of ViewsAjaxResponse.
I have had this issue with the gdoc_field module which does the same thing that this module does, except for Google Docs. The issue we had ultimately ended up being the .htaccess box that often appears on non-production sites to require a name and password before entering the site. Google and Microsoft can only be accessed 100% publicly, so any .htaccess restrictions that require authentication will prevent documents from showing. I hope this helps anyone debugging errors on their Pantheon and Acquia sites for these modules (gdoc_field and md_viewer).
I went ahead and applied the last patch that cacrody@gmail.com posted (#30) with success. I think we need to find an overall solution to this compatibility issue, as this is a very uncomfortable error that isn't site breaking. How about we add a warning status message and/or a warning log message instead of a php warning error? This will make the warning comfortably yellow while also notifying developers that a change needs to be made. It might also be best to limit this error to certain pages (i.e. status report and available updates). If I have time, I will post a patch including the above changes. I hope we get this resolved, as it is very distracting while developing.
I provided a hotfix patch to prevent site errors for those getting this issue seemingly at random. My client's site was getting this error for anonymous users, so it makes me think that this is a local task caching or dependency issue somewhere (the module uses the LocalTaskDefault class from core for it's local tasks). This patch checks if the route exists before providing the local task in the local task deriver class.
Revised test to only use unflag link without an additional delete button link for testing unflagging
Revision of previous patches with updated functional test.
Revision of previous patch with coding standard revisions for tests.
Attached patch to add the delete form route as the 'unflag' link action option for Field Entry forms in the method 'FieldEntry::getUrl'
gtucker6 → created an issue.