WordPress developer in the middle of the night
About WordPress
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.
Con este snippet añadimos a los singles de un cpt en el desplegable que aparece para seleccionar la página estática del sitio.
Esta opción está en: Ajustes -> Lectura
GIST URL: https://gist.github.com/Oscar-Abad-Folgueira/ebc85aac65319ba3605b156c87a60c2a
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!
El título del post viene por la traducción que hace Google Translate tanto de «bulk delete» como de «bulk». Me ha parecido gracioso y no he podido resistir la tentación. Pero venga, vamos a lo que vamos.
Estoy casi seguro de que en algún momento te ha pasado que te has encontrado alguna web de algún cliente (seguramente heredada) que, por motivos de spam, tiene una buena cantidad de comentarios pendientes de moderar. Pero segurísimo que estoy.
Podríamos ir página por página y mandarlos primero a la papelera y luego pues nada, otra vez para eliminarlos definitivamente. Pero estarás de acuerdo conmigo en que el tiempo es oro y hay que buscar otra solución.
Por suerte para ti y para mi, existe un plugin que nos va a ayudar en esta tarea. Se trata de WP Bulk Delete.
WP Bulk Delete nos permite, entre otras cosas, eliminar los comentarios en función del estado de los mismos.
En la captura puedes ver que hay un montón de comentarios pendientes e incluso uno en spam. Seleccionamos los estaos que queremos eliminar y listo! En un momento acabará esta pesadilla.
Ah! Siempre, antes de hacer este tipo de cosas te recomiendo hacer un backup completo de tu sitio. Sobre todo de la base de datos pero si es completo, mejor
Antes de marcharme comentar que este plugin te permite eliminar otro tipo de cosas como entradas, posts de otros cpts y demás. Es muy completo.
Nada más por mi parte.
Saludos y 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!
Vuelvo con otro pequeño código un tanto extraño.
La verdad es que, aunque parezca increíble, simpre me encuentro con tareas un poco «raras» que necesitan mis clientes y esta es una de ellas.
La idea es añadir un texto que podría se un «Anuncio» o «Aviso» en la parte superior de las páginas de producto individual y ya puestos, que se muestre sólo en la página de un producto en concreto. Voy a explicarte cómo hacer los dos casos, ok?
Pues vamos allá!
A modo de ejemplo, te muestro una captura en la que puedes ver el anuncio de «¡¡ESTE ES NUESTRO PRODUCTO ESTRELLA!!». Eso si, muy sencillo porque el objetivo de esta entrada es mostrarte cómo hacerlo y luego tu puedas darle aspecto y diseño a este «anuncio».
Y este es el código necesario:
Lo único que tendríamos que hacer sería modificar el texto del «h2» a nuestro gusto y ya puestos poner un poco de estilos a la clase «anuncio-estrella».
Ahora vamos a añadir un poco de código para que el anuncio se muestre sólo en uno de los productos y para ello usaremos el «id» del producto.
Supongamos que el producto en el que queremos que se muestre el anuncio tiene la «id» «18». Añadimos el código «&& get_the_id() == 18» a la comprobación del «if». Total, que nos quedaría así:
Fácil y sencillo, ¿Verdad?
Claro que esto lo podríamos adaptar de muchas maneras y formas diferentes. Tanto para que se muestre en otras circunstancias como en categorías, etiquetas, etc… así como para que ese anuncio se muestre en cualquier otro sitio de nuestra web. Lo dejo a tu imaginación.
Pero antes de terminar…
Venga, a por el siguiente…
WooCommerce ha añadido una nueva opción al menú de administración de WordPress con el nombre de «Márketing» y que podemos encontrar justo debajo de la opción «Análisis» del menú de administración.
Es muy posible que esta opción no nos interese por lo que podemos desactivarla con un sencillo snippet:
Y ya está.
Espero que esta información os sea de ayuda.
Podés dejar un comentario si lo queréis.
Saludos y mucho ánimo!
En ocasiones queremos localizar alguna cadena dentro de los ficheros de WordPress. Ya puede ser dentro de de algún tema o plugin.
Los motivos pueden ser variados pero ahora mismo se me ocurre que necesitemos cambiar una traducción que no conseguimos que se traduza por el motivo que sea.
Podemos realizar una búsqueda en nuestro equipo sobre los directorios que nos interesen pero también disponemos de un plugin que nos ayudará en este sentido.
El plugin es String Locator y como bien dice su nombre, busca y localiza cadenas de texto.
Una vez que tenemos instalado el plugin, nos dirigimos al menú Herramientas –> String Locator del panel de administración de WordPress y veremos algo similar a esto:
Es tan sencillo como indicar la cadena que queremos buscar en el segundo campo, el de «Search String» y en el desplegable podemos elegir si buscar en todos los ficheros de WordPress o en temas o en plugins en concreto para afinar nuestra búsqueda.
Como digo, seleccionadmos dónde queremos buscar la cadena, la cadena que queremos buscar y por último, hay una opción «RegEx search» que es por si introducimos expresiones regulares en el campo de cadena.
Cuando realiza la búsque nos mostrará los ficheros donde ha encontrado esa cadena:
El resultado es del todo aclaratorio porque indica la cantidad de veces que ha encontrado el string así como dónde los ha encontrado. El fichero en el que está y la línea de ese fichero.
Es un plugin muy últil para utilizar en ciertas ocasiones
Otra cosa muy buena de este plugin es que lo podemos desinstalar hasta que no volvamos a necesitarlo.
Espero que esta información os sea de utilidad.
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!!
Para realizar algunas traducciones en algún tema o plugin de WordPress, hay varias formas de hacerlo.
El motivo puede ser variado, desde que ese texto no esté traducido a nuestro idiomar hasta que, por el motivo que sea, no nos convence la traducción que existe en nuestro idioma y necesitemos cambiarla para adaptarla a nuestras necesidades.
En cualquier caso, yo voy a comentar la opción de hacerlo mediente un plugin o hacerlo mediente código.
Loco translate es un plugin fabuoso y muy ulizado que podemos utilizar tanto para traducir o cambiar traducciones de plugins y temas del repostorio de WordPress como el mismo WordPress así como plugins y temas privados que hayamos comprado.
Como digo es una solución fácil de usar.
El plugin lo podemos encontrar en el repositorio oficial de WordPress en el siguiente enlace:
https://es.wordpress.org/plugins/loco-translate/
Eso por una parte. Ahora veamos cómo hacerlo usando código.
Loco Translate es fantástico, como ya he dicho antes pero tal vez no sea la mejor solución si lo que queremos es traducir unas pocas palabras o incluso una sola. No merece la pena y para esos casos tal vez sea mejor utilizar un poco de código sencillo.
Utilizaremos el siguiente trocito de código:
Lo que estamos haciendo es el ejemplo es traducir o cambiar la traducción de «Agotado» por «Sacabao!«.
Entonces, si queremos cambiar la traducción de cualquier palabra, modificaríamos estos campos y listo.
Ahora bien, ¿Y si el texto no está traducido?
En el ejemplo anterior el texto ya estaba traducido y lo que hemos hecho ha sido cambiar la traducción y ahora lo que queremos es traducir un texto que no está traducido por el motivo que sea.
En este caso haremos algo parecido pero usando la variable $original como se indica a continuación:
De manera similar, modificamos la palabra original y la traducción y listo!
Espero que os haya sido de ayuda.
Cualquier cosa me dejáis 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!
Puede ser que en un momento dado necesitemos saber si un post, del tipo que sea, tiene o no asignado un término de una taxonomía en concreto.
Antes de nada, vamos a sentar las bases para saber de lo que estamos hablando y lo que vamos a hacer, ok?
Os pongo el siguiente ejemplo:
Tenemos un Custom Post Type «Hook» que usamos, como ya habréis adivinado, para crear información de hooks de WooCommerce, cada hook en un post.
Este CPT «hook», tiene una taxonomía a la que llamaremos «tipo» en la que recogeremos el tipo de hook si es «Action» o es «Filter».
Ahora bien, en nuestro fichero de archivo de el cpt «hook», necesitamos saber si cada uno de los hooks (posts del cpt hook) es «action» o «filter » y para eso podemos usar la siguiente función:
has_term( string|int|array $term = '', string $taxonomy = '', int|WP_Post $post = null )Podéis encontrar más información sobre esta función en: https://developer.wordpress.org/reference/functions/has_term/
Ahora bien, como en nuetro fichero de archivo de hook tenemos todo este tinglado montado en un loop que recorre todos los posts de tipo hook para ir pintándolos en el front, ahí es donde vamos a meter esta función para comprobar si el post es un action o es un filter.
Pero antes, tenemos que saber que el motivo por que el cual queremos saber si es un «action» o un «filter» es para añadirle una clase css en cada caso porque queremos pintar de manera diferente los actions y los filters.
Por consiguiente nuestro código quedaría algo así:
Recordemos que este código está dentro de un loop en el que vamos recorriendo todos los posts del cpt «hook».
Ahora, vemos un poco por encima la función que hemos usado y cómo la hemos usado.
has_term( 'action', 'hook-type' );Como podemos ver, en nuestro caso hemos incluído como primer parámetro ‘action’ que es el slug del término de taxomía que queremos comprobar y como segundo parámetro hemos añadido el slug de la taxonomía ‘hook-type’.
De esta forma comprobamos si el post actual tiene asignado el término ‘action’ y si es así, establecemos un valor a la variable que vamos a usar para guardar el nombre de la clase css.
Espero que me haya explicado bien pero de todas formas, cualquier duda que tengáis sobre esto, me lo podéis comentar cuando queráis e intentaré ayudaros en todo lo que pueda.
Saludos a tod@s!
Hoy volvemos como no, con un nuevo WordPress Snippet.
Se que a muchos os gustan estos trocitos de código y por eso los voy poniendo. Además, así me da tiempo a preparar otro tipo de contenido con el cual estoy ahora y que poco a poco iré anunciando para cuando llegue el momento.
Pues bien, en este post vamos a hacer algo bien sencillo que no es otra cosa que cambiar la palabra de saludo que WordPress pone delante del nombre del usuario logueado, en la parte superior derecha de la pantalla.
Eso es, a este saludo me refiero. En concreto a la palabra «Hola«.
Si, esta palabra es posible modificarla de otras formas como por ejemplo modificando el fichero «.po» de la traducción al Español de WordPress pero aquí estamos para hacer cosas con WordPress, para trastear y para practicas programación que es lo que nos gusta, ¿Verdad?
A los que ya visitáis esta web de vez en cuando igual os choca un poco que ponga este título.
Pues bien, éste va a ser el primero de muchos WordPress Snippets que vamos a hacer y que a partir de ahora procuraré hacerlo de dos formas. La primera de ellas será la que venimos haciendo hasta ahora para incluir en el fichero «functions.php» de nuestro tema y la segunda será creando un plugin.
Los plugins que crearemos al principio serán muy sencillos, sin complicaciones pero según vayamos avanzando, intentaré complicarlos para que aprendáis todo lo que podáis con mis consejos.
Nos centramos en este Snippet en concreto y para ello nos queda claro que lo que tiene que hacer es sustituir la palabra «Hola» por otra palabra que nos guste para saludar a los usuarios registrados. En mi caso voy a sustituirla por «Qué pasa«.
Crearemos la función «oaf-wp-reemplazar-hola«. Aquí a vuestro gusto…
Bueno, como es pequeña, pongo la función y a continuación explico un poco el código.
function oaf-wp-reemplazar-hola( $saludo ) {
$nuevo_saludo = 'Que pasa';
if ( is_user_logged_in() ) {
$text = str_replace( 'Hola', $nuevo_saludo, $saludo );
}
return $saludo;
}En primer lugar creamos una variable para almacenar la palabra que queremos que sustituya a «Hola«. Esta variable la he llamado $nuevo_saludo para que quede claro de lo que estamos hablando.
Posteriormente comprobamos que el usuario esté logueado y si es así procede a reemplazar el texto «Hola» por el que contiene la variable $nuevo_saludo y lo guarda en la variable $saludo.
Par finalizar, retornamos el valor de $saludo y función lista.
Ahora nos queda el filtro o filter, como era de esperar.
En este caso utilizaremos el «gettext» junto con el nombre de la función que acabamos de crear.
Por consiguiente el filtro quedaría así:
add_filter( 'gettext', 'oaf-wp-reemplazar-hola' );
Fácil y sencillo, ¿Verdad?
Creo que no hay nada más que explicar sobre esto por lo que voy a poner el código completo del snippet a continuación para que podáis disponer de el cuando queráis.
Eso es, si. Con desenlace me refiero a ver lo que nos ha hecho este snippet y para ello basta con mirar de nuevo en la parte superior derecha de la pantalla y ver cómo no saluda ahora:
