Problem/Motivation
The "cache_form" database table (or cache bin) is well known for being a problem point for heavy-traffic sites or in situations where a form is displayed on every page of the site, such as a login or contact block. The problem is that any form that makes use of the #ajax
form API property will immediately make two entries in the cache_form
table just by viewing the form.
This has lead to run-away tables with millions of entries in some cases. And while more recent solutions like
#2091511: Make cache_form expiration configurable, to mitigate runaway cache_form tables β
attempt to mitigate the problem, they don't solve the underlying issue that the Drupal form system has a database write operation simply upon view of a form.
This issue has already been solved in Drupal 8 through
#2263569: Bypass form caching by default for forms using #ajax. β
.
Proposed resolution
Similar to the Drupal 8 issue, make it so that instead of posting to system/ajax
, AJAX requests by default post to the current page path. This allows the normal form execution to occur in the same way as the non-Ajax approach. Then detect when the form is built (in drupal_get_form()
) if it was done via an Ajax request. If so, process the form normally, but then return the set of Ajax commands directly, ending the page request early.
This eliminates the need for the system/ajax
callback entirely, but it is left in place for backwards-compatibility. This suggested change only affects #ajax usages that use "callback", any usages that leverage "path" will still by default trigger the "cache_form" table to be used.
Remaining tasks
Tests are probably still failing.
User interface changes
None.
API changes
Switches the File module to use #ajax['callback'] instead of #ajax['path'], and in the process eliminates the menu callback at "file/ajax".
Data model changes
None.