Tag: WordPress (Page 137 of 220)

For some time now, I’ve been a big fan of using WordPress for web application development, but I think that developers actually embracing the CMS (let alone seeing the CMS) as a foundation for something like that is still a couple of years off.

Sure, we’re going to see some people using it for things like that. I mean, we’re already seeing some out-of-the-box applications like AppPresser, but projects like that are the exceptio, not the rule. In my own experience, I’ve found that clients are very interested in using WordPress, but using it for more application-like capabilities.

This doesn’t mean that gigs for themes, plugins, and what not are slowing down, but that people are wanting web applications for themselves or their companies, but want to be able to administer it using the WordPress dashboard or using a some custom front-end work.

But that’s beside the point.

What I’m getting at is that as developers, designers, and other people end up seeing WordPress as potential foundation for web application development, the more innovative things we’re going to see entering the space.

Continue reading

Yesterday, I came across a comment that was in the context of a larger post that I think does an excellent job of highlighting what we – as theme developers – should be doing with our projects rather than what we’re currently doing.

For those who know @Rarst, this wisdom will come as no surprise, but for those of you who are new to theme development, or WordPress development of any kind, then I think you’ll find this insightful:

We can chuckle and point fingers at bundled plugin monstrosities. But the reason those monstrosities exist include WordPress strategically for years disregarding need for third party infrastructure and dependency management. It’s telling that it has been priority so low, that even backwards compatibility was broken on related parts of core without a second thought.

So how does this translate, exactly? That is, what is it that we’re doing or that we can do in order to make theme development, plugin development, or both much stronger, resilient, and generally better than what we’re doing now?

Continue reading

Because WordPress is built using a number of languages none of which are compiled, it makes it completely possible to make things happen within your theme, plugin, or extension by circumventing the native APIs.

This means that if you wanted to, say, introduce some type of element on one of the dashboard screens or you wanted to introduce functionality into one of your templates that didn’t previously exist, there’s a strong chance that you’d be able to do so simply by “brute force.”

And by that, I mean that you’d be able to make something happen – and probably work correctly – without using the native set of APIs that are available.

But when you’re faced with that situation, I highly recommend taking a step back and determining if you’re approaching the problem in the best way possible given your set of constraints.

Continue reading

Obviously, I can only speak for as much of the culture that I’ve experienced both online and offline so I don’t mean this to be an overly general statement, but I think it’s fair we live in a highly polarized culture – if not offline, and if not in the west, then certainly online.

That is, we have no problem telling one another if their policy, their ideas, their implementations, or whatever sucks, or if it’s terrific. Unfortunately, it seems to be much more of the former than the latter.

I tend to be more on the pessimistic side – I know, probably not the most flattering personality trait, but I try to fight it :) – so I don’t know if it’s getting better, but I can definitively say that over the past few days, I’ve personally experienced some criticism – all constructive – that’s respectful and that has generated a lot of food for thought.

Continue reading