CakePHP: Creating a plugin.

Posted by: JDS

I created a sample plugin, "Hello World". Here it is, along with a tarball to test out.

I wanted to see how easy (or not) it would be to create a CakePHP plugin. This example is a simple "Hello World" plugin that uses no database and has the bare minimum of features to be considered an actual CakePHP plugin.

A plugin mimics the underlying MVC structure of Cake's main Application directories and files. So to create a plugin, you need to recreate a Cake PHP App's file and directory structure as follows:

Some Notes For These Examples

  • "APP" in these examples refers to your CakePHP APP directory
  • My examples are for CakePHP 1.2. Therefore, the examples in the CakePHP Manual are not exactly the same as these examples. For example, Views in CakePHP use the ".ctp" extension.
  • I develop, test, and deploy on Linux systems. So my examples use bash shell commands, such as "mkdir".
  • I use the Vi text editor. Vim, actually. Well, gvim, to be absolutely precise. Change "vi" in the examples to whatever text editor you want.
  1. Create a directory to house the plugin, named after the plugin.
    For "Hello World," for example, mkdir APP/plugins/hello_world
  2. Create a plugin app_controller
    For "Hello World," for example, vi APP/plugins/hello_world/hello_world_app_controller.php
  3. Create a plugin app_model
    For "Hello World," for example, vi APP/plugins/hello_world/hello_world_app_model.php
  4. Create the plugin MVC directories
    For "Hello World," for example, mkdir APP/plugins/hello_world/models
    mkdir APP/plugins/hello_world/views
    mkdir APP/plugins/hello_world/controllers
  5. And finally, create the PHP files that correspond to the Model, View(s), and Controller
    For "Hello World," for example, vi APP/plugins/hello_world/models/hello_world.php
    vi APP/plugins/hello_world/views/hello_world_controller.php
    vi APP/plugins/hello_world/controllers/hello_world.ctp

Here is the code for the PHP and Template (i.e. View) files, above:

APP/plugins/hello_world/hello_world_app_controller.php

Note that I added the beforeFilter() function here. It is optional! But I needed it in my app to override some default beforeFilter() authentication checking that happened earlier in the code stack.

<?php
class HelloWorldAppController extends AppController {
    function beforeFilter(){
        return true;
    }
}
?>

APP/plugins/hello_world/hello_world_app_model.php

<?php
class HelloWorldAppModel extends AppModel {
}
?>

APP/plugins/hello_world/models/hello_world.php

<?php
class HelloWorld extends HelloWorldAppModel
{
    var $name = 'HelloWorld';
    var $useTable = false;
}
?>

APP/plugins/hello_world/views/hello_world_controller.php

<?php
class HelloWorldController extends HelloWorldAppController
{
    function index() {
        $this->set('out', 'Hello World');
    }
}
?>

APP/plugins/hello_world/controllers/hello_world.ctp

<?php echo $out ?>

Integrating PHP Generic ACLs with CakePHP 1.2

Posted by: JDS

PHPgACL can be found at http://phpgacl.sourceforge.net/ CakePHP can be found at http://cakephp.org/
Text here

Using vendor libraries in CakePHP

Posted by: JDS

First a rant, and then some actual useful information.

<soapbox>There is no clear documentation on using vendor() in a CakePHP app. Arrgh! I had to piece this together from blogs, forums, tutorials, and other bits and pieces on the web. Why can't this very basic information be included somewhere on the CakePHP panoply of websites? I mean, in the "manual", vendors/ directory is mentioned, vendor() function is mentioned, but some very basic stuff is ommitted! Like all the stuff I list here.</soapbox>

Note: The examples assume the use of a vendor class called "HelloWorld", in a file "APP/vendors/hello_world.php", which looks like this:

<?php
class HelloWorld {
    function HelloWorld(){
        return "Hello World";
    }
}
?>

Anyway, here are some very important basics to using vendor libraries in CakePHP.

Where do you use the vendor() function?

If you want to use the vendor libs inside a particular "action" (i.e. CakePHP "URL" or, more specifically, a method (function) inside a CakePHP Controller class), then call vendor() inside the "action".

For Example:

