Cómo crear Custom Post Type (CPT) sin plugin

En los inicios de WordPress sólo existían las entradas o post. No había páginas; y es que sí, WordPress nació como un CMS para blogs. Posteriormente se añadieron las páginas, que no es más que un tipo de post. Lo que pasa es que se decidió crear este tipo de post llamado páginas para crear contenido más «estático».

Pero estos dos tipos de contenido no son los único que tiene WordPress por defecto. Los diferentes tipos de contenido que trae WordPress de serie son:

  • Entradas
  • Páginas
  • Medios
  • Revisiones, que sirven para almacenar las revisiones de un post publicado.
  • Menú de navegación
  • CSS personalizado. El CSS que añadimos en el personalizador de WordPress se almacena en la base de datos, como si fuese un tipo de post.
  • Changesets, o conjunto de cambios. Es como un autoguardado, pero del personalizador de WordPress

Bien, pues desde la versión 3.0 de WordPress, podemos crear nuesto tipos de post personalizados, o Custom Post Types (CPT).

¿Qué son los Custom Post Types?

Los CPT nacen de la necesidad de tener la información de nuestro sitio web bien organizado. Podemos crear diferentes tipos de post para tener información concreta, y con las características que se quiera.

Es decir, no es lo mismo un portfolio de trabajos que un calendario de eventos por ejemplo. Y es que WordPress no sólo nos da la posibilidad de crear diferentes tipos de post, sino que además podemos darles diferentes características.

Podemos hacer que tengo o no la imgen destacada, que sea jerárquico, que tenga su propia taxonomía, etc. Os recomiendo que echéis un vistazo a la página del Codex de WordPress que habla de la función register_post_type(): https://codex.wordpress.org/Function_Reference/register_post_type

Desde mi punto de vista, no hay que tener miedo de crear todos los Custom Post Types que sean necesarios. Facilitaremos mucho la vida de nuestros clientes; y más si lo completamos con custom fields para que añadan la información estrictamente necesaria necesaria sin complicarse.  Pero esto lo trataremos en otro post.

Cómo crear Custom Post Types

Para crear un CPT en WordPress podemos hacerlo como siempre: mediante un plugin o mediante código.

En el repositorio de plugins de WordPress hay un montón de plugins que nos ayudarán a crear nuestros propios Custom Post Types. Mira https://wordpress.org/plugins/search/custom+post+type/

Pero os voy a demostrar que es muy sencillo crearse por código un CPT

Crear un Custom Post Type mediante código

Crear un CPT mediante código es algo tan sencillo como lo siguiente:

function create_post_type() {
  register_post_type( 'acme_product',
    array(
      'labels' => array(
        'name' => __( 'Products' ),
        'singular_name' => __( 'Product' )
      ),
      'public' => true,
      'has_archive' => true,
    )
  );
}
add_action( 'init', 'create_post_type' );

Con este código básico ya tendríamos creado el CPT Products con el identificador acme_product.

Pero vamos a completarlo un poco más, haciendo un ejemplo completo. Vamos a crear un Custom Post Type de Trabajos. En nuestro ejemplo, para crear un CPT, lo haremos en dos pasos:

  • Crear la taxonomía
  • Crear el CPT

Crear la taxonomía

La taxonomías son un elemento realmente poderoso de WordPress, aunque menos utilizado de lo que se debería. Quizás porque es algo que a todo el mundo le suena, pero pocos saben realmente para qué sirve. Información del Codex de WordPress: https://codex.wordpress.org/es:Taxonom%C3%ADas

Pues bien, es algo tan sencillo como decir que nos sirve para clasificar la información de un tipo de post. Por ejemplo, si tenemos un CPT de «deportes», podemos crear diferentes taxonomías: fútbol, baloncesto, petanca, …

En WordPress, por defecto, nos trae de serie dos taxonomías: categorías y etiquetas. Pero podemos crear diferentes taxonomías para cada CPT.

En nuestro ejemplo, vamos a crear una taxonomía llamada «Tipos de Trabajo» para poder agruprar los trabajos por diferentes tipos: programación, diseño, etc. El nombre de los tipos de trabajo es lo de menos porque, al igual que las categorías, puede ser el propio usuario el que las cree.

La función para crear la taxonomía es register_taxonomy(). Codex de WordPress: https://codex.wordpress.org/Function_Reference/register_taxonomy 

Y en nuestro caso sería:

// Registrar la taxonomia
function fgr_trabajos_taxonomia() {

    // Definimos un array para las traducciones de la taxonomía
    $etiquetas = array(
        'name' => __( 'tipos' ),
        'singular_name' => __( 'Tipo de Trabajo' ),
        'search_items' =>  __( 'Buscar Tipos de Trabajo' ),
        'all_items' => __( 'Todos los Tipos de Trabajo' ),
        'parent_item' => __( 'Tipo de Trabajo padre' ),
        'parent_item_colon' => __( 'Tipo de Trabajo padre:' ),
        'edit_item' => __( 'Editar Tipo de Trabajo' ),
        'update_item' => __( 'Actualizar Tipo de Trabajo' ),
        'add_new_item' => __( 'Agregar un nuevo Tipo de Trabajo' ),
        'menu_name' => __( 'Tipos de Trabajo' ),
    );


    // Función WordPress para registrar la taxonomía
    register_taxonomy(
        'tipos',
        array('trabajos'), // Tipos de Post a los que asociaremos la taxonomía
        array(
            'hierarchical' => true, // True para taxonomías del tipo "Categoría" 
//y false para el tipo "Etiquetas"
            'labels' => $etiquetas, // La variable con las traducciones de las etiquetas
            'show_ui' => true,
            'show_admin_column' => true,
            'query_var' => true,
            'rewrite' => array( 'slug' =>; 'tipos-de-trabajos' ),
        )
    );

}
add_action( 'init', 'fgr_trabajos_taxonomia', 0 );

Registrar el Custom Post Type (CPT)

Una vez creada la taxonomía, necesitamos crear nuestro Custom Post Type (CPT), llamado «Trabajos«.  Esto se hace con la función de WordPress register_post_type(). Codex de WordPress: https://codex.wordpress.org/Function_Reference/register_post_type 

En nuestro caso sería los iguiente:

