/** * Respond to a custom menu deletion. * * This hook is used to notify modules that a custom menu along with all links * contained in it (if any) has been deleted. Contributed modules may use the * information to perform actions based on the information entered into the menu * system. * * @param $menu * An array representing a custom menu: * - menu_name: The unique name of the custom menu. * - title: The human readable menu title. * - description: The custom menu description. * * @see hook_menu_insert() * @see hook_menu_update() */ function hook_menu_delete($menu) { // Delete the record from our state setting. $my_menus = state_get('my_module_menus', array()); unset($my_menus[$menu['menu_name']]); state_set('my_module_menus', $my_menus); }
<?php /** * @file * Handles incoming requests to fire off regularly-scheduled tasks (cron jobs). */ /** * Defines the root directory of the Backdrop installation. * * The dirname() function is used to get path to Backdrop root folder, which * avoids resolving of symlinks. This allows the code repository to be a symlink * and hosted outside of the web root. See issue #1297. */ define('BACKDROP_ROOT', dirname(dirname($_SERVER['SCRIPT_FILENAME']))); // Change the directory to the Backdrop root. chdir(BACKDROP_ROOT); include_once BACKDROP_ROOT . '/core/includes/bootstrap.inc'; backdrop_bootstrap(BACKDROP_BOOTSTRAP_FULL); if (!isset($_GET['cron_key']) || state_get('cron_key') != $_GET['cron_key']) { watchdog('cron', 'Cron could not run because an invalid key was used.', array(), WATCHDOG_NOTICE); backdrop_access_denied(); } elseif (state_get('maintenance_mode', FALSE)) { watchdog('cron', 'Cron could not run because the site is in maintenance mode.', array(), WATCHDOG_NOTICE); backdrop_access_denied(); } else { backdrop_cron_run(); }
/** * Asserts that the most recently sent e-mail message has the given value. * * The field in $name must have the content described in $value. * * @param $name * Name of field or message property to assert. Examples: subject, body, id, ... * @param $value * Value of the field to assert. * @param $message * Message to display. * * @return * TRUE on pass, FALSE on fail. */ protected function assertMail($name, $value = '', $message = '') { $captured_emails = state_get('test_email_collector', array()); $email = end($captured_emails); return $this->assertTrue($email && isset($email[$name]) && $email[$name] == $value, $message, t('E-mail')); }
/** * Return an array of tasks to be performed by an installation profile. * * Any tasks you define here will be run, in order, after the installer has * finished the site configuration step but before it has moved on to the * final import of languages and the end of the installation. This is invoked * by install_tasks(). You can have any number of custom tasks to perform * during this phase. * * Each task you define here corresponds to a callback function which you must * separately define and which is called when your task is run. This function * will receive the global installation state variable, $install_state, as * input, and has the opportunity to access or modify any of its settings. See * the install_state_defaults() function in the installer for the list of * $install_state settings used by Backdrop core. * * At the end of your task function, you can indicate that you want the * installer to pause and display a page to the user by returning any themed * output that should be displayed on that page (but see below for tasks that * use the form API or batch API; the return values of these task functions are * handled differently). You should also use backdrop_set_title() within the task * callback function to set a custom page title. For some tasks, however, you * may want to simply do some processing and pass control to the next task * without ending the page request; to indicate this, simply do not send back * a return value from your task function at all. This can be used, for * example, by installation profiles that need to configure certain site * settings in the database without obtaining any input from the user. * * The task function is treated specially if it defines a form or requires * batch processing; in that case, you should return either the form API * definition or batch API array, as appropriate. See below for more * information on the 'type' key that you must define in the task definition * to inform the installer that your task falls into one of those two * categories. It is important to use these APIs directly, since the installer * may be run non-interactively (for example, via a command line script), all * in one page request; in that case, the installer will automatically take * care of submitting forms and processing batches correctly for both types of * installations. You can inspect the $install_state['interactive'] boolean to * see whether or not the current installation is interactive, if you need * access to this information. * * Remember that a user installing Backdrop interactively will be able to reload * an installation page multiple times, so you should use state_set() and * state_get() if you are collecting any data that you need to store and * inspect later. It is important to remove any temporary variables using * state_del() before your last task has completed and control is handed * back to the installer. * * @param array $install_state * An array of information about the current installation state. * * @return array * A keyed array of tasks the profile will perform during the final stage of * the installation. Each key represents the name of a function (usually a * function defined by this profile, although that is not strictly required) * that is called when that task is run. The values are associative arrays * containing the following key-value pairs (all of which are optional): * - display_name: The human-readable name of the task. This will be * displayed to the user while the installer is running, along with a list * of other tasks that are being run. Leave this unset to prevent the task * from appearing in the list. * - display: This is a boolean which can be used to provide finer-grained * control over whether or not the task will display. This is mostly useful * for tasks that are intended to display only under certain conditions; * for these tasks, you can set 'display_name' to the name that you want to * display, but then use this boolean to hide the task only when certain * conditions apply. * - type: A string representing the type of task. This parameter has three * possible values: * - normal: (default) This indicates that the task will be treated as a * regular callback function, which does its processing and optionally * returns HTML output. * - batch: This indicates that the task function will return a batch API * definition suitable for batch_set(). The installer will then take care * of automatically running the task via batch processing. * - form: This indicates that the task function will return a standard * form API definition (and separately define validation and submit * handlers, as appropriate). The installer will then take care of * automatically directing the user through the form submission process. * - run: A constant representing the manner in which the task will be run. * This parameter has three possible values: * - INSTALL_TASK_RUN_IF_NOT_COMPLETED: (default) This indicates that the * task will run once during the installation of the profile. * - INSTALL_TASK_SKIP: This indicates that the task will not run during * the current installation page request. It can be used to skip running * an installation task when certain conditions are met, even though the * task may still show on the list of installation tasks presented to the * user. * - INSTALL_TASK_RUN_IF_REACHED: This indicates that the task will run on * each installation page request that reaches it. This is rarely * necessary for an installation profile to use; it is primarily used by * the Backdrop installer for bootstrap-related tasks. * - function: Normally this does not need to be set, but it can be used to * force the installer to call a different function when the task is run * (rather than the function whose name is given by the array key). This * could be used, for example, to allow the same function to be called by * two different tasks. * * @see install_state_defaults() * @see batch_set() * @see hook_install_tasks_alter() * @see install_tasks() */ function hook_install_tasks(&$install_state) { // Here, we define a variable to allow tasks to indicate that a particular, // processor-intensive batch process needs to be triggered later on in the // installation. $myprofile_needs_batch_processing = state_get('myprofile_needs_batch_processing', FALSE); $tasks = array('myprofile_data_import_form' => array('display_name' => st('Data import options'), 'type' => 'form'), 'myprofile_settings_form' => array('display_name' => st('Additional options'), 'type' => 'form'), 'myprofile_batch_processing' => array('display_name' => st('Import additional data'), 'display' => $myprofile_needs_batch_processing, 'type' => 'batch', 'run' => $myprofile_needs_batch_processing ? INSTALL_TASK_RUN_IF_NOT_COMPLETED : INSTALL_TASK_SKIP), 'myprofile_final_site_setup' => array()); return $tasks; }
// ------------------------------------------------------------ // Call the daily and weekly processing tasks as needed. // ------------------------------------------------------------ $now = time(); // Figure out if it's been 24 hours since our last daily processing. if (state_get('project_usage_last_daily', 0) <= $now - PROJECT_USAGE_DAY) { project_usage_process_daily(); state_set('project_usage_last_daily', $now); } // We can't process the weekly data until the week has completed. To see if // there's data available: determine the last time we completed the weekly // processing and compare that to the start of this week. If the last // weekly processing occurred before the current week began then there should // be one (or more) week's worth of data ready to process. $default = $now - config_get('project_usage.settings', 'life_daily'); $last_weekly = state_get('project_usage_last_weekly', $default); $current_week_start = project_usage_weekly_timestamp(NULL, 0); if ($last_weekly <= $current_week_start) { project_usage_process_weekly($last_weekly); state_set('project_usage_last_weekly', $now); // Reset the list of active weeks. project_usage_get_active_weeks(TRUE); } // Wipe the cache of all expired usage pages. cache('project_usage')->flush(); /** * Process all the raw data up to the previous day. * * The primary key on the {project_usage_raw} table will prevent duplicate * records provided we process them once the day is complete. If we pull them * out too soon and the site checks in again they will be counted twice.
// Timestamp for beginning of the oldest available data. $oldest_time = (int) db_query("SELECT MIN(timestamp) FROM {project_usage_raw}")->fetchField(); $oldest_day_end = project_usage_daily_timestamp($oldest_time, 1); $daily_timestamp = project_usage_daily_timestamp($oldest_time); // Process all days up until the current one. while ($daily_timestamp < $start_of_current_day) { project_usage_process_daily($daily_timestamp); // Increment the timestamp to the next day. $daily_timestamp = project_usage_daily_timestamp($daily_timestamp, 1); } state_set('project_usage_last_daily', $daily_timestamp); $tables_updated = TRUE; } // Process the weekly data up until the current week. Data for the current // (partial) week is not calculated. $last_processed_weekly_timestamp = state_get('project_usage_last_weekly', REQUEST_TIME - PROJECT_USAGE_YEAR); $start_of_current_week = project_usage_weekly_timestamp(); if ($last_processed_weekly_timestamp < $start_of_current_week) { // Start with the week following last processed one. $next_weekly_timestamp = project_usage_weekly_timestamp($last_processed_weekly_timestamp, 1); // Process all weeks up until the current one. while ($next_weekly_timestamp < $start_of_current_week) { // Increment the timestamp to the next week. $last_weekly_timestamp = $next_weekly_timestamp; $next_weekly_timestamp = project_usage_weekly_timestamp($last_weekly_timestamp, 1); project_usage_process_weekly($last_weekly_timestamp); state_set('project_usage_last_weekly', $last_weekly_timestamp); } // Reset the list of active weeks. project_usage_get_active_weeks(TRUE); $tables_updated = TRUE;