WordPress developer in the middle of the night
About Desarrollo
En el post anterior comenté la forma de saber si WooCommerce está instado.
Ahora bien, si en lugar de eso queremos saber si está activado para realizar algún proceso en el que necesitemos que está activo y no sólo instalado, podemos utilizar el siguiente código.
Sobra decir que, tanto este código como el del post anterior, lo podemos adaptar a cualquier otro plugin del que necesitemos conocer si está instalado o activado.
Seguimos…
Si queremos saber si está instalado el plugin de WooCommerce en el WordPress en cuestión sobre el que vamos a realizar alguna tarea contra WooCommerce o lo necesitamos porque vamos a desarrollar algún plugin para WooCommerce y no debería de activarse si WooCommerce no está instalado, podemos utilizar el siguiente código para saber si está instalado y tomar las medidas oportuna en caso contrario.
Espero que os sea de utilidad.
Seguimos…
Para este caso estamos utilizando el plugin JWT Authentication for WP REST API que nos facilita el trabajo a la hora de configurar la autenticación a través de la rest API de WordPress.
Si queremos establecer un tiempo de expiración personalizado para el token y que después de ese tiempo ya no se pueda utilizar y el usuario no pueda acceder, podemos hacerlo a través del siguiente código utilizando el filtro «jwt_auth_expire»:
Cambiar el valor de $expire a vuestras necesidades. Siempre teniendo en cuenta que se trata de segundos.
En el ejemplo lo he establecido a 1 hora.
Saludos y ánimo.
En el tutorial crear un posts de WordPress con código te explicaba mismamente eso, pero en esta ocasión vamos a ir un poco más allá para crear no sólo el post o la entrada sino que vamos a crear, publicar y conectar las traducciones de un mismo post.
Creo que no hace falta decirlo pero vaya usted a saber. Necesitas tener instalado WPML y para el ejemplo que te voy a mostrar, 3 idiomas configurados en WPML. En este caso yo tengo configurados «español», «inglés» y «euskera».
El idioma que he configurado como «principal» o «por defecto» en WPML es «español».
Aclarado esto, vamos al lío:
Lo que voy a hacer es crear una función donde crear el contenido de cada post: «título», «contenido» y «estado». Almaceno el contenido de cada idioma en un array para crear cada unos de los posts por separado y luego ya los conectaré.
Por ejemplo, para crear el contenido en español:
$post_original_es = array(
'post_title' => 'Título del post en español',
'post_content' => 'Contenido del post en español y bla, bla, blac...',
'post_status' => 'publish'
);Y para crear el contenido en inglés:
$post_traducido_en = array(
'post_title' => 'My post title - English',
'post_content' => 'My post content in english and ble, ble, ble...',
'post_status' => 'publish',
);De momento no pongo el de euskera porque es más de lo mismo pero en otro idioma.
Como puedes observar, creo un array con el contenido que quiero, un array por cada idioma.
De momento no he publicado nada, sólo he creado esos arrays para preparar el contenido que publicaré.
Ahora voy a utilizar la función wp_insert_post() que ya usé en el tutorial que te comentaba al inicio. Lo que hace es precisamente eso, crear el post en WordPress y como el estado está establecido a «publish», pues los publicará, de esta forma:
$post_original_es_id = wp_insert_post( $post_original_es );
$post_traducido_en_id = wp_insert_post( $post_traducido_en );Con estas dos líneas que acabo de poner, lo que hago es publicar dos posts, cada uno con su información. Pero ¡Ojo! todavía no están conectados. Cada uno va a su bola, ahora mismo no tienen nada que ver el uno con el otro.
Pues bien, este código mas el relativo al tercer idioma, lo metemos en una función y al final de la misma devolvemos un array con estos 3 arrays de posts.
function nuevos_posts_para_publicar() {
$output = array(); // array que contendrá los posts para publicar
// Crear el post original en español
$post_original_es = array(
'post_title' => 'Título del post en español',
'post_content' => 'Contenido del post en español y bla, bla, blac...',
'post_status' => 'publish',
);
// Crear el contenido del post para inglés
$post_traducido_en = array(
'post_title' => 'My post title - English',
'post_content' => 'My post content in english and ble, ble, ble...',
'post_status' => 'publish',
);
// Crear el contenido del post para euskera
$post_traducido_eu = array(
'post_title' => 'Nire mezuaren izenburua - Euskara',
'post_content' => 'Nire mezuaren edukia euzkaraz eta bleu, bleu, bleu...',
'post_status' => 'publish',
);
// Insertar los 3 posts en la base de datos con wp_insert_post();
$post_original_es_id = wp_insert_post( $post_original_es );
$post_traducido_en_id = wp_insert_post( $post_traducido_en );
$post_traducido_eu_id = wp_insert_post( $post_traducido_eu );
return $output = array(
'original' => $post_original_es_id,
'traduccion_en' => $post_traducido_en_id,
'traduccion_eu' => $post_traducido_eu_id
);
}Hasta el momento todo bien. Puedes ejecutar este código para que lo que hacer y te darás cuenta que crea un post en cada idioma, sin más. Todavía no hay magia.
Ahora vamos a crear otra función que hará la conexión entre los 3 posts, el original en español y los otros dos en inglés y euskera.
Esta función recogerá lo que ha retornado la función anterior como $output y lo recoge, por ejemplo así:
$nuevos_posts_ids = nuevos_posts_para_publicar();Perfecto, ya tengo los tres posts en la nueva función para trabajar con ellos.
En primer lugar establecemos el tipo de elemento con un el filtro wpml_element_type de WPML de esta forma:
$wpml_element_type = apply_filters( 'wpml_element_type', 'post' );Ahora, obtengo información del idioma original para usarlo más adelante. De esta forma:
$get_language_args = array('element_id' => $nuevos_posts_ids['original'], 'element_type' => 'post' );
$original_post_language_info = apply_filters( 'wpml_element_language_details', null, $get_language_args );
Como ves, uso el filtro wpml_element_language_details de WPML.
Ahora que ya tengo los detalles del idioma orginal (español), voy a establecer los detalles de los otros dos idiomas pero para este ejemplo pongo solo uno, ya lo tendrás todo al final del tutorial.
$set_language_args_en = array(
'element_id' => $nuevos_posts_ids['traduccion_en'],
'element_type' => $wpml_element_type,
'trid' => $original_post_language_info->trid,
'language_code' => 'en',
'source_language_code' => $original_post_language_info->language_code
);Ya ves. Simplemente creo un array con una serie de información que nos va a hacer falta, como el id del post, el tipo, que ya había establecido anteriormente, el código del idioma y el idioma original.
Por último, ejecuto una acción de WPML con los argumentos que acabamos de establecer para inglés. De esta forma:
do_action( 'wpml_set_element_language_details', $set_language_args_en );De esta forma, WPML ya sabe qué post tiene que conectar y con qué post.
Más información sobre wpml_set_element_language_details.
Ya lo tienes todo para crear traducciones a manta.
Lo suyo sería crear un «trigger» para que se ejecutara esta función pero este caso es algo diferente ya que que si lo dejamos así y lo metemos en el ‘wp_footer‘ pues no pararía de crear posts y eso no interesa.
Como hace poco publiqué un post sobre cómo crear cron jobs en WordPress, pues me he tomado la libertad de añadir para que puedas probarlo y ejecutar el cron cuando quieras y vayas viendo los resultado. Pero eso si, como esto es algo más «gordo», no nos quedaríamos aquí sino que tal vez habría que añadir código para que se borraran todos los posts antes de crear los nuevos.
Lo que molaría es sincronizar los posts. Que es el caso. El mío, me refiero. La información de los posts la traemos de una base de datos externa que no tiene nada que ver con WordPress pero tenemos un campo para saber cuando se hizo el último cambio del contenido y así, comparando ese campo con el correspondiente campo en nuestro WordPress, podemos saber si tenemos o no tenemos que eliminar ese post y crearlo de nuevo. Cuando digo post, me refiero al post en los 3 idiomas, ok?
Pero bueno, de lo que se trata es de que lo pruebes y lo entiendes y para eso creo que con un cron job es suficiente.
A continuación tienes todo el código:
Espero que te haya gustado este tutorial y no dejes de comentarme cosas relacionadas con este tutorial, ok?
Venga, mucho ánimo!
Te pongo en situación.
Tenemos un campo de tipo «Select» en un grupo de ACF pero, por el motivo que sea, no disponemos de los datos o diferentes opciones que podrá seleccionar el usuario en ese campo. Normalmente, en una caso «normal», rellenaríamos las opciones del campo «select» directamente desde la edición del campo de ACF pero puede darse el caso de que esos valores u opciones no las tengamos a nuestra disposición en el momento de crear el campo «select» sino que pueden ser valores que dependan de alguna otra opción o que incluso los estemos calculando o recogiendo de otros sitios o campos. No se si me explico bien… Espero que me entiendas.
Una opción para poder hacer esto puede ser utilizar un campo de una página de opciones. Éste campo es posible que lo rellenemos «a mano» pero también es posible que lo hagamos a través de alguna función, etc…
Bueno, voy a comentar esta opción. Autorrellenaremos el campo «select» con los datos de un campo de tipo «texarea» que tenemos en una página de opciones.
Por el momento he creado una página de opciones bien sencilla con el siguiente código:
add_action('acf/init', 'oaf_otra_pagina_opciones');
function oaf_otra_pagina_opciones() {
// Comprobar si existe la función acf_add_options_page
if( function_exists('acf_add_options_page') ) {
acf_add_options_page(array(
'page_title' => 'Opciones',
'menu_title' => 'Opciones',
'menu_slug' => 'opciones',
'capability' => 'edit_posts',
'update_button' => 'Actualizar',
'updated_message' => 'Las opciones se han guardado',
'redirect' => false
));
}
}Y posteriormente he creado un grupo de campos con un campo de tipo «select». He asignado este grupo de campos a la página de opciones que acabo de crear así:
Y para que quede claro, el campo no tiene ningún valor asignado:
Ahora sólo faltaría disponer y tener a mano la información del misterioso campo «Select» del que tanto estoy hablando. Por ejemplo, pongamos:
Ya vemos que no tiene ninguna opción establecida.
Ahora vamos al lío…
En el «texarea» de la página de opciones voy a añadir algunas opciones de esta manera:
Si, ya se. Nada de original. Es lo que hay, que hay prisa…
Ahora es cuando viene lo bueno, lo interesante. El código que hará esta magia por nosotros.
Antes de mostrar los resultados de este código, aluna puntualización:
Utilizamos el filtro «acf/load_field» que, en resumen, se lanza cuando se cargan los campos. Podemos utilizarlo sin más para que se ejecute algo cada vez que se cargue un campo, cualquier campo pero lo más lógico es limitarlo a un campo en concreto, un tipo de campo, etc…
A continuación, algunas opciones:
Como puedes ver, hay muchas opciones y variantes que podemos emplear.
Como decía, en este filtro ejecutamos una función que lo que hace es recoger las líneas del campo textarea que tenemos en la página de opciones, convertirlo en array y devolver este array para que el filtro haga la magia.
Con esto que he hecho, podemos ver que, efectivamente se autorellena el campo select que queremos.
Y no solo eso sino que, cuando se cambie el contenido del campo textarea de la página de opciones, al cargar el campo select, se actualizarán las opciones automaticamente ya que se alimenta del contenido de ese campo:
Y, el resultado:
Mola, ¿verdad?
Pues a partir de aquí, lo que te apetezca. Que te parecería que en lugar de tomar los campos de un textarea de la página de opciones, lo tomara de todas las opciones de un campo de otro grupo de ACF? ahí te lo dejo porque es interesante y divertido. Si te interesa esto último, me dices y saco un rato para hacer otro tutorial.
Espero que este tutorial te sea de utilidad y que te anime a seguir profundizando en el desarrollo tanto con ACF como con WordPress.
Nos vemos en otra ocasión
Las tareas programadas son muy útiles en ciertos casos.
Habrá tareas que necesites que se ejecuten cada cierto tiempo sin tener que estar pendiente de ejecutarlas tu mismo/a en esos momentos. Eso es inviable, no podemos estar pendientes en ciertos momentos para ejecutar una función que necesitamos que se ejecute en cierto momento o en ciertos momentos.
Pues bien, para eso, WordPress dispone de un mecanismo que nos permite programar la ejecución de tareas o funciones en código y es muy sencillo como verás a continuación.
Antes, debo avisarte de que las tareas programadas de WordPress no son como las que puedas programar a nivel de servidor ya que las de WordPress dependen de que tengas visitas o por decirlo de otra forma. Si no tienes visitas en el momento en que tienes programada la tarea, no se ejecutará en ese momento sino que se ejecutará en el momento que tenga lugar la primera visita después de esa programación. En cambio, los cron jobs que configuras a nivel de servidor no depende de esto sino que se ejecutarán en el momento preciso. Pero en este tutorial te voy a enseñar cómo puedes crear tareas programadas en WordPress, la otras las dejaremos para otro tutorial si te parece interesante.
Al lío. Para crear una tarea programada en WordPress, crearemos un hook y le asignaremos una función que queramos que se ejecute.
Para este ejemplo he creado el hook «cron_borrar_todos_posts» y le asigno la función «oaf_borrar_todos_posts» de esta manera:
add_action('cron_borrar_todos_posts', 'oaf_borrar_todos_posts');Ahora lo que tenemos que hacer es crear un evento o programación para decirle a WordPress que cree esa programación en el momento y la periodicidad de la misma como por ejemplo:
wp_schedule_event((strtotime('24:00:00')), 'daily', 'cron_borrar_todos_posts');Con esto le estamos diciendo a WordPress que todos los días, a las 24 horas ejecute la función «cron_borrar_todos_posts«.
Para más información sobre wp_schedule_event(), haz click por aquí.
También te animo a que le eches un vistazo a la función wp_get_schedules() para que entiendas mejor la parte de las recurrencias de las tareas programadas.
No está de más añadirle un condicional para asegurarnos de que no existe ya esa tarea programada de esta forma:
if (! wp_next_scheduled('cron_borrar_todos_posts')) {
wp_schedule_event((strtotime('24:00:00')), 'daily', 'cron_borrar_todos_posts');
}Como ves es muy secillo.
Ah, bueno, nos falta la función que va a ejecutar. Para este ejemplo he creado una función que borra todos los posts:
function oaf_borrar_todos_posts(){
$todos_posts = get_posts( array('post_type'=>'post','numberposts'=>-1) );
foreach ($todos_posts as $unpost) {
wp_delete_post( $todos_posts->ID, true );
}
}Y para que que lo tengas todo en un mismo sitio y ordenado, te dejo el código completo en un gist:
Personalmente me parece una herramienta muy útil para ciertos casos que yo mismo uso según para qué.
En otro tutorial te voy a enseñar un plugin para poder ver y semi-gestionar estas tareas programadas de WordPress y así puedas tener una visión más gráfica de lo que está ejecutando WordPress y cuando.
Sin más, nos vemos…
Este es un tutorial que lo podéis encontrar por la web en un montón de sitios y me parece muy bien, cuanto más información mejor.
Entonces, si hay tanta información sobre esto en la web, ¿Porqué hacer otro tutorial sobre lo mismo?
Con este tutorial pretendo, no sólo que sepas crear una página de opciones con ACF sino que quiero que entiendas algunas cosas que puedes hacer para hacer páginas de opciones más avanzadas, con sub-páginas, configurarlas a tu gusto o incluso ubicarlas en lugares diferentes del back de WordPress. Pero eso si, iré paso a paso y veremos algunos casos y ejemplos para que todo fluya y nos enteremos bien de lo que estamos haciendo y sobre todo de lo que podemos hacer.
Las páginas de opciones son páginas que se usan el en backend de WordPress para alojar diferente contenido pero normalmente tendrán opciones o ajustes que se puedan realizar sobre algunas funcionalidades de WordPress.
Muchos plugins incluyen su propia página de opciones para independizarla de todo lo demás y que así, tengas en un mismo sitio todos los ajustes que puedas realizar con ese plugin.
En cuanto a la situación de las páginas de opciones, hay de todo pero la mayoría de los plugins tienen por costumbre situar sus páginas de opciones justo debajo de «Ajustes» en el menú de administración de WordPress, como podemos ver en la siguiente captura:
Como podemos ver en la captura, hay tres plugins que tienen sus propias páginas de opciones. Ya veremos y hablaremos de sub-página pero de momento ahí queda eso.
Otra opción muy usada es crear una página de opciones dentro del menú ajustes.
En este caso podemos ver que el plugin «Duplicate Post» crea su propia página de opciones dentro del menú «Ajustes«.
Estas dos son las opciones más elegidas por los plugins para crear sus páginas de opciones aunque también los hay que lo hacen «más arriba» en el menú del admin de WordPress.
Como es el caso de Mailpoet y un plugin de formularios de contacto como se puede ver en la siguiente captura:
Ahora que ya hemos visto algunas de las ubicaciones donde generalmente se colocan las páginas de opciones, vamos a entrar en materia y vamos a crear una página de opciones con ACF.
Para crear una página de opciones con Advanced Custom Fields, por supuesto, debemos tener instalado el plugin ACF y en su versión de pago (PRO). Necesitamos tener instala la versión Pro, ok?
Vamos a usar la función acf_add_options_page() qué como explica en la documentación oficial de ACF, nos permite crear de manera sencilla y rápida una página de opciones.
También comenta que las páginas de opciones se usan para guardar datos globales y por consiguiente, no están asociados a ningún post o página pero que, aún así, los datos se guardan en la tabla wp_options de la base de datos.
Para sentar las bases diré que la función acf_add_options_page() puede recibir com parámetro un array con los ajustes que hayamos establecido de esta forma:
acf_add_options_page( [$settings] );La gracias de todo esto está en ese array [$settings]. Él es que nos permite decirle a la función las características que tendrá nuestra nueva página de opciones. Pero esto lo veremos un poco más adelante. Ahora vamos a crear nuestra primera página de opciones con ACF.
Casi no merece la pena comentar esta opción pero la voy a comentar, mas que nada, por motivos didácticos para que veas lo más básico y te puedas hacer una idea desde dónde partimos y lo que vamos a ir añadiendo o modificando hasta conseguir lo que realmente queremos.
Para no hacer más larga la espera, a continuación pongo el código necesario para crear una página de opciones super básica.
Esta página de opciones no tiene nada de nada. No tiene ningún ajuste por ningún lado y por consiguiente se ajusta a los valores y por defecto establecidos por la función para estos casos.
Podemos ver en la siguiente captura de pantalla que ha creado una opción en el menú con el nombre «Options«. Sin más. Como no le hemos dicho nada de nada, muestra lo que tiene establecido por defecto. ¿Esperabas otra cosa?
Además, cuando seleccionamos «Options» en el menú, se mostrará una página vacía con un mensaje tal como este:
Suponiendo que no sepas a qué se debe este mensaje te puedo adelantar que es porque no hemos asignado ningún grupo de campos de ACF a esta página de opciones. Ya te he comentado que empezamos por lo básico.
Como se que nos va a venir bien para el resto del tutorial, voy a crear un grupo de campos con un par de campos para que podamos ver cómo va quedando nuestra página de opciones.
Para hacer esto, creamos un nuevo grupo de campos en ACF con el nombre que queramos y los campos que queramos. Para este ejemplo yo he creado lo siguiente:
Podemos ver que se ha creado un grupo de campos con el nombre «Datos Generales» que tiene cuatro campos que vamos a utilizar para recoger y almacenar los datos de esta empresa en cuestión en la página de opciones. Y esto es lo importante ahora. He establecido la Ubicación del grupo de campos para que se muestre en la página de opciones «Options» que es la que tenemos ahora mismo, no tenemos más por el momento.
Por lo tanto, en nuestra página de opciones mostraría algo como lo suguiente:
Como digo, es una página de opciones super básica pero es posible que para ciertas situaciones nos pueda servir. Casi mejor para entornos de test porque, como ya veremos, no cuesta mucho darle un toque para personalizarla y quedar mejor.
Resumiendo… Hemos creado una página de opciones, hemos creado un grupo de campos en ACF con 4 campos y hemos asignado este grupo de campos a nuestra página de opciones.
Seguimos…
Ahora que ya sabemos cómo crear una página de opciones básica, sin pasarle el array de ajustes pero asignándole del grupo de campos, vamos a ir paso más allá y ver cómo podemos realizar algunos ajustes en nuestras páginas de opciones.
He comentado antes que para esto, debemos pasarle a la función acf_add_options_page() un array con los ajustes que necesitemos y para ello voy a poner un ejemplo y luego comentaré una a una las diferentes opciones de que disponemos.
Como vemos, establecemos los diferentes ajustes para la página de opciones el el array $options_page.
Paso ahora a comentas las diferentes opciones que hemos usado en el código anterior.
Esta opción sirve para establecer el título de la página de opciones en sí. Aparecerá en la parte superior izquierda de la mima.
En este caso hemos establecido el valor de ‘page_title’ a ‘Datos Generales’. Por lo tanto vemos el título Datos Generales como en la captura siguiente:
Esta opción nos permite establecer el nombre del item del menú dentro del menú de administración de WordPress.
En este caso se ha establecido ‘menu_title» igual que ‘page_title’ y se mostrará así en el menú de administración:
Esta opción creo que no tiene ningún truco, incluso menos que las dos anteriores pero bueno, venga, va, lo digo… Establecemos el slug o url relativa de esta página de opciones
En nuestro ejemplo nos debería de quedar algo así:
http://acf.local/wp-admin/admin.php?page=datos-generalesCada cual con su url.
Este argumento también es interesante ya que podemos establecer el nivel de permisos que debe tener el usuario para poder ver la página de opciones.
En nuestro caso hemos establecido el valor de ‘capability’ a ‘edit_posts’.
Para más información y detalles acerca de los permisos y roles, mira esta página.
Vamos a por el siguiente…
Este argumento se refiere a la posición del item de menú dentro del menú de administración de WordPress. Si no indicamos nada, generalmente se mostrará debajo de «Ajustes» como hemos visto hasta ahora.
Podemos darle un valor muy grande para que aparezca al final de todos como ‘999’:
O darle otro valor para ubicarlo en cualquier otro lado como vemos aquí:
Opción interesante, claro que sí. Permite que indiquemos el icono del ítem de menú que por defecto está establecido al engranaje.
En el ejemplo he establecido a ‘dashicons-superhero-alt‘ por lo que se mostrará así:
Tienes ver la lista completa de iconos disponibles, revisa los Dashicons.
Él mimo lo dice todo. Se refiere al texto del botón de «Update» que aparece en la página de opciones y de debemos de pulsar cuando queramos guardar los cambios.
En este caso se refiere al mensaje que se mostrará tras pulsar en el botón de actualizar (update).
Para el caso he puesto ‘Las opciones se han guardado’.
El tipo de dato de este atributo es booleano por lo que deberemos establecer a ‘true‘ o ‘false‘.
La opción por defecto es ‘true’ por lo que si no indicamos nada o establecemos ‘true‘, la página de opciones por defecto establecida para esta opción de menú, será la primera página de opciones hija.
Todavía no hemos visto esto de páginas de opciones hijas o sub-páginas de opciones pero lo veremos, claro que si.
En este caso lo he establecido a false para que sepamos que la página de opciones será la que estamos creando ya que no tiene páginas hijas.
Hay algún atributo más pero prefiero que los veamos dentro de un rato para no contarte algo que no te voy a mostrar de momento.
Hace un momento he comentado el atributo ‘redirect‘. Pues bien, lo vamos a usar ahora mismo.
Aprovechando el código anterior, he añadido otra página de opciones pero en este caso, a parte de cambiar los datos necesarios, he añadido otra opción ‘parent_slug‘.
Antes de nada, pongo el código y te comento un poco el nuevo atributo.
Esta opción o atributo nos sirve para establecer quién es la página «padre» de esta.
En el código anterior podemos ver que está establecido el slug de la página de opciones que ya habíamos creado y por eso también podemos ver que el atributo ‘redirect‘ de la primera página de opciones lo he establecido a ‘true‘, para que sea esta última la página de opciones que muestre el contenido y la otra sea una página padre que lo que hace es servir de contenedor a la página hija o páginas, si existiera alguna más.
Esto ya va cogiendo forma.
A continuación vamos a ver cómo podemos crear una página de opciones con varias sub-páginas
Como ya tenemos la idea en la cabeza con lo que acabamos de hacer con la página hija, ya tenemos el trabajo hecho.
Ahora lo que queremos es una página de opciones con varias páginas hijas. Para el ejemplo lo voy a hacer con 2 sub-páginas para no extenderme demasiado.
Por lo tanto, crearemos una página de opciones como la que habíamos creado antes «Datos Generales» y dos sub-páginas: «Datos empresa» y «Clientes«. Si, ya se que no es un buen ejemplo de uso pero no se me ha ocurrido nada interesante pero, quien sabe, tal vez se dé el caso…
En este caso no voy a guardar las funciones en variables sino que las voy a ejecutar directamente dentro la función. Por lo tanto quedaría así:
Interesante, ¿verdad?
Tengo que comentar alguna cosa.
He creado otro grupo de campos de ACF «Clientes Empresa«, he creado un repeater con los campos «Nombre» y «CIF«. También he asignado este campo a la página de opciones «Clientes» que hemos creado.
He cambiado el valora del atributo ‘parent-slug‘ y le he indicado el valor directamente, ya que no estoy guardando en variables. Este atributo lo establezco igual en ambas páginas puesto que lo que hace es indicar qué pagina es la página padre y ambas tienen el mismo padre. O eso dicen ellas…
Podríamos crear el número de sub-páginas que necesitemos, no hay problema con esto.
Hasta ahora hemos visto cómo crear páginas y sub-páginas de opciones. En todos los casos hemos estado siempre dentro de estas páginas que hemos creado pero si se da el caso de que queramos que nuestra página de opciones no tenga vida propia o más bien, que no tenga un ítem en el menú de administración de WordPress sino que queramos que descienda de alguno de los menús que ya existen, como por ejemplo el menú «Ajustes«, lo único que tendríamos que hacer sería establecer el slug de ese menú, el que nos indique cuando nos ponemos sobre el enlace, como contenido del atributo ‘parent_slug‘.
Para este ejemplo he cambiado el atributo ‘parent_slug’ en las dos sub-páginas de esta manera:
'parent_slug' => 'options-general.php'Total, que nos quedaría algo como esto:
Como se puede observar, dentro del menú «Ajustes«, tenemos tanto a la página de opciones «Datos empresa» como a la de «Clientes«.
Esto lo podemos hacer con otra opción de menú.
Como ya sabemos, el caso de las páginas de opciones es algo singular ya que no están asociadas a ningún post o página y van por su cuenta.
Aunque la forma de obtener o mostrar los datos de un campo de página de opciones sea utilizar igualmente las fuciones «get_field()» o «the_field()«, hay una particularidad puesto que, además de indicar el nombre del campo, debemos indicar también el parámetro ‘option’ en la función.
Por ejemplo:
<?php get_option( 'empresa', 'option' ); ?>De esta manera obtenemos el valor del campo ‘empresa‘ que está asociado a una página de opciones.
Pues si, es posible, claro que si. Pero no te esperes algo guapísimo porque no.
Es muy sencillo y te lo voy a explicar poco a poco para que no queden dudas.
Si pensamos un poco, podemos crear un grupo de campos con una serie de campos para lo que sea, ok? En este caso lo que queremos son unos campos que solo se puedan modificar desde un sitio, desde una página, verdad? Así pasa con las páginas de opciones, que solo se puede modificar el valor de esos campos desde la página de opciones y por lo tanto solo hay un dato por campo como mucho, ¿si?
Pues bien, la idea que te propongo para esta página de opciones «casera» es crear una página con el nombre, digamos… «Ajustes Globales» u «Opciones«, como tu quieras. Luego creamos un grupo de campos con estos campo que queremos para los ajustes de nuestro sitio y se lo asignamos a esa página en concreto, a ninguna más. De esta forma, estos campos sólo se mostrarán en esa página. En ninguna otra página ni post.
Como puedes ver en la captura siguiente…
He creado, como te he dicho, un grupo de campos «Ajustes generales» con 3 campos. Para que me sea más fácil identificar los nombre o identificadores de los campos, he añadido la palabra «opción_» delante. Buena idea, ¿verdad?
Ahora, en la sección de «Ubicación» lo ajustamos de tal forma que sólo se muestre en la página «Página de opciones (free)«. La primera condición sobraría porque la segunda es más específica pero más vale asegurarse…
Con esto y con la página «Página de opciones (free)» creada, ya podemos ir y aplicar los ajustes que necesitemos.
De momento bien. No tenemos ninguna pega, la verdad.
Ahora lo que debemos saber es cómo acceder a estos campos y que sólo se muestran en esta página.
Lo que haremos será especificar el ID de esta página en las funciones que usemos para recoger estos campos. Por ejemplo:
$nombre_empresa = get_field( 'option_field_name', 41 );Tenemos que indicarle el ID en el segundo parámetro. En mi caso es «41«.
Y nada más, ya ves qué fácil es crear una página de opciones «casera«.
Si quieres trastear un poco para dejarla mejor, puedes desactivar gutenberg en esa página en concreto e incluso jugar con las opciones de ACF para quitar cosas. Esto ya te lo dejo a ti.
Hasta aquí hemos llegado y parece que fue ayer cuando empecé a escribir este tutorial.
Espero que sea de utilidad.
Mucho ánimo!
WordPress pone a nuestra disposición un buen número de funciones para realizar comprobaciones o chequeos de dónde estamos para que nosotros realicemos una acción u otra en función del resultado de esa función.
Pues bien, hoy vengo a hablarte de «is_page_template()«. Esta función, como ya habrás adivinado, nos permite comprobar si se trata de una template.
El modo sencillo sería este:
Ahora bien, si queremos comprobar una template en concreto lo que podemos hacer es esto:
Y así, sin más, muy sencillo pero muy útil. Pero échale un vistazo a la documentación de «is_page_template()» por si tienes alguna duda.
Ahora lo que hagas con este condicional es sólo cosa tuya, de tu imaginación y de tus necesidades.
Espero que te sea de utilidad.
Seguimos…
Pues si, hoy me ha hecho falta volver a hacer esto y ya sabes, no te acuerdas de cómo lo hiciste la última vez y toca buscar un poco.
La idea es que queremos aplicar ciertas reglas css dentro de la administración de WordPress. En mi caso lo quiero aplicar para unas cosillas de Advanced Custom Fields. Que no viene al caso pero ahí queda.
Como siempre, lo ideal es tener todo bien organizado y en mi caso, en este caso, he creado un fichero «admin.css» dentro del directorio «assets/css/» del tema activo. Por lo que quedaría «/assets/css/admin.css«. Y en este fichero puedes añadir todo el css que queráis aplicar en tu backend de WordPress.
Ahora bien, para que este css afecte al backend de WordPress, tendremos que usar el hook «admin_enqueue_scripts» de la misma forma que lo hacemos cuando encolamos para el front con «wp_enqueue_scripts» o styles.
El código que hay que incluir en el fichero functions.php de vuestro tema o en otro fichero si es que lo tienes organizado así es el siguiente:
Ya ves que es muy sencillo y fácil de implementear.
Pruébalo y me cuentas.
Saludos y mucho ánimo!
El tema Storefront se ha convertido en un referente en cuanto a temas «padre» para WooCommerce. En buena parte porque está desarrollado y mantenido por los mismos creadores de WooCommerce.
Personalmente soy un fiel seguidor de Storefront también porque está muy bien desarrollado desde la base y con muchísimas utilidades tanto para el usuario final como para los desarrolladores.
Es por eso también por lo que en su día decidí basar mi propia web en Storefront, crear un tema hijo y seguir a partir de ahí.
No me enrollo más y vamos a ver cómo crear un tema hijo de Storefront.
1-. Crear un directorio (carpeta) con el nombre del tema, nuestro tema. Para este ejemplo: «mi-store«.
2-. Dentro de esa carpeta creamos el fichero «style.css» con el siguiente texto en la parte inicial:
/*
Theme Name: Mi Store
Theme URI: https://oscarabadfolgueira.com/mi-store
Author: Oscar Abad Folgueira
Author URI: https://oscarabadfolgueira.com
Template: storefront
Description: Tema de ejemplo basado en Storefront
Version: 1.0.0
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Text Domain: mi-store
License: GPL v2 or later
*/
/* --------------- CSS Peronalizado ----------------- */Esto es la base y lo adaptaremos a nuestro caso.
Hay más opciones que podemos incluir pero de momento nos sirve con estas.
3-. Ahora creamos un fichero vacío y le ponemos el nombre «functions.php«.
En este fichero copiaremos el siguiente código:
function sf_child_theme_dequeue_style() {
wp_dequeue_style( 'storefront-style' );
wp_dequeue_style( 'storefront-woocommerce-style' );
}Este código nos sirve para cargar los estilos de Storefront por lo que si no queremos cargar esos estilos, no las incluimos pero intuyo que por el momento si que queremos hacerlo.
Así, sin más ya tenemos el tema hijo listo para ubicarlo en el directorio /wp-content/themes/ y activarlo desde «Apariencia» –> «Temas«.
Recuerda que el tema Storefront debe estar instalado, ok?
Si quememos, también podemos añadir a la capeta del tema, una imagen para «screenshot» con el nombre «screenshot.png«. Ésta será la imagen que veamos en Apariencia –> Temas.
Con todo lo que hemos hecho, el contenido del directorio /themes/ tendría un aspecto como este en lo que se refiere a nuestro tema hijo «mi-store»:
Os dejo también el enlace a github para que lo descarguéis si queréis y ahorréis tiempo:
Espero que os sea util esta información y que creéis muchos temas hijo de Storefront.
Cualquier observación que tengáis, podéis dejarme un comentario.
Saludos y mucho ánimo!!
Si estamos realizando cambios o desarrollando algo desde cero para WordPress es aconsejable que activemos el modo depuración para poder «ver» los mensajes y avisos que se nos puedan mostrar.
Por defecto, este modo depuración está desactivado.
Para activar el modo depuración en WordPress lo haremos usando la constante de PHP WP_DEBUG.
Como he dicho anteriormente, por defecto, ésta variable global está establecida a «false» por lo que si queremos activar el modo depuración deberemos establecerla a «true«.
Esto lo haremos en el fichero «wp-config.php» de nuestro WordPress de la siguiente manera:
define( 'WP_DEBUG', true ); // Activamos el modo depuración
define( 'WP_DEBUG', false ); // Desactivamos el modo depuración (opción por defecto)Es muy sencillo y fácil pero debemos acordarnos de desactivarlo una vez que hayamos terminado con el desarrollo y pasemos nuestra web o desarrolo a real.
Espero que os haya sido de utilidad
Y ya sabéis, cualquier cosa me comentáis en un comentario.
Mucho ánimo!!
Cuando estamos desarrollando en WordPress, picando código en los diferentes ficheros php, ya sabemos que nos muestra el contenido de ese fichero como es el caso de los ficheros de archivo.
En el ejemplo que os presento queremos ya tenemos un fichero archive-hook.php donde tenemos implementado todo el código necesario para que muestre todos los posts del CPT «hook» en forma de listado como nosotros/as queremos pero, la casualidad es que también queremos mostrar algún tipo de contenido más estático en la parte superior de esa página, como si fuera el ancabezado de la página de archivo y después que muestre el listado que ya tenemos preparado en el código.
Dependiendo de cómo lo tengamos, es posible que al crear la página «hooks» en el panel de administración de WordPress, no nos muestre ese contenido y solo nos muestre lo que tenemos implementado en el fichero «archive-hook.php«.
Nota: He dicho crear la página «hooks» porque se trata de un CPT y tenemos reescrita el slug por «hooks«.
Bien, en estos casos vamos a tener que echar mano de una función de WordPress para coger el contenido de la página «hooks» y decirle por código que nos la muestre antes del listado de los hooks que tenemos implementado en el fichero «archive-hook.php«.
Esto que comento, podemos hacerlo usando la función: «get_post();«
A continuación podemos ver el formato y parámetros de esta función:
get_post( int|WP_Post|null $post = null, string $output = OBJECT, string $filter = 'raw' )Tenéis más información sobre la función get_post() en el siguiente enlace: https://developer.wordpress.org/reference/functions/get_post/
Para el caso que nos ocupa, lo único que necesitamos es el ID del post (en este caso, página) que tiene el contenido que queremos mostrar por código antes del listado.
Por consiguiente, una forma de hacerlo sería la siguiente:
Con esto conseguimos mostrar el contenido de ese post que hemos creado en forma de página, entrada o de otro tipo en nuestro código.
Es una forma sencilla de tener el control de la parte estática a través del editor de WordPress y dejar la parte dinámica al código.
Espero que os sea de utilidad y cualquier duda o sugerencia, ya sabéis, dejadme un comentario o hacédmelo saber de cualquier otra forma.
Saludos a todos/as!
Este post va a ser rápido y además, fácil, sencillo y para toda la familia.
Si no conoces o no has trasteado nunca con la Query de WordPress, te aconsejo que lo hagas más pronto que tarde.
La función WP_Query() de WordPress es una herramienta fantástica que nos permite modificar el loop por defecto con diferentes argumentos.
Como la Query de WordPress daría para muchos posts, si os parece vamos a ver el código necesario para el caso en el que queremos excluir el post actual de dicha query.
Para ello utilizaremos ‘post__not_in’ en los argumentos que le pasaremos al nuevo objeto de WP_Query y en el caso que nos ocupa lo estableceremos como «array (get_the_ID())«.
Claro que podemos recoger antes el ID y guardarlo en un variable pero creo que así se ve más claro.
A continuación os dejo el código de un ejemplo sencillo para que podáis copiarlo y probarlo cuando queráis.
Cualquier cosa, ya sabéis, me la comentáis. Ya sabéis que me podéis encontrar en Twitter como @oabadfol
Si nos dedicamos a cualquier cosa relacionada con WordPress o tenemos pensado hacerlo, no podemos dejar de lado la comprensión de su base de datos. Dependiento del nivel en el que nos movamos, tendremos que ahondar más o menos en su comprensión pero en cualquier caso, nunca está de más conocer sus tablas y cómo está estructura.
En esta guía voy a intentar resumir la estructura de de la base de datos de WordPress de manera que sea lo más comprensible posible para todos y todas.
Espero que esta guía os sea de ayuda y os anime un poco a profundizar en el desarrollo WordPress y en su comprensión.
Antes de empezar a ver cada una de las partes, tablas, etc… de la base de datos de WordPress, vamos a comentar lo que necesitamos par poder seguir esta guía y verlo con nuestros propios ojos a la vez que seguimos la guía.
En mi caso parto de:
Conocimientos necesarios:
Aunque creo que en este caso no es necesario un mínimo conocimiento de WordPress para ententer lo que vamos a comentar, si que creo que lo ideal sería:
Estos no son requisitos imprescindibles.
Cuando instalamos WordPress se crean 12 tablas iniciales que son las que vamos a explicar en esta guía.
Nota: Ante de continuar debemos saber que no deberíamos utilizar el prefijo por defecto que nos ofrece WordPress que no es otro que «wp_«. Deberíamos cambiarlo por otro por motivos de seguridad. Para esta guía he utilizado el prefijo por defecto por motivos didácticos.
Tras realizar una instalación de WordPress sin nada más, nos econtraremos estas tablas en nuestro phpMyAdmin:
Esta es la estructura de tablas que nos vamos a encontrar en una nueva instalación de WordPress.
A continuación vamos a resumir un poco cada una de las tablas para más adelante pasar a detallarlas un poco más cada una de ellas.
| Las 12 tablas de WordPress | |
|---|---|
| wp_commentmeta | Esta tabla contiene contenido adicional sobre los comentarios. |
| wp_comments | Aquí están los datos de los comentarios. |
| wp_links | Esta tabla está obsoleta desde la versión 3.5 de WordPress. Aquí se almacenan o almacenaban los enlaces. |
| wp_options | Aquí se almacenan los datos de configuración de WordPress además de datos sobre configuración de plugins, temas, etc.. |
| wp_postmeta | Información relacionada con los posts. Esta tabla está relacionada con la tabla wp_posts. |
| wp_posts | Se almacena todo el contenido de WordPress como entradas, páginas, ficheros, etc… |
| wp_termmeta | Metadados relacionados con las categorías. |
| wp_terms | Aquí se almacenan las categorías y etiquetas. |
| wp_terms_relationships | En esta tabla se establece la relación entre los posts con las categorías, etiquetas, etc.. |
| wp_term_taxonomy | Establece las características de las taxonomías como las entradas, páginas, etc… |
| wp_usermeta | Tabla con información adicional sobre los usuarios de la tabla wp_users. |
| wp_users | En esta tabla es donde se almacenan todos los usuarios con su información básica como contraseña, email, etc.. |
Con esta breve explicación ya nos podemos hacer una idea de la estructura de la base de datos de WordPress y hacerno una idea que dónde se almacenan algunos datos aunque lo veremos un poco mejor más adelante en esta guía.
Para comprender un poco mejor la estructura de la base de datos de WordPress debemos entender cómo están relacionas entre ellas.
A continuación podemos ver un esquema de las relaciones entre las tablas obtenido del codex de WordPress.org.
En la imagen anterior podemos ver graficamente las relaciones entre las tablas de la base de datos de WordPress en sus últimas versiones.
Detallaremos un poco más la relación de cada una de las tablas más adelante en esta guía.
Como ya hemos comentado anteriormente, en la tabla wp_commentmeta se almacenan los datos adicionales de o sobre los comentarios que se almacenan en una instalación de WordPress.
Como podemos ver en la imagen anterior esta tabla es muy sencilla y sólo tiene 4 campos:
| Campos tabla wp_commentmeta | |
|---|---|
| meta_id | Id principal de la tabla |
| comment_id | Id del comentario (tabla wp_comments) |
| meta_key | Clave del valor |
| meta_value | Meta o valor del campo |
Destacaremos que el cambio comment_id hace referencia al id de la tabla wp_comments por lo tanto queda claro que ambas están relacinonada a través de este campo.
Para obtener datos de la tabla wp_commentmeta podemo utilizar la función get_comment_meta() que nos devolverá el campo meta de un comentario.
metacomentario = get_comment_meta( $comment->comment_ID, 'mimeta', true );
Esta es la tabla donde se almacenan o guardan los comentarios que se han realizado en nuestro WordPress. Tanto los comentarios que se han aprobado como los que no han sido aprovados.
| Campos tabla wp_comments | |
|---|---|
| comment_ID | Id del comentario |
| comment_post_ID | Id del post (tabla wp_posts) |
| comment_author | Autor del comentario |
| comment_author_email | Email del autor del comentario |
| comment_author_url | Url del autor del comentario |
| comment_author_IP | Ip del autor del comentario |
| comment_date | Fecha y hora del comentario |
| comment_date_gmt | Fecha y hora del comentario (gmt) |
| comment_content | Contenido del comentario |
| comment_karma | Meta o valor del campo |
| comment_approved | Aprobación del comentario (0, 1 o spam) |
| comment_agent | Browser, sistema operativo, etc.. |
| comment_type | Tipo (pingback | trackback) |
| comment_parent | Comentario padre del actual |
| user_id | id del usuario si está registrado |
Para obtener datos de la tabla wp_comments podemo utilizar la función get_comments() que nos devolverá el campo meta de un comentario.
<?php
// Mostrar por pantalla los autores de los comentarios del post con id 15
$commentarios = get_comments('post_id=15');
foreach($comments as $comment) :
echo($comment->comment_author);
endforeach;
?>Esta tabla se utilizaba en veriones anteriores pero se dejó de utilizar. Antes se utilizaba para la gestión de los enlaces.
Si necesistamos o queresmos volver a utilizar esta característica de WordPress la podemos seguir usando si instalamos el plugin «Link Manager«.
No se muestran detalles de esta tabla por que no se utiliza normalmente.
Para obtener más información sobre la tabla wp_links podemos visitar este enlace.
Como ya hemos comentado al principio de esta guía en esta tabla se guardarán y gestionaran las opciones de nuestra instalación de WordPress.
Esta tabla es algo especial puesto que, en principio, no tiene ninguna relación con ningun otra tabla de la base de datos de WordPress.
Enl a siguiente captura podemos ver la tabla completa que crea WordPress tras la instalación.
Esta tabla, como podemos ver, solo tiene 4 campos o filas.
| Campos tabla wp_options | |
|---|---|
| option_id | Id de la opción |
| option_name | Nombre de la opción |
| option_value | Valor de la opción |
| autoload | Si la opción se carga automaticamente |
// Obtener el email del administrador $admin_email = get_option( 'admin_email' );
Cada meta data de un post se almacena en la tabla wp_postmeta.
Algunos plugins también pueden utilizar esta tabla para guardar su propia información.
| Campos tabla wp_postmeta | |
|---|---|
| meta_id | Id de la información (meta) |
| post_id | Id del post asociado |
| meta_key | Clave del meta |
| meta_value | Valor del meta (información) |
// Obtener la información adicional o meta del post actual a través de su ID $meta = get_post_meta( get_the_ID() );
Aunque todas las tablas de la base de datos son muy importantes, la tabla wp_posts es por lo menos una de las más imporntes sino la más importante.
Debemos tener en cuenta que aquí, en la tabla wp_posts se almacena la información de los posts de WordPress lo que incluye entradas, páginas, etc…
| Campos tabla wp_posts | |
|---|---|
| ID | Id de la información (meta) |
| post_author | Autor del post |
| post_date | Fecha del post |
| post_date_gmt | Fecha del post (gmt) |
| post_content | Contenido del post |
| post_title | Título del post |
| post_excerpt | Extracto del post |
| post_status | Estado del post (publicado, borrador, etc..) |
| comment_status | Estado comentarios (abiertos?) |
| ping_status | Estado de los pings (abiertos?) |
| post_password | Contraseña del post |
| post_name | Nombre del post |
| to_ping | Url a la que enviar pingback |
| pinged | Url a la que se ha enviado pingback |
| post_modified | Fecha y hora de modificarción del post |
| post_modified_gmt | Fecha y hora de modificarción del post (gmt) |
| post_content_filtered | Usado por algunos plugins de cache para guardar uan versión en caché |
| guid | Url permanente al post |
| menu_order | Número de orden en el menu |
| post_type | Tipo de post (post, page…) |
| post_mime_type | El Mime type de los ficheros subidos |
| comment_count | Número de comentarios del post |
// Obtener los últimos 15 posts $args = array( 'numberposts' => 10 ); $latest_posts = get_posts( $args );
En este tabla se almacenan los metadatos relacionados con las categorías.
| Campos tabla wp_termmeta | |
|---|---|
| meta_id | Id de la información (meta) |
| term_id | Id del término |
| meta_key | Clave del meta |
| meta_value | Valor del meta (información) |
// Obtener el valor del término 'color' $color = get_term_meta( $term_id, 'color', true );
En la tabla wp_terms se guardan tanto las categorías como las etiquetas para los posts y páginas.
| Campos tabla wp_terms | |
|---|---|
| term_id | Id de término |
| name | Nombre del término |
| slug | Slug del término |
| term_group | Agrupación de terminos (alias) |
// Obtener todas la información de los términos de la categoría con ID 1 $term = get_term( 1 , 'category' ); echo $term->name;
Los posts están relacionados con categorías y etiquetas por la tabla wp_terms y esta asociación es mantenida en la tabla wp_term_relationships.
| Campos tabla wp_term_relationships | |
|---|---|
| obtect_id | Id de término |
| term_taxonomy_id | Nombre del término |
| term_order | Slug del término |
// Devuelve una lista de términos de taxonomía de productos que se aplican a $post
$product_terms = wp_get_object_terms( $post->ID, 'product' );
if ( ! empty( $product_terms ) ) {
if ( ! is_wp_error( $product_terms ) ) {
echo '<ul>';
foreach( $product_terms as $term ) {
echo '<li><a href="' . esc_url( get_term_link( $term->slug, 'product' ) ) . '">' . esc_html( $term->name ) . '</a></li>';
}
echo '</ul>';
}
}Esta tabla almacena la información que describe la taxonomía como categorías, tags, cpt... para las entradas de la tabla wp_terms.
| Campos tabla wp_term_taxonomy | |
|---|---|
| term_taxonomy_id | Id del témino de taxonomía |
| term_id | Id del término |
| taxonomy | Nombre de la taxonomía |
| description | Descripción |
| parent | Padre |
| count | Número |
En la tabla wp_usermeta se almacenan datos adicionales de los usuarios.
A continuación podemos ver el contenido de la tabla wp_usermeta tras la instalación de WordPress:
| Campos tabla wp_usermeta | |
|---|---|
| umeta_id | Id de la tabla |
| user_id | Id del usuario (tabla wp_users) |
| meta_key | Clave de la información o meta |
| meta_value | Valor de la información o meta |
// Obtener y mostrar toda la información meta de un usuario a través de su id <?php $metauser = get_user_meta( 1 ); print_r( $metauser ); ?>
Como su nombre indica, aquí se almacenan los datos de los usuarios: nombre, email, etc…
Esta tabla está directamente relacionada con la tabla wp_usermeta.
| Campos tabla wp_users | |
|---|---|
| ID | Id del usuario |
| user_login | Login o username para acceder |
| user_pass | Contraseña del usuario (encriptada) |
| user_nicename | Nombre del usuario que se muestra |
| user_email | Email del usuario |
| user_url | Campo url del usuario |
| user_registered | Fecha y hora en que se registró el usuario |
| user_activation_key | Se usa para reestablecer las contraseñas |
| user_status | Se usaba antes |
| display_name | nombre del usuario elegido para mostrar (user_login, user_nicename…) |
// Obtener una lista de todos los usuarios con el nombre 'oscar' $usuarios_oscar = get_users( array( 'search' => 'oscar' ) );
Si habéis llegado hasta aquí es que le habeis prestado algo de atención a esta guía.
Ya se que no es lo más detallada que cabría esperar pero la idea es dar una base, unas pinceladas sobre las que ahora podréis trabajar vosotros, hacer pruebas y sacarle el mayor partido posible a el desarrollo con WordPress.
El conocimiento de la base de datos de WordPress nos va a ayudar muchísimo, nos va a abrir algunas puertas que si no supiéramos cómo funciona nos costaría más llevarlo a cabo.
Para terminar, espero que os sea de ayuda lo máximo posible.
Saludos y hasta la próxima!
En ocasiones, por el motivo que sea es posible que se muestre algún mensaje de error o aviso de PHP en nuestras páginas o entradas de WordPress y la verdad es que queda muy feo.
Antes de continuar hay que tener en cuenta que los errores y avisos están para algo, para hacerles caso e intentar resolverlos pero también debemos hacer algo rápidamente para que los visitantes no vean estos errores o avisos mientras nosotros procuramos solucionarlos lo ante posible.
Teniendo en cuenta esto, nos ponemos en la situación que por ejemplo, después de instalar o actualizar un plugin nos muestra un mensaje de error como por ejemplo algo similar a esto:
Warning: Cannot modify header information - headers already sent by xxxx (output started at xxxxruta/de/nuestro/wordpress/header.php:59) in /otra/ruta/...xx/fichero.php
Como no queremos que se muestre este mensaje de error, vamos a ocultar todos los mensajes y avisos de php para que no se muestren, por lo menos mientras lo vamos solucionando.
Si nos fijamos en el fichero ‘wp-config.php‘ de nuestro WordPress seguramente veremos la siguiente línea:
define('WP_DEBUG', false);Como este «define» no nos está solucionando el problema que tenemos, lo que vamos a hacer es eliminar esa línea de define para añadir las siguiente líneas en nuestro ‘wp-config.php‘:
ini_set('log_errors','On');
ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Añadimos estas líneas, guardamos el fichero y lo subimos a su directorio, refrescamos el navegador y es muy probable que ya no veamos los mensajes de error que nos aparecían hace un momento.
Espero que esto os sea de ayuda en esos momentos de tensión en los que aparece un mensaje de error de este tipo y no sabemos por donde tirar.
Eso si, os recuerdo que los mensajes de error de php deben estar activados, ok? En cuanto lo solucionéis, volvéis a dejarlo como estaba y listo.
Venga, saludos y hasta la próxima!
Si queremos añadir texto al título de los las entradas de WordPress de una categoría específica, aquí te explico una manera de hacerlo.
Para ponernos en situación pongamos que tenemos una página web de una inmobiliaria donde vamos poniendo anuncios de pisos en venta, en alquiler, vendido, alquilado, etc…
De momento lo estamos gestionando con categorías que podrían ser las que he comentado:
Cada vez que publicamos un piso en venta le ponemos un título en plan: Piso de 90 metros cuadrados en el centro. Por poner un ejemplo.
Después rellenamos todo el contenido que necesitemos y le asignamos por ejemplo la categoría «En venta«.
Pues bien, lo que queremos es que a partir de ahora cuando una entrada tiene establecida la categoría «En venta» se modifique el título de la entrada para que los visitante vean el título siguiente: «EN VENTA: titulo….«.
Es sólo un ejemplo para que lo entendamos pero habría que hacer lo mismo con el resto de categorías para que cuando un piso «en venta» se venda y le asignemos la categoría «Vendido«, el título que se muestre sea: «VENDIDO: título…«.
Para que nos quede claro, no queremos que se modifique el título en si, ok? Porque cuando cambiemos de categoría sería más complejo ya que tendríamos que quitar el texto existente del comienzo y luego añadir el nuevo correspondiente a la categoría.
Voy a intentar hacerlo lo mas sencillo posible para que lo entendamos bien.
En primer lugar damos por sentado que ya tenemos creadas las categorías que hemos comentado antes.
Ahora vamos a crear una función que insertaremos en el fichero functions.php de nuestro tema en la que comprobaremos con un «if» si el post tiene asignada una categoría de las que nos interesan y si es así que añada el texto que queremos al inicio del título y que devuelva esa cadena.
Para el ejemplo de la categoría «en venta» quedaría así:
if( in_category( 'en venta') ) {
$title = 'EN VENTA: ' . $title;
}Se entiende bien ¿verdad?
Ahora bien, tendríamos que hacer un «if» como el anterior para cada categoría. Por supuesto hay maneras mejores de hacerlo como por ejemplo con un Switch pero bueno, en este tutorial lo hacemos con varios «if» para que se entienda mejor.
Como digo, para el caso de la categoría «vendido«, el if quedaría así:
if( in_category( 'vendido') ) {
$title = 'VENDIDO: ' . $title;
}¿Lo tenemos claro? Pues sigamos…
Ahora que ya hemos visto y entendido el funcionamiento básico, vamos a crear la función que contendrá los «if» y que devolverá el título modificado.
La función la vamos a llamar: «modificar_titulo_por_categoria» y quedaría así:
function modificar_titulo_por_categoria( $title, $id ) {
if( in_category( 'en venta') ) {
$title = 'EN VENTA: ' . $title;
}
if( in_category( 'vendido') ) {
$title = 'VENDIDO: ' . $title;
}
return $title;
}Ya casi lo tenemos, lo único que nos falta es añadir un filter que ejecute la función que acabamos de crear.
Usaremos el filtro ‘the_title‘, como no.
Bien, pues para no demorarnos más, aquí tenéis el código completo con esas dos categorías de ejemplo que hemos comentado.
Ya sabes, lo puedes copiar y pegar en el fichero functions.php de tu tema WordPress y modificarlo a tu gusto.
Y aquí podéis ver el resultado:
Para terminar te comento que si necesitas un plugin que haga algo similar a lo que hemos comentado en este artículo, no dudes en comentármelo a través del formulario de contacto. Explícame bien lo que necesitas para que yo lo tenga claro, ok?
Venga, pues sin más, nos vemos en el siguiente!!
Pues si, de nuevo volvemos con este tema y con otro WordPress Snippet.
Os recuerdo que en el tutorial anterior «WordPress Snippet: Cambiar el icono del login de administración» lo que hacíamos era cambiar el logo, es decir, la imagen.
Pues bien, en esta ocasión vamos a cambiar la url a la que apunta ese logo o esa imagen. Por si no lo sabéis, esa imagen apunta a la web oficial de «wordpress.org» y en cada idioma es diferente. Por ejemplo, en mi caso que lo tengo instalado con la versión Español – España la url es: «http://es.wordpress.org» y en cada caso será la correspondiente a su idioma.
Y como no, os recuerdo que el enlace que vamos a cambiar es el que apunta el logo de WordPress de la imagen siguiente:
Pues nada, como este también es muy sencillo lo que voy a hacer es poner el código sin más y comentar un poco para que nos quede lo suficientemente claro.
Como digo, aquí está el código:
Y ya está!!
Para explicar un poco el código, en primer lugar comentar que utilizamos el hook «login_headerurl» que se explica el mismo, ¿Verdad?
Bien, este hook lo utilizamos en un filtro o filter e indicamos que ejecute la función «oaf_my_login_logo_url» que creamos expresamente para eso, para cambiar la url asociada a este logo.
La función que creamos lo que hace simplemente es retornar la url que nosotros queremos y que en este caso es «https://oscarabadfolgueira.com«.
Tengo que decir que esta no es una práctica aconsejada por los WordPresseros porque, encima que nos dan WordPress «by the face«, hacemos «trampas» para que parezca lo más nuestro posible, ¿verdad?
Yo no tengo costumbre pero me ha parecido interesante compartirlo porque seguro que a alguien le viene bien para complementar el artículo anterior.
Bueno, espero que os sea de ayuda este y los otros artículo que voy publicando.
Como siempre, recordad que cualquier duda o problema en el que yo os pueda ayudar, no dudéis en poneros en contacto conmigo.
De la misma forma, si se os ocurre alguna otra cosa de la queráis que escriba aquí, lo mismo, poneos en contacto conmigo.
Saludos y hasta el siguiente…
Este snippet o trocito de código nos puede servir en aquellos casos en los que queramos redirigir a los nuevos usuarios registrados a una página específica. Generalmente será de nuestra web pero podría ser una página externa.
Podríamos utilizarlo para llevar a los nuevos usuarios a una página en la que expliquemos ciertas ventajas o servicios de nuestra empresa o a algún que otro regalito para los nuevos.
Como este Snippet es muy sencillo, dejo el código a continuación:
Como siempre, este código lo podemos incluir en el fichero functions.php de nuestro tema o crear nuestro propio plugin.
También como siempre os invito a que me hagáis llegar vuestras dudas sobre este y cualquier otro tutorial o artículo que haya publicado e incluso a proponerme algún otro artículo que os pueda ser de interés.
Saludos y seguimos!
En ocaciones vemos comentarios por la web que simplemente dicen «Ok«, «Buen trabajo«, «Buen tutorial«, etc..
Es posible que con esto nos baste pero también es posible que no nos interesen eso comentarios tan cortos y que necesitemos establecer algún mecanismo para establecer un mínimo de caracteres en los comentarios y así forzar al usuario que comenta a explayarse un poco más.
Pues bien, para trabajar con lo comentario disponemos del hook: «preprocess_comment» que más o menos nos hacemos una idea de en qué momento se ejecuta.
Lo que haremos será modificar el tamaño mínimo establecido para comentarios utilizando el hook que acabamos de comentar.
add_filter( 'preprocess_comment', 'set_minimal_length_for_comments' );
Llamaremos a la función que se ejecutará en el filter hook «preprocess_comment» como: «set_minimal_length_for_comments«.
Pues bien, nos ponemos manos a la obra creando la función de momento:
function set_minimal_length_for_comments( $comment ) {
return $comment;
}Esta parte de momento la entendemos bien. La función recibe el comentario en una variable y al final de la función la devuelve, eso si, después de hacer unos procesos que le indicaremos.
$min_length = 15;
if ( strlen( trim( 'comment_content'] ) ) < $min_length ){
wp_die( 'Los comentarios deben ser por lo menos de ' . $min_length . ' caracteres.' );
}Establecemos 15 como número mínimo de caracteres que deben tener los comentarios y posteriormente comprobamos si la longitud (en caracteres) del comentario es menor que 15. Si es así, muestra un aviso al usuario que está realizando el comentario.
Por lo tanto, ahora cuando alguien intente publicar un comentario corto como este:
No le dejará publicar el comentario y le mostrará un mensaje de aviso como el siguiente:
A continuación pongo el código completo de este Snippet:
Lo podéis utilizar simplemente incluyendo el código en el fichero «functions.php» de vuestro Tema o si lo queréis, podéis crear vuestro propio plugin.
Cualquier duda u observación me la podéis hacer llegar a través del formulario de contacto, a través de un comentario o en las redes sociales.
Espero que os sea de ayuda.
Saludos y hasta el próximo!
Con esta entrada o post comienzo una serie de artículos sobre diferentes snippets de código para WordPress, que no son más que «trocitos» de código que realizan o pretenden realizar tareas concretas.
En este caso voy a explicar el código para modificiar el número de posts por página que establece WordPress o que tal vez nuestro thema también lo haya modificado. En esos casos en los que queramos modificar el número de posts por página en algunas de las páginas de nuestro blog, podemos utilizar el código que pondré a continuación.
Pero antes de nada comentar que procuraré hacer dos partes o más bien hacerlo de dos formas, o tres si me apuras.
En primer lugar vamos a ver cómo hacerlo con programación estructurada y en otro artículo lo haremos con programación orientada a objetos.
Para incluir este código u otros en vuestro blog de WordPress, lo podéis hacer en el fichero «functions.php» de vuestro tema. No hay problema. Lo podeís poner al final del fichero y listo. Eso si, tened cuidado puesto que si lo hacéis en el editor de WordPress y algo falla, tendréis que modificar el fichero «functions.php» descargándolo por ftp y luego volver a subirlo.
Es muy común olvidar algún «;» o algún cierre «}«. Sin más, tenedlo en cuenta.
También podéis crear vuestro propio plugin y dependiendo de algunas cosas, tal vez en otro artículo lo haga en un plugin y así vemos mejor cómo se hace un plugin y vamos practicando.
Comenzamos creando la función que ejecutará el hook:
function number_of_posts_per_page( $number ) {
........
}Como podemos ver en la función, recibe una variable. Esta variable contendrá el número de posts por página que le indiquemos.
Y ahora el action que ejecutará la función y que es el alma de la programación en WordPress:
add_action('pre_get_posts', 'number_of_posts_per_page');Lo que hace es ejecutar la función que vamos a crear en el action «pre_get_posts» que como su propio nombre indica tiene lugar antes de cojer los posts para luego mostrarlos. De esta manera, le pasamos el númeor de posts a este hook y el lo hará todo por nosotros.
Ahora bien… Podemos establecer el número de posts por página en diferentes páginas. Como por ejemplo en la página de inicio, en la de búsqueda, en la de etiquetas, etc..
En primer lugar haremos una prueba sólo con la página de inicio.
Supongamos que queremos que en la página de inicio de nuestro blog se muestren los artículos de 15 en 15. Para ello, dentro de la función que hemos comentado antes, especificamos lo siguiente:
if ( is_home() ) {
$number->set( 'posts_per_page', 15 );
}¿Fácil verdad?
Por si acaso comento la jugada: Si «is_home«, osea que si es la página de inicio o inicial de nuestro blog que haga algo:
$number->set( 'posts_per_page', 15 );
Establecer en 15 el número de «posts_per_page» y guardarlo en la variable $number.
Creo que no hay mucho más que decir sobre esto porque se ve muy claro.
Bien, pues ya que estamos, vamos ha tener en cuenta otras páginas para establecer también el número de posts por página. Como por ejemplo las siguientes:
Al igual que con la página de inicio, cada una de las anteriores dispone de un «is_xxx» para saber si se trata de la página en cuestión.
A continuación indico las páginas junto con sus funciones:
Página de inicio. ---> is_home() Página de etiquetas. --> is_tag() Página de autor. ---> is_author() Página de búsqueda. --> is_search() Página de categoría. ---> is_category() Página de archivo. ---> is_archive()
Pues ya tenemos toda la información que necesitamos para completar nuestro snippet WordPress.
Aquí teneís el código completo:
Como he indicado antes, lo podéis incluir en el fichero «functions.php» del theme o hacer un plugin.
Espero que os sea de utilidad.
En posteriores artículos veremos más cosas sobre esto y otras muchas cosas de WordPress.
Saludos.
