Agregar un script debería de ser fácil. Y así es en la mayoría de los casos. Sin embargo hay ocasiones en las cuales los desarrolladores nunca tuvieron en mente WordPress u otro CMS.

Es por eso que a veces se requiere de saber que tan compatible es un código.

Por ejemplo, el siguiente es uno que alguien quería incluir en una instalación de WordPress:

Parece simple, ¿verdad?

Pero al menos hay un problema evidente: Se necesita de jQuery para poder hacerlo, eso nos dice la primera línea.

Antes de siquiera agregar este código, es importante el tener al menos una idea de lo que hace y sus necesidades. Podemos ver tutoriales en la Internet, pero sin tener una idea será difícil el encontrar una solución real.

Si no tenemos dicha noción, no podremos agregar scripts externos a WordPress de una forma rápida y eficiente.

Solucionando el problema de agregar scripts externos a WordPress

Existen muchas formas de agregar un script en WordPress, sin embargo para este ejemplo hay que tomar ciertas consideraciones. Por ejemplo que la versión de jQuery que se usa en WordPress es diferente.

El jQuery que está instalado viene en modo de compatibilidad. Por lo cual el símbolo “$” no va a funcionar por defecto. Si el código no fue escrito para funcionar bajo dicho modo, es decir cambiando “$” por jQuery, simplemente este arrojará errores.

Es por ello que se necesita modificar una función alrededor del código para hacerlo funcionar. Debería quedar así:

De esta forma, debería de poder correr en cualquier instalación estándar de WordPress con el jQuery incluido por defecto. Solo se le hicieron algunos pequeños cambios a la función anónima para permitir usar “$” al resto del código dentro de ella.

Este segmento de código puede ser entonces agregado de múltiples formas, dependiendo de las necesidades. En cualquier caso, debe de ser agregado al footer.

1. Agregarlo directamente mediante un widget

Esta puede ser la forma más sencilla de agregar el código, pero con el inminente riesgo de que no funcione. Al menos no a la primera.

Pero eso se puede resolver si le añadimos una función que espere a que el documento esté listo. De esta manera el script se ejecutará una vez que el documento web se haya cargado por completo.

De esta forma, en el widget de HTML se podría poner lo siguiente:

No parece complicado. Además de que se puede editar directamente desde la interface web.

2. Agregarlo mediante un hook y función

Usando una función y el hook “wp_footer” podemos agregar el código que queramos al final de la página. Este código lo debemos de pegar dentro del functions.php o similar.

Gracias a esto, el código deberá de aparecer en la zona de pie de página. No es la forma ideal pero debería de funcionar relativamente bien. Aunque imprimir código así no es la forma más elegante de resolverlo.

3. Agregarlo correctamente mediante wp_enqueue_script

Esta es la forma correcta de agregar un script jQuery, ya que incluso permite que se pueda “optimizar”. Usar correctamente el hook wp_enqueue_scripts permite hacer muchas cosas a la hora de manipular los script a agregarse.

Así es, esto es todo lo que se tiene que hacer para agregarlo. Con ello el script será incluido en el front-end para los visitantes, además de que podrá ser optimizado por los plugins de caché disponibles.

Pero para que funcione se debe de crear un archivo *.js y almacenarlo en un lugar accesible dentro del servidor web. O en su defecto se puede aportar una dirección URL completa.

Este método también permite convertir el código fácilmente en un plugin. Lo cual puede facilitar la vida a la hora de realizar actualizaciones. Permitiendo así mantener menos código.

¿Qué hay de los plugins para agregar scripts a WordPress?

Otra de las formas para agregar scripts externos a WordPress es el usar un plugin que facilite el trabajo. Hay muchos de ellos en el repositorio que permiten hacerlo. La mayoría con diversas opciones diferentes para cada caso.

Sin embargo, los plugins no siempre solucionan el problema. El cual se agrava si no sabemos como es que JavaScript funciona. Y aún más si no se sabe detectar errores.

Un script puede ser agregado mediante un plugin correctamente. Pero a la hora de ejecutarse, puede arrojar errores. Mismos que impiden su correcta ejecución. Estos errores muchas veces van más allá de lo que un plugin puede solucionar.

