Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

drupal module pages

I'm having a conceptual sort of roadblock. So, I'd like to make a custom Drupal module, with several different pages, each of which "does stuff".

I'm not understanding how to make/integrate different pages into my module, and what their URLS would be.

I do have this :

 /* FILE : mymodule.module */
 function mymodule_menu() { 

   $items = array(); 
   $items['mymodule/landingpage'] = array( 
    'page callback' => 'mymodule_landing',
    'access arguments' => array('access content'),
    'type' => MENU_NORMAL_ITEM,
   );  
   return $items; 
 }

 function mymodule_landing() { 

   $title = 'Hello World'; 
   $content ='This is a simple Hello World Proof of Concept'; 
   return theme_box($tile, $content); 
 }

And when I go to mysite.com/mymodule/landingpage, I see the content generated by mymodule_landing().

But this doesn't seem like what I want to do because the content for landingpage is generated inside the mymodule.module, and it leaves me super confused about how I'd go about making my mysite.com/mymodule/step2, ... , mysite.com/mymodule/step99 pages

I have the gut feeling that the code for each page should be in it's own corresponding file, and I'm not understanding how to do it, this doesn't seem like the right way.

Can you explain how I should be doing it, where the file should go (with my other module files, right?), and what URL it would be viewable at?

like image 875
rlb.usa Avatar asked Mar 17 '11 21:03

rlb.usa


1 Answers

What you are doing so far is mostly correct (The "title" key is required for each item, so be sure to include that). Since the page callback is directed at mymodule_landing(), the content returned from that function will be displayed as your content on the page.

To make more pages (like step2, step99, etc) you would continue with creating more paths in mymodule_menu() like:

$items['mymodule/step2'] = array( 
  'title' => 'Step 2',  // Required
  'page callback' => 'mymodule_step2',
  'access arguments' => array('access content'),
  'type' => MENU_NORMAL_ITEM,
); 

And so forth... You could use the same page callback mymodule_landing() and simply pass "page arguments" or each can have its own page callback.

To put your function mymodule_landing() in a separate file, you can use the file and file path keys (see below)

 $items['mymodule/landingpage'] = array( 
   'title' => 'Landing Page',  // Required
   'page callback' => 'mymodule_landing',
   'access arguments' => array('access content'),
   'type' => MENU_NORMAL_ITEM,
   'file' => 'mymodule.pages.inc',
   'file path' => drupal_get_path('module', 'mymodule'),
 );  

You should put these files in your module directory (or sub-directory inside module directory and set the correct file path) and can access each page at mysite.com/mymodule/landingpage, mysite.com/mymodule/step2, etc.

Best Practices for Page Handler Include Files (read more at http://drupal.org/node/146172):

Module developers are free to split off page handlers for their modules however they choose. However, the following guidelines and standards are recommended:

  • Any module that has more than ~50 lines of code for page handler functions (including form handling functions if applicable) should split them off into a separate file. That reduces the overhead for PHP when loading modules, and therefore speeds up every single request on the site.
  • Page include files should be named in the form modulename.key.inc, where "modulename" is the name of the module and "key" is a one-word descriptive term for the types of page handlers it includes.
  • For most modules, splitting page handlers into two files -- example.admin.inc (for administrator-only pages) and example.pages.inc (for pages accessible by non-administrator users) -- is sufficient, and is the recommended practice. If a module has no non-administrator pages, it should just have a single example.admin.inc file. If a module has no administrator-only pages, it should just have a single example.pages.inc file.
  • Modules that have a large number of page handlers may choose to separate out page handlers even further. If so, each file should be grouped logically by function (for instance, admin pages related to theming, admin pages related to logging, other admin pages, and user-accessible pages) and clearly marked. Remember that splitting the module's page handlers up too far makes maintenance more difficult, and only one page handler include file is ever loaded regardless of how finely-grained the handler functions are separated.

Added just for reference: hook_menu() documentation

The page_example.module may also be of help to you.

like image 79
Laxman13 Avatar answered Oct 23 '22 05:10

Laxman13