Tag: WordPress (Page 178 of 219)

When it comes to building custom WordPress applications, plugins, or themes, one of the things that I’m a big proponent of doing is maintaining the native WordPress admin look and feel.

That is to say that I am not a fan of introducing option pages or other elements that deviate from the styles that WordPress core provides.

Case in point: Theme settings pages should match the same theme as the rest of the settings pages in WordPress. There shouldn’t be any major deviation in color scheme, font, or the way certain elements function. By that, I mean tabs should work without any fancy animation, and so on.

But there are times when modifying core user interface components that enhance the experience and that do deviate slightly from the core native WordPress core styling.

In those cases, is deviating from WordPress core acceptable?

Continue reading

In my previous post, I shared a few thoughts on how I think someone can become a better WordPress developer.

When it comes to talking with beginner – or intermediate – WordPress developers, one thing that I’ve noticed is that when you suggest the WordPress Codex as a resource, there’s beginning to be a somewhat-typical response that I’m beginning to hear:

Please don’t suggest the Codex.

Bummer, right?

Continue reading

Recently, I received an email from a fellow developer who had finished reading a number of series of articles on WordPress, who had watched a number of WordPress tutorial videos, and was working towards mastering WordPress.

He went on to discuss his current skill set, his aspirations, and the type of projects he eventually wanted to take on as his career progressed.

Not bad, right?

Here, you’ve got a person that knows who he is, knows where he wants to be, and is looking for advice on how to get there.

Unfortunately, there was only so much advice I could give (I’d love to master WordPress, as well!), but the bottom is line I responded with a series of things that i think he – or anyone – can do in order to become a better WordPress developer.

Continue reading

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.

Continue reading