Issue #22336 by quicksketch, scor, boombatower, and rfay. Move all core Drupal files under a core subdirectory.

1 files changed, 68 insertions, 0 deletions

diff --git a/core/includes/cache-install.inc b/core/includes/cache-install.inc
new file mode 100644
index 000000000000..8bcf8b7b1c17
--- /dev/null
+++ b/core/includes/cache-install.inc
@@ -0,0 +1,68 @@
+<?php
+
+/**
+ * @file
+ * Provides a stub cache implementation to be used during installation.
+ */
+
+/**
+ * A stub cache implementation to be used during the installation process.
+ *
+ * The stub implementation is needed when database access is not yet available.
+ * Because Drupal's caching system never requires that cached data be present,
+ * these stub functions can short-circuit the process and sidestep the need for
+ * any persistent storage. Obviously, using this cache implementation during
+ * normal operations would have a negative impact on performance.
+ */
+class DrupalFakeCache extends DrupalDatabaseCache implements DrupalCacheInterface {
+  function get($cid) {
+    return FALSE;
+  }
+
+  function getMultiple(&$cids) {
+    return array();
+  }
+
+  function set($cid, $data, $expire = CACHE_PERMANENT) {
+  }
+
+  function deletePrefix($cid) {
+    try {
+      if (class_exists('Database')) {
+        parent::deletePrefix($cid);
+      }
+    }
+    catch (Exception $e) {
+    }
+  }
+
+  function clear($cid = NULL, $wildcard = FALSE) {
+    // If there is a database cache, attempt to clear it whenever possible. The
+    // reason for doing this is that the database cache can accumulate data
+    // during installation due to any full bootstraps that may occur at the
+    // same time (for example, Ajax requests triggered by the installer). If we
+    // didn't try to clear it whenever this function is called, the data in the
+    // cache would become stale; for example, the installer sometimes calls
+    // variable_set(), which updates the {variable} table and then clears the
+    // cache to make sure that the next page request picks up the new value.
+    // Not actually clearing the cache here therefore leads old variables to be
+    // loaded on the first page requests after installation, which can cause
+    // subtle bugs, some of which would not be fixed unless the site
+    // administrator cleared the cache manually.
+    try {
+      if (class_exists('Database')) {
+        parent::clear($cid, $wildcard);
+      }
+    }
+    // If the attempt at clearing the cache causes an error, that means that
+    // either the database connection is not set up yet or the relevant cache
+    // table in the database has not yet been created, so we can safely do
+    // nothing here.
+    catch (Exception $e) {
+    }
+  }
+
+  function isEmpty() {
+    return TRUE;
+  }
+}