Sidebars are an integral part of the WordPress experience but understanding how they work on a database-level is not at the forefront of tutorials. You can find any number of posts about creating widgets, customizing them, extending them and so on, but how they are actually put together at the end and come together in multiple sidebars is often overlooked.

In this article – true to the database series – we’ll be looking at how sidebars and widgets are stored in the database.

What Is a Widget Area

The term sidebar is actually a misnomer since that’s not really what we’re talking about. The term sidebar comes from a time when sidebars became prevalent and they were the first to be “widgetized”. Since then we have found that footers, headers and other sections can sometimes benefit from widgets – modular content blocks.

From here on out I will be referring to “widget areas”. A sidebar can be a widget area, just like any other section on your website can potentially contain widgets. In a nutshell: any area that can contain widgets and can be controlled from the widgets section in the admin constitutes a widget area.

Widgets Areas in the Database

The widget areas – and indeed all widgets – are stored in the options table. The first row to look at will be the one with the option_name of sidebars_widgets. The content of the option_value column contains all the defined sidebars and the ID of the widgets within. If you use var_dump( get_option( 'sidebars_widgets' ) ) you’ll see something like this:

Array
(
    [wp_inactive_widgets] => Array
        (
        )

    [sidebar-1] => Array
        (
            [0] => text-2
            [1] => categories-2
        )

    [array_version] => 3
)

In my current setup, I don’t have any inactive widgets and I have one sidebar (sidebar-1) with a text widget and a category list widget – the ID of these widgets is shown in the array.

Based on this info we know what sidebars are defined and what widgets they contain but we don’t know anything about the configuration about each specific widget. To get that information we need to look at some further rows.

Widgets in the Database

Each widget has a separate row in the options table. The value of the option contains all defined widgets of the type and their settings. To get all defined text widgets we need to look at the value of the widget_text option. To view category list widgets we need the widget_categories option.

Array
(
    [1] => Array
        (
        )

    [2] => Array
        (
            [title] => First Text Widget
[text][/text]

=> Fist Content
[filter] =>
)

[_multiwidget] => 1
)

I’ve pasted the results of get_option( 'text_widget' ) above. There is an empty array there which is the remnant of a deleted widget, the second member corresponds to text-2 from the value of sidebars_widgets. It contains all the options for the widget.

Summary

We now have all the data required to assemble sidebars of our own accord if needed, and hopefully a deeper understanding of how things work in the background. I think that knowing how sidebars work on the database level gives us insight into manipulating them with the functions available out of the box, and manipulating them in unique ways if the need arises.

Want to get rid of sidebars? Check out: How to Remove the Sidebar in WordPress (4 Methods).

Daniel Pataki

Hi, my name is Daniel, I'm the CTO here at Kinsta. You may know me from Smashing Magazine, WPMU Dev, Tuts+ and other WordPress/Development magazines. Aside from WordPress and PHP I spend most of my time around Node, React, GraphQL and other technologies in the Javascript space.

When not working on making the best hosting solution in the Universe I collect board games, play table football in the office, travel or play guitar and sing in a pretty bad band.