Drupal 7

Installing multi-core Apache Solr 4.x on Debian, Ubuntu, Red Hat, CentOS, and more

I've installed Apache Solr on a range of servers over the years. The consistent problems are I don't do it enough to memorize it, but it's enough to be frustratingly repetitive. I end up researching the process every time. I've discovered this is a common problem for many people. There are numerous blog posts describing the process in detail. Download this, configure that, etc. This time I needed to install Solr on two local dev machines, the staging server, and the production server. I thought: "Four times? Nope, I'm scripting this!"

The definitive Drupal "Field API Option List vs. Taxonomy" pro & con list

Here I am building out a content type for a new project again. I've got to decide whether to use a Option List field or a Taxonomy field. It's an easy choice right? Right? Once you think far enough down a site roadmap, you'll discover it rarely becomes a simple answer. I've read many articles on the subject and nothing I've found seems to cover all details. That being said, if you find any details or related links I've missed be sure to let me know in the comments.

Making a custom block with an admin settings form in a Drupal module

Often while building a Drupal website, you'll need to create a custom Block containing HTML and content. Completely standard right? It's a problem when your client or the site maintainer needs to change some of that content. They are forced to wade through significant amounts of HTML to find that little bit of content to update. Instead, why don't you build a custom settings page? Your site maintainer gets a simple form to update and you get variables to output.

Using theme hooks to display a tpl.php on a menu path

The Node, Views and Panels modules can (and should!) handle most pages you need on a site, but sometimes you need complete control of a "hard coded" content area. You could create a new Page node with a Full HTML text format. Instead, how about putting the whole thing in code? Your work will be in version control and much more straightforward to maintain. Imagine editing HTML in a text editor rather than in the Drupal admin! So much better.

Programmatically creating nodes using Entity Wrapper

Creating nodes via the UI in Drupal is easy, creating or updating them programmatically(in code) has always been a tedious. I've nearly lost my mind staring into the depths of a dpm($node);

The problem was the lack of straightforward API to handle the field level CRUD. You had to manually shove correctly formatted data into an object, often by comparing against an existing node's array. The correct old process went(and still can if you want!) like this:

Get the renderable array for a single field instance

I'm building an interface to simplify the user experience during content creation. Users select options in three <select> fields, then on submit, they are forwarded to the correct content type add node form for the options selected. Some of the values from the original form will be be pre-filled in the new node add form.
To create this new form, I need fields from the content types and user profile. Given a content type, field name, and field instance, this is the code you need to get the Form API renderable array for the field.


Subscribe to Drupal 7