feature(application): Introduces Elgg\Application for loading/booting…

… Elgg

Removes references to engine/start.php in docs.
Removes load_plugins().
Deprecates inclusion of start.php for booting the core.
Moves settings loading to Elgg\Config and allows setting the config file path or bypasses loading a settings file.
Allows Elgg\Config to not use the global $CONFIG.
Allows use of Elgg\Database without booting core via the Application.
Refactors Elgg\CacheHandler and several other direct-call scripts to use Application
Allows the cache handler, export handlers, and thumbnail server to work using the CLI server.
Allows the Logger to be injected into Database during boot for lighter partial boot (e.g. cache_handler).
Removes unneeded join date GET param from profile icon URLs.

Refs #7721

.scripts/validate_commit_msg.php

@@ -18,7 +18,7 @@
 
  $rootDir = dirname(__DIR__);
 
- require_once "$rootDir/vendor/autoload.php";
+ require_once "$rootDir/autoloader.php";
 
 $is_file = false;
 

autoloader.php

@@ -0,0 +1,34 @@
+<?php
+/**
+ * We handle here two possible locations of composer-generated autoload file. One is directly in Elgg directory
+ * when not using as dependency, other is in the main project dir, parent to this one.
+ */
+
+$paths = [
+	__DIR__ . '/vendor/autoload.php',
+	__DIR__ . '/../../../vendor/autoload.php',
+];
+
+foreach ($paths as $path) {
+	if (!is_file($path)) {
+		continue;
+	}
+
+	if (!is_readable($path)) {
+		echo "'$path' exists but is not readable by your webserver.\n";
+		break;
+	}
+
+	$autoloader = (include $path);
+	if (!$autoloader) {
+		echo "'$path' was present but did not return a autoloader.\n";
+		break;
+	}
+
+	return $autoloader;
+}
+
+echo "You must set up the project dependencies. Run the following commands:\n" .
+	"curl -s http://getcomposer.org/installer | php\n" .
+	"php composer.phar install";
+exit;

composer.json

@@ -45,5 +45,8 @@
         "elgg/sniffs": "dev-master",
         "squizlabs/php_codesniffer": "~1.5",
         "simpletest/simpletest": "~1.1"
+    },
+    "config": {
+        "optimize-autoloader": true
     }
 }

docs/appendix/faqs/development.rst

@@ -152,7 +152,7 @@ There are 5 :doc:`Elgg events </design/events>` that are triggered on every page
 4. pagesetup, system
 5. shutdown, system
 
-The *boot*, *system* event is triggered before the plugins get loaded. There does not appear to be any difference between the timing of the next two events: *plugins_boot*, *system* and *init*, *system* so plugins tend to use *init*, *system*. This event is triggered just after the plugins are loaded near the end of the boot script (``/engine/start.php``). The *pagesetup*, *system* event is thrown the first time ``elgg_view()`` is called. Some pages like the default ``index.php`` do not call ``elgg_view()`` so it is not triggered for them. The *shutdown*, *system* event is triggered after the page has been sent to the requester and is handled through the PHP function ``register_shutdown_function()``.
+The *boot*, *system* event is triggered before the plugins get loaded. There does not appear to be any difference between the timing of the next two events: *plugins_boot*, *system* and *init*, *system* so plugins tend to use *init*, *system*. This event is triggered in ``Elgg\Application::bootCore``. The *pagesetup*, *system* event is thrown the first time ``elgg_view()`` is called. Some pages like the default ``index.php`` do not call ``elgg_view()`` so it is not triggered for them. The *shutdown*, *system* event is triggered after the page has been sent to the requester and is handled through the PHP function ``register_shutdown_function()``.
 
 There are :doc:`other events </guides/events-list>` that are triggered by the Elgg core but they happen occasionally (such as when a user logs in).
 

docs/guides/guidelines.rst

@@ -80,27 +80,19 @@ The object/<subtype> view
 Actions
 -------
 