En esos casos, es importante mirar entonces a la consola del navegador. Muchas veces encontraremos ahí que es lo que está sucediendo. Como por ejemplo el caso de la «$» de jQuery, la cual ya había explicado. O incluso otros errores como contenido mixto o errores en el código.

Esas son cosas que requieren más pericia para ser corregidas.

Conclusiones sobre agregar scripts externos a WordPress

Agregar scripts de jQuery es relativamente sencillo en WordPress. Sin embargo se deben de tener ciertas nociones para evitar problemas.

En el caso de que algo suceda, siempre es bueno mirar la consola que ofrece el navegador web. Siempre nos dará pistas sobre lo que puede estar pasando. Para el desarrollador, la consola será siempre una de las mejores herramientas.

Además hay que recordar que la versión de jQuery que se incluye previene el uso de “$” en las funciones. Por lo cual hay que encapsular el código si nos muestra ese tipo de errores.

Y cuando todo haya fallado. Siempre será buena idea preguntar. Ya que puede haber alguien dispuesto a ayudar.

The post Formas de agregar scripts externos a WordPress appeared first on Endless Manifesto.

Saber PHP es algo que invariablemente te va a ayudar. Igualmente mirar el Codex de WordPress… pero al final del día, muchas cosas se condensan en una sola frase: Mira el código fuente.

Entendiendo los Hooks y Transients en WordPress

Hay quienes han hecho un esfuerzo para documentar que hooks se usan y en que momento. Incluso puedes encontrar infografías muy buenas que te dan una guía visual. Eso da mucha luz, pero siempre quedará la duda en algunos casos.

¿Qué es un hook o gancho?

Para ponerlo en palabras simples, es un punto en el cual vamos a “adjuntar el código que queramos”. ¿Eh? Sí. Básicamente llegamos y pegamos el código que queremos en el lugar al cual queremos.

Existen dos formas de hacerlo: Como filtro o como acción. Pero no te enredes con los términos, ya que su diferencia es prácticamente semántica. ¿Por qué? Porque la función para agregar acciones es un alias de la misma para agregar filtros.

Pero eso no significa que debas intercambiarlas a placer. Si cambias información, usa “add_filter”. Si cambias el comportamiento usa “add_action”. A la larga tu código se entenderá mejor.

Un ejemplo

Por ejemplo, la forma más fácil “pegar” código es con un tema y una función. Digamos que tenemos el archivo functions.php y que queremos probar los hooks. Por ejemplo, iniciaríamos con esto:

View the code on Gist.

Una vez que tengamos la función, la magia empieza cuando agregamos “add_filter”:

View the code on Gist.

Con ella, le decimos a WordPress que ejecute nuestra función (agregada como filtro) cuando le toque al hook indicado. En este caso, use uno arbitrario. Es muy probable que no funcione para nada.

Hasta ahí todo bien con el ejemplo. ¿Entonces como saber donde debo agregarla para que se ejecute? Aquí es donde las cosas se complican un montón y es importante mirar el código.

Como mencione en una entrada anterior, tuve que mirar el código para darme una idea. En ese caso, estuve buscando la función “do_action”. ¿Por qué? Porque ella es la que da la pauta de donde se van a realizar los cambios.

De esa forma sabemos exactamente en donde se va a “pegar” el código que queremos. Pero ten en cuenta que no podrás cambiar nada antes de ese punto (ni después, a menos que haya otro hook que te lo permita).

El ejemplo simple quedaría así para que funcione:

View the code on Gist.

Igualmente buscando y mirando el uso de “do_action” y “apply_filters”, obtendrás el nombre del hook el cual tienes que usar y que “variables” le pasará. Con ello tendrás el 90% del trabajo hecho.

Aunque google será tu amigo por un buen rato.

Recuerda, podemos agregar cuantas funciones queramos a un hook. Por ejemplo, con varios “add_filter” en diferentes momentos con diferentes funciones. Incluso podemos indicar en que orden se ejecutarán.

¿Qué hay de los transients?

Para hacer la historia corta con ellos, se trata básicamente de “variables”. Imagina que son como “cookies” o “sesiones”. Pero en vez de afectar a un solo usuario, podemos usar su contenido para todo el sitio. Son usadas especialmente para guardar consultas complejas.

