If you’re coding for the web, you almost certainly have encountered frameworks that make use of the Dependency Injection Container. Incredibly useful – but what is it?
In the most simplistic way – it’s just a great big bag of stuff. That’s it. There’s nothing magical about the container, it’s simply an object that stores references to other objects. Combined with a liberal use of Interfaces, this allows for a high level of abstraction and therefore also aids in unit testing smaller code parts.
For example, if you’re injecting the entire DIC into a component, you are metaphorically handing that component a great big bag of stuff and saying “here’s what we have to work with. Ask for it by name.” The component may then access the container and all configured dependencies.
You may well now be saying “well that sounds a bit like code soup” – and you’d be right. Normally, you’d only inject the dependencies that a component requires (and not the whole bag). The major frameworks (e.g. Laravel, Symfony, Zend) feature Dependency Injection Containers and an associated service locator and dependency manager. These are no longer simply “great big bags of stuff“, but true DI systems that allow for a high level of abstraction.
For a super simple Dependency Injection Container, see Pimple (by Sensio Labs). This is a great place to get started with understanding how a system will utilise a DIC. It is super simple, and forces you to understand how things are bootstrapped and provided for your system.
For more detailed information on dependency injection, see these links:
Opening a Terminal to the extracted directory, I then compiled the code:
$make&&sudo make install
As I did not have autoconf, I installed it using Brew. Alternatively, you can compile it from source if you do not have Brew.
$brew install autoconf
The next few steps are where I had some problems. I was getting strange errors:
fatal error: 'php.h' file not found
and "ERROR: `phpize' failed"
Digging around, it turns out there’s a bit of a strange bug here. It can be quite simply solved by downloading/updating XCode from the App Store and symlinking the XCode SDK headers to the MAMP directory:
Here’s a WordPress snippet to remove RSS feeds for comments while keeping the main one available.
RSS is super nifty. It’s a great way to keep on top of breaking news and articles from your favourite blogs and/or aggregators (I’ve got over 100 subscriptions in my feedly reader).
So it’s a wonder then that WordPress offers RSS feeds for comments on all your posts. I presume there’s a group of people who really like to track conversations, but in my experience, it’s the minority. This functionality should really be an additional (and not core) part of WordPress. If you want to prevent your site serving pointless additional RSS feeds, you’ll need to remove them from wp_head.
Removing them, however, is a two-step process. Add the following to your functions.php file:
// First, we remove all the RSS feed links from wp_head using remove_action
// We then need to reinsert the main RSS feed by using add_action to call our function
// This function will reinsert the main RSS feed *after* the others have been removed
And that’s it. The first two actions strip the RSS using remove_action with a high priority. The final add_action call tells WordPress to load our function when processing wp_head. This will go through and reinsert the main feed, leaving the comment feed out.
Congratulations! Your post conversations are now untrackable.
* Drop the table and options associated with the plugin
* @return void
I would fully expect the system to execute the functions hooked within the constructor. Had that been the case, I wouldn’t have lost a day debugging a non-existant problem.
Finding a solution
Of course, everyone’s setup is different. There were many suggestions for fixing the problem. For the sake of usefulness, here’s the other major suggestion:
Your global variables aren’t global
If (like me), your plugin is a global, you actually need to explicitly define it as such with the global keyword. For example, the snippet
should instead by written this way:
Why? Well, for this, we need to consider how the plugin has its code loaded. After installation, your plugin has its code included “normally” with standard includes. This creates the global scope that you would expect. However, when you register a function with register_(de)activation_hook, it is called from within another function’s scope, effectively hiding your non-explicit globals.
Confused? Consider the plugin example from earlier. The variable $my_instagram is declared in the global scope, with global visibility. When your code executes, your plugin is included at the same scope, meaning you will have access to the variable (as they share the same suitably-high scope). Due to the way the hook/filter system in WordPress works, your activation/deactivation hooks are executed within a localised (not global) scope.
This scope-confusion applies to all functions created using create_function, or (in our specific example), functions called with call_user_func (and call_user_func_array). These functions have their own scope and are thus shielded from the cheap-and-nasty pile of implicit “globals” that haven’t been properly declared as such.
You can find a suitably more technical (and probably correct) write-up at the WordPress Codex page for register_activation_hook.
tl;dr: Explicitly declare your globals if you want them to work everywhere.
Ok, that’s great, but what’s the answer?
After having accidentally (and rather unwillingly) been given a very rough refresher on scope, I found that this was not my problem at all. Even running proxy functions (which eliminates scope issues) failed to call the functions specified in the hook.
After much trial and error (and I mean much), I found that the paths within register_(de)activation_hook were not matching the path found in plugin_dir_path. In fact, __FILE__ was returning a completely different path.
The problem? I had symlinked the theme directory in my install, meaning that __FILE__ returned a different path to plugin_dir_path. This is especially important, as the file path specified by the first parameter of register_(de)activation_hook is included before the function specified by the second parameter is called. So, if the path in the first parameter is wrong, you probably aren’t going to be executing many functions today.
This is always my favourite part. To fix the symlinking problem, you just have to be very specific when you’re asking WordPress to execute a hook for you.
* Drop the table and options associated with the plugin
* @return void
The most important changes occur on lines 1, 16, and 17. The first line fixes the definition by manually specifying the path using the base plugin directory (instead of an automagic WordPress search). Lines 16 and 17 specify the main plugin file itself as the path (instead of relying on __FILE__).
This allowed WordPress to find the plugin files without a hitch, which is especially important in the installation/uninstallation phases.
I don’t normally plug work that I do in my daily grind, but this one is for super-great cause. Instead of our usual advertising selves, we’re using our powers for good and completely upgrading the National Breast Cancer Foundation‘s Pink Ribbon Breakfast site. Their goal is to have 0 deaths by 2030, which is a pretty nice goal all-round.
Are you using Zend? Do you have only a core controller and don’t need extraneous URL parameters? Try this.
Most of the time, I am using Zend Framework to its (mostly) full capacity. Models, Controllers, View Helpers – the whole box-and-dice. However, there has been several occasions where I’ve only needed a single controller serving up mostly static pages, or pages leveraging an external service.
The biggest problem that arises in this case when using the default Zend Router, is that action names are treated as controller names. I don’t know about you, but I personally hate seeing http://example.com/index/my-action when what I actually want to see is http://example.com/my-action.
Here’s a nice way to completely tidy up all your actions, serving them from a single controller. (I use a Bootstrap file to initialise my application):
This basically says that my first parameter is always going to be an action name, and everything else is to be parsed as normal. I set request defaults in the array. In this case, the default controller is “index”. This allows everything to be passed straight through to my IndexController.
Addtionally, if you are using modules and want to retain routing for these also (for example, a one-controller site with an admin module), you can add this route rule to your system:
This says that anything starting with “admin” needs to be routed to the admin module, and the rest of the URL is to be parsed as normal.
That’s it! This will allow you to route all requests to a single controller for the front-end, and still maintain a complete module for the administration on the back-end.
Hopefully this cleared up some things for others, as I found the Zend Framework documentation to be quite dismal.
Originally, I was getting the “Memcache::addServer function expects at most 6 parameters, 8 given” warning. To force Zend to play nice with memcache (and send the right parameter count), you need to make sure you have the compatibility option set to true in the backend options array.
Here’s an example on how to use:
Hope this helps in getting started with Zend_Cache (even on a technology as old as memcache).