by Robert Basic on July 20th, 2010
OK, here’s a quicky one from the office :P
I was trying to load a Front Controller plugin which resides in app/modules/my_module/controllers/plugins/ and not in the “usual” lib/My_App/Plugin/. I want this plugin to be called in every request and I want the plugin file to be under it’s “parent” module.
Here’s what I did: added the path to the plugin and it’s namespace to the Zend_Application_Module_Autoloader as a new resource type and then just register the plugin in the front controller in an other _init method.
Code is better, here’s some:
class News_Bootstrap extends Zend_Application_Module_Bootstrap
{
/**
* Autoloader for the "news" module
*
* @return Zend_Application_Module_Autoloader
*/
public function _initNewsAutoload()
{
$moduleLoader = new Zend_Application_Module_Autoloader(
array(
'namespace' => 'News',
'basePath' => APPLICATION_PATH . '/modules/news'
)
);
// adding model resources to the autoloader
$moduleLoader->addResourceTypes(
array(
'plugins' => array(
'path' => 'controllers/plugins',
'namespace' => 'Controller_Plugin'
)
)
);
return $moduleLoader;
}
public function _initPlugins()
{
$this->bootstrap('frontcontroller');
$fc = $this->getResource('frontcontroller');
$fc->registerPlugin(new News_Controller_Plugin_Scheduler());
}
}
If anyone knows a better way for doing this, please do share it with me.
Now back to work. Cheerio.
by Robert Basic on July 11th, 2010
As I said 2 weeks earlier, I decided to move my stuff over to linode. Well, I did it. Kinda.
First step was to change the nameservers of the domain. I thought it’s gonna take a while, so I took my time with moving the files and the database, but (at least on my end) the dns changes were alive and kickin’ under an hour.
My original idea was to run everything on nginx, but that soon turned out to be a bad idea cause there was no way I could setup properly the rewriting – if PHP was working right, CSS was broken. If CSS was working right, PHP was broken. At one point I broke everything. Hooray for me. Then I just took down nginx and all that php-fastcgi stuff and installed apache. Everything is lovely once again, the world is all shiny and pink and full of rainbows and unicorns. But fear not, I will not let nginx beat me in this mad game of rewrites! Just have to do that somewhere else, not on a live server.
Now to setup the emails and my job here is done. Oh, and the sidebar is a tad broken. Sorry bout that.
Carry on now, nothing left to see here.
Tags:
about,
me,
moving.
Categories:
Blablabla.
Comments:
2 comments.
by Robert Basic on June 27th, 2010
Just a little heads up to all of you who stumble upon this place: I’ll be moving servers and stuff in the coming month to linode and most likely there’ll be some downtimes and fuckups so just thought to let you all know (this sounds like there’s someone reading this blog at all, heh).
Hope I won’t forget to make backups.
Tags:
about,
me,
moving.
Categories:
Blablabla.
Comments:
4 comments.
by Robert Basic on April 27th, 2010
I’m using Netbeans as my main IDE for PHP and Python projects for over a year now, yet only now I have stumbled upon this feature – creating filters for tasks that show up in the “Tasks” window (Ctrl+6 shortcut to show/hide the window).

Task filters

Setting rules for the filter
To be honest, I wasn’t even using it (until now), cause, by default it shows all the todo-s and issues from all the files from the current project. This can produce a pretty big list if (like me) you have Zend Framework, Pear and other frameworks and libraries set on the include path for the project you’re working in, as the little @todo-s will show up from those files, too.
Filters to the rescue. On the “Tasks” window there’s that little icon of that whatever-it’s-called showed on the first image, where you can create and edit filters. I’ve created a simple one, which excludes todo-s from files that have “Zend” in their location and includes only from PHP files (second image).
Me likes this feature.
by Robert Basic on April 21st, 2010
I just hacked up a little code snippet based on Matthew’s Honeypot WordPress plugin. It’s basically just a Validator for a Zend Form element which is hidden from the user via CSS. Cause it’s hidden, users won’t see it, but spambots will, well, cause they are bots.
If the element is left empty, it’s valid, otherwise it’s not.
So, here’s the code:
class App_Validate_Honeypot extends Zend_Validate_Abstract
{
const SPAM = 'spam';
protected $_messageTemplates = array(
self::SPAM => "I think you're a spambot. Sorry."
);
public function isValid($value, $context=null)
{
$value = (string)$value;
$this->_setValue($value);
if(is_string($value) and $value == ''){
return true;
}
$this->_error(self::SPAM);
return false;
}
}
I add the element to the form like this:
$this->addElement(
'text',
'honeypot',
array(
'label' => 'Honeypot',
'required' => false,
'class' => 'honeypot',
'decorators' => array('ViewHelper'),
'validators' => array(
array(
'validator' => 'Honeypot'
)
)
)
);
There. Done.
Happy hackin’!