function fgr_trabajos_cpt() {

 	$labels = array(
 		'name'                  => _x( 'Trabajos', 'Post Type General Name', 'fgr' ),
 		'singular_name'         => _x( 'Trabajo', 'Post Type Singular Name', 'fgr' ),
 		'menu_name'             => __( 'Trabajos', 'fgr' ),
 		'name_admin_bar'        => __( 'Trabajos', 'fgr' ),
 		'archives'              => __( 'Trabajos Archivos', 'fgr' ),
 		'attributes'            => __( 'Trabajos Atributos', 'fgr' ),
 		'parent_item_colon'     => __( 'Trabajo superior', 'fgr' ),
 		'all_items'             => __( 'Todos los Trabajos', 'fgr' ),
 		'add_new_item'          => __( 'Añadir nuevo Trabajo', 'fgr' ),
 		'add_new'               => __( 'Añadir nuevo', 'fgr' ),
 		'new_item'              => __( 'Nuevo Trabajo', 'fgr' ),
 		'edit_item'             => __( 'Editar Trabajo', 'fgr' ),
 		'update_item'           => __( 'Actualizar Trabajo', 'fgr' ),
 		'view_item'             => __( 'Ver Trabajo', 'fgr' ),
 		'view_items'            => __( 'Ver Trabajos', 'fgr' ),
 		'search_items'          => __( 'Buscar Trabajo', 'fgr' ),
 		'not_found'             => __( 'No encontrado', 'fgr' ),
 		'not_found_in_trash'    => __( 'No encontrado en la papelera', 'fgr' ),
 		'featured_image'        => __( 'Imagen destacada', 'fgr' ),
 		'set_featured_image'    => __( 'Establecer imagen destacada', 'fgr' ),
 		'remove_featured_image' => __( 'Borrar imagen destacada', 'fgr' ),
 		'use_featured_image'    => __( 'Usar como imagen destacada', 'fgr' ),
 		'insert_into_item'      => __( 'Insertar en Trabajo', 'fgr' ),
 		'uploaded_to_this_item' => __( 'Subido a este Trabajo', 'fgr' ),
 		'items_list'            => __( 'Listado de Trabajos', 'fgr' ),
 		'items_list_navigation' => __( 'Navegación Trabajos', 'fgr' ),
 		'filter_items_list'     => __( 'Filtrar Trabajos', 'fgr' ),
 	);
 	$args = array(
 		'label'                 => __( 'Trabajo', 'fgr' ),
 		'description'           => __( 'Entradas tipo trabajos / proyectos', 'fgr' ),
 		'labels'                => $labels,
 		'supports'              => array( 'title', 'editor', 'thumbnail', 'custom-fields' ),
 		'taxonomies'            => array( 'tipos' ),
 		'hierarchical'          => false,
 		'public'                => true,
 		'show_ui'               => true,
 		'show_in_menu'          => true,
 		'menu_position'         => 5,
 		'menu_icon'             => 'dashicons-megaphone',
 		'show_in_admin_bar'     => true,
 		'show_in_nav_menus'     => true,
 		'can_export'            => true,
 		'has_archive'           => true,
 		'exclude_from_search'   => false,
 		'publicly_queryable'    => true,
 		'capability_type'       => 'post',
 		'show_in_rest'          => true,
 	);
 	register_post_type( 'trabajos', $args );

 }
 add_action( 'init', 'fgr_trabajos_cpt', 0 );

Algunas aclaraciones:

  • Primero definimos una variable de tipo array, $labels, que simplemente contendrá el texto que aparecerá en las diferentes opciones de nuestro CPT.
  • En la otra variable de tipo array, $args, vamos añadiendo los diferentes argumentos de nuestro CPT. Podéis ver un listado completo en el enlace del Codes de WordPress.
  • Algunos argumentos interesantes cuando creamos el CPT:
    • ‘supports’. Aquí indicamos qué elementos va a tener nuestro CPT. Si no indicamos nada, por defecto sólo contendrá el título y el editor de texto. En nuestro caso le estamos añadiendo también la imagen destacada y soporte para custom fields o campos personalizados.
    • ‘taxonomies’. Le indicamos que nuestra taxonomía va a ser la creada anteriormente, «tipos».
    • Para todas las demás opciones os invito a leer detenidamente la página del Codex de WordPress.

 

Tanto en la función de registrar la taxonomía, como en la de registrar el CPT, utilizamos el hook de WordPress ‘init‘. Este hook se ejecuta inmediatamente después de cargar el WordPress. Es decir, en cuanto carga el core de WordPress, nos creará nuestra taxonomía y nuestro CPT.

Bien pero, ¿dónde se añade este código?

Esto es lo más sencillo 🙂  Para añadir este código tenemos dos opciones:

Una es añadirlo en el archivo functions.php del tema que tenemos activo. Dentro de la carpeta de nuestro tema activo, editamos el archivo functions.php y añadimos ese código y ya está. No tenemos que hacer más.

Pero haciéndolo de esta forma nos podremos encontrar con un problema en el futuro. Y es que cuando cambiemos de tema (que os aseguro que algún día se cambiará) perderemos nuestro CPT.

Lo normal es que queramos conservar el CPT Trabajos para seguir mostrando o añadiendo contenido a ese tipo de post. Entonces lo que podemos hacer es crear nuestro propio plugin con este código.

Es muy sencillo crearse un plugin de este tipo. Es más, podemos crear este código en un plugin que esté ahí siempre y que ningún usuario o administrador de WordPress pueda ni desactivarlo ni eliminarlo. Pero, ¿cómo? Creando un «must use plugin» o «plugin imprescindible«.

Creando un plugin imprescindible o must use plugin

No me voy a extender demasiado en esto, que ya se está haciendo demasiado largo. Simplemente decir que los plugins que creemos de esta manera nos e pueden desactivar desde el WordPress como cualquier otro plugin. Y tampoco eliminar. La única manera de eliminarlo es acceder por ftp y borrarlo.

Lo primero para crear este tipo de plugin es acceder por ftp a la carpete «wp-content» de nuestra instalación de WordPress. Ahí creamos una carpeta nueva, si no está creada, que se llame «mu-plugins«.
Y surge la magia!! Todos los plugins que metamos dentro de esta carpeta aparecerán como «imprescindibles» dentro de la sección plugins de nuestro WordPress. Y ningún usuario lo podrá desactivar ni borrar. Chulo ¿no?

Bien, pues ahí solo debemos de crear por ftp un archivo con extensión php, en mi caso fgr.php

Lo editamos y escribimos los siguiente:

<?php
/*
Plugin Name: Funciones para aumentar funcionalidades
Plugin URI: http://fgrweb.es
Description: Plugin para liberar de funciones el fichero functions.php y ser mas limpio todo. 
Version: 0.0.1 
Author: Fernando Garcia Rebolledo 
Author URI: http://fgrweb.es 
License: GPLv2 o posterior 
*/

Evidentemente podeis cambiar las referencias a fgr por vuestro nombre, o lo que queráis. A continuación pegáis el código de creación de taxonomía y creación de cpt y listo. Aunque se cambie de tema, al tener el código dentro de este plugin imprescindible, siempre vais a tener el CPT Trabajos.

 

Y eso es todo. Me ha quedado un poco máslargo de lo que me esperaba, pero bueno.

Espero que haya quedado claro. Espero vuestro feedback!!

Algunas pistas para elegir un buen hosting para tu web de WordPress

Busca, compara, y si encuentras algo mejor…sigue buscando

Si no quieres leer más, quédate con el título. La elección de un buen hosting es probablemente una de las elecciones más importantes cuando decidimos poner en marcha nuestra web. Y no es una elección sencilla. Hay que investigar, buscando lo que mejor se adapte e nuestras necesidades.

La mala elección de un hosting nos puede traer muchos quebraderos de cabeza. Que nuestra web vaya lo suficientemente fluida y rápida no es únicamente responsabilidad del programador. Aunque optimicemos la web para que cargue rápida, si tenemos un hosting lento sólo podemos hacer una cosa: ¡¡huir!! Pensemos que nuestro visitante no va a esperar 4 ó 5 segundos a que cargue la página.

En este post te daré unas pistas para poder elegir un buen hosting para alojar una web hecha con WordPress.

Pistas para seleccionar tu hosting para WordPress