Por ejemplo, aquí tengo el siguiente ejemplo:

View the code on Gist.

Eso se lo agregué a un tema para hacer “algo” una vez al día.

La gran ventaja, es que podemos recuperar el valor de un transitent fácilmente con “get_transient”. Solo necesitas el nombre y listo. Pero ojo, si este ya se encuentra expirado no regresará valor alguno. Esa es su naturaleza, temporal. No es buena idea usarlos para información permanente.

¿Por que expiran? Bueno, es una de sus características. Cuando asignamos su valor con “set_transient”, debemos de definir un tiempo tras el cual expirará (ok, podemos asignar “0” o no asignar nada para que jamás expiren, pero esa es otra historia… no deben de ser usados para almacenar información permanente).

Igualmente pueden ser fácilmente borrados con “delete_transient”, si queremos deshacernos de ellos antes de que expiren.

Estos son más fáciles de usar, pero abren un nuevo universo de posibilidades.

Conclusión sobre los Hooks y Transients en WordPress

He estado invirtiendo el tiempo que puedo para poder entender de fondo todas las características que tiene WordPress.

PHP me ha ayudado mucho, aunque me he topado con muchas entradas en blogs que dan por sentado que ya sabes como funciona lo expuesto aquí. Eso puede frustrar un poco, ya que a veces no se entiende el contexto.

Quizá sea idea tomar un curso que me facilite el camino. Solo es cuestión de hacerme del tiempo.

The post Hooks y Transients en WordPress appeared first on Endless Manifesto.

Gutenberg is going to be the new editor for WordPress. Something I was not aware of until I was lurking some at articles archives while killing some time.

While I am still kind of new in the sense of editing for this platform, I had known the WYSIWYG editors for the web for quite some time. Back in the day, using them even at Drupal was necessary to add content quite quickly.

WordPress right now comes bundled with TinyMCE, what does an excellent work already even if it shows some age.

The team aims to get a much more modern editor that is more flexible and eventually more feature rich.

Gutenberg on the run

You can give a peek at the editor in action here, and even try and make some stuff with it. Right now, it does not offer a lot of features as it is still under heavy development. But it is getting a lot of bugs fixes constantly.

While I was messing with it some, I was thinking how much it looks like to some of the modern visual editors. Especially in the sense of making stuff easy for the one creating content.

Competence or Just an Update?

There out we have stuff like Divi, SiteOrigin and Visual Composer. All of them aimed to easily create outstanding content for «pages» into WordPress.

Some of them can be used to build regular posts. But I do not think it is effective to use them for regular blogging.

Of course, while using Gutenberg for a few minutes… it was clear that it is way more easy to create content with it, than with TinyMCE. It can potentially create a competence against visual composers.

This is because it can offer much more freedom. But for now, it still lacks the feature to add columns.

Just go there and tame the beast

Hope it is not a hard task

Of course, the team behind the development of Gutenberg know that making such radical changes to the editor may be a catastrophic choice. They may leave a segment with the ability to create rich content.

Yet, developing software is about to take risks and aim to make things better for everyone. To always improve and find new and better solutions.

This risk can totally pay off eventually.

But so far, I do not see this specific piece of software making its debut on WordPress 4.8, to be released June 8. Or at least I see a kind of transition time between TinyMCE and Gutenberg.

Time will tell when we can see it in a production environment. But I would really like to see it soon enough, with a bunch more of features.

The post Gutenberg for WordPress appeared first on Endless Manifesto.

During such time, I have learned PHP, MySQL, some Javascript and whatever I have come across with it. Of course, back in the day, you did not have anything named «Joomla», «Drupal» or «WordPress». If you wanted a CMS, you either spend a bunch of bucks or ended making one by yourself. I mostly did stuff with my bare hands.

While doing stuff yourself seems nice, there is a moment where you eventually grow tired. You just want to add content and have everything work without issues.

While adding stuff was not hard… it was not really efficient, in the way I did stuff… so, with the time you simply stopped to do so.

Retaking the network

Somewhere in 2010, I started to be serious about retaking and having a much more professional site and so on. I had a bunch of experience with a website from back 2004, but I was more than sure that did not want to go all the same road all once again.