-Actions are transient states to perform an action such as updating the database or sending a notification to a user. Used correctly, actions are secure and prevent against CSRF and XSS attacks.
+Actions are transient states to perform an action such as updating the database or sending a notification to a user. Used correctly, actions provide a level of access control and prevent against CSRF attacks.
 
-.. note::
+Actions require action (CSRF) tokens to be submitted via GET/POST, but these are added automatically by elgg_view_form() and by using the ``is_action`` argument of the ``output/url`` view.
 
-   As of Elgg 1.7 all actions require action tokens.
-
 Action best practices
 ^^^^^^^^^^^^^^^^^^^^^
 
-Never call an action directly by saying:
-
-.. code:: html
-
-   ...href="/mod/mymod/actions/myaction.php"
-
-This circumvents the security systems in Elgg.
-
-There is no need to include the ``engine/start.php`` file in your actions. Actions should never be called directly, so the engine will be started automatically when called correctly.
+Action files are included within Elgg's action system; like views, they are *not* regular scripts executable by users. Do not boot the Elgg core in your file and direct users to load it directly.
 
 Because actions are time-sensitive they are not suitable for links in emails or other delayed notifications. An example of this would be invitations to join a group. The clean way to create an invitation link is to create a page handler for invitations and email that link to the user. It is then the page handler's responsibility to create the action links for a user to join or ignore the invitation request.
 
+Consider that actions may be submitted via XHR requests, not just links or form submissions.
+
 Directly calling a file
 -----------------------
 

docs/guides/pagehandler.rst

@@ -15,7 +15,7 @@ The plugin's page handler is passed two parameters:
 Code flow
 ---------
 
-Pages in plugins should be served only through page handlers, stored in ``pages/`` of your plugin's directory and do not need to ``include`` or ``require`` Elgg's ``engine/start.php`` file. The purpose of these files are to knit together output from different views to form the page that the user sees. The program flow is something like this:
+Pages in plugins should be served only through page handlers, stored in ``pages/`` of your plugin's directory and do not need to use ``Elgg\Application``. The purpose of these files are to knit together output from different views to form the page that the user sees. The program flow is something like this:
 
 1. A user requests ``/plugin_name/section/entity``
 2. Elgg checks if ``plugin_name`` is registered to a page handler and calls that function, passing ``array('section', 'entity')`` as the first argument

docs/guides/upgrading.rst

@@ -12,12 +12,14 @@ See the administrator guides for :doc:`how to upgrade a live site </admin/upgrad
 From 1.11 to 2.0
 ================
 
-Removed Functions
------------------
+Removed Functions and Scripts
+-----------------------------
 
  - get_db_error()
  - execute_delayed_query()
  - get_db_link()
+ - load_plugins()
+ - mod/groups/icon.php
 
 Callbacks in Queries
 --------------------
@@ -68,6 +70,17 @@ The following views received ``label`` elements around some of the input fields.
 - views/default/forms/admin/plugins/sort.php
 - views/default/forms/login.php
 
+engine/start.php is deprecated
+------------------------------
+
+Plugins should use the class ``Elgg\Application`` to boot Elgg. Typical usage:
+
+.. code:: php
+
+    // boot Elgg in mod/myplugin/foo.php
+    require_once dirname(dirname(__DIR__)) . '/autoloader.php';
+    (new \Elgg\Application)->bootCore();
+
 From 1.10 to 1.11
 =================
 

docs/guides/views.rst

@@ -166,7 +166,7 @@ Note that if you extend the core css view like this:
 
 	elgg_extend_view('css', 'custom/css');
 
-You **must** do so within code that is executed by engine/start.php (normally this would mean your plugin's init code).  Because the core css view is loaded separately via a ``<link>`` tag, any extensions you add will not have the same context as the rest of your page.
+You **must** do so within your plugin's init code. Because the core css view is loaded separately via a ``<link>`` tag, any extensions you add will not have the same context as the rest of your page.
 
 .. _guides/views#altering-view-input: