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?

1 Answer
1

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:

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.

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.