tags:

views:

44

answers:

1

actually this question popped out when i was looking at thw wordpress codex about widgets but i think its more of a PHP question. 3 questions here actually:

  1. why is the codex and the book using 2 seemingly different methods to contruct the widget. codex uses parent::WP_Widget (static method?) and book uses $this->WP_Widget (instance method?) will there be any differences?

  2. i also noticed that i the PHP4 constructer WP_Widget and not __construct is used. isit just for compatibility reasons? i could use $this->__construct too right?

  3. i tried ...

    // in pp_widget class extends WP_Widget
    function __construct() {
        $this->WP_Widget(...); // or $this->__construct(...) 
    }
    

and it fails with

Fatal error: Maximum function nesting level of '100' reached, aborting! in D:\Projects\Websites\wordpress\wp-content\plugins\post-product\post-product.php on line 137 Call Stack: 0.0002 331328 1. {main}() D:\Projects\Websites\wordpress\wp-admin\widgets.php:0 0.0008 331592 2. require_once('D:\Projects\Websites\wordpress\wp-admin\admin.php') D:\Projects\Websites\wordpress\wp-admin\widgets.php:10 0.0013 331848 3. require_once('D:\Projects\Websites\wordpress\wp-load.php') D:\Projects\Websites\wordpress\wp-admin\admin.php:20 0.0020 332224 4. require_once('D:\Projects\Websites\wordpress\wp-config.php') D:\Projects

in the wordpress codex:

class FooWidget extends WP_Widget {
    /** constructor */
    function FooWidget() {
        parent::WP_Widget(false, $name = 'FooWidget');  
    }

and from the book professional wordpress

class pp_widget extends WP_Widget {
    function pp_widget() {
        $this->wp_widget(...);
    }

the underlying wordpress code for the constructor

function WP_Widget( $id_base = false, $name, $widget_options = array(), $control_options = array() ) {
    $this->__construct( $id_base, $name, $widget_options, $control_options );
}
...
function __construct( $id_base = false, $name, $widget_options = array(), $control_options = array() ) {
    $this->id_base = empty($id_base) ? preg_replace( '/(wp_)?widget_/', '', strtolower(get_class($this)) ) : strtolower($id_base);
    $this->name = $name;
    $this->option_name = 'widget_' . $this->id_base;
    $this->widget_options = wp_parse_args( $widget_options, array('classname' => $this->option_name) );
    $this->control_options = wp_parse_args( $control_options, array('id_base' => $this->id_base) );

}

+1  A: 

i also noticed that i the PHP4 constructer WP_Widget and not __construct is used. isit just for compatibility reasons? i could use $this->__construct too right?

You can. I tend to prefer using __constructor because A) it's not ambiguous and B) I don't have to change the name if I refactor the class name.

i tried ...
// in pp_widget class extends WP_Widget
function __construct() {
    $this->WP_Widget(...); // or $this->__construct(...) 
}

In PHP, the reserved function name __construct is an alias for the method of the same name as the class. It is typically called by $my_object = new MyClass();. It's no surprise that this is an infinite recursive loop, as the object inherits those methods.

amphetamachine
hmm, but i still dont get why if i use `pp_widget` instead of `__construct` it will work since `__construct() = pp_widget()`
jiewmeng