La privacidad y la optimización de un widget de panel de WordPress

Lo que vas a crear

En las dos primeras partes de esta serie, completamos, un complemento con todas las funciones que nos muestra el estado del servidor como un widget del panel de control. Como tal, está disponible para todos los usuarios registrados. Parte de la información puede ser confidencial, y no queremos que la vean, por lo que es mejor verificar el rol del usuario para determinar si debemos poner el widget a su disposición.. 

Uso de roles o capacidades para limitar la visibilidad

WordPress utiliza un concepto de roles, diseñado para dar al propietario del sitio la capacidad de controlar lo que los usuarios pueden y no pueden hacer dentro del sitio. Cada función tiene permitido realizar un conjunto de tareas llamadas Capacidades. Podemos personalizar el rol y sus capacidades con las funciones add_roles y add_cap.

Nuestro plugin creará una nueva llamada de capacidades. servermetric. Solo el usuario que tiene esa capacidad puede cargar los widgets de nuestro panel de control. Agregaremos esta capacidad para el rol de administrador para que todos los usuarios del administrador la vean de forma predeterminada. 

Para los otros usuarios, puede usar el Editor de roles de usuario del complemento para administrar las capacidades de cualquier usuario en particular y asignar el servermetic capacidad para el usuario.

Usamos add_cap para agregar una nueva capacidad, sin embargo, esta función escribe en la base de datos, por lo que solo debemos hacerlo al activar el complemento. Una vez desactivada, debemos limpiar la base de datos eliminando la función con remove_cap.

clase Tablero // ... otro código const CAP_METRIC = 'server_metric'; / ** * Comenzar a configurar el gancho * / public function run () add_action ('wp_dashboard_setup', array ($ this, 'add_dashboard_widgets')); add_action ('admin_enqueue_scripts', array ($ this, 'add_asset')); add_action ('admin_footer', array ($ this, 'footer')); register_activation_hook (__ FILE__, array ($ this, 'add_servermetric_caps')); register_deactivation_hook (__ FILE__, array ($ this, 'remove_servermetric_caps'));  / ** * Agregar capacidad severmetric para administración por defecto * / function add_servermetric_caps () // obtiene el rol de autor $ role = get_role ('administrador'); // Esto solo funciona, porque accede a la instancia de la clase. // permitiría al autor editar las publicaciones de otros para el tema actual solo $ role-> add_cap (self :: CAP_METRIC);  function remove_servermetric_caps () // get_role devuelve una instancia de WP_Role. $ role = get_role ('administrador'); $ role-> remove_cap (self :: CAP_METRIC);  //…

Creamos una nueva llamada constante. CAP_METRIC y establece su valor en server_metric para que podamos cambiar fácilmente el nombre de la capacidad más tarde fácilmente. Modificamos nuestra correr método para agregar dos ganchos.

El register_activation_hook se ejecuta al activar el complemento. Acepta dos parámetros:

1. (cadena) nombre de archivo: ruta al archivo principal del complemento
2. (llamar de vuelta) (necesario) La función que se ejecutará cuando se active el complemento

register_deactivation_hook se ejecuta cuando se desactiva el complemento. Acepta el mismo parámetro que register_activation_hook.

Dentro de cada función enganchada, cargaremos el rol. administrador y llama add_cap o quite la tapa en el objeto roles.

A continuación, modificaremos nuestra add_dashboard_widgets Método para registrar solo los widgets si el usuario actual tiene el servermetric gorra.

 / ** * Registre el proider del widget del panel de control para que aparezca en el panel de control * / function add_dashboard_widgets () if (! Current_user_can (self :: CAP_METRIC)) return false;  $ widget = Widget :: instance (); foreach ($ widget-> get_provider () como $ name => $ provider) $ widget-> register ($ name); 

A continuación, utilizamos current_user_can para verificar si el usuario actual tiene la capacidad de solicitud.
Ahora, solo el administrador verá el widget al cargar el panel de control. Si desea habilitar el widget de estado del servidor para otros usuarios, puede instalar el complemento User Role Editor para administrar roles y capacidades para cualquier usuario.. 
Una vez instalado y activado, vaya al menú Usuarios, seleccione el Usuario> Capacidades:

