5 * Callbacks and hooks related to form system.
9 * @addtogroup callbacks
14 * Perform a single batch operation.
16 * Callback for batch_set().
18 * @param $multiple_params
19 * Additional parameters specific to the batch. These are specified in the
20 * array passed to batch_set().
21 * @param array|\ArrayAccess $context
22 * The batch context array, passed by reference. This contains the following
24 * - 'finished': A float number between 0 and 1 informing the processing
25 * engine of the completion level for the operation. 1 (or no value
26 * explicitly set) means the operation is finished: the operation will not
27 * be called again, and execution passes to the next operation or the
28 * callback_batch_finished() implementation. Any other value causes this
29 * operation to be called again; however it should be noted that the value
30 * set here does not persist between executions of this callback: each time
31 * it is set to 1 by default by the batch system.
32 * - 'sandbox': This may be used by operations to persist data between
33 * successive calls to the current operation. Any values set in
34 * $context['sandbox'] will be there the next time this function is called
35 * for the current operation. For example, an operation may wish to store a
36 * pointer in a file or an offset for a large query. The 'sandbox' array key
37 * is not initially set when this callback is first called, which makes it
38 * useful for determining whether it is the first call of the callback or
41 * if (empty($context['sandbox'])) {
42 * // Perform set-up steps here.
45 * The values in the sandbox are stored and updated in the database between
46 * http requests until the batch finishes processing. This avoids problems
47 * if the user navigates away from the page before the batch finishes.
48 * - 'message': A text message displayed in the progress page.
49 * - 'results': The array of results gathered so far by the batch processing.
50 * This array is highly useful for passing data between operations. After
51 * all operations have finished, this is passed to callback_batch_finished()
52 * where results may be referenced to display information to the end-user,
53 * such as how many total items were processed.
54 * It is discouraged to typehint this parameter as an array, to allow an
55 * object implement \ArrayAccess to be passed.
57 function callback_batch_operation($multiple_params, &$context) {
58 $node_storage = \Drupal::entityTypeManager()->getStorage('node');
59 $database = \Drupal::database();
61 if (!isset($context['sandbox']['progress'])) {
62 $context['sandbox']['progress'] = 0;
63 $context['sandbox']['current_node'] = 0;
64 $context['sandbox']['max'] = $database->query('SELECT COUNT(DISTINCT nid) FROM {node}')->fetchField();
67 // For this example, we decide that we can safely process
68 // 5 nodes at a time without a timeout.
71 // With each pass through the callback, retrieve the next group of nids.
72 $result = $database->queryRange("SELECT nid FROM {node} WHERE nid > :nid ORDER BY nid ASC", 0, $limit, [':nid' => $context['sandbox']['current_node']]);
73 foreach ($result as $row) {
75 // Here we actually perform our processing on the current node.
76 $node_storage->resetCache([$row['nid']]);
77 $node = $node_storage->load($row['nid']);
78 $node->value1 = $options1;
79 $node->value2 = $options2;
82 // Store some result for post-processing in the finished callback.
83 $context['results'][] = $node->title;
85 // Update our progress information.
86 $context['sandbox']['progress']++;
87 $context['sandbox']['current_node'] = $node->nid;
88 $context['message'] = t('Now processing %node', ['%node' => $node->title]);
91 // Inform the batch engine that we are not finished,
92 // and provide an estimation of the completion level we reached.
93 if ($context['sandbox']['progress'] != $context['sandbox']['max']) {
94 $context['finished'] = $context['sandbox']['progress'] / $context['sandbox']['max'];
99 * Complete a batch process.
101 * Callback for batch_set().
103 * This callback may be specified in a batch to perform clean-up operations, or
104 * to analyze the results of the batch operations.
107 * A boolean indicating whether the batch has completed successfully.
109 * The value set in $context['results'] by callback_batch_operation().
111 * If $success is FALSE, contains the operations that remained unprocessed.
113 function callback_batch_finished($success, $results, $operations) {
115 // Here we do something meaningful with the results.
116 $message = t("@count items were processed.", [
117 '@count' => count($results),
120 '#theme' => 'item_list',
121 '#items' => $results,
123 $message .= drupal_render($list);
124 drupal_set_message($message);
127 // An error occurred.
128 // $operations contains the operations that remained unprocessed.
129 $error_operation = reset($operations);
130 $message = t('An error occurred while processing %error_operation with arguments: @arguments', [
131 '%error_operation' => $error_operation[0],
132 '@arguments' => print_r($error_operation[1], TRUE)
134 drupal_set_message($message, 'error');
139 * @} End of "addtogroup callbacks".
148 * Alter the Ajax command data that is sent to the client.
150 * @param \Drupal\Core\Ajax\CommandInterface[] $data
151 * An array of all the rendered commands that will be sent to the client.
153 function hook_ajax_render_alter(array &$data) {
154 // Inject any new status messages into the content area.
155 $status_messages = ['#type' => 'status_messages'];
156 $command = new \Drupal\Core\Ajax\PrependCommand('#block-system-main .content', \Drupal::service('renderer')->renderRoot($status_messages));
157 $data[] = $command->render();
161 * Perform alterations before a form is rendered.
163 * One popular use of this hook is to add form elements to the node form. When
164 * altering a node form, the node entity can be retrieved by invoking
165 * $form_state->getFormObject()->getEntity().
167 * Implementations are responsible for adding cache contexts/tags/max-age as
168 * needed. See https://www.drupal.org/developing/api/8/cache.
170 * In addition to hook_form_alter(), which is called for all forms, there are
171 * two more specific form hooks available. The first,
172 * hook_form_BASE_FORM_ID_alter(), allows targeting of a form/forms via a base
173 * form (if one exists). The second, hook_form_FORM_ID_alter(), can be used to
174 * target a specific form directly.
176 * The call order is as follows: all existing form alter functions are called
177 * for module A, then all for module B, etc., followed by all for any base
178 * theme(s), and finally for the theme itself. The module order is determined
179 * by system weight, then by module name.
181 * Within each module, form alter hooks are called in the following order:
182 * first, hook_form_alter(); second, hook_form_BASE_FORM_ID_alter(); third,
183 * hook_form_FORM_ID_alter(). So, for each module, the more general hooks are
184 * called first followed by the more specific.
187 * Nested array of form elements that comprise the form.
189 * The current state of the form. The arguments that
190 * \Drupal::formBuilder()->getForm() was originally called with are available
191 * in the array $form_state->getBuildInfo()['args'].
193 * String representing the name of the form itself. Typically this is the
194 * name of the function that generated the form.
196 * @see hook_form_BASE_FORM_ID_alter()
197 * @see hook_form_FORM_ID_alter()
201 function hook_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
202 if (isset($form['type']) && $form['type']['#value'] . '_node_settings' == $form_id) {
203 $upload_enabled_types = \Drupal::config('mymodule.settings')->get('upload_enabled_types');
204 $form['workflow']['upload_' . $form['type']['#value']] = [
206 '#title' => t('Attachments'),
207 '#default_value' => in_array($form['type']['#value'], $upload_enabled_types) ? 1 : 0,
208 '#options' => [t('Disabled'), t('Enabled')],
210 // Add a custom submit handler to save the array of types back to the config file.
211 $form['actions']['submit']['#submit'][] = 'mymodule_upload_enabled_types_submit';
216 * Provide a form-specific alteration instead of the global hook_form_alter().
218 * Implementations are responsible for adding cache contexts/tags/max-age as
219 * needed. See https://www.drupal.org/developing/api/8/cache.
221 * Modules can implement hook_form_FORM_ID_alter() to modify a specific form,
222 * rather than implementing hook_form_alter() and checking the form ID, or
223 * using long switch statements to alter multiple forms.
225 * Form alter hooks are called in the following order: hook_form_alter(),
226 * hook_form_BASE_FORM_ID_alter(), hook_form_FORM_ID_alter(). See
227 * hook_form_alter() for more details.
230 * Nested array of form elements that comprise the form.
232 * The current state of the form. The arguments that
233 * \Drupal::formBuilder()->getForm() was originally called with are available
234 * in the array $form_state->getBuildInfo()['args'].
236 * String representing the name of the form itself. Typically this is the
237 * name of the function that generated the form.
239 * @see hook_form_alter()
240 * @see hook_form_BASE_FORM_ID_alter()
241 * @see \Drupal\Core\Form\FormBuilderInterface::prepareForm()
245 function hook_form_FORM_ID_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
246 // Modification for the form with the given form ID goes here. For example, if
247 // FORM_ID is "user_register_form" this code would run only on the user
248 // registration form.
250 // Add a checkbox to registration form about agreeing to terms of use.
251 $form['terms_of_use'] = [
252 '#type' => 'checkbox',
253 '#title' => t("I agree with the website's terms and conditions."),
259 * Provide a form-specific alteration for shared ('base') forms.
261 * Implementations are responsible for adding cache contexts/tags/max-age as
262 * needed. See https://www.drupal.org/developing/api/8/cache.
264 * By default, when \Drupal::formBuilder()->getForm() is called, Drupal looks
265 * for a function with the same name as the form ID, and uses that function to
266 * build the form. In contrast, base forms allow multiple form IDs to be mapped
267 * to a single base (also called 'factory') form function.
269 * Modules can implement hook_form_BASE_FORM_ID_alter() to modify a specific
270 * base form, rather than implementing hook_form_alter() and checking for
271 * conditions that would identify the shared form constructor.
273 * To identify the base form ID for a particular form (or to determine whether
274 * one exists) check the $form_state. The base form ID is stored under
275 * $form_state->getBuildInfo()['base_form_id'].
277 * Form alter hooks are called in the following order: hook_form_alter(),
278 * hook_form_BASE_FORM_ID_alter(), hook_form_FORM_ID_alter(). See
279 * hook_form_alter() for more details.
282 * Nested array of form elements that comprise the form.
284 * The current state of the form.
286 * String representing the name of the form itself. Typically this is the
287 * name of the function that generated the form.
289 * @see hook_form_alter()
290 * @see hook_form_FORM_ID_alter()
291 * @see \Drupal\Core\Form\FormBuilderInterface::prepareForm()
295 function hook_form_BASE_FORM_ID_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
296 // Modification for the form with the given BASE_FORM_ID goes here. For
297 // example, if BASE_FORM_ID is "node_form", this code would run on every
298 // node form, regardless of node type.
300 // Add a checkbox to the node form about agreeing to terms of use.
301 $form['terms_of_use'] = [
302 '#type' => 'checkbox',
303 '#title' => t("I agree with the website's terms and conditions."),
309 * Alter batch information before a batch is processed.
311 * Called by batch_process() to allow modules to alter a batch before it is
315 * The associative array of batch information. See batch_set() for details on
316 * what this could contain.
319 * @see batch_process()
323 function hook_batch_alter(&$batch) {
327 * @} End of "addtogroup hooks".