Page 246 of 428

Is There Room to Improve Error Logging in WordPress?

October 21, 2014 / Tom / 0 Comments

I think that one of the best ways to stay current with whatever tools, languages, etc. that you’re working with is to take a look and see what other communities are doing with their tools.

For what it’s worth, I also think that bringing experience from previous projects and/or jobs to new projects and/or jobs is important – you get a chance to continue doing all of the things that worked well, a chance to avoid the things that didn’t work, and a chance to discover a new set of things that work and things that don’t.

One of the more popular tools to come out as of late is Docker. There are a lot of really cool things about it, and there are a lot of articles already being written about it. I recently read one that struck a chord with me and with WordPress-related development.

Especially this quote:

Logging is a critical part of running an application. It’s often undercooked because it’s been here for so long no one think about it anymore. But trust me, when things stop logging, admins start crying.

Is Docker Ready For Production?

Yes, it’s a good read for anyone who likes to see how other developers are doing their thing in another area of the industry and there’s a number of points made that I think many people who have been working in software for a number of years can identify with, but I couldn’t help but ask myself if I’m doing (or we’re doing) enough logging in the WordPress projects I’m (or we’re) deploying.

Formance for Client Side Form Validation

October 20, 2014 / Tom / 0 Comments

Arguably, one of the most tedious tasks that comes with building pages – or just parts of pages – is form validation. And by that, I mean handling all information that users provide in a given form and making sure that it’s in the proper format and safe to write to a data store.

For the most part, we don’t build forms that freely accept any type of information. We’re usually looking for names, dates, addresses, phone numbers, and so on. Sometimes, we’re looking for more, like payment information, in the case of building an eCommerce site.

At this point, there are validation libraries in the majority of common programming languages. This means it’s pretty easy to hook up a library to our work, pipe the information through it, and then report any errors before actually submitting any information.

But in the context of web applications, good validation is usually two-fold:

Client-side form validation
Server-side form validation

WordPress and The Single Responsibility Principle

October 17, 2014 / Tom / 0 Comments

I love the fact that people are working to bring more advanced object-oriented programming techniques to WordPress-related development.

That is, I’m really glad to see others are pushing for people to write more truly object-oriented code rather than using classes as a “poor man’s namespace” (ht to Franz for that nickname), or doing things like setting up hooks outside of a constructor.

he had more than one responsibility.

To be fair, I’m as guilty as the next for not always writing very good object-oriented code in the context of WordPress (though I’m slowly working to change that – hopefully the Plugin Boilerplate is proof-positive of that), and I think it’s something that we should all be striving to get better at doing.

Programmatically Deactivate WordPress Widgets

October 16, 2014 / Tom / 0 Comments

If you’re in the business of building themes for fun, for clients, or for purchase within a marketplace or your own store, then there’s a chance that there’s some type of functionality that’s unique to your theme that should be activated whenever the theme is activated.

In my experience, this is something that’s typically unique to niché WordPress themes because they tend to have specific features, customizations, and so on that are relevant to their theme.

Case in point: Let’s say that you’re working on a niché theme that has a number of widgetized areas, but also has very specific widgets for said areas. That is, upon theme activation, you want to make sure that each widgetized area is clear so not to bust up the layout.

In other words, you need to programmatically deactivate WordPress widgets whenever the theme is activated so that the layout of the theme looks as it should when the user activates it.

“When Should I Use Ajax?” and Other Mysteries of the Web

October 15, 2014 / Tom / 0 Comments

A few months ago, I published a post that covered how to achieve single page tabbed navigation in WordPress. In the post, I mentioned the following:

In some cases, it may be best to load pages via Ajax, in some cases, it’s better to load things up all in the first page load.

Generally speaking, I stand by this statement. I know Ajax is fun and I know that it’s gotten incredibly easy to implement, but there are times where it makes sense to load all information with the page and times when said loading should be done asynchronously.

In the comments, someone asked:

I am also very interested and awaiting post regarding your take on when to use ajax and when to load it all.

Though this could have been answered in the comments, it seems as if this is an ongoing discussion among those who build things for the web, so I thought I’d take the time to answer it in the form of a post. If nothing else, perhaps it will spark you to share some of your opinions on it, as well.

Tom McFarlin

Is There Room to Improve Error Logging in WordPress?

Formance for Client Side Form Validation

WordPress and The Single Responsibility Principle

Programmatically Deactivate WordPress Widgets

“When Should I Use Ajax?” and Other Mysteries of the Web