2010-09-13 4 views
1

effectivement cette question a sauté quand je regardais thw wordpress codex sur les widgets mais je pense que c'est plus d'une question PHP. 3 questions ici en fait:

  1. pourquoi est le codex et le livre en utilisant 2 méthodes apparemment différentes pour contruire le widget. le codex utilise parent::WP_Widget (méthode statique?) et utilise le livre $this->WP_Widget (méthode d'instance?) Y aura-t-il des différences? J'ai également remarqué que le constructer PHP4 WP_Widget et non __construct est utilisé. isit juste pour des raisons de compatibilité? je pourrais utiliser $this->__construct trop raison?

  2. j'ai essayé ...

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

et il échoue avec

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

dans le codex wordpress:

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

et du livre de wordpress professionnel

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

le code sous-jacent pour le wordpress constructeur

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)); 

}

+0

Wordpress est célèbre pour son style de codage incohérent et son horrible codebase. Je n'essaierais pas de comprendre pourquoi le code est tel qu'il est. – Gordon

Répondre

1

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?

Vous pouvez. J'ai tendance à préférer utiliser __constructor car A) ce n'est pas ambigu et B) Je n'ai pas besoin de changer le nom si je refaçonne le nom de la classe.

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

En PHP, le nom de la fonction réservée __construct est un alias pour la méthode du même nom que la classe. Il est généralement appelé par $my_object = new MyClass();. Il n'est pas surprenant qu'il s'agisse d'une boucle récursive infinie, car l'objet hérite de ces méthodes.

+0

hmm, mais je ne comprends toujours pas pourquoi si j'utilise 'pp_widget' au lieu de' __construct' cela fonctionnera depuis '__construct() = pp_widget()' –

Questions connexes