Author: Tom (Page 145 of 428)

Using Package tags in WordPress (that is, the @package tag that you see in code comments) is one aspect of plugin development that I call into question. And it’s not because of others who have written any given plugin; it’s coming from my experience (or lack thereof).

When I first got into writing WordPress plugins, I wasn’t using features like namespaces mainly because of the mixed messages I’d received regarding PHP versions, support for them, and so on.

So I did the next best thing and used the @package tag as defined in the phpDocumentor manual and that I’d seen so many other plugins doing in their source code.

But I noticed a conflict: There is a disconnect between how plugins are using them and how the manual defines them.

Continue reading

WordPress Unit Tests naturally play a big part in making sure that new features introduced into core work as expected and that previous features do not break. And pushing forward with more test coverage is a Good Thing™.

In the last couple of plugins, I’ve released into the WordPress Plugin Repository, I’ve included unit tests with the plugin. Of course, these aren’t for the users benefit (why would they be?).

The way I see it if we’re working with open source, why not include these tests for those who may download, run, fork, test, or explore the code base?

But there’s a thing about these unit tests: They inherit from WP_UnitTestCase. And the more I work with creating plugins for fun, for profit, and for others, the more I think that unit tests we ship with our plugins don’t necessarily need to inherit from that class.

Instead, they should inherit from the standard set of classes provided by PHPUnit.

Continue reading

In the previous post, I shared a way to process all of the files in a given directory. Specifically, it covers how to read all of the files that have a particular naming convention.

There’s a second part, though:

What if you want to delete all files?

That is, let’s say you’ve processed all of the individual files, and then you want to delete all files that are in the directory from which you were reading them.

Continue reading

Let’s say you’re working on a WordPress file that has to import data from a very large file. To avoid PHP timeouts, it helps to separate the files and then import then in pieces (or in chunks, because that word is more fun :).

But to do that, it implies you’re capable of taking a file and splitting it into some smaller files.

When you do this, I assume that each smaller file will follow a particular naming convention (like file_0.txt, file_1.txt, and so on).

So when it comes time to read each file, how do you do it?

Continue reading

HTML data attributes are one of the neat features of HTML5 that give us a lot of flexibility.

We can use them for a variety of things (and abused for just as much), but the general idea behind the attribute, according to MDN, is this:

HTML5 is designed with extensibility in mind for data that should be associated with a particular element but need not have any defined meaning. data-* attributes allow us to store extra information on standard, semantic HTML elements without other hacks such as non-standard attributes, extra properties on DOM, or setUserData.

Yes, it reads a bit long. Consider it like this, though:

Data attributes provide a way to save extra information about an element in a semantic way without using conventional hacks (that so many of us are used to using).

Though there are a variety of ways in which this attribute can be used, I’ve found it to be useful when working with a front-end element that’s part of a dynamic set of larger elements.

Further, any one of these elements will be used via JavaScript to send data to the server via Ajax.

Here’s a simple example of how to use the HTML data attributes and Ajax.

Continue reading