<?php
class MyClass extends AppController{
    function HelloWorld(){
        vendor( 'hello_world);
        $hw = new HelloWorld;
        $hw->HelloWorld();
    }
}
?>

You don't, however, use vendor() inside the class itself, like, say, outside class functions. Example:

<?php
class MyClass extends AppController{
    // WRONG! You cannot call functions in this area of a class declaration!
    vendor( 'hello_world);

    function HelloWorld(){
        $hw = new HelloWorld;
        $hw->HelloWorld();
    }
}
?>

If you want to include the vendor libraries or plugins or whatever in a global context, for use by every controller, you can call vendor() in one of several different places. I am not sure which of these is best, though! For performance or security reasons, there may be a preferred location. The places are:

  • Inside beforeFilter() in app_controller()
  • Outside the class declaration in the controller file itself.
  • In the "bootstrap" file APP/config/bootstrap.php

More information needed? Maybe. I'll try to get some more as I work with these things.

CakePHP 1.2 Access Control Lists

Posted by: JDS

Are they different enough from 1.1 ACLs that the 1.1 code does not apply?
So, I cannot get ACLs to fucking work. First of all, CakePHP: Why am I using the still-beta 1.2? Well, it is (1) because there are so many improved nice new features that I did not want to not have them, (2) the Cake team's "beta" is actually quite stable, and (3) I did not want to climb the learning curve twice. Okay, so, then does the code on this page http://bakery.cakephp.org/articles/view/real-world-access-control not apply to CakePHP 1.2 ACLs? This is by far the clearest, simplest description of CakePHP ACL implementation (and ACLs in general) that I've found but it doesn't fucking work! Aarrgh! I found this page http://bakery.cakephp.org/articles/view/how-to-use-acl-in-1-2-x and that is helpful, except for the follwoing questions now: Why is there a call to $acl->create() at all? I tried these examples without that call and it seems like the create() call is not needed. Does create() even do anything at all? Has create() been superceded by save()? Did save() exist in ACL 1.1? Allright, maybe if I ever get a chance I'll add the answers to these questions.

CakePHP Bakery: A Good idea, poorly implemented.

Posted by: JDS

Or, at least /incompletely/ and /buggily/ implemented.
Being a Linux user, the first question I ask when using a website that doesn't work is: "Is this because I am using desktop Linux?" In other words, "Would this website, which is apparently broken, actually work in, say, MSIE on Windows or Safari on Mac?" Now, regarding the Cake Bakery, I ask myself this question all the time. Because the Bakery is very, very buggy. Broken, even.
  • Articles disapear randomly
  • Articles come up with blank pages all the time, for no apparent reason
  • Code snippets are often buggy and incomplete (not the Bakery's fault, per se)
  • Little things don't work like I imagine they should. Like "Comments" on articles -- why can't you use anything but letters in the comment title??? That's just plain dumb.
  • Article dates are often impossibly incorrect. 12-31-1969, for example, or, 1-22-1999. 1999?? CakePHP did not exist then, AFAIK.
  • The "Search" form does not work all the time (i.e. randomly blank results pages similar to the randomly blank articles pages)
  • The "Search" form really, really, really should have a "Go" or "Submit" button. Why the fuck does it not have a Submit button?? and so on...
  • Why I think I should stick to HTML 4.01 STRICT and not use XHTML

    Posted by: JDS

    Okay, so, XHTML has been the newest, "best" version of HTML for what, six, seven years now? But I still don't see valid reasons to us it for an HTML website intended for public consumption. Here is why. Mostly this bulleted list is so I can have a handful of talking points when some new kid says, "We gotta be using XHTML 1.0!" False!
    Okay, so, this has been discussed before. Some references: http://hixie.ch/advocacy/xhtml http://www.webmasterworld.com/forum21/12026.htm Reasons Browsers still have troubles with the application/xhtml+xml MIME type. Serving XHTML as HTML to support non-xhtml supporting browser removes any advantage of using XHTML HTML 4.01 STRICT is a very strict, very well supported, very functional HTML definition that does everything that general HTML consumption needs. Must use core DOM methods in JS HTML comments differences Other general incompatibilities. XHTML can be transformed into HTML 4.01 strict with, say, XLS. But this strikes me as unnecessary overhead unless one has needs that can only be addressed by using XML. Y'know, just because a technology exists, and is the newest thing, does not make it the best thing to use, in any given situation, or, even, ever.