WordPress es el sistema de gestión de contenidos (cuyas siglas en ingés son CMS) más extendido a nivel mundial (prácticamente un 27% del total de páginas webs están hechas con WordPress). Un CMS es, básicamente,  un software que permite al usuario la creación y modificación de contenido, generalmente de una web, sin tener conocimientos de programación.

Las características más importantes que debemos tener en cuenta a la hora de elegir un servidor para una web hecha con WordPress son:

  • Características técnicas: Php y soporte MySql.
  • Espacio en disco.
  • Tráfico mensual.
  • Atención al cliente.
  • Panel de control fácil de utilizar.
  • No mirar el precio, en un primer acercamiento.

Vamos a ver más en profundidad cada uno de estos puntos

A) Características técnicas del servidor

  Para que WordPress funcione perfectamente, el servidor donde está instalado debe soportar :

  • Lenguaje de programación PHP, versión 5.6 o superior. En este punto os recomiendo que busquéis un proveedor que utilice la versión 7 de php. Hubo bastantes mejoras que, entre otras cosas, permiten una mayor velocidad en nuestra web.
  • Bases de datos MySQL, verión 5.6 o superior, o MariaDB, versión 10.0 o superior.
  • El módulo mod_rewrite del servidor Apache instalado.

El sistema operativo que nos recomiendan (encarecidamente) desde WordPress es Unix/Linux. Como nos indican en la página de WordPress.org, «La mayor parte de proveedores de hosting e instalación personal en sistemas Unix/Linux deberían poder alojar WordPress bajo configuraciones muy comunes«.

Hay otra alternativa, que es instalar WordPress en un servidor Windows con SQL Server. Os dejo un par de enlace donde habla cómo instalar WordPress en un servidor Windows:

Instalación de WordPress para Windows

WordPress con SQL (beta)

B) Espacio en disco y cuota transferencia

Normalmente vamos a contratar un espacio en un servidor compartido. Esto es, una única máquina física sirve para alojar varias webs. Nosotros contratamos un espacio del disco de esa máquina. Para necesidades más críticas en cuanto al control de los datos o una configuración más personalizada del servidor, necesitaremos contratar un servidor dedicado, es decir, una máquina que trabaje sólo para nosotros.

Como digo, en la gran mayoría de las ocasiones con un servidor compartido nos será suficiente. Pero, ¿cuánto espacio del servidor necesito? Bien, pues como muchas veces pasa, depende.

Realmente hoy en día, la mayoría de alojamientos ofrecen al menos 1Gb de espacio en el disco, lo que es cantidad más que suficiente para un sitio web.

Otra cosa es la tasa de transferencia. Esto es, la cantidad mensual de información que nuestro alojamiento nos permite transmitir entre la web y los visitantes. En muchos hosting, con el plan más básico, nos lo venden como ilimitada. Pero, si prevemos que nuestra web va a tener mucho tráfico, es mejor escoger un pan mejor. Mi recomendación en este sentido es que empecéis con un plan básico y si es necesario, se escoge un plan mejorado más adelante.

C) Atención al cliente

Este es un punto muy importante. Una buena atención al cliente es muchas veces la diferencia entre un hosting bueno a uno malo. Antes de contratar un hosting informaros sobre cómo es la atención al cliente. Buscad en Google qué críticas tiene.

Un buen hosting nos debe ofrecer una atención al cliente por tres vías: tickets de soporte, chat online y teléfono. Como nos darán, por norma general, unos días de prueba, mi recomendación es que probéis las tres formas. Probad cómo resuelven los problemas y el trato que os dan.

En este punto me vais a permitir que de mi opinión. Como desarrollador web he trabajado, y trabajo, con varios proveedores. Y tengo que decir que para mi como atención al cliente gana SiteGround. Siempre que me he tenido que poner en contacto para cualquier problema, me lo han resuelto en una sesión de chat. Nada de volver a ponerme en contacto más adelante, o ya lo resolveremos y te avisamos. Un diez. Aunque recalco que esta es mi experiencia.

D) Panel de control

Si tenemos que llevar nosotros mismos la administración de la web, por lo menos que nos lo pongan fácil. Lo más común es que utilice cPanel, aunque no tiene por qué ser así. Lo importante es que el panel de control que nos proporcionen sea fácil de utilizar y podamos hacer la tareas más comunes fácilmente: crear bases de datos, cuentas de correo, cuentas ftp y todo aquello que podamos necesitar.

Es un punto importante, creedme. Me he encontrado con hostings que no tienen panel de control y cada vez que hay que crear un correo, por ejemplo, hay que ponerse en contacto con ellos para que te lo creen. Pérdida de tiempo infinita.

E) No mires tanto el precio

¿Os suena el dicho de «lo barato sale caro»? Pues es aplicable también en un hosting. Hay hostings que son hasta gratuitos. Y puede valer en un momento dado para hacer algún tipo de prueba. Pero nada más.

Estamos hablando de nuestra web, o nuestra tienda online, o nuestro blog… No es cuestión de jugársela por unos euros, ¿no? Además, si comparamos precios, veremos que hoy en día no es nada caro tener un hosting de garantías por poco dinero.

Algunos hostings recomendados

Según la propia página de WordPress.org, recomiendan tres:

Además de estas empresas, os recomiendo que miréis también estas dos:

  • Webempresa
  • Dinahosting, que se está involucrando últimamente un poco más en la comunidad WordPress. Estoy probando en estos días su servicio con una web y de momento muy bien.

Conclusión

Quiero acabar como empecé, y es que en el tema del hosting no existe la verdad verdadera. Así que busca, compara y si encuentras algo mejor, sigue buscando.

WordCamp Chiclana – 7 y 8 de octubre de 2017

Chiclana: la ciudad que acoge

Los días 7 y 8 de octubre de 2017 se celebra en la ciudad gaditana de Chiclana la primera edición de una WordCamp muy especial.

Esta era una WordCamp muy esperada en la comunidad. El comentario cuando se empezaba a rumoear que Chiclana estaba preparando su primera WordCamp era: «Estos chicos de Chiclana son muy grandes!!». Y es que, la apuesta era fuerte. Por tratarse de una ciudad pequeña y ser la primera edición. Pero los chicos de WP Chiclana no le tienen miedo a nada y decidieron organizar la primera edición de la WordCamp Chiclana.

Chiclana es una ciudad de unos 80.000 habitantes, situada en el arco de la bahía de Cádiz. Yo conozco esa zona por motivos familiares y os puedo asegurar que el marco es incomparable. Toda la zona de la bahía de Cádiz merece la pena ser visitada. Y, además, en Octubre es una fecha ideal para visitarlo, ya que no hay esos calores de verano que a los del norte nos cuesta tanto aguantar.
Pero, como los organizadores dicen, lo que distingue de verdad a esta zona es su gente. Humildes, con ganas de ayudar en lo que puedan y con ese punto de vista de las cosas que tiene la gente de Cai.

Entradas a 5 Euros

Pero, por si fuera poco el marco incomparable de Chiclana, la organización nos sorprende con el precio de las entradas para WordCamp: ¡¡5 €!! Y es que, por 5€ tendrás lo siguiente:

  • Acceso a todas las ponencias  talleres del sábado 7 de octubre.
  • Acceso al Día de la Comunidad, el domingo 8 de octubre.
  • Parada de café a media mañana.
  • Comida con networking.
  • Café a media tarde (WordPress no se podría mantener sin cafeína).
  • Camiseta del evento.
  • Descuentos en la fiesta post-WordCamp (after party).

