Tag: WordPress (Page 179 of 220)

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

The Importance of Timing WordPress Functions

October 8, 2013 / Tom / 0 Comments

After this post was published, Brady Vercher also reminded me of two WordPress-specific functions.

When it comes to working with the WordPress database – or any application that provides an API for data serialization – I try to always stick with the API unless it’s absolutely unavoidable.

For the most part, I tend to favor APIs that provides the necessary functions for reading and writing data, and I generally assume that they have everything built into them that they need in order to make data storage and retrieval as secure and as fast as possible (though I’ve been burned by this assumption before).

In some cases, this is true; in others, not so much.

Case in point: I’ve been working on a large intranet application for someone that’s built on top of WordPress. One component of the application requires the import of a relatively large set of data in CSV format that’s also piped through a third-party plugin.

Unfortunately, there was a bottleneck in the code that was causing timeouts on the remote server.

No matter how high you set PHP’s timeout settings, a third-party script monitor would always kill it first. I’m actually in favor of having these types of monitors running.
Long scripts create a terrible user experience so I wasn’t happy with the performance even when I was able to marginally improve it.
Isolating bottlenecks can be a tedious process, but can seriously pay off if you spend the time to do it.

When I finally located the bottleneck, it was occurring in the third-party plugin.

WP Gist For GitHub Gist in WordPress

October 3, 2013 / Tom / 0 Comments

When it comes to embedding source code into posts, I’ve been a fan of the SyntaxHighlighter plugin by Alex Mills for a long time – I’ve used it on every programming blog that I’ve maintained for as long as I can remember.

But ever since GitHub rolled out Gists, I’ve been using those to store frequently used functions, examples of code for posts or other articles, and snippets for which I’d like to have others come in introduce their changes, and/or their comments.

Straight from the Gist homepage:

Gist is a simple way to share snippets and pastes with others. All gists are Git repositories, so they are automatically versioned, forkable and usable from Git.

Easy enough, right?

Perhaps one of the cooler things about gists is that they can be embedded in WordPress posts; however, I’ve had mixed success with the native support in doing that.

But Michael Novotny’s WP Gist plugin makes it really easy to embed nice-looking, gist-specific code into a WordPress post.

WP Comment Notes (And What We Can Learn From It)

October 1, 2013 / Tom / 0 Comments

About a year and a half ago, I released the first version of Single Post Message for WordPress which is a simple plugin specifically for adding a notification at the top of the bottom of a given post.

For whatever it’s worth, it’s one of the plugins I’ve enjoyed creating the most not only because it scratched my own itch, but also because it’s an extremely lean, focused plugin that aims to solve exactly one problem.

The other day, Pippin William tweeted the following:

Good plugin idea for someone: add metabox to edit screen that allows notes to be entered and displayed just above comment form for that post

— Pippin Williamson (@pippinsplugins) September 28, 2013

To which Japh Thomson replied:

@pippinsplugins Sounds like a feature request for @tommcfarlin’s “Single Post Message” plugin: http://t.co/boCu7LdmSO

— Japh (@Japh) September 29, 2013

And to which Andrew Norcross built and responded with:

https://twitter.com/norcross/status/384463729578225664

You can read the entire conversation, but there are three things that I really dig about this particular exchange and the plugin that came out of it. But before discussing those, I think its worth checking out the WP Comment Notes plugin itself.

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.