Tag: WordPress (Page 110 of 219)

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

Where Do You Find Quality WordPress Support?

January 13, 2016 / Tom / 0 Comments

Last week, I asked: “Should WordPress product support be in-house?” And the short version of the conclusion to which I came is simple: Yes. It should be. This still leaves a question about how to handle general WordPress support, though.

Specifically, the problem is when something goes wrong with your product, the general end user doesn’t know if it was your work, the theme, WordPress, or the environment on which all of the software is running.

And if your product is the last thing the user installed, then you’re likely going to be the first person contacted. So let’s say you are running a theme or plugin or WordPress product shop, and your customer has a problem, but it’s not related to the work you’ve done.

In other words, though you do (and arguably should) offer in-house product support, the problem isn’t related to your product at all.

What then?

WordPress and Data Ownership, Social Networks and Privacy

January 12, 2016 / Tom / 0 Comments

I try to be pretty open-minded about most things. That is, I try not to be legalistic or dogmatic about any particular idea. If something comes along that contradicts something I hold true or near and dear, I’m willing to evaluate the evidence and see if it reinforces or challenges what I believe.

Admittedly, there are people who are better at it than I am but I do my best.

But one thing I absolutely cannot get passed – and this is something becoming more and more prevalent the older I get and the more I work in software, specifically in open source – is the idea of data ownership.

And I believe there’s a direct result between what we’re able to do with WordPress and data ownership that can positively impact the type of solutions we release and we’ve yet to even realize we can build.

Should WordPress Product Support Be In-House?

January 8, 2016 / Tom / 0 Comments

When asked if product support is done in-house by the company who built the product, the easy answer appears to be yes, doesn’t it? I mean, why would you have it any other way?

More specifically, why would you have someone who doesn’t work for your company handle support for something you (or you and your team) built?

Sure, there are loopholes – a phrase I use loosely in this post – for this like hiring someone to work for your company who can be a dedicated resource to handling support of the product when they aren’t as familiar with the product.

But when that happens, I think the lack of experience shows when you start to get into slightly more complicated issues.

The Advantages of Creating an Interface

January 7, 2016 / Tom / 0 Comments

In web development, I think many who here the term “interface” or who talk about “creating an interface” usually refer to how the page, site, or graphics will look.

And that’s completely normal because when the majority of outlets – presentations, news, articles, media, etc. – talk about the way something looks as it relates to technology, they always talk about its interface.

Not to mention, it is the correct term.

But when it comes to object-oriented programming, the idea of creating an interface is a bit different. Rather than referring to the way a program looks, you could say that it has more to do with how it functions.

Even that isn’t necessarily the proper definition, but it’s close enough. If you’re an experienced programmer, then you’re likely already familiar with this idea.

But if you’re someone who’s just getting into object-oriented programming (specifically using PHP in the context of WordPress), then maybe this will help when designing the architecture of your next project.

Don’t Over-Engineer Your Project

January 6, 2016 / Tom / 0 Comments

Over the last few days, I’ve been building the site that’s going to power the membership aspects of the WordPress Development course I’m working on. Initially, I went into the project like any other developer: I was ready to sit down, start writing code, handle a bunch of configuration, and generally tweak my WordPress installation at a level that I was convinced would take me a long time.

But it wasn’t like that at all.

And that’s something I know developers are plagued with more often than they – or we – would like to admit:

We over-engineer our solutions all of the time.

It doesn’t have to be like that, though. It takes a slightly different approach and it requires that we fight our natural inclinations, but it can be done.

It just requires a more pragmatic approach.