About some tools you can use to make your life working with WordPress easier.
So I was having this issue with Composer not being able to update dependencies or even self updating to its newer version. I’m on a Mac, and this didn’t happen while using El Capitán, but I recently installed Sierra, which didn’t break a thing right until now.
I did some digging, and it became apparent that PHP couldn’t obtain SSL certificates while using both Git and cURL. Finally, after some googling around, this article did the trick.
Uno de los grandes problemas que podemos encontrarnos al trabajar con PHP es que, por carecer nativamente de una separación de ámbitos, podemos ejecutar casi cualquier bloque de código en casi cualquier lado. Eso puede ser una gran ventaja en muchos casos, pero también puede llevarnos a provocar, muchas veces inconscientemente, un desorden enorme en la organización de nuestros proyectos, tanto a nivel código como a nivel de archivos.
Teniendo en cuenta este problema, este post es un intento de repaso por algunas prácticas que, creo, deberíamos considerar al programar con PHP. Más concretamente, cuando trabajamos con funciones privadas o internas.
If you develop websites using WordPress professionally (basically, if you make a living out of it or a significant part of your income comes from there), and you haven’t implemented yet an automatic deployment system, you should strongly consider doing it. Being sincere, it’s not the easiest thing in the world. In fact, both the process and the learning curve will take a lot of working hours out of you, all spent in fruitless tests and dealing with communication between servers. The good thing is that you can take advantage of a lot of resources based on the work of people who lost some sleep hours in exchange of putting a complete deployment system in practice before you have to create a totally new one. There even exist some tools specially designed for WordPress that can be really useful to you.
Let’s suppose you have a website with an e-commerce plugin. A user comes in, buys a product and goes fine through the checkout process, but when the site tries to redirect the user to the third-party gateway where he wants to pay, something goes wrong. The redirect goes to a 404 page or never gets done. And that only happens with that single costumer. All the other costumers who bought that same product from your site did it without an itch. Whatever the problem is, you need to debug locally to find the source of it.
So now you need to replicate the process in your local mirror of the production site. You click the “buy now” button in the product page, then go to the checkout page and fill the form with the very same values that the user has previously entered. You click “confirm purchase”, and then notice the error through your favourite Javascript profiler: the email of the user customer has a character that your validator doesn’t like, so you need to improve it, but somehow the form was sent either way instead of prompting the user to re-enter his email, and you need to fix that too.
A couple of minutes later, while you’re fixing your code, you receive a phone call from the customer, who says that he received a second purchase confirmation email for an operation he did not perform. Then you have to explain to him that you were working on the issue that he reported earlier, and he understands but insists on the fact that he was bothered for a second time (the first one being his impossibility to pay) and that you should be a little bit more professional. And he is right. Now let’s suppose that this email thing happens often, and that you even lost sales because of this. The same can be applied to other scenarios regarding emails being sent, such as creation of testing users, or posting test contents to a blog with a lot of suscribers that should be notified of new posts by email. I’m sure you don’t want this. I really don’t for sure.
There comes a time in the life of a WordPress developer, no matter what his/her experience is, when he/she needs to run some plugins only in a local environment. Such cases could be related to plugins meant for testing, importing, deleting data, etc. I think you get the idea: I’m talking about any plugins that are not meant for a live site. The problem here is, given the fact that you need those plugins for your development cycle, how can you keep them from being active when you deploy your site to a production stage? And there’s another important question about this: Do you even need those plugins to be uploaded to your live site?
Yeah, sure you can manually deactivate those plugins once the site goes to production, but what if you need to do some maintenance? Let’s say you pull the remote database to your local stage in order to continue your local work after a deploy. Then you need to manually activate your development plugins again. And let’s suppose you finish your work by now and update your live site with your local changes, including a possibly modified database. Then your development plugins get activated again, so you need to manually deactivate them once more. And now let’s say you do all of this at least once a week, and that you also have a testing server. That’s a whole bunch of time that you’re losing in repetitive tasks. You could use that time to read some XKCD, or learning to dance Gangnam Style.
Well, there’s a couple of things you can do to solve this issue.
