A browser or other client could ignore or override the cookie lifetime, and keep the session alive longer than intended.Even when session.gc_maxlifetime has run out, there is a chance for the session to stay alive for a bit longer, because the garbage collection only happens every once in a while (depending on session.gc_probability and session.gc_divisor).session.gc_maxlifetime is a server-side limit, but okie_lifetime is a client-side limit.For one hour it would have to be 60 * 60 = 3600.įrom the information I found, and my understanding of it: (note: the article says 60 = 1h, which afaik is wrong.(2 * 7 * 24 * 60 * 60 seconds = 1209600 seconds) About the valuesįor more information on these values, see Fix.ĭecide on suitable values for session.gc_maxlifetime and okie_lifetime, and use one of the places mentioned above to set these values.įor the project I am working on, I decided to set both values to 1209600 = two weeks. grep is your friend.Īlso look for modules that modify login duration, such as or. in /etc/apache2/nf, or /etc/apache2/sites-enabled/. ini_set() statements in your Drupal's sites/*/settings.php.Otherwise, the number specifies seconds of login duration. This means that closing the browser causes a logout. Look for okie_lifetime and session.gc_maxlifetime.Ī value of okie_lifetime = 0 causes the Expire = Session for the session cookie. Open admin/reports/status/php for current phpinfo. This can give you clues whether this is a problem with your global server config or with your specific site. your localhost), and with different browsers. It can also be interesting to compare with other Drupal sites installed on the same server (e.g. Most of the time this is not what you want! The cookie that is relevant for login has a key = "SESS.".Īn "Expire" of "Session" means that the cookie expires when the browser is closed.
To debug this, one can use browser developer tools to inspect cookie expire date. Inspect your session cookies with browser developer tools Check if the cache already contain data.Look for session.gc_maxlifetime and okie_lifetime. If your data is not already in the cache, compute it and add it to the cache using the set() method.Call the get() method to attempt a cache read, to see if the cache already contains your data.A cid is a string, which must contain enough information to uniquely identify the data. Define a Cache ID (cid) value for your data.Request a cache object through \Drupal::cache().'tags' =>, //invalidate when node id 1 or term id 2 is updated 'tags' =>, //invalidate when any node updates It has to be unique string and cannot contain spaces. The syntax for setting cache tags is thing:identifier. Without cache tags we wouldn't know which cache item to invalidate If a renderable output which is output of a Controller or a custom block depends on content provided by some entity, we use cache tags to invalidate the data.įor example, if a node is updated, which appear in two views and three blocks. Before Drupal 8, there was no way to identify individual pieces of expired data stored in different cache bins.Ĭache tags provides a way to track which cache items depend on some data managed by Drupal. The cached data in different bins becomes old and obsolete at some point of time and requires removal from these bins to accommodate the latest changes. Here is an example from a custom block in Drupal 8: use Drupal\Core\Cache\Cache Cache max-age is the maximum time that the cache is stored.For dependencies on data managed by Drupal, like entities and configuration. Cache tags define what object the cache depends on.
If we have user as a context, every user may not have the same user permissions or language.
Caching can either be permanent or valid only for a certain time span, and the cache can contain any type of data. To make websites faster Drupal stores web pages in a cache. The Drupal Cache API is used to store data that takes a long time to compute.
0 kommentar(er)
