Tag: WordPress (Page 179 of 219)

Articles, tips, and resources for WordPress-based development.

WordPress: Fatal Error Memory Exhausted

September 25, 2013 / Tom / 0 Comments

At some point, anyone building a theme, plugin, or even just working with WordPress has seen the Fatal Error: Memory Exhausted message. It typically reads something like this:

Fatal error: Allowed memory size is 268435456 bytes exhausted (tried to allocated 29596635 bytes) in …/wp-includes/wp-db.php on line 885.

Yes, your message may be a little different, but the point is the same: You see a fatal error, it has something to do with the amount of memory allowed, how much was attempted to be allocated, and what file threw the error.

In my opinion, one of the big problems with errors like this is that it’s far too easy to Google for a quick solution to fix the problem rather than truly understand the problem.

Sure, I understand we’ve got stuff to do and work to get done, but understanding what the problem may be is important to helping us become better developers, and, who knows, we may uncover a bug in a piece of open source software.

In this case, it’s not the latter, but here’s a good way to go about understanding the above error.

WordPress Theme Updates and Semantic Versioning

September 19, 2013 / Tom / 0 Comments

Maybe I’m more observant than I used to be, or maybe there is a trend that’s actually happening, but one thing that I’ve noticed is that more and more WordPress developers are beginning to take interest in semantic versioning.

In short (and straight from the website), semantic versioning works like this:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,

MINOR version when you add functionality in a backwards-compatible manner, and

PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Easy enough to remember, right?

One of the things that sticks out, however, is that certain parts are meant to be updated and changed when there are “incompatible API changes”, when there are backwards-compatibility changes, and when there re bug fixes (and, in which I include, hot fixes).

This clearly makes sense in the context of a larger application such as, you know, WordPress itself, but Themes?

Let’s be honest: most WordPress Theme Updates don’t necessary fall under these same changes because they don’t have an API. Even more so, it raises the question of what would be considered a backwards-compatible change?

Or do they?

The more I’ve given this some thought, the more I think semantic versioning works just fine for WordPress theme updates, and it’s something that I’d love to see continued to be implemented.

The WordPress Theme Customizer: When Live Preview Doesn’t Work

September 18, 2013 / Tom / 0 Comments

I’m currently working on a lengthy set of articles that are intended to provide an in-depth look at the WordPress Theme Customizer. Yes, there has been a lot of material already written on this subject.

Some of the best articles are:

Otto’s guide to the WordPress Theme Customizer
The comprehensive Codex article on the Theme Customization API
And an open source example of how to use the Theme Customizer

And though I’ve done work with the Theme Customizer in the past, there have been a few gotchas that I’ve found when trying to work with the customer starting from the ground up.

I don’t plan to document them all here, but if you happen to be working with the Theme Customizer and you’re specifically trying to get the “Live Preview” function working and it’s not, perhaps this will help.

Sending Data on POST with WordPress

September 11, 2013 / Tom / 0 Comments

The title of this particular article is somewhat misleading as it has nothing to do with sending an email upon creating a new post in WordPress, but actually whenever the HTTP `POST` action has occurred.

Additionally, the methodology describing below isn’t relegated to just sending emails – it can be used when any data needs to be managed upon a `POST` request. This includes sending emails, serializing data to the database, evaluating information to be presented on the next page view, or whatever else.

Of course, one of the best ways to actually demonstrate how to do something is to give some practical example, so for all intents and possible, I’m going to show how to structure a project using the event-driven model of WordPress to send an email upon a `POST` request.

Using WordPress Simple Settings For The Settings API

September 4, 2013 / Tom / 0 Comments

Though I still this project may be useful for some, I've updated my personal opinions on this.

When it comes to working with WordPress, it’s no secret that I’m a fan of using the WordPress APIs as much as possible, and not circumventing the built-in functionality with vanilla PHP.

Arguably, one of the most complicated APIs to work with is the WordPress Settings API. It’s unintuitive, requires some small details to manage, and also requires a bit of repetitive code.

For many developers, the unintuitive nature and the way in which sections, settings, and options are built begs for a cleaner interface. And if you’re one of those developers, then you should check out Clif Griffin’s WordPress Simple Settings project.