Creo que no se puede ofrecer más por menos. Nadie podrá tener la excusa de no ir por el precio de la entrada.
Además de la entrada básica de 5€, hay otros dos tipos de entrada: la de suscriptor por 20€, y la de colaborador por 100€. Como veis, unos precios muy ajustados.
Os recomiendo que, si tenéis pensado ir, compréis la entrada rápidamente, ya que al precio al que están, se están agotando.
Para comprar la entrada y ver qué beneficios hay por cada tipo de entrada haced clic aquí.

Llamada a voluntarios y ponentes

Como en todas las WordCamps, ya se ha lanzado una llamada a voluntarios y ponentes.

Los voluntarios tendrán la posibilidad de ver cómo es una WordCamp desde dentro. Las labores que hay que hacer son varias: registro de asistentes, presentar charlas, micrófono para preguntas, ayudar a los asistentes,.. Yo he sido voluntario en la WordCamp Bilbao de este año y recomiendo a todo el mundo que lo pruebe. Es ver la WordCamp desde otro punto de vista: te das cuenta de cómo es la organización de un evento de este tipo, conoces a gente muy interesante, patrocinadores,.. El voluntariado es uno de los pilares más importantes sobre los que se sustenta WordPress en general, y una WordCamp en particular. Y os aseguro que es una satisfacción poder contribuir.
Para ser voluntario rellena el formulario que encontrarás en esta página.

También se ha abierto la llamada a ponentes. Cada charla dura 45 minutos, incluyendo las preguntas, que suelen ser unos 10 minutos. Muchas veces esas preguntas se prolongan en la parada para el café o la comida, que para eso es el networking. 
Lo único que se busca en las charlas y talleres de una WordCamp, es la originalidad. En principio no se cierra ningún tema, siempre que éste tenga que ver con WordPress, evidentemente. Lamentablemente la fecha límite para enviar propuestas terminó el pasado 30 de junio.

Conclusión

Id a Chiclana. Id a la WordCamp Chiclana 2017. Esta gente se lo merece

 

WordPress 4.8 is coming

  El próximo 8 de Junio es la fecha elegida para el lanzamiento de la nueva versión de WordPress: la 4.8. Su principal novedad será el nuevo editor: Gutenberg.

  Se avecinan cambios, y es que la versión 4.8 de WordPress traerá algo demandado por los usuarios desde hace tiempo: un editor avanzado.

Novedades de WordPress 4.8

  A grandes rasgos, esta versión tendrá las siguientes novedades:

  • Editor TyniMCE, con el que se podrá, entre otras cosas, formatear texto en línea.
  • Nuevos widgets de medios.
  • Editor WYSIWYG en los widgets de texto.
  • Se añade información de las WordCamps en la sección noticias del tablero de administración.

Fechas

  Como es lo normal, antes de salir la versión definitiva, habrá un periodo para testear. Las fechas serán las siguientes:

  • 12 de Mayo: Lanzamiento de la Beta 1.
  • 19 de Mayo: Lanzamiento de la Beta 2.
  • 25 de Mayo: Lanzamiento de la primera versión «Release Candidate». Esto es, la versión candidata a definitiva.
  • 1 de Junio: Lanzamiento de la versión definitiva «Release Candidate».
  • 7 de Junio: Empieza a funcionar la versión definitiva 4.8
  • 8 de junio: Lanzamiento oficial de WordPress 4.8

  Si queréis ir testeando la versión 4.8 es muy sencillo. Os instalais un WordPress de prueba, y le añadís un plugin que está en el repositorio, el «WordPress Beta Tester«. Este viernes día 12 recibiréis una actualización y a empezar a testear la nueva versión. Por cierto, mal día el 12 de Mayo: es viernes y además ese fin de semana es la WordCamp Bilbao.

El editor Gutenberg

  Uno de los obstáculos de WordPress ha sido, desde hace un tiempo, su editor. Es ciertamente limitado en cuanto a funcionalidades, y era muy demandado un nuevo editor. Los plugins para maquetar contenido son cada vez más utilizados, en gran parte debido a las carencias del editor por defecto de WordPress.

  Es verdad que hay algún plugin que vitaminan mucho el editor que viene por defecto en el core; en concreto estoy hablando del TinyMCE Advance, que da un extra al editor de WordPress, integrando botones como la inserción de tablas, diferentes fuentes, tamaños, etc… No en vano, tiene más de 2 millones de instalaciones, ahí es nada. 

  Por otro lado están los maquetadores visuales para WordPress: todo un mundo. Yo, de hecho, suelo utilizar Elementor para muchos de mis proyectos (a ver si hago una entrada hablando de este magnífico maquetador). El problema que suele pasar con estos maquetadores es que, por lo general, pesan mucho y ralentizan la carga de la página. Y mucha gente igual sólo lo utiliza para maquetar columnas, por ejemplo, cosa que el editor de WordPress no lo permite.

  Así que la mayoría de usuarios de WordPress esperaba un editor mejorado para la nueva versión del core, y su nombre es Gutenberg (un nombre muy acertado, por cierto).

  En este enlace tenéis un ejemplo de una entrada hecha con Gutenberg. ¡Parece que está hecho con un maquetador visual!.

Pantalla editor gutenberg

  Por lo que parece es un editor visual en línea. Puedes ir modificando la entrada desde el front, y ver directamente cómo queda. No como ahora, que hay que guardar en el back y ver cómo quedan los cambios en la web.

  En este enlace podéis ver diferentes imágenes de cómo es el editor. Como dicen ahí, está sujeto a cambios, no es definitivo. Pero será a bien seguro algo muy similar.

  Pero como casi siempre, para poder hablar de algo lo mejor es probarlo. En este enlace podréis probar el funcionamiento de Gutenberg. Personalmente me parece una autentica pasada. Es lo que muchos usuarios veníamos demandando desde hace tiempo.

  Se sigue trabajando en ello, pero tiene toda la pinta que va a ser la estrella del nuevo WordPress 4.8. Un último enlace: Cómo funciona el editor por bloques

Cambios en widgets

 Por lo que parece, este va a ser otro de los cambios fuertes de WordPress 4.8. Por un lado parece que va a haber widgets de medios. Esto es, en un widget vamos a poder insertar directamente una imagen como se hace ahora en el editor de texto. Ahora se puede hacer, pero hay que copiar la url del archivo de imagen, ir al widget y pegar esa url. 

  También se va a implementar un editor de texto TinyMCE en los widgets, al estilo de lo que hace este plugin

Conclusión

  Como ya se anunció en el 2016, los esfuerzos se centrarían en el editor del core de WordPress, pero hay muchos más cambios. Podéis ver  las notas de las reuniones de los desarrolladores aquí

  A partir de mañana veremos cómo va la beta 1 y seguiremos informando. Para aquellos que lo vayáis probando la beta, ¿qué os parece?

