Problem/Motivation
When you perform an Ajax operation in a views handler plugin, views stores the value of the form element that triggered the Ajax submission in a temporary_options
property on the ViewExecutable
and, when loading the handler again when (re-)building the form afterwards, the temporary options are used to instantiate that handler, so that you can rely on $this->options
being properly set the correct value.
However, even though HandlerBase::submitTemporaryForm()
attempts to persist the temporary options in the user tempstore, they are never actually stored because when serializing the the view entity, the ViewExecutable
is thrown away so that it will be re-instantiated on-demand after the view has been fetched from cache. With it, the temporary options are thrown away, as well. This seems to be an unintended side-effect of #2252763: Views exposed filter form causes enormous form state cache entries.
Some additional confusion is caused by the fact $temporary_options
is in fact declared on ViewsUI
, but it is actually used on ViewExecutable
including by code in Views module, even though it is only necessary for Views UI. \Drupal\views_ui\Form\Ajax\ConfigHandler::submitForm()
, however, attempts to unset the temporary options on the ViewUI
object, even though those will never be set.
Proposed resolution
?
Steps to reproduce
Proposed resolution
Remaining tasks
Needs Issue Summary update to clarify the problem
Investigate the problem
Comments
Comment #13
quietone CreditAttribution: quietone at PreviousNext commentedThis was a bugsmash issue of the day yesterday and discussed by longwave and lendude.
The consensus what that the Issue Summary doesn't describe the actual fault. So the question is, is this a bug or a task? If the variable is cleared without being used is it actually needed, or is it used in a vary confusing manner? It was decided that diving into the code was needed to take this further.
I am tagging this for an IS update.