Si alguna vez has montado un sitio WordPress para algún cliente seguro que le has instalado unos cuantos plugins, muchos de ellos que no querrías que alguien desactivase por error.
Me refiero a que hay plugins que, por su utilidad e integración con el tema y la instalación, si se desactivan pueden destrozar completamente el aspecto y la funcionalidad de un sitio.
Plugins como, por ejemplo, un sistema de comentarios personalizado como Disqus, el plugin de mejoras de SEO o el que añade una tienda electrónica a la web.
Bien, podrías no dar permisos de administrador al dueño del sitio, pero esto casi nunca es opcional, así que la otra alternativa es – informando al cliente – instalarle un quitamanías en forma de función que oculte aquellos plugins que no quieras que aparezcan en la lista de plugins y, en consecuencia, no puedan actualizarse o desactivarse por algún «dedo flojo» con derechos de administrador.
Solo tendrías que añadir la siguiente función a tu plugin de funciones o al fichero functions.php del tema activo:
//Quitar plugins de la lista de plugins
add_filter( 'all_plugins', 'hide_plugins');
function hide_plugins($plugins)
{
// Ocultamos el plugin Hello Dolly
if(is_plugin_active('hello.php')) {
unset( $plugins['hello.php'] );
}
// Ocultamos el plugin Disqus
if(is_plugin_active('disqus-comment-system/disqus.php')) {
unset( $plugins['disqus-comment-system/disqus.php'] );
}
return $plugins;
}En el ejemplo anterior hemos ocultado los plugins Hello Dolly y Disqus pero puedes añadir o modificar cualquiera en la lista siguiendo el patrón del código, tu decides.
Otro método que también funciona sería con el siguiente código:
function ayudawp_ocultar_plugin() {
global $wp_list_table;
$hidearr = array('directorio-del-plugin/archivo-principal-del-plugin.php');
$myplugins = $wp_list_table->items;
foreach ($myplugins as $key => $val) {
if (in_array($key,$hidearr)) {
unset($wp_list_table->items[$key]);
}
}
}
add_action('pre_current_active_plugins', 'ayudawp_ocultar_plugin');En este caso debes cambiar la ruta al archivo principal del plugin, pues la que he puesto (en rojo) es claramente de ejemplo 😉
Una vez guardes los cambios los plugins seguirán instalados, activos o no, como estuviesen en el momento de ocultarlos, pero a salvo de dedos inquietos.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
AVISO: Esta publicación es de hace 3 años o más. Si es un código o un plugin podría no funcionar en las últimas versiones de WordPress, y si es una noticia podría estar ya obsoleta. Luego no digas que no te hemos avisado. ¡Ah! ¿te funciona? pues entonces no he dicho nada :)
Hola Fernando,
En los casos que propones, suelo poner el plugin como muplugin ( https://codex.wordpress.org/Must_Use_Plugins ). Si bien, es verdad, que hay algunos que necesitan pequeños retoques para funcionar como muplugins, sin embargo, luego es más óptimo.
Un saludo y buen comienzo de semana.
Ponerlo como mu-plugin podría llegar a ser un problema si más tarde uno quisiera desactivar el plugin. Siendo un mu-plugin, las únicas alternativas para hacer eso son eliminar el archivo o moverlo a la carpeta de plugins tradicionales. Cualquiera de esas dos opciones implica modificar el estado del código en producción. La solución del artículo me parece más elegante porque se puede aplicar a usuarios que tengan roles o capacidades específicas, mientras el administrador principal sigue teniendo completo control sobre los plugins.
Andres, los mu-plugins no funcionan así.
Primero tenemos que distinguir entre «activación» y «ejecución». En el caso de los plugins convencionales están ligadas. En el caso de los muplugins, no.
Tú con los mu-plugins escoges cuando se ejecutan. Esto es muy bueno, por ejemplo, si vas a usar un shortcode de mapa de gmaps en contacto , lo cargas sólo en contacto. Así no añades css y js que sólo usarás en contacto.
Para ejecutar un mu-plugin sólo tienes que hacer un require o include a nivel de código.
Ahora bien, si hablamos de «activación» como tareas que requiere el plugin antes de usarse. Primero hay que tener en cuenta que no todos los plugins necesitan de una activación al uso. Shortcodes, widgets, plugins que no necesiten de base de datos o tareas especiales, no lo necesitarás.
Sin embargo, para plugins que si requieran de activación( y posteriormente desactivación ), lo haces tú manualmente junto con el código de ejecución. Para desactivarlo lo mismo, nunca eliminarlo o moverlo, porque en ese caso dejas de ejecutarlo pero no lo desactivas.
Sí, en los casos de activación/desactivación, quizás sea un pelín más complejo porque no tienes interfaz. Pero, eso es una de las cosas por lo que los usas, ¿ no es cierto ?. Sino usas plugins normales.A cambio tiene más ventajas:
– Como he comentado lo puedes ejecutar cuando quieras.
– Por lo anterior, tu sistema es más eficiente en cuanto recursos y velocidad.
– Se carga antes que los plugins normales con lo que puedes usarlo como librería o base para plugins a medida que tengas que usar.
Eso sin contar las ventajas de que no aparezca a nivel de interfaz WordPress.
Manuel, creo que no entendiste mi post. No hace falta que me expliques cómo funcionan los mu-plugins (aunque sí es bueno para quien no lo sepa). Mi punto es que usando mu-plugins, si se da un caso en que quieras que dejen de ejecutarse (antes cometí el error de hablar de activación), sea cuál sea el momento en el que se carguen, aún vas a necesitar modificar código o mover archivos de un lado a otro, lo cual es equivalente a un nuevo deploy. De esa manera se pierde dinamismo en la aplicación. Los plugins convencionales, en cambio, al poder activarse y desactivarse, no requieren trabajo de desarrollo para dejar de ejecutarse.
El punto es que tenemos dos alternativas para ocultar la opción de desactivación de plugins al usuario:
1. La que se describe en el artículo.
2. Por medio de mu-plugins.
La ventaja de la opción 1 es que, por medio de un chequeo de roles y capacidades, se pueden ocultar plugins a los usuarios que haga falta. Además, no hace falta escribir código adicional ni mover archivos para desactivarlos. La desventaja es que ciertos plugins esenciales aún quedan atados a un sistema de activación y desactivación. Incluso el mismo administrador, aún cuando otros usuarios no vean estos plugins, podría desactivarlos por error. Para esos casos, sí, lo ideal son los mu-plugins.
Las ventajas de la opción 2 son las que tú describes. La desventaja es que se requiere más trabajo cuando queremos que un mu-plugin deje de funcionar.
Personalmente, no prefiero ningún método en lugar de otro; de hecho uso los dos en combinación. Pero sí creo que hay que pensar bien qué método elegir para cada plugin sobre el que no se quiera dar control a los usuarios, a fin de evitarnos trabajo adicional en el futuro.
Hola, me interesa aplicar lo que enseña Fernando pero con la opción de limitar por niveles de usuarios, por ejemplo que un editor no acceda al plugin x