While Twenty Twelve has been an anticipated feature of the upcoming WordPress 3.4 release, some will be disappointed to hear that the new default theme for this year will not ship with WordPress 3.4. Instead, it will likely come with WordPress 3.5. However, if you’re interested in playing around with the theme as is, you can download the source via GitHub. While no direct reasoning was given as to why the theme was punted, I’m going to guess that because 3.4 development is already behind, it made sense to postpone it to speed up the development of everything else going into 3.4.
By Jeffro on March 21, 2012
By Jeffro on December 27, 2011
Intriguing interview conducted by Gihyo.jp which is a Japanese focused developer resource site.
As your experience straddles both, where do you think open source excels? And where is it weak?
The open source model is probably best in the world at bringing together hundreds of people, from casual passersby to those who are deeply involved, to make constant, incremental improvement to core software. For projects with a clear goal―like the Linux kernel or Wikipedia―having an efficient method for people to contribute outstrips anything any proprietary company could do. The weaknesses are that it’s harder to make radical changes and do design. And those two are very much related. Open source is best at incremental improvements of things you already do, as well as responding to user requests. But with open source, it’s a lot harder to move the community to do something that users have never imagined they want. The problem is not impossible to overcome. But it means that whoever is leading the change must lay out the case as a compelling direction for the future―and to do it before a single line of code is written.
I can imagine those who have witnessed the development of WordPress for at least the past two years may take exception to the last sentence in that quote. In my opinion, that is not how most WordPress development works. I might as well cite the classic example known as the Capital_P Dangit function. The so called compelling direction was laid out after the change was added to WordPress 3.0. The change occurred without a trac ticket attached to it which further illustrates the point that sometimes, the compelling case to add something to WordPress never happens before one line of code is written.
While I’d definitely like to see dialogue occur between users and developers on certain proposed features before one line of code is written, it’s often been said to me that we’ll end up talking in circles with no lines of code ever being written. It’s easier to talk than code. So where does the balance come into play? WordPress history shows us that plugins appear to be the balance makers. Additions or reverts to core are often remedied by someone releasing a plugin, after the fact. This is the road WordPress development has chosen to go down more often than not. It’s definitely annoying at times but I’m happy to see that WordPress has such a large user base that someone, somewhere, will most likely develop a plugin to right the wrongs of WordPress. Those wrongs are considered from a per user basis as even I realize WordPress can’t hit the sweet spots for all users.
In the life of WordPress, there are both good and bad milestones. One year later, I still consider the addition of the Capital P function as a big mistake that will go down in my history book as a bad milestone. I chose to use this example as it best reflects the complete opposite of Matt’s response to the original question. I’m hoping that things change and that at some point, what Matt says becomes the norm for how WordPress development works, not the other way around. We need to see more events like this complete with published results and open discussion about those results.
By Jeffro on November 16, 2010
Andrew Nacin who many in the WordPress community know as a house hold name by now has published a retrospective post into his first year heavily involved with WordPress development since his first patch was submitted. One of the most encouraging lines within hist post is the following:
I’ve learned what it means to have an opinion without having a personal agenda.
Not only does Andrew tell us what it’s been like for him to be a part of the WordPress development community the past twelve months, but we also find out that he is writing the core contributor handbook which may be ready by the end of this year. Also for those that don’t know, Andrew Nacin is the technical editor of the new book, Professional WordPress Plugin Development which I talked about with Brad Williams during episode 105 of WordPress Weekly. Andrew is one of those people who constantly makes me wonder, how does he do that? Personally, I think he has some robotic DNA within him but who knows.
The bottom line is, thanks to his incredible amount of time devoted to the project, WordPress is better because of it, minus the capital P dangit filter. From me to you, thank you Andrew for your commitment to the project and helping my install of WordPress to perform better.
By Jeffro on June 27, 2010
In this episode of WordPress Weekly, I interviewed WordPress core developer, Andrew Nacin. Andrew joined the core committ team in February of 2010 and since then, he’s been an insanely active contributor all over the WordPress project whether it be through code, the forums, mailing lists, etc. During our conversation, we talked about Andrews life before WordPress, how he became a developer, how he’s able to be so active within the community, his Google Summer of Code project that deals with a theme revision system, and near the end of the show, we talked about some of the ways to contribute to the WordPress project.
This episode of WordPress weekly is brought to you by, BackupBuddy. BackupBuddy is an awesome plugin by the guys at PluginBuddy.com. You can configure BackupBuddy to perform automatic database backups of your site on a daily, weekly, or monthly schedule and when the backup process is complete, BackupBuddy will notify you via email. However, one of the killer features of this plugin is its easy migration tool. It’s the plugin I use to backup WPTavern on a daily basis. (P.S.) Speaking of BackupBuddy, they just announced support for Amazon S3.
Next Episode: Saturday, July 3rd 2P.M. EST
Subscribe To WPWeekly Via Itunes: Click here to subscribe
Length Of Episode: 1 hour 11 Minutes
Download The Show: WordPressWeeklyEpisode103.mp3
Listen To Episode #103:
By Jeffro on May 28, 2010
One of the more inspiring posts to read within the past two weeks. Glenn Ansley whom I met at WordCamp Raleigh and is the man behind Full Throttle development told his story on how contributing to the core of WordPress has stepped up his game overall as a developer.
Its funny how you think you know ‘who’ a community is because you’re following a couple mailing lists or a couple of opinionated talkers on Twitter. Getting plugged into the development process has opened me up to a whole new world of very intelligent individuals that I continue to learn from by listening in on their conversations. My coding has become more efficient due to the little tidbits of information I skim off of their public discussions every day.
His story is well worth the read, especially for aspiring developers looking to contribute back in the form of a patch. But the biggest lesson overall is that because Glenn made the effort to familiarize himself with the entire process of how the inner circle of WordPress development works, he has turned himself into a more efficient developer overall.
By Jeffro on April 7, 2010
Marshall who goes by the user name MrMaz in the BuddyPress community has been appointed the newest member of the BuddyPress core team. Marshall will be focusing on the BuddyPress API which will make the lives of developers easier to seamlessly integrate their plugins into BuddyPress. His work will be slated for release in 1.4 and onward. Marshall has a successful BuddyPress plugin called BuddyPress Links which adds rich media sharing. How this plugin integrates into BuddyPress as if it’s a part of the core was a sure sign that Marshall knows what he’s doing and was one of the major reasons why he was asked to join the team.
Congrats to Marshall.
By Jeffro on January 12, 2010
Although I’ve thought about this issue endlessly, including most of the issues raised here, there are some things brought up in the comments that I haven’t thought about before. More importantly, you could be right.
That’s why we’re doing this whole thing as an experiment; not the Large Hadron Collider type that could potentially destroy the universe, but more incrementally with just three initial plugins.
Now if in the course of working on these three plugins it looks like we’re going to cause the end of WordPress as we know it, we’ll change course. It’s not that big a deal, and we’ll figure something else out. The only dangerous course of action is doing nothing at all.
That Matt guy. Always showing up in interesting conversations related to something dealing with WordPress with a calm, cool head. How does he do that? It must help when you know for sure what is going on. His comment is the first I’ve heard of Core Plugins being an experiment. It’s also the first time I’ve heard someone clearly spell out three different types of core plugins that will be part of the experiment. An abandoned plugin, a newly created plugin, and functionality taken out of WordPress and put into a plugin.
So far, the discussions surrounding core plugins have been as if everything is set in stone. We now know that is not the case. There is no guarantee that core plugins are going last or if they will prosper. The way Matt presents how core plugins are going to be used brings me back to a calmer state and I think we should watch the experiment take place and see what happens.
By Jeffro on December 18, 2009
For the past year or so, we’ve all been hearing this term ‘canonical plugin‘ at numerous WordCamps and in interviews Matt has conducted. I’ve struggled with understanding what this term means in relation to the WordPress ecosystem and how plugins are developed but after months of hearing Matt talk about the idea and of course, reading the recent post on the dev blog that goes into more detail, I think I get it.
The idea is to make it as easy as possible to enable people to collaborate with plugin authors. Instead of everyone going their own seperate ways, bring resources and people together to focus on a common goal, that being the canonical plugin. These plugins would be under the wings of the core development team to insure compatibility, good coding practices, and would probably excel at whatever functionality they were designed for.
Now for as long as I’ve used WordPress, the plugin ecosystem is like the free market. After awhile, end users spread the word and generally can determine plugins that are good for a specific purpose. For example, Contact Form 7 was a house hold name that I saw mentioned time and time again as an easy way to generate a contact form in WordPress. The wisdom of the crowds in this case was correct. I wonder though how the canonical system will affect the free market system the repository currently has or if nothing will happen. Do plugin developers really want to work together for the common good or do they want to do their own thing without anyone looking over them?
I have no idea how this canonical plugin system will work or how it will evolve but the core development team of WordPress has discussed the issue at great lengths and I look forward to sitting back and watching to see what the vision turns into. One thing I really like about this canonical plugin idea is that it gives the team the option to yank out specific functionality in the core of WordPress and turn it into a group developed plugin. The example I continuously bring up are the Code editors in WordPress. Personally, I think these should be removed but a number of people find them useful. I think the editors should be replaced by a canonical plugin called CodePress. CodePress would then be a built in editor on steroids with line numbers, colorful syntax highlighter and something I’d love to see, revisions or versioning.
I have a bunch of questions regarding canonical plugins that I think will be addressed in the coming weeks. First, how does a plugin become canonical? How does that plugin become non canonical? How will this system work?
As for the name, I’ve decided to stick with Canonical. Core this or core that is just ripe for confusion. I get the idea behind the relationship of these plugins with the core of WordPress but I still think this name would be bad in the long run. In the poll, I voted for Other and then left the space blank. Too bad Canonical is also big in the Ubuntu community so confusion could arise from that term as well.
I’m hoping that the canonical stuff takes off as the entire team hopes and believes it will. There is also a thread dedicated to the topic of Canonical plugins that you can find here.
By Jeffro on October 30, 2009
There is some great news for those involved with or following the BuddyPress project. Andy Peatling announced today on the development blog that John James Jacoby aka jjj has been added to the BuddyPress core development team which brings the total to two members. Anytime I’ve done a show about BuddyPress or needed to ask a question or two in the BuddyPress IRC channel, John has been around to listen or try to push me in the right direction. Congrats to him for being added to the core team for one heck of a project. This is a huge step forward allowing Andy to remove some of the development weight off his shoulders.