Luego, en la pantalla de capacidades, podemos asignar la server_metric gorra.

Editar las capacidades del usuario con el plugin User Role Editor

Al utilizar roles y capacidades, mejoramos la seguridad de nuestro complemento para que nuestro widget esté disponible solo para los usuarios en los que confiamos.

Almacenamiento en caché de la métrica del servidor

WordPress utiliza la API de Transients como una API de caché. Los datos se serializan y almacenan en el wp_option Tabla de WordPress con un tiempo de expiración del caché.. 

En lugar de obtener datos métricos en cada solicitud HTTP, podemos obtener los datos una vez y almacenarlos en caché. Sin embargo, no podemos simplemente poner todo en el caché o usar el mismo tiempo de caducidad. Por ejemplo, el espacio en disco puede almacenarse en caché durante 15 minutos, y la información del servidor puede almacenarse en caché durante 60 minutos, ya que rara vez cambian. De manera similar, el software instalado se puede almacenar en caché por un día, ya que rara vez cambia una vez que el servidor se configura y se aprovisiona para la producción.

Utilizamos principalmente get_transient y set_transient cuando se trabaja con la API. Según la documentación de WordPress:

1. get_transient ($ transitorio): recupera el nombre del transitorio como una cadena y devuelve sus datos. Si los datos han caducado, devuelve falso. Deberíamos usar === operador para verificar porque podemos almacenar un valor vacío para el transitorio.
2. set_transient ($ transitoria, $ valor, $ vencimiento): recupera tres parámetros: el nombre del transitorio, su valor y su tiempo de caducidad en segundo. Tenga en cuenta que el nombre transitorio no debe tener más de 45 caracteres.
   

Nuestras dos opciones son considerar almacenar en caché los datos métricos o almacenar en caché los datos HTML generados. El almacenamiento en caché de los datos HTML puede hacer que nuestro sitio sea muy rápido, pero pone una carga en la base de datos. Para ello, podríamos hacer un punto de referencia para decidir cuál es la mejor.. 

Para nuestro tutorial, simplemente almacenemos en caché los datos métricos. Además, deberíamos tener una forma de invalidar el caché, como un ancla, que nos permita volver a cargar los datos del tablero y forzar la carga de los datos en lugar de hacerlo desde el caché..

Datos de caché para el widget

Podemos utilizar directamente la función. get_transient o set_transient para trabajar con Transient API. Sin embargo, si decidimos cambiar la forma en que usamos Transient API, tenemos que revisar cada lugar donde lo usamos y modificarlo para cada widget.. 

Vamos a agregar una capa más para abstraer el mecanismo de caché. Diseñaremos una clase de caché simple para nuestro widget que tiene tres métodos:

1. conjunto: establecer datos de caché para un widget
   
2. obtener: obtener datos de caché para un widget
   
3. carga: intente cargar desde el caché, si no existió, calcule los datos, configure el caché y devuelva
   

Vamos a componer el archivo widget / cache.php de la siguiente manera. Tenga en cuenta que, como nuestra convención de carga automática, el nombre de la clase será Cache y su espacio de nombres es AX \ StatBoard \ Widget

get_metric (); static :: set ($ provider, $ data, $ cache_time); devuelve $ datos;  

Primero, note que hemos marcado nuestros métodos de caché como estáticos. Nuestro conjunto y obtener Los métodos son sólo envoltorios para  get_transient y set_transient. los carga método se sienta encima de conjunto y obtener. Todos estos métodos esperan recuperar el objeto proveedor de widget; por lo tanto, dentro de carga método que podemos invocar get_metric Método para obtener los datos reales.. 
Aquí, lo más importante es el nombre transitorio. Dado que el nombre de la clase es único dentro de nuestra aplicación, lo consideramos lo suficientemente único para el nombre transitorio. La función get_class devuelve el nombre de clase de un objeto.
Tiempo para usar nuestro Cache clase. Trataremos de implementar Cache para widget / software.php. Cambia nuestro original obtener el contenido método para:

$ info) $ content. = "
$ cmd  $ info
"; echo $ content; //…

