Si nos basamos en el sencillo ejemplo hellodolly.php proporcionado por WordPress , o incluso la misma los documentos oficiales, nunca llega a escribir un plug-in adecuado y eficiente. Queremos aquí para analizar una posible estructura, a continuación, un esqueleto que se pueden utilizar varias veces.
Los Fundamentos
En primer lugar tenemos que entender cómo y cuándo un plugin para WordPress se carga en el sistema. Cuando es activada por un plugin, el archivo que contiene el código principal, reconocido por las líneas clásicas del comentario:
1 2 3 4 5 6 7 8 | / * Nombre de Plugin: Mis Plugins Plugin URI: http://wordpress.org/extend/plugins/mioplugin/ Descripción: Descripción de mis plugins Versión: 1.0.0 Autor: Giovambattista Fazioli URI Autor: http://labs.saidmade.com * / |
se carga o si hay en el front-end y si nos encontramos en la administración (back end):
Este comportamiento es correcto en sí mismo, y probablemente en muchos casos no es tenido en cuenta por el promotor. Además, algunos plugins tienen una estructura (como la configuración, y luego no tienen necesidad de una administración) que haría inútil insistir sobre este punto.
Sin embargo, es evidente que algunos plugins tienen una aplicación uniforme, es decir, que traen consigo una gran cantidad de código que se usa sólo en el backend de WordPress. En estos casos, si usted no toma las precauciones que usted puede subir a la parte delantera, la parte visible a los navegantes, el código completamente innecesario que no hace nada, pero pesan la carga del blog.
Posibles conflictos: espacio de nombres
De lo anterior se desprende otro dato importante, todos los plugins de WordPress se cargan en la misma zona de la operación, que se traduce en la desafortunada consecuencia de que si dos plugins diferentes tienen una función (una variable o constante) tiene el mismo nombre, estos entrarán en conflicto unos con otros!
Lo ideal sería, entonces, sería capaz de:
- Aparte de cargar el código para el front-end y back-end
- Proteger el "espacio" para evitar posibles conflictos con otros plugins cargados en el sistema
Front-end o back-end?
La forma más sencilla de determinar si se trata de la administración (back end) es llamar a la función is_admin() :
1 2 | is_admin ( ) ) // includi il codice lato back-end if (is_admin ()) / / Incluir el código de la parte de atrás else / / Código son front-end |
En la práctica, esquemática, se puede lograr:
o:
1 2 3 4 5 | is_admin ( ) ) { if (is_admin ()) { 'admin.php' ) ; require_once ('admin.php'); { Else {} 'client.php' ) ; require_once ('client.php'); } |
Utilización de las clases para proteger el espacio de nombres
Para evitar el solapamiento de desagradable es una buena manera de "envolver" nuestras funciones y nuestras variables en contenedores adecuados: los objetos. Mediante la definición de una clase que tiene más oportunidad de proteger los nombres de nuestras funciones, podemos obtener como beneficio añadido de la reutilización de código en el plugin de futuro. Esta técnica hace posible tener dos plugins diferentes, por lo que dos objetos diferentes con el mismo método (función). El conflicto se elimina gracias a la nomenclatura de las diferentes clases y sus instancias.
Sketch plug-in
Habiendo dicho todo esto, vemos cómo hacer un boceto (que se encuentra al día en un repositorio de Google Code Saidmade ), un esqueleto, puede volver a utilizar cada vez que tenemos que escribir un plugin. En primer lugar todos los objetos en la nueva organización para que nos demos cuenta de que si bien es cierto que hay una separación de la "red" entre el back-end y el front-end también es cierto que algunas "características" son y serán compartidos! Esto, a nivel de programación orientada a objetos, señala el camino a seguir a lo largo de una organización de código posible. Por ejemplo, la intuición sugiere que la creación de una clase "madre", es decir, una clase de la cual se derivan las clases de "cliente" (parte delantera) y "admin" (back end), que sería una buena cosa!
Esta clase de "madre" que contienen todas las propiedades (variables) y métodos (funciones) ambientes compartidos por front-end y back-end:
Así que tendremos a nuestra clase "madre" y dos clases para el front-end y back-end:
1 2 3 | sketch_class.php-wp / / los padres de clase sketch_admin.php-wp / / clase para el back-end sketch_client.php-wp / / clase para el front-end |
El archivo principal ( wp-sketch.php ) sólo se incluirán en una manera oportuna, y crear instancias de estas clases correctamente:
1 2 3 4 5 6 7 8 9 10 | 'wp-sketch_class.php' ) ; // load the core class require_once ('wp-sketch_class.php') / / cargar la clase principal is_admin ( ) ) { // check admin if (is_admin ()) {/ / Comprobar admin 'wp-sketch_admin.php' ) ; // load admin class require_once ('wp-sketch_admin.php') / / carga de clase admin / / new WPSKETCH_ADMIN ( ) ; // create object Wp_sketch_admin WPSKETCH_ADMIN $ = new () / / crear el objeto { Else {} 'wp-sketch_client.php' ) ; // load client front-end class require_once ('wp-sketch_client.php') / cliente / carga front-end de clase new WPSKETCH_CLIENT ( ) ; // create object Wp_sketch_client WPSKETCH_CLIENT $ = new () / / crear el objeto } |
) ei nomi delle classi stesse ( WPSKETCH_ADMIN e WPSKETCH_CLIENT ), ma non i metodi e le proprietà in esse presenti. Este "contexto" sólo hay que tener cuidado de un concepto único sobre las variables que contienen instancias de clases ( $wp_sketch_admin y $wp_sketch_client ) y los nombres de las clases mismas ( WPSKETCH_ADMIN y WPSKETCH_CLIENT ), pero los métodos y propiedades que contienen .
sono “sottoclassi” (figli) di WPSKETCH_CLASS , definita nel file wp-sketch_class.php . Ambas clases WPSKETCH_ADMIN y WPSKETCH_CLIENT son "subclases" (los niños) de WPSKETCH_CLASS , definida en el archivo wp-sketch_class.php . Esto, como se mencionó anteriormente, sólo contendrá los elementos compartidos (variables y funciones), ya que siempre se carga independientemente de si estamos en el back-end o front-end.
En conclusión ...
Puede descargar todo el esqueleto de la Saidmade repositorio Google Code . . En este también se encuentra un archivo wp-sketch_functions.php , que se utiliza para evitar que las llamadas a funciones en un front-end para traducir una llamada oggetto->metodo() . De hecho, es un archivo opcional no siempre es necesario.
La posible evolución de este enfoque son siempre una mejor identificación de la sección en la que estamos operando y WordPress, y en este sentido, una amplia gama de acciones de optimización a realizar, con el fin de cargar sólo el código necesario y cuando necesitamos realmente. Ulteiori ejemplos de este lado vamos a ver pronto.
[...] Una de las técnicas para escribir rápidamente un plugin de WordPress se puede preparar un esqueleto (croquis) para comenzar. Especificaciones de WordPress, de hecho, a menudo conducen a tener plugins estructuralmente muy similares, en realidad, son los nombres de funciones y su cambio de contenido. Sin embargo, en la preparación de un esqueleto, tenga en cuenta no duplicar nombres, constantes o funciones utilizadas por otras personas (incluyendo el nuestro) plugin, de lo contrario obtener un plugins errore.Tutti activo comparten la misma área de operación. Así que si un plugin tiene una función que se llama abc_normalize () no otros plugins pueden tener una función con un nombre identico.Caso de forma remota? ¿Coincidencia? Aunque a primera vista parece una cosa muy insignificante, es muy molesto cuando sucede, sobre todo para el usuario final que se encuentra incapaz de usar un plugin. También en la definición de las constantes (por ejemplo, TABLE_NAME, WP_MAIN_PATH, etc ...) es mucho más común de obtener duplicados. Para más detalles: En la estructura de los objetos de un plugin para Wordpress [...]
[...] En la estructura de un plugin de WordPress objeto Cómo estructurar las clases de un plugin de WordPress para la carga óptima y la reutilización de código. [...]
[...] Esta serie con la continuación natural del artículo de Napolux, estructura u objeto con un blog wordpress plugin [...]
[...] En la estructura de los objetos de un plugin para Wordpress [...]
Hola he leído este gran artículo y quería hacerte una pregunta: He creado un plugin para la gestión de los productos clasificados por categorías y otras categorías de wp creado por mí con otras tablas en la plguin back-end trabaja duro para hacer que funcione perfectamente situado en el front-end que no sé cómo mostrar la lista de productos para venta al por menor ... es decir, nn saber cómo hacer que funcione con mod rewrite permalinks estaría actuando muy bien.
que me haga saber
Domingo
@ Serdominik: Hola Domingo, ¿podría decirme algo más en detalle lo que usted necesita?
@ Giovambattista Fazioli:
Hola, gracias por darme una respuesta.
Mi pregunta es muy difícil de entender en unas pocas líneas de texto y la escritura es difícil de hacer entender (lo siento si te doy la) y otra difícil de seguir los comentarios a través de las preguntas y respuestas para mí, así, entre muchas cosas que me olvide de ir a ver Si por casualidad te veo respondió hoy, después de 3 días. Si quieres y si te sientes nn es un trastorno a través de MSN o Skype o correo electrónico
Desafortunadamente, muchos prefieren no hacer comentarios sobre los detalles del proyecto que estoy haciendo
[...] El código de producto sigue el estándar orientado a objetos en la estructura de los objetos descritos en un plugin para Wordpress [...]
Discusión [...] sobre la estructura de un plug-in está disponible en: En la estructura de los objetos de un plugin para Wordpress, que muestra un esqueleto posible que un paquete correctamente [...]