WordPress Development for Beginners: Widgets and Menus

Widgets and menus are generally your first port of call when making customizations to a WordPress site. Not only do they allow you place and display content anywhere on your site (that is widget-ready, of course, in the case of widgets) but they’re also noteworthy features for any potential users of your themes.

While adding widgets and menus to your theme ultimately involves some coding expertise, the actual PHP needed is straightforward to implement. Once you’ve got your head around the logic you can then put your CSS skills to use styling how your sidebars and menus look and feel.

This is the fourth post in our five-part series for beginners, teaching you the fundamental concepts of WordPress development so you can take the leap from tinkerer to developer. By the end of the series, you will be able to create your own rudimentary themes and plugins, and flesh them out with your own features.

In this tutorial, you’ll learn how to code and customize your own sidebars and menus. We’ll also delve into coding custom queries for more complex functionality.

Note: For this series, it’s important that you already have a thorough understanding of HTML and CSS as both of these languages are essential building blocks when working with WordPress.

Let’s get started.

Missed a tutorial in our WordPress Development for Beginners series? You can catch up on all five posts here:

Working with Widgetized Areas

What many people call sidebars are actually widgetized areas. Sometimes they do indeed display in the sidebar area, but this isn’t always necessarily the case.

Widget areas can be displayed anywhere on your site and where exactly is really up to you as the theme developer. You might want to display one widget in the footer, another underneath a post, one hidden behind a menu, and so on.

You also need to tell WordPress that you plan on creating a widgetized area. This is called registering a sidebar and makes the user interface show up in the admin.

In part three of this series, WordPress Development for Beginners: An Introduction to Theme Development, we created a functions.php file. Let’s make the main content for the theme we’ve been working on a bit narrower and add a second column for the sidebar. We’ll register the sidebar first so add the following to your functions.php file:

