AOPHP was apparently started in early 2005 as a research project by John Stamey and Bryan Saunders but for unknown reasons it did not get popular and was loosely maintained for a number of years.  Since about 2007, the topic hasn’t really been talked about much.

One of my personal rules of using PHP is to Never Suppress Errors (except in production). I follow this rule because it keeps me from shooting myself in the foot, and generally I try to avoid that.

PHP supports a number of different scope models for error suppression, which can be combined to produce sophisticated (or atrocious) use of errors. They seem to fall into a few categories; Per-environment, per-file, and per-command.

Per-Environment — Globally configured via PHP.ini, this is imperative for a production environments that you want to hide messy errors from. For example, you wouldn’t want to hand out a stack trace to potential hacker or burden a casual user with cryptic error messages. Error suppression at this level is usually smart and can be part of good security.

Per-File — PHP doesn’t just enforce a single global rule, but also supports overriding the above environmental setting manually. Since PHP is stateless, this change only applies to the current page lifespan, or until it is manually turned off — which can be useful for certain scenarios like showing errors. Or vice versa, not showing errors, the choice is yours. Generally these statements are less than sublime, but all-in-all, they are easy enough to find and do only one thing.

Per-command — Finally, PHP supports per-command error suppression in the form of an ‘at’ symbol “@”. This is the one I have always told myself NEVER TO USE! It’s not that I’m paranoid, it’s just impractical to go through ALL of your code and add/remove these symbols whenever you move to production.

Disabling Mootools in Joomla 1.5 was actually pretty simple. All you need to to is add the following to your template above your head tag:

getHeadData();
    $headers['scripts'] = array();
    $this->setHeadData($headers);

    // make sure to eliminate any of the following
    //JHTML::_('behavior.framework', true);
    //JHTML::_('behavior.mootools', true);
?>

In Joomla 1.6 this can remain the same if you adjust a tiny bit of Joomla internals. Specifically we need to modify the setHeadData() function in joomla16/libraries/joomla/document/html/html.php (around line 116).

// original version
$this->_scripts = (isset($data['scripts']) && !empty($data['scripts'])) ?
                  $data['scripts'] : $this->_scripts;

// updated version ( !empty() replaced with is_arrray() )
$this->_scripts = (isset($data['scripts']) && is_array($data['scripts'])) ?
                  $data['scripts'] : $this->_scripts;

What this does is allow Joomla to accept an empty value for $headers['scripts'] where it would previously reject it.

Let me know if you have any questions.

Happy coding!

A few weeks back I posted that: NodeJS is gonna kill PHP There are some merits to that statement. NodeJS is moving along quickly, with new modules getting added daily. Many of the web methodologies transition easily to Node Javascript is a strong language with a strong history of development. Asynchronous from the top to the bottom. AWESOME! YOU GET TO USE ALL THE JAVASCRIPT YOU’VE EVER WRITTEN. (emphasis added) Atwood’s Law (Anything that can be written in Javascript, will be written in Javascript) PHP is unable to advance. At the same time, I (almost) never consider an argument valid [...]

I’ve been thinking about practice lately—and about growth. Here are some thoughts: Programming is a complicated job. Many people see it as a craft, and as craftsmen, programmers must spend countless hours honing their skills and improving their expertise to reach a level to compete at the level they desire to be at. For example: If I want to build web pages at an amateur level, I simply need to know HTML, some CSS, and maybe some jQuery. For every question that might come up, there is usually a hundred answers on Google. If I want to do the same thing [...]