web-dev-qa-db-fra.com

Comment structurer un plugin en plusieurs fichiers avec l'aide de classes?

J'écris mon premier plugin simple à partir de rien, alors je cherche un conseil pour structurer les classes dans le plugin. J'ai encapsulé certaines fonctions de base dans une classe dans le fichier de plugin principal, mais je suppose que cela deviendra assez maladroit avec beaucoup de fonctions dans un seul fichier.

La structure de mon répertoire de plugin à ce jour ressemble à ceci:

inc
-Core.php
-Plugin-settings.php
css
-Style.css
lang
plugin-file.php

Une chose avec laquelle j'ai eu du mal, c'est de structurer le plugin en plusieurs fichiers à l'aide de classes.

Le code du fichier de plugin principal est:

<?php
/**
* Plugin Name: Plugin name
* Plugin URI: http://someurl.com
* Description: Some description
* Version: 1.0
* Author: Me
* Author URI: http://someurl.com
*/
define( 'SBP_DIR', plugin_dir_path( __FILE__ ) );   // Defining plugin dir path.
/*----------------------------------------------
    Including Files
----------------------------------------------*/
include(SBP_DIR_DIR . 'inc/core.php');              // main plugin functions
include(SBP_DIR_DIR . 'inc/plugin-settings.php');   // the plugin options page HTML
/*----------------------------------------------
    Class Dummy_Class
----------------------------------------------*/
global $sbp_class;
if ( !class_exists("Dummy_Class") ) {
    class Dumy_Class {
/*----------------------------------------------
    Function Construct
----------------------------------------------*/
        function __construct() {
            $this->path = plugin_basename(__FILE__);
            add_action( 'init', array( $this, 'init' ) );
            add_action('admin_enqueue_scripts',  array( $this, 'enqueue' ) );
            add_filter("plugin_action_links_$this->path", array( $this, 'sbp_settings_link' ) );
        }
/*----------------------------------------------
    Function init
----------------------------------------------*/
        function init() {
            load_plugin_textdomain( 'sb-pack', false, basename( dirname( __FILE__ ) ) . '/lang' );  // load plugin textdomain
        }
/*----------------------------------------------
    CSS style of the plugin options page
----------------------------------------------*/
        function enqueue($hook) {
            global $sbp_settings_page;
            if ( $hook != $sbp_settings_page )  // load stylesheet only on plugin option page
                return;
            wp_enqueue_style('styles', plugin_dir_url( __FILE__ ) . 'css/styles.css');
        }
/*----------------------------------------------
    Add settings link on plugins page
----------------------------------------------*/
        function sbp_settings_link($links) {
            $settings_link = '<a href="options-general.php?page=sbp-options">Settings</a>';
            array_unshift($links, $settings_link);
            return $links;
        }

    }   //End class Dummy_Class
    $sb_pack = new Dummy_Class; // instantiate the plugin class
}   //End if (!class_exists("Dummy_Class"))

Je tiens à mentionner que le fichier core.php contient les fonctionnalités du plug-in, à savoir plusieurs fonctions.

Mes questions sont:

  1. Comment devraient être inclus les fichiers core.php et du plugin-settings.php dans le fichier du plugin principal?
  2. Ces fichiers devraient aussi avoir des classes uniques? Comment allez-vous les structurer et pourquoi?

Je n’ai pas une connaissance approfondie de OOP et j’ai donc besoin d’un peu d’instruction étape par étape.

Toute réflexion sera apprécié.

pluginsoop
1
Knott

Quelques règles de base pour l'organisation d'objets dans un plugin.

  • Une déclaration de classe par fichier, pas d'autre code dans ce fichier. Le new Dummy_Class ne doit pas se trouver dans le même fichier que la déclaration de classe.

  • Tout ce qui envoie des données à l'utilisateur doit avoir sa propre classe: HTML, CSV, sortie XML ou en-têtes HTTP.

  • Chaque algorithme, chaque source de données doit avoir sa propre classe afin que vous puissiez le changer plus tard. Disons que vous stockez des données dans une option et que vous souhaitez le modifier ultérieurement pour utiliser une table de base de données personnalisée: vous devriez pouvoir le faire sans modifier tous les fichiers.

  • L'enregistrement et la création d'objets appartiennent à une classe distincte (contrôleur). add_action( 'something', array( $this, 'callback' ) ) est généralement un signe de mauvaise conception, utilisez un objet séparé au lieu de $this.

  • Évitez les constantes globales, elles encombrent l'espace de noms global. Il suffit de transmettre le chemin du fichier de plug-in actuel au contrôleur principal.

5
fuxia