what is option_name on database that store the information of current initiate widget in frontend sidebar?

Question

what is option_name on database that store the information of current initiate widget in frontend sidebar ?

Answer 1

Solved. What EAmann said is right. The problem is in the configuration of the widget system in WordPress. For every multi-instance widget such as text, The information is stored in a different option name where the value of every widget store in a serialized manner.

The trick is about how we store the serialized text widget's information that sometimes has special chars. We must use heredoc. The use of heredoc is to avoid the situation when a string must contain ['] and ["], because both can not be use on one line together.

$serialize_sidebar_widgets = <<< EOD
a:7:{s:19:"wp_inactive_widgets";a:0:{}s:9:"sidebar-1";a:1:{i:0;s:6:"text-3";}s:9:"sidebar-2";a:0:{}s:9:"sidebar-3";a:0:{}s:9:"sidebar-4";a:0:{}s:9:"sidebar-5";a:0:{}s:13:"array_version";i:3;}
EOD;

$serialize_widgets_text = <<< EOD
a:3:{i:2;a:0:{}i:3;a:3:{s:5:"title";s:5:"hello";s:4:"text";s:21:"saya hellokankamu yah";s:6:"filter";b:0;}s:12:"_multiwidget";i:1;}
EOD;

Now we can store them in the database:

$wpdb->update( $wpdb->options, array( 'option_value' => $serialize_sidebar_widgets ), array( 'option_name' => 'sidebars_widgets' ) );
$wpdb->update( $wpdb->options, array( 'option_value' => $serialize_widgets_text ), array( 'option_name' => 'widget_text' ) );

PS: If we store multi-instance widgets then we should remember that the widgets have their own configuration. For example, text widget is stored in 'widget_text'

PS: Read how to use heredoc in PHP.

Answer 2

Sidebar widgets are stored in multiple places in the database. To be perfectly honest, I think it would be next to impossible to have your theme create a pre-populated, widgetized sidebar when it first installs.

However, there is still a way to set up a default widget display for when you install a theme the first time. If you take a look at the default TwentyTen theme, you'll see that it defines a list of "default" widgets that will be loaded if the user doesn't have a dynamic sidebar:

<div id="primary" class="widget-area" role="complementary">
    <ul class="xoxo">
    <?php
        /* When we call the dynamic_sidebar() function, it'll spit out
         * the widgets for that widget area. If it instead returns false,
         * then the sidebar simply doesn't exist, so we'll hard-code in
         * some default sidebar stuff just in case.
         */
        if ( ! dynamic_sidebar( 'primary-widget-area' ) ) : ?>

            <li id="search" class="widget-container widget_search">
                <?php get_search_form(); ?>
            </li>

            <li id="archives" class="widget-container">
                <h3 class="widget-title"><?php _e( 'Archives', 'twentyten' ); ?></h3>
                <ul>
                    <?php wp_get_archives( 'type=monthly' ); ?>
                </ul>
            </li>

            <li id="meta" class="widget-container">
                <h3 class="widget-title"><?php _e( 'Meta', 'twentyten' ); ?></h3>
                <ul>
                    <?php wp_register(); ?>
                    <li><?php wp_loginout(); ?></li>
                    <?php wp_meta(); ?>
                </ul>
            </li>

    <?php endif; // end primary widget area ?>
    </ul>
</div><!-- #primary .widget-area -->

This code block hard-codes a search widget, an archives widget, and a meta widget. Pretty basic, but it means new blogs will always show something useful in the sidebar even if the owner hasn't had the chance to customize the site just yet.

If you're shooting for creating "a list of widgets that is automatically installed when a theme registers for the first time" then this is the safest, and friendliest way to do it.