Se puede ver que nos deshacemos de $ cmds = $ this-> get_metric () y simplemente reemplazarlo con Caché :: cargar que cargará datos de la memoria caché, o los cargará desde el sistema si no existiera ninguna memoria caché. 
Asegúrese de pasar el segundo parámetro por cuánto tiempo desea que se almacenen en caché los datos; de lo contrario, los datos solo se almacenan en caché durante cinco minutos. Debido a que la información del software en el servidor rara vez cambia a corto plazo, configuramos el tiempo de caché en 24 horas.
Ahora que tienes la idea, puedes repetir con todos los demás widgets que te gustaría almacenar en caché. Simplemente reemplazar get_metric dentro obtener el contenido con:

Cache :: load ($ this, $ time_in_second);

para que se encargue de su almacenamiento en caché.
Los datos del uso del disco se pueden almacenar en caché durante horas, y la interfaz de Ethernet se puede almacenar en caché durante aproximadamente un día. Depende de usted decidir cuánto tiempo desea almacenarlo en caché. También podemos crear una página de opciones para que el complemento administre estos valores de caché de por vida. Puede ser un ejercicio para que trabajes después de haber completado este artículo..
Tenemos un ejemplo final con widget / ethernet.php. Podemos agregar capacidad de caché de la siguiente manera:

función pública get_content () 
$ interfaces = Cache :: load ($ this, 3600 * 24 * 7);
$ html = '


';
foreach ($ interfaces como $ interface => $ ip) 
$ html. = "


";

$ html. = '
Interfaz
IP
$ interfaz
$ ip
';
echo $ html;

  //… 

De nuevo, solo necesitamos reemplazar get_metric con Caché :: cargar. La información de Ethernet y su dirección IP probablemente nunca cambian, así que establezco una vida útil de caché muy larga en una semana: 3600 segundos * 24 horas * 7 días.

Fuerza de carga de datos reales

Una vez que hemos agregado una capacidad de caché, deberíamos admitir un mecanismo para que el administrador pueda extraer el widget sin que se almacene en caché. La forma más fácil de hacer esto es usar un parámetro de consulta especial para indicar que queremos datos reales. 

¿Qué tal un pequeño parámetro como nocache ¿para esto? Así que en lugar de la URL predeterminada del tablero de WordPress con domain.com/wp-admin/ nosotros podemos usar domain.com/wp-admin/?nocache. 

¿Suena fácil? Vamos a hacerlo.

Edita nuestro método obtener en widget / cache.php

 función estática get (Provider $ provider) if (isset ($ _ GET ['nocache'))) return false;  $ cache_id = get_class ($ provider); if (false! == $ data = get_transient ($ cache_id)) return $ data;  falso retorno; 

Siempre y cuando el nocache el parámetro de consulta existió, devolvemos falso instantáneamente y, por lo tanto, forzamos que los datos reales se recuperen en lugar de los datos almacenados en caché.
Ahora, pensemos en agregar esta característica sin la clase Cache. Puede que tengamos que ir a cada línea de get_transient y compruebe el parámetro de consulta allí. Por lo tanto, considere dividir las cosas en muchas capas al diseñar su complemento. No pongas todo en el mismo archivo o copia el código de pegar una y otra vez.
Ahora, tratemos de visitar domain.com/wp-admin y domain.com/wp-admin?nocache y note la diferente velocidad..987ms cargando con caché habilitado

Aquí está el resultado con ?nocache = 1 adjunto a la URL.

3.01 segundo cargando sin caché

Uso de cronjob para generar caché

Aunque implementamos y usamos un caché, si falta el caché, la página sigue siendo lenta. Todavía necesita tiempo para extraer datos del servidor. Todavía tenemos espacio para mejorar con el cronjob. Podemos programar nuestro complemento para que se ejecute en un intervalo específico. WordPress nos permite hacer esto a través de wp_schedule_event. Idealmente, podemos usar wp_schedule_event para programar un gancho que se ejecutará en un intervalo específico.

