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 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:
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:
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.
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:
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?
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:
acf/load_field => Se aplica a todos los campos
acf/load_field/type={$type} => Se aplica a todos los ficheros de un tipo específico
acf/load_field/name={$name} => Se aplica a los campos con un nombre específico
acf/load_field/key={$key} => Se aplica a los campos con una clave específica
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.
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:
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:
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.
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.
¿Qué con las páginas de opciones de WordPress?
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.
Cómo crear una página de opciones
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.
Crear una página de opciones super básica
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.
Crear un grupo de campos y asignarlo a la 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…
Opciones básicas para las páginas de opciones de ACF
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.
‘page_title’
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:
‘menu_title’
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:
‘menu_slug’
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í:
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…
‘position’
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í:
‘icon_url’
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.
‘update_button’
É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.
‘updated_message’
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’.
‘redirect’
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.
Crear página de opciones con página hija
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.
‘parent_slug’
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
Crear páginas de opciones con 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.
Establecer la página de opciones bajo Ajustes u otro ítem de menú
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ú.
Cómo obtener los datos de campos de páginas de opciones
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.
Cómo crear una página de opciones con ACF Free o de andar por casa
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:
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.
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.
Vamos a meternos con el desarrollo con Advanced Custom Fields que es una de las tecnologías o herramientas con las que trabajo todos los días y me parece muy interesante para cualquier persona que se mueva en el desarrollo de WordPress.
En este tutorial lo que vamos a hacer es una consulta a WordPress para que recoja todos los valores de un campo cd ACF y los guarde en un array para que posteriormente los podamos tratar o utilizar para cualquier otra tarea que necesitemos.
Para este ejemplo vamos a suponer que tenemos un grupo de campos «Empresa» que tendrá dos campos. Uno para el nombre de la empresa y otro para un Id de empresa. Para hacerlo sencillo vamos a suponer que estos dos campos son únicos y que no se van a repetir aunque no vamos a realizar este desarrollo en este tutorial. Lo haremos más adelante en otro, claro que si.
Ah! y para que nos sea más sencillo o diferente, he creado una CTP «Empresa» que es el tipo de contenido que tendrá estos campos.
Entonces, suponemos que tenemos esto en ACF:
Teniendo esto como base para nuestro ejemplo de desarrollo, imaginemos que tenemos un buen número de empresas y que «odas» estas empresas tienen contenido único en estos dos campos.
Lo que queremos hacer es recorrer todos los posts de tipo empresa y guardar estos dos valores en un array para luego usarlo para otras cosas.
Para ello primero crearemos una función y dentro de esta usaremos la WP_Query para realizar la consulta.
Vamos allá y luego lo explico:
Hemos creado una función que podremos utilizar posteriormente en un hook o como necesitemos y dentro de esta función, lo principal es la query que hacemos a todos los posts del CPT empresa que estén publicados.
Recordemos que sólo queremos los ids y los nombre de las empresas, el resto de contenido nos da igual. Por lo menos por ahora.
Inicialmente creamos un array vacío fuera del if para almacenar los datos que necesitamos.
Una vez realizada la query, la recorremos y por cada post recogemos el id_empresa y el nombre_empresa para finalmente añadirlos al array $lista_ids_nombres_empresas.
Y ya lo tendríamos.
Lo último que hacemos es resetear la consulta y devolver el array con todo el contenido.
Podéis utilizar cualquier método para aseguraros de que efectivamente el contenido se guarda en el array y que es el contenido correcto. print_r o var_dump por ejemplo.
Como muestra, aquí tenemos una captura en la que confirmamos que efectivamente todo va como tiene que ir.
Este es sólo el comienzo. La consulta es muy sencilla pero en otros tutoriales veremos cosas algo más complejas, ok?
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.
En el anterior artículo de esta serie vimos una introducción y los tipos de shortcodes que podemos utilizar e implementar. Esto nos dio una visión general de lo que podemos hacer con los shortcodes de WordPress pero esto no acaba aquí, ni mucho menos. Podemos sacarle mucho provecho a la Shortcode API y lo vamos a ir viendo a lo largo de esta serie de artículos.
En este segundo artículo vamos a ver las posibles opciones que tenemos a la hora de programar shortcodes para WordPress.
Seguro que existe algún plugin que podríamos utilizar para crear nuestros shortcodes. Alguno del tipo a Code Snippets pero nosotros no lo vamos hacer. Es más, de las dos opciones que veremos, sólo utilizaremos una de ellas y ya os explicará porqué dentro de un momento.
Bueno, no esperamos más. Acabo de comentar que hay dos formas de hacer un shortcode para WordPress:
1-. En el fichero functions.php.
2-. En un plugin (nuestro plugin).
Y aunque tenemos opciones variadas, vamos a centrarnos e intentar explicar estas dos opciones lo mejor posible para que nos quede claro.
Empecemos:
1-. En el fichero functions.php
Bueno, entiendo que conocéis un poco de la estructura de fichero de WordPress y su funcionamiento porque de no ser así, seguramente no estaríais leyendo este artículo.
Pues bien, sabemos que existe el fichero functions.php de WordPress y lo que hay dentro.
Por consiguiente simplemente comentar que podemos realizar la programación de nuestros shortcodes en este fichero. Pero…
A mi esto no me gusta nada de nada. Es más, lo desaconsejo totalmente. ¿Por qué? Porque todo lo que implementemos en el fichero functions.php se va a quedar ahí y corremos el riesgo de perder nuestro código en alguna de las actualizaciones de WordPress.
Además, que si programamos un shortcode y lo queremos exportar a otra instalación WordPress, tendremos que volver a modificar el functions.php de este nuevo WordPress.
Por consiguiente, no vamos a hacer nada que modifique este fichero, nosotros y nosotras vamos a trabajar siempre de la segunda forma que comento a continuación:
2-. En un plugin (nuestro plugin).
Esta, esta es la buena!
Procuraremos, siempre que nos sea posible, crear un plugin para nuestro o nuestros shortcodes.
Por supuesto también puede formar parte de un plugin más grande, con más opciones y más código. Con esto quiero decir que es posible que nuestro shortcode sea sólo una parte de un plugin que desarrollamos.
Y ¿Por qué digo que esta manera es mejor?
Bueno, supongo que ya lo habréis intuido pero lo comentamos, claro que si.
Al programar nuestro shortcode en un plugin podremos exportarlo fácilmente a otras instalaciones de WordPress simplemente instalándolo en cada una de estas instalaciones.
No dependemos de las posibles actualizaciones de WordPress. Es decir, que las actualizaciones de WordPress no tocarán nuestro código y por consiguiente seguirá donde estaba.
También nos sirve para aprender. Si estamos aprendiendo a programar para WordPress, es una buena práctica hacer las cosas siempre que podamos, siempre que se nos ocurra una posible funcionalidad, aunque ya exista. Pues plugin para hacer. Os lo aconsejo, hacedlo y ya veréis…
Y para terminar con los beneficios, que seguro que habrá más, comentar que las cosas claras y el código limpio y ordenado. Es mucho más claro y ordenado tener cada cosa en su sitio para no tener problemas más adelante. Si programamos nuestros plugins, la instalación de WordPress estará mucho más limpia. Además, podremos desactivarlo o desinstalarlo cuando queramos sin tener que volver a tocar el functions.php.
¿A quedado claro?
Acostumbraos a hacer las cosas bien desde el principio. Programad, programad y programad todo lo que podáis.
En el siguiente artículo de esta serie hablaremos de los shortcodes que pone a nuestra disposición WordPress. Es decir, que ya están programados y listo para que nosotros los utilicemos en WordPress y aprovechemos su potencia.
Este sitio web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando regresas a esta web, ayudar a nuestro equipo a comprender qué secciones del sitio web te resultan más interesantes y útiles y ofrecerte publicidad a tu medida.
Cookies estrictamente necesarias
Las cookies estrictamente necesarias deben estar habilitadas en todo momento para que podamos guardar tus preferencias para la configuración de cookies.
Si desactivas esta cookie no podremos guardar tus preferencias. Esto significa que cada vez que visites esta web tendrás que activar o desactivar cookies de nuevo
Cookies de terceros
Este sitio web utiliza Google Analytics para recopilar información anónima, como la cantidad de visitantes al sitio y las páginas más populares.
Mantener estas cookies habilitadas nos ayuda a mejorar nuestro sitio web.
Por favor, primero habilita las cookies estrictamente necesarias para que podamos guardar tus prefencias.
