An interface for condition plugins.
Knowing how to clear Drupal's cache is an important skill for any developer. You'll likely find yourself doing it frequently in order to get Drupal to register the changes you make to your code, or other updates you make via the UI. It is also a good first step to trouble shooting problems with your Drupal site: Clear the cache before you do any other debugging to ensure it's not just a bad. Oct 16, 2020 configuration — these have cache tags of the form config: custom (for example libraryinfo) Drupal provides cache tags for entities & configuration automatically — see the Entity base class and the ConfigBase base class. (All specific entity types and configuration objects inherit from those.).
Condition plugins are context-aware and configurable. They support the following keys in their plugin definitions:
- context: An array of context definitions, keyed by context name. Each context definition is a typed data definition describing the context. Check the typed data definition docs for details.
- configuration: An array of configuration option definitions, keyed by option name. Each option definition is a typed data definition describing the configuration option. Check the typed data definition docs for details.
@todo Replace the dependency on DrupalCoreFormFormInterface with a new interface from https://www.drupal.org/node/2006248. @todo WARNING: The condition API is going to receive some additions before release. The following additions are likely to happen:
- The way configuration is handled and configuration forms are built is likely to change in order for the plugin to be of use for Rules.
- Conditions will receive a data processing API that allows for token replacements to happen outside of the plugin implementations, see https://www.drupal.org/node/2347023.
- Conditions will have to implement access control for checking who is allowed to configure or perform the action at https://www.drupal.org/node/2172017.
Hierarchy
- interface DrupalCoreExecutableExecutableInterface; interface DrupalCorePluginPluginFormInterface; interface DrupalComponentPluginConfigurablePluginInterface; interface DrupalComponentPluginPluginInspectionInterface; interface DrupalCoreCacheCacheableDependencyInterface
- interface DrupalCoreConditionConditionInterface
See also
DrupalCoreTypedDataTypedDataManager::create()
Related topics
Drupal Cache Form Template
Namespace
DrupalCoreConditionMembers
| Name | Modifiers | Type | Description |
|---|---|---|---|
| CacheableDependencyInterface::getCacheContexts | public | function | The cache contexts associated with this object. Overrides CacheableDependencyInterface::getCacheContexts |
| CacheableDependencyInterface::getCacheMaxAge | public | function | The maximum age for which this object may be cached. Overrides CacheableDependencyInterface::getCacheMaxAge |
| CacheableDependencyInterface::getCacheTags | public | function | The cache tags associated with this object. Overrides CacheableDependencyInterface::getCacheTags |
| ConditionInterface::evaluate | public | function | Evaluates the condition and returns TRUE or FALSE accordingly. |
| ConditionInterface::isNegated | public | function | Determines whether condition result will be negated. |
| ConditionInterface::setExecutableManager | public | function | Sets the executable manager class. |
| ConditionInterface::summary | public | function | Provides a human readable summary of the condition's configuration. |
| ConfigurablePluginInterface::defaultConfiguration | public | function | Gets default configuration for this plugin. |
| ConfigurablePluginInterface::getConfiguration | public | function | Gets this plugin's configuration. |
| ConfigurablePluginInterface::setConfiguration | public | function | Sets the configuration for this plugin instance. |
| DependentPluginInterface::calculateDependencies | public | function | Calculates dependencies for the configured plugin. |
| ExecutableInterface::execute | public | function | Executes the plugin. |
| PluginFormInterface::buildConfigurationForm | public | function | Form constructor. |
| PluginFormInterface::submitConfigurationForm | public | function | Form submission handler. |
| PluginFormInterface::validateConfigurationForm | public | function | Form validation handler. |
| PluginInspectionInterface::getPluginDefinition | public | function | Gets the definition of the plugin implementation. |
| PluginInspectionInterface::getPluginId | public | function | Gets the plugin_id of the plugin instance. |
© 2001–2016 by the original authors
Licensed under the GNU General Public License, version 2 and later.
Drupal is a registered trademark of Dries Buytaert.
https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Condition!ConditionInterface.php/interface/ConditionInterface/8.1.x
The Varnish HTTP cache is truly an amazing bit of software that can help take the performance and responsiveness of your high-traffic website to the next level. According to the developers behind Varnish, the reverse-proxy cache can speed up page delivery by a factor of at least 300 times that of a similar server that doesn’t use Varnish to serve cached HTML. Varnish is highly configurable yet fairly simple to install and set up for most use cases, making it an ideal addition to any high-performance web platform.
Drupal Cache_set
Drupal developers may have encountered some woes when adding Varnish to their stack, however, such as the need to integrate a method of purging nodes and other pages when critical content is added or updated – for example, adding a breaking story to the homepage of a news outlet. One lesser-known hangup comes into play when Varnish is used to cache a page containing a Drupal FAPI form that uses ajax to validate or submit. Within both Drupal 7 and Drupal 8, all forms are cached for a hard-coded timespan of six hours. If the page containing your ajax form is cached for longer than six hours, Varnish will continue to serve form markup containing a stale form build ID, which will inevitably cause submissions to fail with no indication or work-around for the end user.
Drupal Cache Control
Fear not, however! With the help of one of the several modules which integrate Drupal with a Varnish cache server, it is possible to force the URLs of your pages containing an ajax form to be purged from the HTTP cache – before the form build ID expires – thereby avoiding the problem altogether. Perhaps the most straightforward way to achieve this is to use a Drupal module like Advanced Page Expiration to send an alternative cache-lifetime header that is shorter than your default (and shorter than the six-hour form-cache lifetime). Another option is to leverage the Purge module and force the necessary URLs to be removed from the cache upon a specific event such as when page content is updated, during a cron run, or perhaps even upon an unsuccessful form submission due to an invalid form build ID (although this would have the obvious downside of allowing at least one submission to fail). The Purge module also has several versions in the works for Drupal 8, so it’s a good choice if you’re using the latest and greatest Drupal.