Mirando este ejemplo, nuestro complemento puede programar un enlace para invocar cada tres minutos, el enlace, a su vez, invocará otra función para recuperar los datos métricos. Los datos están siempre disponibles en caché y lo suficientemente frescos..

Abra nuestro archivo de plugin principal, serverdashboard.php, y actualice el método de ejecución para incluir un nuevo gancho así como un nuevo manejador de ganchos.

 3 * 60, 'display' => __ ('Una vez cada 3 minutos')); devuelve $ horarios;  / ** * Programa de configuración para el evento. Si el programa no existe, lo registramos en * / function setup_schedule () if (! Wp_next_scheduled ('metric_generate_every_3min')) wp_schedule_event (time (), '3min', 'metric_generate_every_3min');  / ** * La función principal que se ejecuta en cron y * genera datos * / function generate_metric () $ widget = Widget :: instance (); foreach ($ widget-> get_provider () como $ name => $ provider) // Al llamar a get_content, activamos Cache :: proceso de carga. $ provider-> get_content (); 

En primer lugar, el método wp_schedule_event solo admite tres tipos de recurrencia: diario, horario y diario. Tenemos que agregar un nuevo tipo de recurrencia con el filtro wp_get_schedules. 
Añadimos un tipo más recurrente que se ejecuta cada tres minutos. Su definición:

 $ horarios ['3min'] = array ('intervalo' => 3 * 60, 'display' => __ ('Una vez cada 3 minutos')); devuelve $ horarios;

Podemos personalizar el valor del intervalo en cuántos segundos queremos que se repita el trabajo. A continuación configuramos un metric_generate_every_3min gancho.

 add_action ('metric_generate_every_3min', array ($ this, 'generate_metric'));

Este es nuestro gancho personalizado, no existe en WordPress. Registramos un manejo con método. generar_metric para ese gancho. Cuando metric_generate_every_3min se invoca el gancho, generar_metric será ejecutado.
En la siguiente declaración, nos enganchamos a la acción. en eso con setup_schedule Método para verificar la existencia del próximo evento programado del gancho metric_generate_every_3min. Si aún no está definido, programaremos un evento con wp_schedule_event, utilizando nuestra repetición personalizada cada tres minutos para ese gancho.
Dentro de generar_metric método, pasamos por todos los widgets disponibles y llamamos a sus obtener el contenido método. Al hacer eso, activamos Caché :: cargar proceso para esa métrica.
WordPress ejecutará automáticamente esos eventos programados cada vez que alguien visite su sitio de WordPress. Intentará encontrar el evento programado que debe ejecutarse e invocarlo.
Sin embargo, también puede ejecutarlos manualmente. WordPress ejecuta cronjob a través de visitar el archivo wp-content.php con la URL tudominio.com/wp-cron.php?doing_wp_cron.
Es posible que desee actualizar su cronjob para agregar un nuevo trabajo que haga ping a la URL anterior cada minuto
Vamos a abrir tu crontab en el servidor con crontab -e y añadir esta línea al final de la misma:

0 * * * * wget domain.com/wp-cron.php?doing_wp_cron> / dev / null 2> & 1

Usamos wget para hacer una solicitud HTTP al archivo wp-cron.php. Como no nos importa la salida ni ningún error, redirigimos toda la salida a / dev / null.
Puede leer más sobre la configuración de estos cronjob en los siguientes artículos:

1. http://tommcfarlin.com/wordpress-cron-jobs/
2. http://code.tutsplus.com/articles/insights-into-wp-cron-an-introduction-to-scheduling-tasks-in-wordp…
   

Conclusión

Esto concluye nuestro largo tutorial sobre cómo crear un widget de panel de control del servidor que proporciona información sobre varios aspectos de nuestro sistema.
A lo largo de esta serie, utilizamos bibliotecas de terceros, tomamos una idea, experimentamos con la línea de comandos, aprendimos sobre funciones y capacidades y revisamos las capacidades transitorias de WordPress, así como sus mecanismos de programación de eventos..
Finalmente, lo unimos todo en un plugin de WordPress.
Considere dejar un comentario y háganos saber qué ideas adicionales y cambios se le ocurren, así como cualquier pregunta y / o comentario que pueda tener sobre esta serie en particular..