The SitePoint PHP blog has a tutorial posted for the Drupal users out there showing you how to use plugin derivatives effectively.

In this article we will explore the long answer to that and learn what derivates are and how we can use them. For the latter, we will build an example inside the demo module that can be found in this git repository and which should hopefully help us better understand what’s going on. For a slightly more complex example, the Menu system is great as it provides an individual block for each of its menus (similar to Drupal 7 but using plugins).

They're basically creating a system that allows the dynamic creation of Node Blocks for each of the article nodes but it's just an example of how (and not a recommendation on what you should do). They start in by talking about plugin derivatives - what they are and how they fit into the overall Drupal 8 code structure. The tutorial then shows the creation of the derivative class and explain each part of the code that makes it up. Following this is the other half of the functionality, is the block plugin class that will generate the instances of itself as requested.

The SitePoint PHP blog has a tutorial posted showing you how to build custom cTools in Drupal that will integrate with the widely used cTools tool set.

cTools is one of those critical Drupal 7 modules many others depend on. It provides a lot of APIs and functionality that makes life easier when developing modules. Views and Panels are just two examples of such powerhouses that depend on it. [...] In this article, we are going to take a look at cTools plugins, especially how we can create our very own. After a brief introduction, we will immediately go hands on with a custom module that will use the cTools plugins to make defining Drupal blocks nicer (more in tune to how we define them in Drupal 8).

He starts by briefly introducing the cTools functionality and different types of plugins included in common use. He then moves on to the "block_plugin" handling and the custom functionality you'll be walked through - a plugin encapsulating a block and its related logic. He starts by defining the plugin type with a function the cTools can locate and the code it should contain. From there the code needed to turn a block plugin into a "Drupal block" is added including a prefix to "namespace" them out. Finally the view handling is implemented and a helper function is created to load the plugin. He then shows how to define one of the block plugins complete with a title, markup and type.

On the Drupalize.me site they've posted a guide to getting started with Drupal 8 based on the boilerplate code that already comes with the release.

Drupal 8 represents a lot of changes and a steep learning curve for many Drupal developers and themers. While many of these changes are exciting, there are many things to learn just to get started. One way to learn about the code involved with Drupal 8 modules and themes is to take a look at core's modules and themes for examples to follow. Another is to use a code-scaffolding tool like Drupal Console to generate boilerplate code and comments that you can learn from and then customize.

He makes the assumption that you already have a development environment set up and working then helps you install the Drupal Console for use in the rest of the tutorial. You can then use this command line tool to create a new Drupal 8 installation and generate the boilerplate code for a new theme. Finally, they show the creation of the two other related components: a new module and a block plugin instance. These are generate generic code you can use as a reference point for either updating your current Drupal projects or create new ones.

Matthew Weier O'Phinnney has a new post to his blog filling in some additional details behind a series he's been doing on modules in the Zend Framework v2 releases. In this new post he answers the question "why modules?"

I've blogged about getting started with ZF2 modules, as well as about ZF2 modules you can already use. But after fielding some questions recently, I realized I should talk about why modules are important for the ZF2 ecosystem.

He covers some of the history of the idea, starting with the MVC rework/refactor of the framework and the desire from several people to have self-contained components that could be native to a ZF app. ZFv1 made it work (kinda) with Zend_Application, but it was difficult so solving this became a main focus of ZFv2. He illustrates with a "building block" metaphor based on his current blog site (currently being refactored too).

This kind of building-block development makes your job easier as a developer - and allows you to focus on the bits and pieces that make your site unique. As such, I truly feel that modules are the most important new feature of ZF2.

The NETTUTS.com site recommends that you don't ignore your WordPress footer and instead enhance it with some simple HTML and CSS.

Footers are often an overlooked aspect of designing a site - when they can actually be kinda handy and informative. In this tutorial we'll go through some options you can have for your WordPress site.

They take different bits of information - archived posts, the "about" message and some links - and arrange them in a sidebar sort of format. This is then styled to work more like a footer, moving it down to the bottom of the page and laid out horizontally. The complete code for the tutorial can be dropped easily into the wp-content folder (named "WPFooter").

In the first of his "I will insult your code" series, Nate Abele looks at this submitted code and points out that maybe blocks of switch/case statements aren't such a good idea after all.

The entire submission is actually two files, which together comprise a console script for interacting with a web service (the names of the entrants have been withheld to protect the identities of the guilty). Rather than examine the full entry, we're going to take a look at one part which I find comes up fairly often: switch block overkill.

The example he's talking about has a switch statement with eight different cases under it, most of them just setting two properties on the current class. Its used ot map command line parameters to their correct properties. Nate suggests a bit different method - still using switch/case but pulling the properties to be assigned from an array of options rather than hard-coding them into the evaluation.

Lars Strojny has posted about a the new element that's been introduced in the PHP 5.3 branch - NOWDOC:

PHP 5.3 introduces a new syntax element, NOWDOC. If you know HEREDOC, NOWDOC is easy to understand: it is in fact HEREDOC taken literally. Whily variables are expanded in HEREDOC, in NOWDOC they are not.

NOWDOC is basically a HEREDOC except for one thing - no parsing is done inside of it, making it good for echoing out PHP code (that would otherwise need to be escaped all over).

On the {H{Riot.com site today, there's a new tutorial talking about how to customize your site's Smarty templates a bit more using external plug-ins, specifically one for making those "code block" sections seen all over the web.

We will first learn how block plug-ins can be used in your templates, and then learn how to create our own. Once we know how to create a block plug-in, we will cover a practical example that will show you how block plug-ins can effectively be used in your own web sites.

The tutorial assumes that you already have Smarty installed and that you're familiar enough with it to know how to work with the plug-in system right away. They include some samples of how it can be used (a default block, formatting it with HTML) and, of course, how to integrate this (PHP code and all) into your template and push your content into it.

In a quick new post from Brent Meshier today, he shows us how, with the help of a database CVS file, to block visitors to your site from certain locales.

A client asked me last night if it was possible to block certain countries from accessing his website. He's concerned about the "axis of evil" and their comrades downloading his software. The task is easily accomplished, although it's like using a sledge hammer to tap in a finishing nail. He didn't seem too concerned that we could accidentally block Uzbekistan in the process. Unfortunately his entire site uses plain .html files, no dynamic scripting. This led me to using a slightly creative solution with .htaccess.

Broken up into five simple steps, he makes a light function to drop into an output buffering function to tell it to either show the normal content or return a 401 Unauthorized header to the visitor.

In a quick new post from Brent Meshier today, he shows us how, with the help of a database CVS file, to block visitors to your site from certain locales.

A client asked me last night if it was possible to block certain countries from accessing his website. He's concerned about the "axis of evil" and their comrades downloading his software. The task is easily accomplished, although it's like using a sledge hammer to tap in a finishing nail. He didn't seem too concerned that we could accidentally block Uzbekistan in the process. Unfortunately his entire site uses plain .html files, no dynamic scripting. This led me to using a slightly creative solution with .htaccess.

Broken up into five simple steps, he makes a light function to drop into an output buffering function to tell it to either show the normal content or return a 401 Unauthorized header to the visitor.