I just got done putting up my second website using Drupal as the CMS. The site can be found at http://www.maywoodband.com. This site is home to my band, Maywood. It includes both public and private forums, picture and video galleries, and a customized theme. And it took me only two days of work to get running. To anyone who says that Drupal is hard to work with, I say: Two Days. Not bad for a “steep learning curve”.
So I’m posted a boatload of entries about Drupal, but why am I learning all about it? Well, first of all, it’s friggin’ sweet, but that’s not why I got interested to begin with. I’ve got a project, and I want to get it to the web quickly.
Enter Drupal.
One of my good friends, and occasional contributor to this blog, Sol Kleinsmith, turned me on to the idea of open source content management systems. He chewed my ear off one night over beer and wine about Drupal, I did some research, and was immediately hooked. Ha! Hooked! I’m making Drupal jokes already! (see some of the other posts about Drupal to … well… see how big of a nerd I just was.)
One of the things I was looking for was the ability to extend functionality. My project involves storing, retrieving, and comparing information about different computer systems. Obviously this is pretty specific, and there’s no built in functionality that can be used to achieve this in Drupal. Custom Modules are going to have to be written.
So if you continue to read these posts, you’ll learn how to put together a new custom Module that takes in and stores information in a MySQL database, makes it searchable, compares like information, and displays it in a readable, customizable fashion. Pretty much anything and everything you can do with Drupal, I’m going to try to do.
If you want to check out my work, click on the link below:
And if you’re feeling brave, sign up and start posting in the forums!
Creating a new Module is as simple as creating a handful of files, as long as you know what to call them and where they should be placed. Oh, and you have to know PHP. Details, details…
If you’ve explored the directory structure of your Drupal installation, you might have found a few directories of interest. Specifically, there’s a modules directory in the root of your Drupal installation, which holds the Drupal core modules. You might have also found the sites/all/modules directory. This is where you want to work when writing and installing custom Modules.
When creating a new Module, there are a handful of standard files that are generated. When you write a new Module, the first thing you do is give it a short but meaningful name. For this example, we’ll use the name “modulename”.
The first time you create a new Module, you’ll need to create some directories in the sites/all/modules directory. In order to make changes and updates to downloaded Modules easier, you’ll probably want to create a custom directory. Then, inside the custom directory, create a directory, named after the Module, for each custom Module you’re creating. So, in our case, we’ll be creating a modulename directory. So we end up with:
sites/all/modules/custom/modulename
Once you get the directories all set up, you’ll create the following basic files:
Readme.txt . . . This file describes what your Module does, just in case someone else has to take over maintenance.
modulename.info . . . This file provides information to the Drupal Core about the new Module. We’ll get more into the use and structure of this file later.
modulename.module . . . This is where the meat of the module will reside. Hooks are implemented here. This is another that we’ll get into in greater detail in a future blog entry. Just know for now that you’ll be spending a lot of time in this file.
modulename.admin.inc . . . This file isn’t mandatory, but if you have any kind of configuration in your module, you’ll probably me creating this file. It holds information about administrative forms. Stay tuned for more on this file.
So there really isn’t too much to creating a simple Drupal Module. I’ll get much, much deeper into development in future posts. Keep reading and learn as I do!
Before we get started with development, there are some terms that need to be defined. It’s important that we keep these concepts straight, because it can get pretty confusing if we don’t. So here are some terms and concepts that we’ll need to know before going any further:
Modules . . . The most fundamental concept in Drupal development is the Module. A Module, to put it simply, is a container of code that introduces some sort of behavior to the system. For example, there is a Module that handles Ad Sense publishing. There is a Module that allows you to run forums. There is a Module for blogging. Modules can be enabled and disabled (except for certain modules that are required to run the basic Drupal framework). Custom functionality is added to Drupal by way of custom Modules.
Hooks . . . In order to let Drupal know about newly added functionality, we use Hooks. If you’ve done any event-based programming in the past, you’ve probably heard of callback functions. For those new to the idea, basically what you’re doing is letting a control loop know about functions you’ve written to handle certain events. That’s what Drupal’s Hook system is all about. When you define a Hook function, you’re letting Drupal know you’ve written a function that handles a certain circumstance. I’ll get into a lot more detail in a future entry, but just know for now that Hooks are how you integrate your code with the Drupal core code.
Themes . . . When it comes to presenting information on the web, there are really two parts to the story. There’s the information you’re presenting and then there’s the format you’re presenting it in. That’s where Drupal Themes come in. Themes can be thought of as the presentation part of the system. They define, through HTML markup and CSS code, how the data is displayed on your users’ browser. Again, more detail to come, but know that you should have a good working knowledge of HTML, CSS, and PHP in order to effectively work with Drupal Themes.
Nodes . . . If Modules contain code for dealing with events, hooks define those events, and Themes define presentation, then Nodes define the actual types of content Drupal can deal with. I know this can be a little confusing, and you’re probably wondering why the designers of Drupal would take this approach. Basically, it allows content types to exist independently of functionality, and allows you to apply any functionality to any content you like. Believe me, it’s very cool, and after you get past any confusion, you’ll really like it.
Blocks . . . So how do you take all that great information in your Nodes, press it through the code in your Modules, and display it on the screen? Through Blocks, of course! Well, maybe it’s not that obvious, but that’s how it’s done. Blocks are regions where information is displayed. An example of a block from the Drupal Core would be the Login Block, where you enter your login information. The Block displays a login prompt when no-one is logged in, then displays a menu of options that is dependent on your level of access.
Over the past few months, I’ve been working on a website project in my spare time. In order to speed up deployment of the site, I decided to use Drupal.
While Drupal, with all it’s addons and plugins and themes, is a very complete system for people making community portals, e-commerce websites, internal intranets, and many other flavors of website, it doesn’t quite handle the concept of my project. Because of this, I’m going to be learning how to extend Drupal’s basic functionality.
In order to make my life a bit easier, I purchased a copy of Pro Drupal Development, Second Edition. I’m hoping the book can help me figure out how to properly and cleanly add the functionality I’m looking for. I thumbed through it, and things look promising.
So, in the spirit of sharing, I’m going to be posting my personal notes on Drupal development. I’ll post one installment every week, Monday morning at around 8am. I’m going to cover everything from how to set up your initial installation to how to add custom modules.
You are an Digital Collaborator
If you are a Digital Collaborator, you use information technology to work with and share your creations with others. You are enthusiastic about how ICTs help you connect with others and confident in your ability to manage digital devices and information. For you, the digital commons can be a camp, a lab, or a theater group – places to gather with others to develop something new.
Yup, that’s me… a “Digital Collaborator”. I’d better be, since I work in IT. Find out what kind of tech user you are by visiting PewInternet.org and taking their quiz.
A while back, I wrote an article about a situation my brother-in-law was living through. A few kids he knows at his school were sending him mean, nasty text messages, and it was really starting to get to him. With time, some conversations with people who know and love him, and a thickening of his skin, he was able to start ignoring the stupid messages he was getting and move on. He's a good kid, and knows that people say and do dumb things. He's no worse for it, and from what I know, it has stopped and doesn't bother him any more.
Other kids are not as fortunate as my brother-in-law, and don't necessarily have the tech-savvy and attentive parents, brothers, and sisters that he does. Some kids are left to deal with this sort of thing on their own. It is with that in mind that HR 1966 was introduced to the United States House of Representatives on April 2nd, 2009. The bill, known as the "Megan Meier Cyberbullying Prevention Act," is designed to prevent and punish bullying using electronic means, such as "email, instant messaging, blogs, websites, telephones, and text messages." The bill would amend United States Code Title 18, Chapter 41, which is the section on extortion and threats. It would make harassment by electron means punishable by fines and up to two years in prison.
While I have no issue with the spirit of the bill, I have a giant, monumental problem with the way it is written. Section 3 of the bill adds a new section to Title 18, Chapter 41 of United States Code that reads:
SEC. 3. CYBERBULLYING.
(a) In General- Chapter 41 of title 18, United States Code, is amended by adding at the end the following:
`Sec. 881. Cyberbullying
`(a) Whoever transmits in interstate or foreign commerce any communication, with the intent to coerce, intimidate, harass, or cause substantial emotional distress to a person, using electronic means to support severe, repeated, and hostile behavior, shall be fined under this title or imprisoned not more than two years, or both.
`(b) As used in this section--
`(1) the term `communication' means the electronic transmission, between or among points specified by the user, of information of the user's choosing, without change in the form or content of the information as sent and received; and
`(2) the term `electronic means' means any equipment dependent on electrical power to access an information service, including email, instant messaging, blogs, websites, telephones, and text messages.'.
(b) Clerical Amendment- The table of sections at the beginning of chapter 41 of title 18, United States Code, is amended by adding at the end the following new item:
`881. Cyberbullying.'.
Parts (a) and (b) of the proposed amendment to United States Code basically states that anyone writing anything that could cause "substantial emotional distress to a person" could be prosecuted. Even the use of the word "coerce" is questionable, since there are plenty of websites in the internet designed to convince their audience of something. And the inclusion of "blogs, websites" in part (b) makes all bloggers and web journalists vulnerable to prosecution if they publish something someone doesn't like.
Now, don't misunderstand, I do support legislation that protects kids. Having been bullied a bit myself when I was younger, I understand that it can cause all sorts of social and emotional problems. So I would like to propose a solution: A change of wording. Just add an age-specifying phase, such as "at or below the age of 18" to part (a), so it reads:
`(a) Whoever transmits in interstate or foreign commerce any communication, with the intent to coerce, intimidate, harass, or cause substantial emotional distress to a person at or below the age of 18, using electronic means to support severe, repeated, and hostile behavior, shall be fined under this title or imprisoned not more than two years, or both.
I believe this would still offer the protection that is the heart of the bill, but would eliminate the big-brother type worries that currently surround the proposed amendment. After all, isn't the intent to protect kids under the age of 19 from potential threats, not limit the freedoms of our country's blogging and journalistic communities?
The debate on Internet neutrality, or “net neutrality”, will come to a head in a vote by European politicians on May 5th, according to ComputerworldUK.com. The article, written by Glyn Moody, outlines beautifully just exactly what is at stake.
One of the biggest problems surrounding the net neutrality debate is the fact that many people, especially politicians, seem to understand what allowing ISPs to shape network traffic really means. The ISPs claim it will allow them to more effectively allocate their limited bandwidth, but the end result will actually be that they have the ability to limit access to content served by competitors. It will also allow ISPs to cap the bandwidth available to their users, while charging outrageous premiums for access to bandwidth considered above and beyond what they have deemed necessary for home use.
Click here to read Glyn Moody’s article, written for ComputerworldUK.com.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