Resumen WordCamp Madrid 2017

  El fin de semana del 22 y 23 de Abril de 2017, se celebró la WordCamp Madrid 2017. Era la primera edición de esta esperadísima WordCamp, que, tras unos años de intentos fallidos, por fin se ha puesto en marcha.

 ¿Qué es una WordCamp?

  Las WordCamps son eventos locales, organizados por la comunidad, cuyo fin es compartir ideas, hacer networking y aprender.  Son eventos oficiales, respaldados por la WordPress Foundation, y que, evidentemente, todo gira alrededor de WordPress (.org).

  Pueden durar de uno a 3 días, dependiendo de la organización local del evento. Hay conferencias de todo tipo y para todos los niveles: ya seas un usuario principiante, experto, si eres back-end, front-end, programador, marketiniano (no creo que exista, pero me entendéis xd), … Siempre se aprende algo. Las ponencias, normalmente, son de una calidad extraordinaria, impartidas por verdaderos profesionales del sector.

  En las WordCamps que he asistido, siempre hay dos tracks simultáneos, en los que se dan dos conferencias distintas, por lo que es físicamente imposible asistir a todas las conferencias que se dan. Pero existe una página, WordPress.tv, donde se suelen colgar las conferencias de las WordCamps. Os recomiendo que echéis un vistazo a los videos de esa web, donde se aglutina gran parte de las conferencias mundiales de WordPress.

  Pero hay algo que no se puede hacer viendo los videos: el networking. Bien sea en los coffee break, o bien en la comida, o bien entre una charla y otra, te puedes parar a charlar con alguien para compartir conocimientos, impresiones, hacer preguntas o, simplemente, para aprender. En un intervalo de 5 minutos hablando con profesionales de este nivel se puede aprender una barbaridad. De hecho, esta es mi razón de peso para asistir a las WordCamps, aunque en esta concretamente estuve poco participativo, debido al catarro que arrastraba, pero aún así aprendí y mucho.

El recinto

  La WordCamp Madrid 17 se celebró en Campus Madrid, un sitio super chulo. Es un recinto creado por Google, y dirigido a emprendedores. Es una especie de coworking para emprendedores, con un diseño muy moderno y funcional; muy al estilo Google.

  Campus Madrid tiene un salón de actos enorme y muy bien equipado para este tipo de eventos; ahí era donde se desarrollaban las conferencias del track A. Pero, por poner una pega, al no tener más que esa sala para conferencias, noté mucha diferencia entre el track A y el track B. El track B se desarrollaba en la planta superior del coworking, con lo que en muchas conferencias se quedó pequeño. 

Las conferencias

  El sábado 22 de abril había 22 charlas programadas, por lo que se presentaba un día intenso por delante. En el registro nos regalaron a todos los asistentes una bolsa de tela muy chula con el logotipo grabado de la WordCamp, una serie de regalos (taza, bolígrafos, pegatinas) y publicidad de los patrocinadores.

  Tras charlar brevemente con algún conocido de otras WordCamps, me fui a la charla de presentación de la WordCamp.

WordCamp Madrid. Presentación

  Aclarar que sólo hablaré de las charlas a las que asistí. Para ver el programa completo de la WordCamp, seguid este enlace

Por otro lado, están los videos de las ponencias colgados en Youtube, tanto del track A como del track B



WordPress mató a Bambi – Fernando Tellado

WordCamp 2017 - WordPress mató a Bambi. Fernando Tellado

  Fernando Tellado (@fernanadot) es una de las primeras personas en España que empezó con WordPress. Tiene un blog que es una referencia de WordPress en el mundo hispano: Ayuda WP. También es autor de dos libros sobre WordPress: «WordPress 4.0. La tela de araña«, escrito junto a Yoani Sánchez, y «WordPress.1001 trucos«, del que tengo la suerte de tener un ejemplar firmado 🙂

  Fernando nos dio una charla muy interesante, que intentaba romper los mitos que se tienen sobre WordPress.org. Dio argumentos para echar por tierra todas aquellas dudas que algunos tienen sobre WordPress: que si es inseguro, que sólo vale para blogs, que sólo vale para webs pequeñas,… En los minutos que duró la charla desmontó todos los mitos que circulan en relación a WordPress, y con ejemplos, para que no haya lugar a dudas.


Cómo usar GraphQL para consumir la API REST de WordPress – Félix Zapata

Cómo usar GraphQL para consumir la API REST de WordPress - Félix Zapata

  Félix Zapata (@felixzapata) nos dio una interesante charla sobre GraphQL, un lenguaje tipo query creado por Facebook allá por 2012 y que, hay quien sostiene que está llamado a sustituir a REST.  Nunca he utilizado GraphQL y la verdad que lo que nos mostró Félix en su charla parecía muy interesante. Uno de los puntos que me pareció interesante, si no lo entendí mal, due que con REST puedes hacer varias llamadas a los endpoints para traerte unos pocos datos que necesitas, mientras que con GraphQL con una sóla llamada lo puedes solucionar.

  Os dejo enlace a la presentación de Félix Zapata

  Después de esta conferencia, tuvimos un descanso para tomar un café con churros, como no podía ser de otra manera estando en Madrid 🙂 Tras más o menos media hora, volvimos a la carga con las conferencias.


¿Por qué defender la web abierta? 5 reflexionas para mejorar nuestro futuro – Juan Hernando

  ¿Por qué defender la web abierta? - Juan Hernando

  Sin ser una charla técnica, esta fue para mi una de las mejores de toda la WordCamp. Juan Hernando (@ciudadanob) es creador del blog Ciudadano B, nos contó que venía del futuro para prevenirnos. Un futuro en el que ya no existe la web abierta. Nos habló de los peligros que corremos si no damos importancia a nuestros datos, y lo dejamos todo en manos de grandes corporaciones.

  Enlace a la presentación de Juan Hernando

  Enlace a la entrada de su blog con todos los detalles de la charla.


Los 10 mandamientos del WPO – Pablo López

Los 10 mandamiento del WPO - Pablo López

  Pablo López (@desarrollowp) es el creador del blog DesarrolloWP. Nos habló del WPO (Web Performance Optimization), o lo que es lo mismo, qué debemos hacer en una web para que vaya rápida y, al mismo tiempo, Google nos quiera. Con  la optimización de la carga de las webs conseguimos, entre otras cosas, que la experiencia del usuario sea buena y no abandone desesperado por la lentitud en cargar la web.
  En esta charla dio un repaso a lo que debemos hacer para que una web no vaya «a pedales». Son pistas básicas que debemos tener muy en cuanta a la hora de programar una web.

  Enlace al blog de Pablo López, donde explica la charla que impartió en la WordCamp Madrid

 

  Después de esta charla vinieron tres charlas denominadas «speedTalk». Esto es, charlas cortas, de unos 15 minutos, donde van las tres seguidas y hasta la finalización de las tres no se pueden hacer preguntas. Personalmente no me gusta este modelo, ya que las charlas se te hacen muy cortas.
  Como me entretuve un rato charlando en los pasillos, finalmente sólo pude ver una de estas charlas.


La aventura de usar WordPress en la administración pública y en grandes medios – Joan Artés

La aventura de usar WordPress en la administración pública y en grandes medios - Joan Artés

  Joan Artés (@Joan_Artes) es cofundador de la empresa Artesans, y lleva muchos años trabajando con WordPress. En esta mini-conferencia nos habló de cómo trabajan con grandes clientes y las dificultades que ello conlleva. Aunque duró muy poco fue una charla muy interesante. Me quedé con ganas de más.

 

  Luego vino la comida. Comimos en el mismo recinto, pinchos, cosas para picar y ese tipo de cosas; y mucho coworking. Posteriormente vinieron las charlas de la tarde.


