Tag: WordPress (Page 161 of 220)

If you head over to the WordPress.org homepage and click on the About link, you’ll be taken to a page that, y’know, tells what WordPress.org is all about, what the software can be used for, some history, and so on.

Then, there are also links to various WordPress-related collateral such as logos and graphics, fan art, the GPL, the project roadmap, and the philosophy.

Wait, what? A philosophy?

Exactly. WordPress – a piece of software – has a philosophy. It’s a really, really neat page that I think everyone who is involved with WordPress – be it designers, developers, or users – should read. It’s not technical, it’s easy to understand, and it helps inform us what the software is all about.

As far as developers are concerned, there are a number of things in the philosophy that I believe we give excellent lip service, but we don’t actually practice, abide, or behave in such a way that we support the philosophy.

That’s a longer post for another time.

Anyway, though there’s a number of things in the philosophy that could be discussed (and probably ultimately will be :), one of the many things that we’ve forsaken is the “out of the box” philosophy.

Continue reading

For those developers who are coming to WordPress from other platforms such as .NET or other major database driven system where they are responsible for devising their own database schema, one of the problems that’s often seen in the WordPress-world is this desire to create sets of tables that may or may not interface with the existing WordPress tables.

Just as it takes time to learn the WordPress event-driven paradigm from, say, Model-View-Controller, or something else, it takes time to make sure you fully grok the stack on which you’re working.

And starting at the foundation of WordPress is the underlying database schema.

Continue reading

This past weekend, notable, highly respectable [and former] Automattician Philip Arthur Moore wrote a fantastic article that’s been making it’s way through the usual suspects and circles entitled We’re Ruining WordPress (This Needs To Stop). 

But in the hopes that some of those of you who read this blog are fellow bloggers, publishers, readers, designers, developers, and so on, I wanted to link it here with you to make sure you didn’t miss it and because I hope it resonates with you.

In short: If you’ve yet to read it, I highly recommend it – it short, poignant, and will likely strike a chord with many of you who are looking to contribute to the WordPress economy, have a business within the WordPress economy, or who enjoy following the WordPress economy.

Many of the things that Philip outlines in his post is what we’ve seen happen in other economies, too: Just look at Google Play or the App Store and how little apps cost. Games that used to run us $30 – $50 on a given system now cost $4.99 to $9.99 and people still complain (and it’s not even worth talking about in-app purchases).

Anyway, as much as I enjoy writing about WordPress and the various facets that come with it, and as much as I enjoy doing so with the occasional meme and what not, this particular post hit home with me because I’ve been working in the WordPress economy for several years at this point, I’m getting ready to push forward with a new effort, and because I’ve been thinking about this for the last few months (and clearly more so over the last few days), I thought I’d write a WordPress theme developer introspective of sorts on how it feels to be a part of the WordPress theme developer economy, its challenges, what I want to see change, and what I plan to begin doing as soon as possible.

Continue reading

Before Google practically destroyed the word ‘beta,’ people used to go about getting feedback on their work through closed testing, tight feedback loops, and other forms of getting work in front of others in a closed group of people to see how a sample of users would interact (or just simply react).

Movie production companies still do this – they test audiences: They see how they react to certain actors, certain endings, certain takes, and all that fun stuff.

In software, we still do that, but we throw words around like alpha and beta to the point where they have no real meaning anymore. At one point in the life of projects, alpha testing was solely for an internal group of testers, then beta testing was when it was open to a small group of people in the public in order to gather more feedback and to shake out bugs. Then there were release candidates followed by the final version (or the 1.0).

After that, we rinsed, and we repeated it.

Now, far more people have access to alpha-level software, and projects usually remain in beta as a way to excuse any problems that may occur during the course of using the application. After all, it is beta, so it’s use at your own risk, right?

Anyway, I could say a lot more on this, but I digress.

Continue reading