Author: Tom (Page 147 of 430)

WordPress requests (that is, page requests) are something that can become a bit of a hot topic for those who are concerned about the performance of web applications.

Case in point: Last week, I was having a conversation with a friend who, at one time, was doing a lot of work with WordPress and has since moved into another industry of web application development.

During the conversation, he made the following comment:

And the fact that it doesn’t min / cat files instead of [25] network requests is just plain dumb. And when a person has 23 plugins, that’s 26 files not even including the theme and core.

I adjusted the number above to reflect how this particular site performs with my current theme and my [admittedly small] set of plugins.

25 Wordress requests for all resources for this site alone (along with a JavaScript error).

And though the comment is meant to be humorous and a bit facetious, I don’t think it’s worth dismissing.

In fact, I believe that it’s something worth considering even if we’re simply building things on top of WordPress (versus working on WordPress core).

Continue reading

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