If you don’t understand the add_action() bit don’t worry, we haven’t covered it yet! (We’ll look at it in the next post in this series, WordPress Development for Beginners: Building Plugins.

The meat of the matter is in the mat_widget_areas() function. We use the register_sidebar() function to tell WordPress all the details of our widgetized area.

The name and description parameters will be displayed in the admin user interface, so make them descriptive! Each widget will be wrapped in the code provided in the before and after widget parameters. Use %1$s as a placeholder for the ID and %2$s for any classes and WordPress will generate these automatically.

Once you’ve saved this code, you should see the new Widgets sub-section display within the Appearance menu and our widget area should show up with the given details.

Widget Area in WordPress
Widget Area in WordPress

So far so good. You can now add widgets to this widgetized area as you normally would, but it won’t show up anywhere since we haven’t added it to our theme code just yet.

Create a sidebar.php file and add the following to it: <div id="site-sidebar">This is my sidebar</div>

We’ll need to modify our header and footer files to accommodate a sidebar. The structure we’ll be looking for is the following:

To implement this, we need to open the #site-container div in the header and close it in the footer. We’ll also need to include our sidebar in the footer. It contains the #site-sidebar element.

Here is the final form of the header and footer files for reference:

As you can see, the sidebar file can be pulled in using the get_sidebar() function. At this point, you should see “This is my sidebar” under your content but by adding some styling we can put the sidebar next to our content.

Here are the modifications I’ve made and the new additions and modifications in code form:

  • I modified #site-content to decrease the max-width to 525px and added a left float
  • I added #site-sidebar giving it a 220px width, 22px border, a border radius and white background just like the content and I floated it to the right
  • I added #site-container making it as wide as the cumulative width of the content and sidebar and centering it.
  • I added a clear rule to the footer to force it below the floated elements.

The last piece of the puzzle is to tell WordPress to display all the widgets assigned to our sidebar. This can be done with the dynamic_sidebar() function, adding the ID of our sidebar as the first parameter.

Here’s what the sidebar.php file looks like in the end:

The test theme should now show a narrower content area and a small widget area on the right displaying the chosen widgets. It’s ugly, but nothing a little CSS later can’t fix!

Our Theme sidebar.
Our Theme sidebar.

Widgets: What’s We’ve Learned

That might have been a bit overwhelming if this was your first time implementing a sidebar so let’s recap.

To add a sidebar to WordPress you need to add the following steps:

  • Register the sidebar using register_sidebar()
  • Use dynamic_sidebar() in sidebar.php to pull in your widgets
  • Use get_sidebar() to include the sidebar in the appropriate place
  • Use CSS to style your work

Working with Menus

Menus are similar in their logic to widgetized areas. You first need to register them so they show up in the WordPress admin and then add them to your theme using a function.

Let’s start by registering a new menu in our functions.php file:

This function allows you to add multiple menus by adding members to the array. The array key is the name of the theme location and the value is the name of the menu itself.

Once you’ve done this you can start assembling a menu. Make sure to add some items and then assign the menu to the Our Awesome Header Menu” location, as pictured below.

Putting together our menu.
Putting together our menu.

Wherever you want to output the menu, simplu use the wp_nav_menu() function. I’ll be adding it to the header file right under the #site-header element, like so:

The wp_nav_menu() function takes a bunch of parameters you can use to control the output. The theme location is what really matters for us, though. Take a look at the function documentation in the WordPress Codex for a more in-depth explanation.

Finally, I’ll add some basic styling to make things half-presentable. Excuse the ugliness – it can all be taken care of with some carefully crafted CSS (though that’s not the main focus of this article).

Further Reading and Study

There are many of requirements a theme must meet to be considered for inclusion in the WordPress Theme Directory. We’ve only just scratched the surface and you should now have enough knowledge to start picking away at adding more functionality to your theme. I recommend installing the Theme Check plugin, which will analyze your theme and show you what needs to be done to meet the WordPress Theme Review Team’s requirements.

A few things you should add include a 404 page, perhaps a dedicated view for search results, pagination and a number of other elements everyday websites use all the time, like an about page and contact page. Once you’ve pinned down all the requirements you might want to use the theme customizer to allow any future users of your theme to select their own colors and other options.

We’ve covered the basics of theme development and there’s much more to learn, but as long as you practice you should do just fine. That’s how I learned: bit by bit.

Check back next week for the final post in this series, WordPress Development for Beginners: Building Plugins.

In the meantime, you should:

Did you find this tutorial helpful? Why do you want to learn WordPress development? What do you want to know more about? Let us know in the comments below.

9 Responses

  • Mr. LetsFixTheWorld

    @jeffrey_carandang – While I agree that it’s good for HTML5 to be incorporated into modern documentation, I think that adds a layer of complexity that this tutorial doesn’t need. For anyone using existing themes, some are based on HTML5 and others not – if this article had been based on HTML5 someone could have asked “why not use Divs” with equal justification. Sure, it’s good to start new developers with the latest technology. But as soon as you mention Aside and Section, the new developer would need to understand why those specific elements were used, whereas with Div, which is “basic” HTML, there’s no need to explain – it’s just a container, it doesn’t matter what kind of container.

    As an example, I was confused recently by another tutorial that did use HTML5, naming the menu “nav” in theme location “nav” with a walker building a HTML5 “nav” tag. Ugh. You and I might get that, but it just serves to confuse noobs who are the audience for tutorials like this – and I consider myself a WP noob so I wish the author didn’t do that.

  • Mr. LetsFixTheWorld

    Thanks for the article series. It’s helping to fill in gaps and to prepare me for further reading.

    It was an interesting choice to combine widgets and menus into a single blog. You could easily have gotten two articles out of it given the depth of the topics. But I appreciate the simplicity of presenting just the fundamentals here.

    Trivial typos: 1) In footer-mod.php, the second /Div is tagged ‘site content’ and should be ‘site container’. 2) The summary for “Widgets: What’s We’ve Learned” should be “What We’ve Learned”.

    Regarding the Div ID “header-menu” wrapping the theme location “header-menu” : Is it a general convention to name these the same? Personal convention? Coincidence? As a developer I (believe I) understand that these are separate and unrelated, but someone new to development in general might think that the names Must be the same.

    I’m a long-time developer but new to the nuances of the WP framework. The summary for widgets speaks to me directly in concise terms that I appreciate. Actually, I’d get more from a summary view of the API first, where with a tutorial first we don’t know where it’s going so it’s a little tougher.

    Breaking up my comments to welcome separate responses…

  • Mr. LetsFixTheWorld

    This article starts with the clarification that a “sidebar” really isn’t just for the side, it’s more of a “widget area” that can put anywhere. I’m surprised that the WP world perpetuates the term sidebar, just confusing newcomers who need to figure out or learn that isn’t a “side” thing at all. For me that’s right up there with all of the references to “blogs” in a multi-site environment. We see this in plugins and lots of documentation. These days we’re talking about “sites” in a network, built with a CMS where a blog is just one feature of many. It would be nice to see an intentional shift in this industry from old terms to new – like @jeffrey_carandang suggested using HTML5.

  • Mr. LetsFixTheWorld

    At the moment creating my own themes is not a priority. I need to rely on free themes to publish new sites, with minor tweaks to the code as required. As I build competence in working with existing themes I’m learning their complications and limitations, and that will fuel my urge later to get more into the code.

    While I understand that this series is on WP “Development”, I would appreciate a tutorial on dissecting existing themes, since I think everyone starts with WP just like I have – load themes and use them as-is until there is a critical challenge that needs to be overcome. Picking apart an existing theme would seem to be an ideal way for someone to learn how to create and debug their own – we learn by example.

    My problem is usually figuring out where a specific UI artifact was generated, and which styles were applied to render it as it is. We face that challenge in anything we create or anything we’ve installed. I understand the template hierarchy but that doesn’t help to quickly narrow down which hook or function contributed to some element. (I’m looking at a lot of plugins now to help with such debugging but a lot of them are old, no longer valid, no longer supported.) I know we can use browser tools to inspect elements and see the computed CSS, but for me the most difficult task is that I don’t yet have a diagnostic process to figure out how to fix undesirable styling without messing up something else. Theme authors use Codex-defined styles for many elements but then custom elements for others – it’s a time-consuming challenge to learn which is which. As an example, I have a theme with two menu bars, and the styling on the second one needs a lot of work – I have this on my to-do-list simply because I lack the skill to address it immediately.

    And now that I’ve written more words in comments here than there are words in the page itself, I’ll take my leave. Thanks. :)

Comments are closed.