·
Last month, I joined with several developers in explaining my reasoning behind working with open source software. Like many others, I am involved in open source projects because I enjoy working with the community. Last night, I only reinforced that. For some time, I’ve been hosting all of my various WordPress websites on a multisite
·
Earlier this week a member of the WordPress community, Jacob Santos, aired his concerns with WordPress’ decision making process on the oft distracting WP Hackers mailing list. His argument, in response to a WordPress.org forum thread regarding 2011 roadmaps, comes from the idea that WordPress development is not driven by community input. On the one
·
From time to time, the GPL comes up in less-than-friendly conversation regarding WordPress. Everyone has their own opinion of what the license means, and strings of “but I am not a lawyer” litter every discussion. This turns any lively discussion into a heated debate because “well this is what I think” quickly turns into “you’re
·
Open source is fantastic because you can build upon the code of others. It’s also horrible because you can build upon the code of others. This means someone can take a well-developed plug-in, make one or two minor changes, and redistribute an almost identical system to yours while taking all of the credit. So, as
·
This past week, several people related to the WordPress project have been discussing their motivations for working with free and open source software. There have people explaining the new business leads they get from being prominently listed as open source developers. There have been others lamenting the fact that free development is, by nature, free.
·
Those of you paying close attention probably noticed that I neglected to list a couple of the MetaWeblog API calls last week. That’s because they’re duplicated by calls in the “wp” namespace, and I want to keep everything you can call with a “native” WordPress method in one group. Luckily, none of the MovableType API
·
As odd as it may sound, WordPress’ XML-RPC system is built on others. This makes sense from a development standpoint – why reinvent the wheel when others have done such a great job? But it can be incredibly confusing and downright frustrating when you start working with the WordPress API and have to turn to
·
The most important thing to know about WordPress’ XML-RPC interface is how to send and receive data through it. The interface is turned off by default for security purposes, so when you’re ready to start using it, you’ll have to manually turn it on. Go to Settings » Writing and look for the XML-RPC option
·
I’ve seen a lot of conversations over the past two months regarding WordPress’ built-in XML-RPC functionality. What most of you might not know is that you can write to, read, and administer a WordPress site from anywhere. There are iPhone applications for creating and revising content. There are desktop applications for moderating comments. There are
·
Just to forewarn you, this might come across as a more technical post than I normally throw at you. Still, I did something exciting last night that I wanted to share and perhaps educate you about. I built a custom XML-RPC server. And with that statement I know I’ve already lost most of you. Rather