En ocasiones…hago migraciones – José Ramón Padrón

En ocasiones...hago migraciones - José Ramón Padrón

  José Ramón Padrón (@monchomad), a.k.a Moncho, es el Country Manager en España de SiteGround, para mi la mejor empresa de web hosting en estos momentos. SiteGround no es la primera empresa de hosting en la que trabaja, sino que lleva algo así como 17 años metido en esto. Al oírle hablar se nota que sabe de qué habla. Además de esto, es el responsable de la comunidad WordPress en Las Palmas y, siempre que puede, se involucra en eventos de la comunidad.
  Aunque siendo el responsable de una empresa de hosting, se pudiera pensar a priori que nos venía a vender su empresa, no fue así. Dio una charla muy amena que muchos tips sobre cómo afrontar una migración de un sitio web. Fue una charla muy interesante y muy bien explicada. Lamentablemente, no he encontrado la presentación 🙁


HTTP/2: buenas prácticas – Fernando Puente

HTTP/2: buenas prácticas - Fernando Puente

  Fernando Puente (@fpuenteonline) es, sin duda, uno de los «cracks» de WordPress España. Cuando habla, hay que escucharlo. Lleva como 20 años como programador y actualmente es CEO de La Estrategia de Chapman, que es una empresa de comunicación internacional, donde se gestionan con WordPress cerca de 10 millones de visitas al mes!! (para que luego digan que WordPress no aguanta grandes volúmenes de tráfico).

  Nos habló sobre el protocolo HTTP/2, el «nuevo» protocolo que viene a mejorar el actual HTTP. Es soportado por la mayoría de los navegadores (creo que mencionó el 90%) y conseguimos un aumento en la velocidad de entrega de las páginas del orden del 15%. Habló de buenas prácticas con HTTP/2 y dio algunas recomendaciones. Por último, nos hizo un pequeño test a ver si nos habíamos enterado de la charla 🙂 Como decía, una de las mejores charlas de la WordCamp, impartida por uno de los mejores profesionales de WordPress ¿qué más se puede pedir?

  Enlace a la presentación de la charla


¿Cómo hacer SEO en WP en 2.017? – Juan Moyano Ecénarro

?Cómo hacer SEO en WP en 2017? - Juan Moyano Ecénarro

  Juan Moyano (@cruzmoyano) es profesional del márketing desde hace 19, y responsable de la consultora «Aún Más Difícil Todavía«. Es un auténtico profesional del marketing, con muchos años de experiencia y que hace 5 años decidió emprender con su propio proyecto. Como comunicador, es excelente.

  El marketing digital es algo que cada vez me gusta más. Aunque yo me considero programador web orientado al front-end, como freelance tienes que tocar un poco de todo, y hoy en día el SEO es algo que tienes que saber al menos manejarlo y algunas buenas prácticas. En su charla nos contó que espera Google de nuestras webs. Google es un robot, sí pero cada vez está más humanizado. Nos posicionará mejor si ofrecemos contenido de calidad: así de «fácil». Habló del SEO «on page», del SEO «offpage», la experiencia de usuario, el hosting,… en definitiva, dio muy buenas pistas para optimizar nuestro sitio web. LA charla se me hizo muy corta; espero poder volver a verle en algún otro evento.

  Enlace a su presentación

  Enlace al video de su charla


  Y así acabó el sábado, pero no la WordCamp. Y es que en las WordCamps siempre se reserva un día para colaborar con la comunidad WordPress: el Contributor Day. Como sabéis, WordPress es un software de código abierto, y mantenido por la comunidad, de manera completamente altruista.

  En el Contributor Day  se organizan distintas mesas de trabajo (traducciones, temas, programación,…), y en cada una hay un responsable con experiencia que enseña a los nuevos en qué manera se puede colaborar con WordPress. No hay horario ni plan establecido; es simplemente un día de comunidad, donde cada uno aporta lo que puede o sabe para que WordPress siga creciendo y devolver algo de lo que este software nos ha dado.

  Lamentablemente en esta ocasión no pude acudir el domingo al Contributor Day por tener que quedarme en el hotel a trabajar en un proyecto que tenía que sacar al día siguiente. Sí, los autónomos trabajamos de lunes a domingo 🙂

   Y esto ha sido todo. La semana que viene del 12-14 de Mayo, toca la WordCamp Bilbao, en la que participaré como voluntario y espero contar cómo es una WordCamp desde el otro lado.

 

Foto de grupo de la WordCamp Madrid 17

WPHackathon

  El pasado fin de semana tomé parte de una iniciativa pionera, al menos en España. Se trata del WPHackathon. Os voy a explicar en qué consiste y cómo fue la experiencia.

¿Qué es WPHackathon?

  WPHackathon viene de la conjunción de 3 palabras: WordPress, Hacking y marathon. 

  Entendiéndose hacker como la persona que «..se dedica a programar de forma entusiasta, o sea un experto entusiasta de cualquier tipo», que considera que poner la información al alcance de todos constituye un extraordinario bien» (ver en Wikipedia). No tiene mucho que ver con Mr Robot, ¿no?

  Volviendo al tema, el WPHackathon es básicamente una maratón de programación para WordPress. Hay muchos eventos hackathon, en los que se pone un reto para que quede realizado en un fin de semana (normalmente en 24 horas). Por ejemplo, los programadores de videojuegos hacen quedadas de este tipo, en las que para el domingo por la tarde ya tienen al menos una primera versión del videojuego.

  Bien, pues aquí se trataba de crear webs hechas con WordPress para organizaciones sin ánimo de lucro. A aquellas ONGs que no tuviesen una web, o quisiesen mejorar lo que tienen, se les ofrece esta oportunidad para hacérsela completamente gratis por profesionales de la web.

Organización y colaboradores

  Este primer WPHackathon estuvo organizado por Ibon Azkoitia (web  | Twitter ) de Kreatidos. Ibon es una de las personas más activas dentro de la comunidad WordPress España. Os recomiendo que visiteis su web o Twitter y veais en la cantidad de proyectos relacionados con WordPress en los que anda metido.

  Por otra parte, un evento de este tipo necesita patrocinadores. En esta primera edición fuero:

  • Hotel Gran Bilbao, que nos cedió uno de sus salones para realizar este WPHackathon.
  • MantenimienWP, empresa que se dedica al servicio de mantenimiento de webs hechas con WordPress.
  • SiteGround, que ofreció alojamiento gratuito a aquellas ongs que participasen en este evento.

Participantes

  En la petición de participantes al evento, se pedían perfiles de todo tipo: programadores, diseñadores, copywriters, etc. Lo que se pretende es cubrir con profesional todos aquellos perfiles que participan en la elaboración de un sitio web.

  En un primer momento nos apuntamos 5 participantes, aunque realmente fuimos 3 los que estuvimos más de 24 horas al pie del cañón: Ibón Azkoitia, Rosa Pérez (Twitter) y yo. Aunque sí que hubo gente que iba y venía. Como ejemplo, una chica apareció a eso de las 2 de la mañana. Era diseñadora. Llegó, estuvo retocando unos cuantos archivos css, lo dejó bonito y a eso de las 4 de la mañana se fue a dormir a su casa.

