Page 247 of 429

Display Post Meta Data Error Messages in WordPress

October 22, 2014 / Tom / 0 Comments

One of the things that’s nice bout working with post types – custom or standard – in WordPress is that it’s really easy to hook into the serialization process in order to handle the data. This means that we have the ability to sanitize, format, read, access, modify, verify, etc. all of the data with the post type and with the post type’s meta data before it’s written to the database.

WordPress has a pretty consistent way of displaying error messages throughout the application. Really, it’s pretty consistent in how it displays all types of messages – success, updates, and errors – throughout the system.

Let’s say that you’re working with a WordPress meta box, several of its fields are required, and you want to:

verify the input has been specified
either display an error message if it’s not specified
or write the data to the database if it checks out

The serialization process is pretty standard stuff, but if you’re looking to make sure required fields aren’t empty and that a error message is displayed whenever they’re not entered, then you’ll need to do some additional work.

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.

Tom McFarlin

Display Post Meta Data Error Messages in WordPress

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