Summary:
Do pre-controller hooks execute during caching? Is there any hook-point which will execute? (pre-system?)
I should probably highlight the fact that the hook doesn't affect the content that is sent to the browser. That isn't an issue.
Detailed version:
I plan on implementing some statistics-type functionality in a project I've built using PHP and CodeIgniter.
The project in question is a custom built CMS - due to the extended intervals between updates I've used caching to help speed up load times; this isn't essential but it's preferential. It seems to be a good solution to a largely static site; especially where dynamic content is primarily served client-side - i.e AJAX requests.
The proposed functionality primarily involves a pre-controller hook which accesses methods through libraries such as the User Agent library, before dumping them to a database. From here it can be polled, outputted via JSON and manipulated before being displayed by something like the jQuery flot plugin.
I've read through the documentation on the Web Page Caching as well as the documentation regarding hooks. Unfortunately, it's still not clear whether using caching will completely bypass the hooks.
I'm aware of the cache_override however this means implementing your own caching mechanism; not what I want to do!
The alternative would be gathering statistics client side and submitting it to the server via AJAX; but this isn't ideal either as I'm trying to have a clear separation of logic - for maintenance and testing reasons.
In short:
Do pre-controller hooks execute during caching? No.
Is there any hook-point which will execute? Yes pre_system does execute.
If caching kicks at system/core/CodeIgniter.php:189, the only hook that gets a chance to run is pre_system (system/core/CodeIgniter:124).
Unfortunately you don't get much functionality of codeigniter at that point, no get_instance() and without that most core libraries are not loaded as well. If you are inclined you can look into what functions are defined inside system/core/Common.php thats pretty much all you got.
If you are really want to make this work with the built in classes you can sort of fight your way to a database object and other core stuff like this:
You will have to manually get the BASEPATH.'database/DB.php' file included in. Fortunately in the loader class, it loaded with require_once so it won't break the page on cache miss.
Once you got the Database library loaded instantiate the usual $this->db object with calling DB(). Without parameters it will load the default database from the config files as usual.
At this point you can write your queries from your pre_system hook, and since hooks can be objects, you can move every logging code inside the hook's object. If you need other libraries you can get an instance of them with the load_class() function (don't forget to set the third prefix parameter to empty string if you are not loading a built in class).
At the end you should end up like this (imaginary code):
class MyLoggingHook {
// called from the hook config
public function run($params = array()) {
require_once(BASEPATH.'database/DB.php');
$db = DB(); // getting hold of a DAO instance
// routing information is always useful to have for pageview logs
$RTR = load_class('Router', 'core');
$RTR->_set_routing();
// Router also load Uri and Config classes inside so the following two instances could be interesting too:
// $RTR->uri
// $RTR->config
// load some useful library not related to CodeIgniter
$user_agent_detector = load_class('UserAgentDetector', 'libraries', '');
// do some logging
$db->insert('page_view_log', array('class' => $RTR->fetch_class(), 'method' => $RTR->fetch_method(), /*...*/);
}
}
I should probably mention that i've never used something like this in production and there's the risk of relaying on funcionality that could change from version to version. If you can do without touching the Codeigniter classes inside your hook go with that.
Using PDO for database access, loading the database config with get_config(), you can get by without touching any codeigniter related classes.
Related
I am working with Codeignitor 2.x and I was originally using controllers as modules (though not completely HMVC), in that I had a Top Level controller that would call other lower level controllers. My thinking was that because these lower level controllers were still interacting with the view, that they should remain controllers rather than models or drivers.
What I found, however, is that each instance of a controller also spawns a new instance of CI. So I would have 3 or 4 instances of CI running for each request. Ton of overhead, and also caused session issues.
I have since moved these lower level controllers into the library as drivers. They now capture the CI instance in the construct method, and make modifications to it. This makes it VERY nice to work with, and doesn't require the HMVC extension. The drivers are not externally callable either, so it allows me to funnel all requests through specific entry points.
My question is whether this is structurally correct. I have always held the notion that drivers should only modify the data they are provided through their method calls, but many of these drivers will pull information directly from GET and POST, and while they will not directly append to the View, they are often accessing view files, and passing the processed view to the CI instance for output.
[EDIT] A little more context:
One of the drivers I have created is essentially a user login driver called 'Access'. It makes calls to the 'User' model for create/login/logout methods. The driver uses the POST data to check the User model, then loads the correct view with errors and whatever is needed. The idea, being, with 2 lines, I can include this driver in any controller throughout the project, so there is a significant decrease in code redundancy. Again, I know that the drivers should be confined to their scope, however the driver does not modify anything outside it's scope, but simply returns the view it has created.
Is there another method to for doing this that is more inline with straight MVC?
I can't say whether it is right or wrong. But if I were you, I wouldn't do that. I'd probably refactor some of the code. I'd make sure that they don't grab and manipulate data directly from the $_GET or $_POST superglobals. Instead, pass in some data as arguments to a function call. This would make testing easier, since you don't have to simulate a GET or a POST request. While technically, you could just set the value for the superglobals manually from the code, but I'd not recommend doing that. Supplying data as arguments would be much better, especially if you want to write test cases that are to be executed subsequently. Plus, having the libraries interacting with the scopes beyond its own might introduce some hidden gotchas.
In my opinion, libraries are meant to be something like modules, where you can just drag and drop, and then use them without any hassle. If your code really needs to grab or manipulate values from $_GET or $_POST, maybe they are meant to be models instead. Also, you might want to think whether your code is actually a library or not. Ask yourself, will this code be useful outside this application? Or is it highly dependent and can only be useful for this particular app? If you say yes to the latter, then it's probably should be a model instead of a library. Last thing, you should leave the views to the controller. Just return the data you need from the library/model method then pass it to the view from the controller.
I am trying to build a basic plugin system like the kind you often find in a CMS like WordPress. You have a folder of plugins which tie into the main system's operation through event notifications using an Observer or Event design pattern.
The problem is it's impossible for the system to know which events the plugin wants to act upon - so the system has to load each plugin for every page request just to find out if that plugin is actually needed at some point. Needless to say, that's a lot of wasted resources right there--in the case of WordPress, that adds up to several extra MB of memory for each request!
Are there alternative ways to do this?
For example, is there a way to load all this once and then cache the results so that your system knows how to lazy-load plugins? In other words, the system loads a configuration file that specifies all the events that plugin wishes to tie into and then saves it in APC or something for future requests?
If that also performs poorly, then perhaps there is a special file-structure that could be used to make educated guesses about when certain plugins are unneeded to fulfill the request.
I do have a plugin management tool, but I only every used it with predominantly procedural plugins, and with all includes usually loaded at once. But for an event-based and lazy-loading API I could imagine using shallow wrappers for the plugin management, and resorting to autoloading for the actual extensions.
<?php
/**
* api: whatever
* version: 0.1
* title: plugin example
* description: ...
* config: <var name="cfg[pretty]" type="boolean" ...>
* depends: otherplugin
*/
$plugins["title_event"] = "TitleEventClass";
$plugins["secondary"] = array("Class2", "callback");
?>
In this example I'd assume the plugin API is a plain list. This example feature-plugin-123.php script would do nothing but add to an array when loaded. So even if you have a dozen feature plugins, it would only incur an extra include_once each.
But the main application / or plugin API could instead just instantiate the mentioned classes (either new $eventcb; for the raw classnames or call_user_func_array for the callbacks). Where in turn it would offload the actual task to an autoloader. Thus you have a dual system, where one part manages the list, the other locates the real code.
I'm thereby still imaganing a simple config.php which just lists plugins and settings like this:
<?php
include_once("user/feature-plugin-123.php");
include_once("user/otherplugin2.php");
include_once("user/wrapper-for-htmlpurifier.php");
$cfg["pretty"] = 1;
Again taking in mind that these are just wrappers / data scripts, with the plugin description for managability. One could as well use an actual register_even() API and define an additional wrapper function in each. But listing classnames seems the simplest option.
The aforementioned management tool is kind of rusty and ugly: http://milki.include-once.org/genericplugins/
But it's uneeded if you just need a list (sql table) and no settings management. That overhead is only for prettyprinting the plugin meta data and keeping a human-readable config.php.
In conclusion:
spl_autoload() on the include_path, and a simple event->classname registry, one wrapper script each, simply included all at once.
Wordpress and other CMS systems are very bad examples.
What we have to understand is that modular, almost always means heavier.
The best scheme that I ever worked with to solve this situation is a class based plugin, with a strict naming convention using an auto loader.
So, before using the plugin, you´ll need to create an instance, or use static functions.
You can even call the plugin like:
<?php $thePlugin::method(); ?>
eg:
<?php
spl_autoload_register('systemAutoload');
function systemAutoload($class)
{
$parts = explode('_',$class);
switch($parts[1])
{
case "Plugin":
include("/plugins/{$parts[2]}/{$parts[2]}.php");
break;
}
// ...
}
?>
Regarding Events:
You have to register this events statically to avoid bringing it in a dynamic manner.
The database would be the right place to do it. You can have an events table, and install() and uninstall() methods on the plugin class to add specific events or bind methods to other events. It´s one database query, and if you want more from it, add it to memcached, or to a flat ini file.
Works well for me. This way I was able to get a heavy system that was consuming 8mb per request to drop to 1mb, with the exactly same list of features, without advanced caching. Now we can add more features and mantain the system "clean"
Hope that helps
I would save the plugin class name along with it's subscribed events in a configuration file and then save the parsed config file in APC, for example. Then when an event is triggered the system can lazy load the appropriate plugin classes as needed.
I would like to extend the cakephp logging facility.
Using
$this->log($msg, $level)
you can log a $msg with $level to tmp/logs/$level.log.
How I would like to use logging is:
Separate functions for different levels, e.g. $this->debug($msg) for $this->log($msg, 'debug') and $this->error($msg) for $this->log($msg, 'error') etc. for logging.
Automatically put the name of the class in front of a message, e.g. $this->debug($msg) will lead to "MyClass: $msg" if $this is of type "MyClass".
I know I can extend the functionality by extending AppModel, AppController etc., but as I need the functionality everywhere in my application, I would rather need to extend cakephp's Object - but didn't find a stable mechanism for that (don't want to change it in the cake/ folder).
I though about implementing a new class for that functionality, but I'm not sure how to make that available in cakephp.
Could you please give me some hints where/how I can implement these extensions neatly?
Global convenience methods
Well, you can't really do monkey patching in PHP (5.2 at least), and that is probably a good thing for the the developers that have to maintain your code after you are gone. :)
CakePHP - being an MVC framework with strict conventions - makes it hard for you to break the MVC paradigm by only allowing you the extend the parts you need in isolation (ie. AppModel, AppController, etc.) and keeping the object-orientated foundation untouched in the core (making it hard to add code that "can be used everywhere" for potential misuse).
As for adding functionality that transcends all the MVC separation, the place for this is app/config/bootstrap.php. When you place code here it seems clear that it is not part of the framework (quite rightly so), but allows you to add these sort of essentials before CakePHP even loads. A few options of what to do here might be:
Create a function (eg. some custom functions such as error() that call CakeLog::write() in the way you like.)
Load a class (eg. load your very own logging class called something like.. Log, so you can call Log::error() in places)
See below:
The logger API
Cake does allow for many customisations to be made to things like the logger, but unfortunately the API exposed to us is already defined in the core in this case. The API for logging in CakePHP is as follows, and you can use either approach anywhere you like (well, the former only in classes):
$this->log($msg, $level) // any class extending `Object` inherits this
// or
CakeLog::write($level, $message); // this is actually what is called by the above
The arbitrary $level parameter that you are trying to eliminate is actually quite a powerful feature:
$this->log('Cannot connect to SMTP server', 'email'); // logs to app/logs/email.log
// vs
$this->email('Cannot connect to SMTP server'); // ambiguous - does this send emails?
We just created a brand new log type without writing an extra line of code and it's quite clear what the intention of our code is.
Customising the logger
The core developers had the foresight to add a condition allowing us to completely replace the logger class should we wish to:
function log($msg, $type = LOG_ERROR) {
if (!class_exists('CakeLog')) { // winning
require LIBS . 'cake_log.php';
}
// ...
As you can see, the core CakeLog class only gets instantiated if no such class exists, giving you the opportunity to insert something of your own creation (or an exact copy with a few tweaks - though you would want to sync changes with core - manually - when upgrading):
// app/config/bootstrap.php
App::import('Lib', 'CakeLog'); // copy cake/libs/cake_log.php to app/lib/cake_log.php
The above would give you full control over the implementation of the CakeLog class in your application, so you could do something like dynamically adding the calling class name to your log messages. However, a more direct way of doing that (and other types of logging - such as to a database) would be to create a custom log stream:
CakeLog::config('file', array(
'engine' => 'FileLog', // copy cake/libs/log/file_log.php to app/libs/log/file_log.php
));
TL;DR - Although you can load your own code before CakePHP bootstraps or for use in isolation in each of the MVC layers provided, you shouldn't tamper with the object hierarchy provided by the core. This makes it hard to add class methods that are inherited globally.
My advice: use the API given to you and concentrate on adding more features instead of syntactical subtleties. :)
In addition to what deizel said (great writeup, by the way, deizel), you don't have to use Cake's logger. You're welcome to use any logging system you'd like. Choosing an existing logging framework that you like would probably be the safest bet. bootstrap.php is a good place to do any require calls or initializations.
Otherwise, if you'd like to do things 'in' Cake, I'd recommend creating a plugin with a trio of logging interfaces: a Component, a Behavior, and a Helper. That way the logging functionality would be available in your models, views, and controllers. As for how to code it, I like the idea making the cake classes thin proxies to your real logging class, and using the magic method __call() in your proxies to parse logging requests and environment, then forward on that information to your logger to handle uniformly.
You'd be able to write things like $this->MyLogger->oops("stubbed my toe") and potentially have an oops.log file with your messages and whatever additional information (calling controller/view/model, time&date, etc.) you'd like included.
I have an object oriented framework that uses a page design, where each page extends a view of the framework. So, for instance, my index page for a site is actually a class that implements the abstract class View provided by the framework. I hook the framework by including a startup script at the top of the page and after some processing the framework creates an instance of the page and processes its view data. To add flexibility to the system, I don't require the class name to be the name of the file itself. This allows me to create something like a support class and have it behave as the index for the /support/ subdomain.
I was initially passing the page's class name into the framework via the framework's constructor, but this added a few more steps to the top or bottom of the page. I currently obtain the class name via a pages table in the database identified by a filtered requested URI. I use this table to build navigation and adding an extra table column was practically free. This works OK as long as I have a database connection, but I'm trying to implement static page support for status messages and error reporting, and I need another method for creating an instance of the page's class. If I use the standard convention of naming the class the file's name, then I know I have a dependable way of extrapolating the class name. I don't really want to name all my classes index just for presentation reasons. What is some advice or some standards for how object oriented frameworks are initialized?
View.inc
<?php
abstract class View
{
abstract function getView();
}
?>
Startup.inc
<?php
require_once("View.inc");
require_once("CoreController.inc");
$Framework = new CoreController();
$Framework->Initialize();
exit;
?>
index.php
<?php
require_once("Startup.inc");
class Index extends View
{
public function getView()
{
echo "<pre>View Data</pre>";
}
}
?>
Within my framework I have a TemplateController that processes the page. The page class is known because it is mapped via another class. Without a database however, I would like to discover the class within, say, index.php without changing the way it's currently set up. Here is the actual code within the TemplateController.
//Get the View Class from Page
$view = $page->getPageClass();
//We need to catch View creation failure
$this->Page = new $view($this->Framework);
//Initialize the Page View
$this->Page->Initialize();
//Cache the Page View
$this->cacheView($this->Page, $page->getPageName(), $this->SiteID.TCS_PAGE_SORTID);
In the snippet above $view is the actual name of the class that was mapped from another controller. I'm passing a reference to the framework to the view's constructor and the rest is really irrelevant. I'm trying to come up with a similar mapping technique to identify the page class in the event the database is down. I like the one include line for the framework startup and would like to keep it that simple.
At the top of the TemplateController I have to also reinclude the actual page, since my startup script is at the top, the actual class is not included even though it is the requested page.
include($_SERVER['SCRIPT_FILENAME']);
Please review Stack Overflow question Identifying class names from $_SERVER['SCRIPT_FILENAME'] for more information on what I'm attempting to do.
Here is my checklist of page routing:
Adding new page must be quick
You must not be able to add page unintentionally
Application with million pages should not be slower or more bloated than application with 2 pages
Provide simple way and let people enhance it if they want
Allow easy re-factoring, such as moving several pages into different location
Make framework detect everything. Don't force user to specify base URL, etc.
Create simple to understand page names (hello/world).
Clean illegal characters from the URL
Make it possible to add static pages easy
Provide a way to generate URLs from page names.
Allow user to use pretty URLs by changing what appears before and after the page in the URL
And most importantly
- Stop copying, think about the best approach.
All of those suggestions I have used in the PHP UI framework - Agile Toolkit where I am a contributor.
Relevant sources: Agile Toolkit - a PHP Framework with jQuery, Agile Toolkit - PageManager.php, Agile Toolkit - URL.php and Agile Toolkit - PathFinder.php.
We wanted to make it really simple for developers. And secure too. And flexible. Therefore the "page" class is selected based on the URL. How? Quite easy:
/hello.html -> page_hello
/hello/world.html -> page_hello_world
Class then is mapped into filename. page/hello/world.php
Then there are cases when we want to use dynamic URLs too, such as: /article/234
Many frameworks implement a complex techniques here (arrays, regular expressions, front-controllers). We don't. There is mod_rewrite for this. Just rewrite this into page=article&id=234 and it works. And scales.
Apart from pages, there are other classes, but those classes can't be accessed directly. Therefore pages live under the /page/ folder, do distinguish them and maintain security.
Then comes the designer saying - "I won't write PHP". So we introduce static pages. If class page_hello_world is not defined, we'll look into template/skin/page/hello/world.html. That's a easy shortcut for designers and non-developers to add a new page.
What if a page is not found? Api->pageNotFound() is called. Feel free to redefine and load pages from SQL or display 404 page with a picture of a pink elephant.
And then there are some pages which come from add-ons. We don't want to enable them by default, but instead let users add them to their app somewhere. How?
class page_hello_world extends Page_MegaPage
Next question, is how we handle sub-pages of that page, since sometimes all the functionality can't fit on single page. Well, let's add support for page_edit() method (or any page_XX) as an alias for a sub-page inside those classes. Now add-on developer can include a multifunctional page which can be extended, customized and placed anywhere in the application.
Finally there are hackers, who want to do something really fast. For them we apply same technique to the API. You can define function page_hello_world in the API, and you don't need class.
Some might say that there are too many ways to do a simple thing. Oh well.
I hope that this was helpful.
Use __autoload(). Most major PHP frameworks use autoloading to streamline class loading.
You need some way to map a URL to an object, which is usually handled by a routing component in most frameworks. Might want to take a look at libraries such as https://github.com/chriso/klein.php, or the routing components of the major Frameworks out there (Zend, Symfony, etc.).
Why not to use information from URL to detect correct class? Since you won't use database for static pages, you have to somehow store mapping between URL and class in file. I.e. you will have a file mapping.php:
return array(
'about' => 'AboutView',
'copyright' => 'CopyrightView',
);
Here, about and copyright are URL components and values represent appropriate child classes of View. You can have URL's like http://example.com/index.php?page=about and use rewriting capabilities of webserver to make them look good.
You will change implementation of Page::getPageClass() in order to return correct view class. Depending on URL it will use static mappings from the file above or use database.
What's the problem with this approach?
I have been asked to do a project where the client can create PHP plugins and add them to the website… same concept as WordPress plugins.
What is the best way to make a software that supports that? I'm not asking for the solution, I'm asking for the concept or structure.
First of all, you have to determine how do you want your plugins integrated. If you want something like Wordpress plugins, which are just plain functions most of the times, then it's extremely easy. It's like adding new code to your application.
Well, basically, your application should be able to build a list of plugins available, and to determine which ones are enabled. The list can be built by browsing the files, a config file, or whatever. Enabled plugins can be stored in the database for example.
Then, you just do an interface where the user can enable each available plugin. When enabling it, the web application would write information about it in the plugins database, specifying that it's enabled. Then, the application calls a specific method of the plugin class (really, OOP is mandatory in correct plugin development), like Install(). To avoid exceptions when plugins have no such method, all plugin classes should inherit a base class written in the main web application, which does contain a definition for that method. That method has the sole purpose to perform the initialization of the plugin (create tables to the database, populate statistics, etc).
Also, at each request, your web application should include all the files of the plugins that are specified as enabled. Then use them however you want. Call their methods from templates for example. If you want to write plugins that are transparent to the template developer, then you could do just like in wordpress. There, the plugin at initialization (for example when it's file is included) writes specific data into arrays of actions. It can write what function should be called, with what parameters, and when to be called.
You can even make something like event triggers in your main web application, to enable customization. Before drawing something, call a function called something like do_action("before_output_of_something"), and after output is ended, call the function do_action("after_output_of_something"). The string parameter would be a key in an array of triggers, that points to an array of actions (event handlers). To add event handlers call a function like this add_action("before_output_of_something", $object, "method_name", array("parameters")). do_action method passes the array of actions, and uses call_user_func() PHP function to call event handlers.
There is much more to this topic. All depends on what exactly you want to make.
What I wrote here is just a lousy attempt to express some of the possibilities. What you should do is find a good book, maybe about just this topic.
I would solve this by using the event-dispatcher pattern. You define certain points (events) in your main application. Plugins can register for this events and will be executed, when the related event is triggered.
There are multiple options. Most common is the hooks concept with simple plugin functions, where you just have to include() a plugin from a central configuration script. Each plugin has to register itself, so usually there is a plugin registration method. But it can also just look like this:
$app_plugin["add_title"][] = "do_whatever";
function do_whatever($request, &$page) {...}
And in your main application you just define a couple of plugin calls, wherever you see the need for it. You would use a wrapper function to invoke all plugins, but basically you look for the hook name and invoke all registered plugins:
foreach ($app_plugin["add_title"] as $func) {
$output .= $func($_REQUEST, $page);
Each named hook can have a different set of parameters. Typically you would want to get additional content, but sometimes plugins just modify existing variables, or influence the application flow.
The more hooks you have, the more diverse extensions are possible. And it's not necessary to use functions only. Of course this scheme also works with objects (they just need to be instantiated first.)