Un primer paso muy recomendable para empezar a entender cómo funciona WordPress a nivel código, independientemente de si trabajamos con plugins o themes, es conocer el paradigma de programación orientada a eventos, ya que en él se basan la mayoría de las posibilidades de extensión que tenemos disponibles. Es importantísimo conocer este paradigma a la hora de interactuar con el código de WordPress, ya que desconocerlo puede llevar a muchísimo trabajo innecesario, o a mucho tiempo perdido en mantenimiento, mejoras y arreglo de bugs.
Correctly Obtain the Path to the WordPress Admin Directory
WordPress comes with a lot of handy tools that let you have URLs and paths to some folders without having to hardcode them, such as the content_url() and get_stylesheet_directory() functions for the URL to your content folder and the absolute path to your current theme folder, repectively. You can see a list of all these functions in the Codex.
However, if we search for some function to retrieve the absolute path of the admin folder, we’re lost. We have admin_url(), get_admin_url(), network_admin_url() and get_network_admin_url() but those only gives us URLs, not paths. Our only answer is to create our own function.
Here’s How You Do It
Of course you can use something like ABSPATH . '/wp-admin', but that doesn’t offer any guarantees in case the admin folder were to be renamed at some point, let’s say manually, by a plugin, or with some rewrite rule. There’s a lot of ways thing can go wrong using that method, especially if you’re distributing your code.
What I suggest as a more proper solution is to create a function like this inside your plugin or theme:
What we’re doing here is replacing the base URL of our site with the ABSPATH constant, which contains the full path to the root folder of your WordPress installation, thus leaving the /wp-admin part (or whatever it’s called) intact. We obtain the name of the admin folder dynamically, without the need to hardcode it at any point.
You can also get the path for the network admin by just replacing the call to get_admin_url() with get_network_admin_url().
Hope this helps 🙂
How to Efficiently Flush Rewrite Rules After Plugin Activation
Recently, I’ve been working in a WordPress plugin that adds a custom post type. That’s not a novelty, we’ve all done that before. However, we usually need to flush our rewrite rules after registering the custom post type in order to prevent permalinks from not working properly, but we don’t always do this in a thoughtful way.
A lot of developers just tend to call the flush_rewrite_rules() function right after register_post_type(), without any kind of security check. The thing is, as the Codex article notices, this is an expensive operation that may use a lot of resources, so we don’t want to have it running all the time. Just once, after the custom post type gets registered, is more than enough.
Now With Random Cats Included
I wouldn’t say I am exactly a cat person. I do have a cat, but I’m not really more into cats that I am into dogs. I don’t completely share all of the cat related crazyness that’s been around the internet for years now, but I enjoy it as something cool, funny and cute at different times.
Cats have also become a meme on their own, so in those moments of tension or boredom both at work and home, a gif of a cat going batshit crazy serves as a relief from the awful pits of common life. At least for a while. Then you start looking for more photos, and boom, there goes your day.
How to Deal with Users Being Automatically Generated by WP e-Commerce
In the last four months there was a lot of discussion about some decisions made by the developers of the famous shopping cart plugin WP e-Commerce. I think that discussion would not have exist if there were no users affected by the decisions that originated it. It is to be noted that version 3.8.14, the most recent release of WP e-Commerce, is supposed to definitely fix the issue, but I’m sure there will be a lot of people not putting the plugins on their sites up to date, and there can appear some possible issues with backward compatibility that need to be solved. That’s what this article is meant to.
You can read the first page of the thread if your interested in the technical implications, but basically, since version 3.8.13, WP e-Commerce saves the session data of anonymous customers into the wp_users and wp_usermeta tables, instead of doing it into transients, as was formerly done and other shopping cart solutions, such as WooCommerce, still do. This means that every time a non-registered visitor enters your site a new user will be created and some meta data for that user will be stored. So, if your site gets a lot of visitors, your database will be populated with lots of dummy users in a considerably short time. There is a scheduled task meant to remove this users hourly, but it doesn’t work quite well in some server configurations, so there will be sites where the tables won’t ever be automatically cleaned, with databases growing uncontrollably larger and larger in just a matter of days. That’s not something that any capable developer or site owner wants for his website.
So let me stop here for a minute. I’m not in the train of detractors of this practice. I don’t think it is ideal, but I do think there is a really good reason to do things this way and not another. I’m not that into discussing things that were already done as I am for trying to fix what’s wrong with them. There has been a lot of hate comments, ranting and whining in the thread I linked at the beginning, and I’m pretty sure that’s not the way to solve things, and don’t have me start on the kind of motivation that a programmer finds to get something fixed when he or his product is being attacked. So please, if you need some software to be fixed, be nice and friendly to your programmer. Otherwise, either he won’t do it well or will just walk away from you.
Now let’s get into the problem. This is not exactly a tutorial, so if you’re looking for a copy & paste kind of solution, you’re not gonna find it here. If you have this problem, the solution will depend on your specific server configuration, so you may need to do some modifications to the examples of code I’m gonna provide here.
How to Remove Yoast’s Google Analytics Warning in Network Admin
First of all, I admit I may be missing something here, but this issue annoys me big time, and I’m sure some people will feel the same.
So, what’s the deal? Well, I’ve been using Google Analytics for WordPress for quite a lot of time now in many installations, some of which are multisites. I love this plugin and all its functionality, and I wouldn’t change it for another one in most of the sites I run. But every time I download and install it in a multisite environment, I keep seeing a notice which reads “Google Analytics is not active. You must select which Analytics Profile to track before it can work”.
Some of you may say “why don’t you just set your Analytics Profile and stop whining?”. Well, I’d wish it was that easy. And that’s because, for some of this multisite installations, the main site is just an internal hub that will be hidden from the public, and doesn’t need to have an analytics profile set up.
Make WordPress Stop Sending E-Mails When Working Locally
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.
How to Use Different Plugins for Local, Testing and Production Stages
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.
How to Automatically Activate Jetpack Modules
If you, the like me, use Jetpack cheap jerseys for Inspiration a lot of sites (for Iniciando example, in a multisite or some complex installations), you probably need to have some modules always active for all your sites. It would be awesome cheap jerseys online if you could just have those modules active cheap jerseys without having to do it manually once you have activated the plugin, right? Well, you 2011 can do it.