Impresiones

  En todos los eventos se aprende alguna cosa. Desde una Meetup hasta un WordCamp, siempre acabas sacando algo positivo. Y en esta ocasión no podía ser menos. Lo estuvimos hablando, que el trabajar con otras personas siempre aprendes algo. Nuevas herramientas que no conoces, métodos de trabajo diferentes,…

  En definitiva, una experiencia muy positiva que espero tenga continuidad. De hecho, la idea es hacer más iniciativas de este tipo por toda España. Espero que salga.

  Por último os dejo unas fotografías del evento:

WPHackathon 2017 WPHackathon 2017 WPHackathon 2017

Tutorial WP-CLI desde cero (y III). ¿Qué puedo hacer con wp-cli?

Como ya he comentado en las entradas anteriores, WP-CLI es una herramienta increíble para controlar las instalaciones de WordPress. Vamos a ver un pequeño resumen de lo que podemos hacer con WP-CLI.

Instalar WP-CLI

  Una vez estamos conectados por terminal (si no sabes cómo es, te remito a la segunda parte de este tutorial), lo primero es instalar WP-CLI. Para ello simplemente hay que escribir el siguiente comando:

$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

 

  Lo instala automáticamente. Para comprobar que está instalado podemos escribir un comando. Por ejemplo, este comando nos da versión de WP-CLI que tenemos instalada, en mi caso la 0.23.1:

$ # wp cli version
WP-CLI 0.23.1

 

Algunos comandos de WP-CLI

  Desde la terminal podemos acceder a la lista completa de comandos con

wp help

 

  Para mostrar  la ayuda de un comando en concreto hay que escribir wp help + el nombre del comando. El siguiente ejemplo nos muestra la ayuda para el comando plugin

wp help plugin

 

También podemos consultar los comandos desde la web de wp-cli, muy bien explicados y con ejemplos.

A continuación pongo algunos ejemplos de comandos de WP-CLI

Instalar WordPress

  Para hacer una instalación de WordPress, simplemente tecleamos el siguiente comando:
wp core download
e instala la última versión de WordPress en idioma inglés de Estados Unidos(en_US).

Si se quiere instalar la versión en español de España, por ejemplo, podemos indicarles que nos instale el paquete con ese idioma en concreto:
wp core download --locale=es_ES

Plugins y temas

  El mantenimiento de plugins y temas del repositorio de WordPress es muy sencillo. Podemos instalar, desinstalar, actualizar a la última versión, activar, desactivar, .. en fin, todas las opciones que hay desde el escritorio de administración de WordPress, pero haciéndolo desde la terminal.

  Para instalar un plugin primero debemos saber el nombre del plugin. Para ello vamos al repositorio de plugins y buscamos el plugin que vamos a instalar. Una vez lo encontramos miramos en la barra de dirección el nombre del plugin.
  Por ejemplo, imaginemos que vamos a instalar el plugin de seo de Yoast. Lo encontramos en el repositorio, y la dirección del plugin dentro del repositorio es «https://es.wordpress.org/plugins/wordpress-seo/«. Bien, pues hay que fijarse en wordpress-seo. Para instalar este plugin desde WP-CLI sería
wp plugin install wordpress-seo --activate
  Con esta instrucción lo instala y lo activa.

  De manera similar pasa con los temas. En el ejemplo siguiente voy a hacer lo siguiente: eliminar el tema «Twenty Fifteen», posteriormente instalar un tema del repositorio, «Sydney», y por último crear un tema hijo de este. Vamos allá

#borrar tema Twenty Fifteen
$ wp theme delete twentyfifteen 
Deleted 'twentytwelve' theme. 
Success: Deleted 1 of 1 themes.
#instalar el tema Sydney.
$  wp theme install sydney
Installing Sydney (1.35)
Descargando el archivo de instalación de https://downloads.wordpress.org/theme/sydney.1.35.zip...
Using cached file '/home/fernan17/.wp-cli/cache/theme/sydney-1.35.zip'...
Descomprimiendo...
Instalando el tema...
El tema se ha instalado con éxito.
Success: Installed 1 of 1 themes.
#Crear tema hijo basado en Sydney
wp scaffold child-theme fgr-child-theme --parent_theme=sydney --theme_name='Mi tema hijo' --author='Fernando Garcia Rebolledo' --author_uri=http://fgrweb.es --theme_uri=htts://fgrweb.es --activate
Success: Created '/home/fernan17/public_html/wp-content/themes/fgr-child-theme'.
Success: Switched to 'Mi tema hijo' theme. 

 

Operaciones en la base de datos

  Otra utilidad muy buena de WP-CLI es realizar acciones sobre la base de datos. Lo habitual es ir al panel de control de nustro hosting y utilizar la aplicación phpMyAdmin  para interactuar con la base de datos. Esto lo podemos hacer de forma secilla a través de la terminal. Por ejemplo, podemos lanzar una instrucción select,

$wp db query 'SELECT display_name FROM wp_users WHERE user_login="fgr"'
+--------------+
| display_name |
+--------------+
| fgr |
+--------------+

 

Crear una copia de seguridad de la base de datos,

$wp db export backup.sql
Success: Exported to 'backup.sql'.

 

  Podéis ver todas las operaciones que podemos hacer sobre la base de datos aquí.

Y mucho más…

  Podemos crear, editar y eliminar entradas y páginas, cambiar el dominio, usuarios, etc. En fin, como podéis ver es una herramienta muy completa y sobre todo, muy rápida. Si las acciones que podemos hacer con WP-CLI las tuviésemos que hacer desde el escritorio de nuestra instalación de WordPress tardaríamos una barbaridad en comparación de lo que tardamos con WP-CLI.

  Os voy a dejar un video de una Meetup realizada por la Comunidad WordPress Valencia, y cuyo título lo dice todo: «WP CLI: La navaja suiza de WordPress que te hará un superhéroe«

  Y por último, a modo de ejemplo os enlazo un bash creado por mi, recopilado a su vez de otros, que a través de WP-CLI instala WordPress, crea post, define opciones del wp-config.php, instala algún tema, etc. Sois libres de utilizarlo y ampliarlo si queréis.
Acceso al superinstalador WP en GitHub

 

  Y nada más, espero que esta serie hablando de WP-CLI os haya servido, o, al menos, os entre la curiosidad de probarlo. Cualquier duda me podéis escribir a través del formulario de contacto o dejar un comentario en la entrada.

 

Tutorial WP-CLI desde cero (II). SSH con Putty

En la anterior entrada vimos qué era y para qué servía WP-CLI. Ahora os voy a contar algo que en muchos tutoriales pasan por alto: cómo acceder desde mi ordenador con Windows a través de consola al servidor web. La mayoría de artículos de WP-CLI dan por hecho que sabes cómo conectarse mediante consola con el servidor. Pero en muchos casos no es así. Y os lo voy a explicar cómo hacerlo en un servidor compartido; es decir, el caso más común, donde te habilitan un espacio para tu hosting dentro de un servidor compartido por varias webs. Si este es tu caso, ¡sigue leyendo!

¿Qué es SSH?

SSH es un protocolo de comunicación, que sirve para acceder a máquinas remotas mediante la red. Las siglas provienen de su nombre en inglés, Secure Shell. Permite establecer una comunicación de manera segura, encriptando la comunicación y evitando así que terceras personas puedan ver lo que se transmite durante la sesión.

  Para aquellos que hayáis utilizado telnet en alguna ocasión, es parecido pero mucho más seguro. Es decir, lo manejamos por línea de comandos, pero la diferencia es que en telnet no hay ninguna seguridad mientras que con ssh la información se envía encriptada.