Gathered then some of my pieces around: Plain HTML is a big NO NO. It is going to be a pain to keep such things. Have you tried to edit 10 HTML files? When you are at the 5th one, you already want to do something else.

The second way to go was PHP again with some tricks, but NO. It was very unprofessional. While I for sure were able to make it look nice and such… in the long run, it was falling into the same pitfall than before… or worst… maybe open a random bug can.

What was the solution then? At that time, there were now some names and the CMS started to take everything around.

One of the first considerations I had was the PHP-Nuke CMS, that I remembered seeing from somewhere, but do not remember what exactly made me not to give it a try.After some extra search eventually had a few names to give it a try: Joomla,

After some extra search eventually had a few names to give it a try: Joomla, Drupal and WordPress.

Joomla

I am not going to be fair with this engine as I do not remember giving it enough chances.

When I installed and give it a test run, I felt like that Joomla was quite fitting to what I needed back in the day: A simple blogging platform.

Played with it a few hours until I went ahead to try and customize it. There is where I found the very first problem with it.

Maybe my reaction if I did it today

I ended having no idea how to modify the themes I had downloaded for it.

Maybe if I see the code today, I would be like «why I was so derp?». But back at that day, I spend a fair amount of hours trying to make it look nice and other stuff… just to give up eventually.

So, moved on.

Drupal

I did not give WordPress a try during the 2010-2011 because… well… a bunch of people was like «It is really bloated, avoid it at all costs». Since the CPU use and memory was a concern for me, back at that day, I decided not to question that, so moved to the next one in the line: Drupal.

At that moment, Drupal was in its version 6. Installing was… easy… configuration was not all that bad. Adding and editing a theme was relatively easy after a few hacks here and there… urg… really bad habit from that day.

While for sure getting used to the administration and blocks was… hard… I felt like that it had a lot of potential. Of course, if you did not mind to get messy with the code.

One thing that I do remember is that a bunch of pluggings did not work on it. So setting up the installation was like a trial and error process… because you never had any indication from the Drupal website if the plugin you downloaded might work on your site or version.

Struggles with it

And as the days went on, stuff started to surface and become more and more annoying.

For example, keeping Drupal updated was a struggle on itself… as I needed to re-do some of my changes into it… or something random did broke… you never knew. The experience was not really pleasurable after a couple of years… and that is what you earn when you mess with the code.

Also, it did not help, I think, that I had a multisite install on it. Heck, even doing that multisite install was rough and messy. Create databases, re-do installs, move files and hope for the best.

Eventually, my installation did fall to the hands of hackers given that I was unable to keep it updated and was avoiding to move to Drupal 7 the most I could because… it was going to break many things.

I for sure will give the new Drupal 8 a try sometime soon, but it is clear that it needs full-time attention. Something that I can’t afford most of the time until a good change happens here.

WordPress

Like mentioned before, back in 2010-2011, I simply discarded this one because… well… people said it was boatled. But now in 2016, computing power is better suitable than what it was at 2010. And of course, had now access to better hardware at this host too.

My first «official» contact came during the set-up of a website that is hosted alongside this one. that person insisted on making a WordPress install, so it happened.

After being moving it for a few minutes, it was clear that it was like nothing else that I had tested before. Was so surprised that I ended doing an install on my own space too.

It was clear why it is used on 1 of every 4 websites on the internet.

Remember, not everyone knows PHP, HTML, CSS and such to be able to modify a website. Most people just can have a bad day and a very steep learning curve ahead with CMS.

And even if you do know such things, then you can modify themes and what not quite easily. I have been having a lot of fun doing that recently. It is enjoyable like never before. Still, I want to someday design my own theme rather than modify one.

Maybe someday.

Just my experience

While there are a bunch of articles there out talking about what system is better, I really can only say that is better just to give it a try to any of them.

But one thing is sure: WordPress is really way too easy to use and maintain, while Drupal is just really more powerful, but requires a lot more of dedication.

I am sure of a few things: I’ll keep using WordPress, but will try and tame Drupal eventually.

The post Self history with: Joomla, Drupal and WordPress appeared first on Endless Manifesto.