Ted Bowman's picture

Ok, we have all heard it, and many of us have said it when we were starting out on our journey to learn Drupal development, "I didn't know how to make a module... so I just put some PHP code in a basic page."  It makes me cringe but hey, if you don't know how to make a module and you are in the middle of a project it can seem daunting.

Well, I am happy to say after you reach the end of this blog post you won't ever have to do this again. Wait, don't run, this is a very short blog post. Making a module is very easy! The source code for this example is available on the Custom Page Example sandbox project. Download the code.

Step 1: Make your module folder

I suggest putting your custom module folders in sites/all/modules/custom and modules you download from Drupal.org in sites/all/modules/contrib (short for contributed).  You could put all your folders in just sites/all/modules but I like to be able to tell quickly which modules have been created specifically for a project.

To make your folder you will need to choose the machine name of your module. Basically this is the unique identifier that Drupal will use to tell your module apart from all others.  To keep things simple, let's call our module, custompage. So this means you will create the folder sites/all/modules/custom/custompage.

Step 2: Make a .info file

The .info file determines how your module will show up on your modules administration page. It also lets Drupal know which version of Drupal your module is compatible with, in our case Drupal 7. 

You will use the same machine name that you created in Step #1 for the file name.  So your .info file will be sites/all/modules/custom/custompage/custompage.info.

The .info module file only needs 4 lines:

<code> name = Custom Page<br /> description = A custom page, no PHP in nodes!<br /> package = Current Project<br /> core = 7.x</code>

Here is a screenshot from the module administration page to demonstrate what effect these properties have:

Step 3: Make a .module file

The .module file will contain your actual PHP code.  In order for the PHP to run the file must start with "<?php".

After you have created this file you will need a way to tell Drupal to execute some PHP code when the browser is pointed at a particular URL ( or system path).  To do this we have to implement hook_menu, a Drupal Hook.  You can read more about the Drupal hook system here, but for our purposes it just means we are going to create a specially named function that Drupal will know to call and will let us define systems paths that we will associate with our other PHP functions.

Here is the function:

 

Look at the comments in the screenshot above or download the sandbox project to see the details of how this function works.  For our current purposes it is important to know that this will let the function custompage_output control the output for the system path custom-page (for example http://mysite.com/custom-page) and any user with the "View published content" will be able to access this page.

Now that we have told Drupal the system path that we want to control we have to create the function custompage_output referenced above to actually return back our output.  This function couldn't be simpler.

Callback function

As you can see we are only returning the string "Hello World" here but this is where you could put any PHP Code that you wanted.

Remember this is just a start.  You still should not just put all your business logic in page callbacks. If you are interested in getting a quick start in Drupal module development Six Mile Tech offers an Intro to Drupal Module Development course which explains the key concepts of programming for Drupal.

Feeds: 
Attachment: 

Comments

What is your justification here? To me, this is basically a justification for writing a custom module which you already acknowledge is understood as the best way to code. This is an effective demo of creating a "hello world" page callback in a module, but you lose all of the end-user node editing functionality because they can't change any content on the fly. This does not seem to work as a complete replacement to the PHP input filter.

Ted Bowman's picture

Adam thanks for reading on commenting.

What is your justification here? 

There are serious secruity and code maintenance issues with turning on the PHP filter and entering code in nodes directly.  There are some very good reasons listed here, the list in the answer was made by Berdir, a prolific core contributor and greggles, the Drupal Security Team Lead.

You can also read more about it on the Text filters and Input Formats handbook page. Some quotes from that page:

This effectively allows you to program and extend Drupal just by submitting content to the site! In 99% of cases, this is a bad idea, and the initial attraction of harnessing such power should be weighed by a healthy sense of fear. In most cases it is better to write a simple module instead of using the PHP Evaluator. 

and

Also worth reiterating is the fact that the PHP Evaluator filter poses an extreme risk if it can be used by anyone but highly trusted, PHP-competent site administrators. Most sites will be better off deleting the PHP code input format and not extending use of the PHP Evaluator filter to anyone.

Regarding your comment

you lose all of the end-user node editing functionality because they can't change any content on the fly

You only lose the ability to edit content on the fly if you are mixing content with PHP code which for reasons mentioned above is not a secure and sustainable method of Drupal development. PHP code is not content.

This does not seem to work as a complete replacement to the PHP input filter.

While this simple example may not easily replace what you are currently using the PHP Input filter for, learning the basics of Drupal module development and site building with contrib modules can replace the need to use PHP input filter at all.

The main point of the article is that making a module is not that hard.  If you are alreading writting PHP code that you are placing in a node you probably already have the skills to make a module. When I was first starting out I just didn't know how to get started writting a module.

Even though everyone working his way into Drupal soon is told to never put code into the database, this post has a fresh take.
Your encouraging way of explaining things - and yes, writing a module up to D7 is really _that_ simple - may win people over in a friendly style.

Ted Bowman's picture

Thanks, glad you liked the article.  I think the problem is most people just don't know where to start.

And what about blocks? How this can be applied to use php code in a block? Or Views exposed to the block should do the trick?

Ted Bowman's picture

Blocks are also pretty easy to make. I will put that on my list of tutorials to write but for now you can check out the Examples For Developers module.  There is submodule in that project called block_example.  It is very well commented example of how to define blocks in a module.

Add new comment

Online Trainings

Six Mile Tech offers online trainings via Skype, Google Hangout, or a screen sharing technology of your choice. These trainings can be used for generalized Drupal trainings or to tackle a specific problem for a site you are working on.