Instalar PuTTy.

  Bien, vamos a ver cómo acceder mediante SSH a nuestro servidor compartido Linux con nuestro ordenador Windows. El programa que hace posible la conexión SSH es PuTTy. La verdad que desconozco si es el único, pero es el que yo utilizo y va bastante bien. Gratuito, ocupa poco y hace lo que tiene que hacer.

  La última versión se puede descargar desde aquí. Simplemente se descarga un archivo de instalación para Windows (MSI). Hay dos versiones: para 32 bits y para 64 bits.

  Una vez descargado, la instalación es muy sencilla. La típica instalación de Windows: pantalla, botón «siguiente», etc. Nos creará 10 archivos en la carpeta que le hemos indicado en la instalación.

Instalación de PuTTy

Generar clave privada

  Accedemos al panel de control de nuestro servidor web.  Buscamos la opción SSH. Si no la tenemos, a veces sólo hay que pedirle a nuestro proveedor que nos lo active. Aunque en la mayoría de los casos ya viene activado por defecto. Si no lo tenemos y nuestro proveedor no nos lo activa, quizás lo mejor es que dejes de leer esta entrada y te pongas a buscar otro hosting, ¿no crees?

  Una vez en la sección de SSH, tenemos que generar una clave, que va a ser lo que nos permita acceder mediante SSH de manera segura. En cada panel varía un poco, pero básicamente es lo mismo. Se genera la clave y tenemos que descargar a nuestro ordenador la clave privada. Nos descargará un archivo con extensión .ppk

Clave privada ppk

Conectar con el servidor mediante SSH

Pageant

  Ahora viene lo divertido. Necesitamos que nuestro proveedor de hosting nos proporcione los siguientes datos de acceso SSH:

  • Servidor. En muchos casos será el nombre de dominio, pero en otros muchos no.
  • Puerto. Por defecto es el 22, pero la mayoría de hostings lo tienen cambiado.
  • Usuario y contraseña. Aunque habiendo generado la clave privada no nos hará falta la contraseña.

  Bien, ahora hay que añadir la clave privada a PuTTy. Para ello abrimos uno de los programas  que se nos instaló en la misma carpeta PuTTy, Pageant.exe. Al abrir el programa, lo normal es que se abra minimizado en la barra de tareas. Si es así, simplemente botón derecho -> View Keys. Y os aparecerá la siguiente pantalla:

Pantalla Pageant

Aquí le damos al botón «Add Key» y cargamos la clave privada que nos hemos descargado anteriormente, con extensión .ppk.

Cuando Pageant cargue la clave va a pedir la clave. Esta es la clave que pusimos cuando se creó la clave. 

Pageant Password

PuTTy

Bien, ya tenemos la clave cargada. Sólo queda abrir el programa PuTTy e introducir los datos que nos ha proporcionado nuestro proveedor de hosting.

  A la izquierda nos muestra un árbol con las diferentes opciones. Sólo tenemos que modificar en principio, la primera opción «Session«. Con rellenar las casillas «Host name» y «Port» con los datos de nuestro servidor sería suficiente.
  Los demás datos los que vienen por defecto (por supuesto, «Connection type:SSH» xd). Podemos guardar estos datos para no tener que introducirlos cada vez que arranquemos el programa.

PuTTy

  En esta pantalla hacer clic en el botón «Open» y nos abre el terminal donde hay que introducir el usuario que nos ha proporcionado nuestro proveedor de hosting.

Terminal

  Y… tachán!!!! Estamos conectados al servidor por terminal. Aquí podemos utilizar cualquiera de los comandos de Shell de Linux.

  Bien, pues aquí lo dejamos hoy. En  la próxima entrada veremos cómo instalar el WP-CLI en el servidor y algunos comandos y trucos de WP-CLI.

¡¡Hasta la próxima!!

 

Tutorial WP-CLI desde cero (I). Qué es WP-CLI

Os voy a intentar explicar paso a paso cómo utilizar esta maravillosa herramienta para administrar sitios creados con WordPress: WP-CLI. Todo aquel que maneje o haya manejado una o más instalaciones de WordPress ya sabrá lo tedioso que es subir los archivos por ftp, instalar, buscar los plugins e instalarlos etc. Pues con WP-CLI todo esto se puede hacer en unos pocos segundos. 

  Vamos por partes.

¿Qué es exactamente WP-CLI?

  Tal y como se indica desde su web, wp-cli.org, es una herramienta para manejar instalaciones  de WordPress desde terminal (línea de comandos). Nos permite hacer instalaciones, actualizar plugins y temas, configurar multisitios y mucho más (pero mucho, eh?). Y todo esto sin tener que acceder a ningún navegador. Todo mediante línea de comandos.
  Para el neófito puede que esto no sea para tanto, pero si te ha tocado instalar un sitio con WordPress, instalar temas, plugins, configurar, etc. te darás cuenta de lo importante que es esta herramienta. ¡Un trabajo que puede que te llevase 30 ó 40 minutos, lo puedes hacer con WP-CLI en segundos! Sí, como lo oyes (bueno, como lo lees xd). 

  WP-CLI fue inicialmente programado por Andreas Creten. Posteriormente, en 2009 tomó los mandos Cristi Burcă, y actualmente el proyecto es mantenido por Daniel Bachhuber, aunque con una gran ayuda: desde este año 2017 tiene soporte oficial por parte de la fundación WordPress.org, tal y como anunció en Diciembre pasado , creador de WordPress. Tal y como él dijo WP-CLI «ha sido una de las herramientas de desarrollo que más impacto han tenido en WordPress». 

Andreas Creten dio una excelente charla en la WordCamp  de Praha en el año 2015, donde hace una revisión de su herramienta.

¿Qué puedo hacer con WP-CLI?

  Con esta herramienta podemos realizar la mayoría de las acciones cotidianas con WordPress. Algunas cosas que podemos hacer con WP-CLI:

  • Descargar, instalar y actualizar el núcleo de WordPress.
  • Instalar, borrar y eliminar tanto plugins como temas.
  • Crear y modificar post y páginas.
  • Manejo de usuarios.
  • Controlar opciones de la instalación (post por página, definir página de inicio, etc…).

En este enlace podéis ver la lista de comandos básicos.

¿Qué se necesita para utilizar WP-CLI?

  WP-CLI trabaja mediante terminal, esto es, mediante la típica interface de línea de comandos. Los requisitos mínimos del servidor donde nos vamos a conectar son:

  • PHP versión 5.3.29 o posterior
  • WordPress versión 3.7 o posterior
  • Servidor con entorno UNIX, como puede ser Linux.

La mayoría de los servidores web están ya preparados, aunque es conveniente asegurarse antes de empezar.

 

  Bien, teniendo claro qué es WP-CLI y para qué sirve, ahora hay que ver cómo funciona. Aunque empezaremos en la siguiente entrada. Veremos como configurar todo el entorno desde nuestro PC con SO Windows para poder conectarnos con el servidor mediante línea de comandos. Posteriormente veremos un poco en profundidad qué podemos hacer con WP-CLI.

  Os espero en la próxima entrada.