Author: Tom (Page 196 of 430)

Using Sucuri Antivirus for WordPress

October 19, 2015 / Tom / 0 Comments

A couple of weeks ago, I talked about how there’s no such thing as the perfect WordPress host. In the end, it comes down to the requirements of your project that will dictate what host is best for your project.

But what happens when you find yourself placed in this dilemma:

There’s a host that you want to use because of some of the features, but it doesn’t fit the bill for the rest of the project.

Case in point: One of the things that’s popular right now is to have software such as a malware or a virus scanner. And who would fault anyone for wanting that?

I’m a fan of it and it’s something I recommend to most anyone running a web application. In my mind, anything that saves user input of any type should have something like this.

That said, one of the hosts that I often recommend does not have this built-in. So I’ve opted to go with Sucuri Antivirus.

Sucuri Antivirus

I’m a big fan of the service.

jQuery Raty For Star Ratings

October 16, 2015 / Tom / 0 Comments

I recently wrote about developer maturity. Specifically, I said we should not be afraid to use third-party solutions when possible.

This doesn’t mean we should piecemeal every project together. That isn’t development. That’s implementation (but that’s another post).

Anyway, Andy and I just finished up a project which demonstrates this point quite well. Part of the project called for providing a rating of certain criteria.

As such, we used jQuery Raty for laying the foundation of the rating system.

Keeping Separate Files for Ajax in WordPress

October 15, 2015 / Tom / 0 Comments

When working with Ajax in WordPress, the general setup is pretty straightforward:

Register the `ajaxurl`, if needed
Define the hooks (or the callbacks) on the server-side
Register and Enqueue the JavaScript files
Have your JavaScript file(s) call to the defined server-side hooks
Update the front-end as necessary

And the front-end may refer to the Dashboard, the public-facing part of the blog, or the both. It depends on the nature of what you’re working on.

If you’ve worked with Ajax in WordPress in-depth for any amount of time, then you’re likely familiar with the above process. You’re also familiar with the challenges of maintenance depending on how the code was setup.

If you’re just getting started, then perhaps this post will help shortcut some of the learning the rest of us have had to do.

I don’t think the Ajax APIs are that bad. I know – this is subjective. But from the a maintenance standpoint I believe that there’s at least one thing we can do to make development and maintenance easier.

Using Terminal in Coda 2

October 14, 2015 / Tom / 0 Comments

Most developers in the WordPress space have their favorite IDE of choice. Ask around and you’re likely to hear people share their favorite editors being:

And these are all great options. For what it’s worth, I dig the fact that we have choices when it comes to the tools with which we work.

But I’ve been a fan of Coda ever since I moved to Mac. This doesn’t mean it’s not without its shortcomings. For example, I use a third-party application to do debugging but it’s not that big of a deal.

Terminal in Coda 2

Anyway, one of the things that I’ve noticed with people who opt to use Coda don’t use it to its fullest extent. That is, there are a lot of features I see other developers opt not to use (like the database front-end).

I don’t know if it’s because they don’t know it exists or because old habits die hard. Either way, another example that I rarely see is the terminal in Coda 2.

Showing Poor Source Code

October 13, 2015 / Tom / 0 Comments

The act of showing poor source code either via our blogs or our open repositories can be a scary thing. I mean, we’re putting out for others to read and critique that we’ve worked hard to complete.

Sometimes we do it thinking that we’re on the right track; sometimes we do it when we’re asking for it.

Writing

In the latter case, I’d say that it’s not so scary – we’re asking for critique. In the former, isn’t it a bit more challenging when we get that criticism?

That is, isn’t it harder to deal with the criticism that comes on to something we thought we were doing right?

Of course. Does that mean we should stop sharing our code? No way.