Advanced Feeds in WordPress 18 Oct 2005

WordPress has the capabilities to produce RSS feeds for any website it powers. Just head over to any WordPress blog (try this one!), and append /feed to the URL to get a nice RSS2 feed. (You could also try /feed/atom for an Atom 0.3 feed, or /feed/rss for a RSS 0.92 feed.) But you probably knew that already. But did you know WordPress has the capabilities to produce feeds for any archive page you can find? It’s an incredibly useful feature that few people take advantage of.

Let me give you a few examples. I read Ryan’s blog. He posts a lot of good stuff but normally I’m only interested when he’s talking about WordPress. No problem, I find the archive page for his WordPress category, append /feed to the URL and off I go: there’s an RSS feed containing just the posts in Ryan’s WordPress category.

Now, lets say I read a multi-author blog like Jalenack. Now, for some reason, I’m only interested in reading posts by Andrew. Right, so appending /feed to the archive page for Andrew’s posts will give me a feed of exactly what I want.

Finally, a mention about comment feeds. These are normally linked to, but appending /feed to a permalink gives you a feed for the comments on that post. Try using the comment feeds next time you want to keep up with a discussion.

Incidentally, this would also work for day, month and year archives. However, this is likely to be less helpful as feeds are normally used for seeing when content is updated. I can see however that if you’re building some software that could use the post detail in an easily parseable format, try using the RSS feeds for that archive page.

WordPress’ feeds can be extremely powerful. Try using the more advanced features to target what exactly comes through your feed reader.

How to get involved with WordPress development 18 Sep 2005

I’ve been an active member of the WordPress community for a while now, but have only recently found a meaningful way to contribute. So, I thought I’d aggregate a few tips on how to get involved with developing the WordPress core. So, here you go, in handy 10-numbered-steps format:

1. Before you do anything else, get yourself a WordPress weblog. A wordpress.com one is okay, but I’d say get your own web space. That way, you can actually open up, poke at and hack the code that’s running your blog. That will be essential.
2. Blog. Get familiar with the concepts and terminology that pertains to blogging.
3. Subscribe to the blogs of a few key players in the WordPress community. I’d recommend reading both Ryan’s and Matt’s wordpress.com blogs to keep up to date with cool things that are happening in the community and with the code.
4. Subscribe to wp-hackers. This is the list where all discussion on WordPress development and direction takes place. If you want to partake in discussions which will be key to WordPress’s future, post to or at least lurk on wp-hackers. It will give you a key understanding of the design goals.
5. Hang out in #wordpress on freenode. A whole bunch of experienced WordPress people hang out there.
6. Make a special effort to get along to the weekly IRC meetups. They happen at 9pm GMT every wednesday in #wordpress-meetup, again on Freenode. These are the best places to catch up on the very latest WordPress information. Matt always makes these meetings, Ryan most of the time as well. If you don’t manage to to make it to the meetings themselves, Codex has logs.
7. Get familiar with the codebase. Check out a copy of the WordPress trunk from the subversion repository, and play with it. Read some development articles on Codex and get familiar with what goes where, when and depending on what.
8. Answer support questions from the forums and/or #wordpress. This will get you looking at code that you yourself don’t use, like (say) blog-by-email, the XMLRPC interface, the user structure and so on.
9. Bookmark Trac. Trac is WordPress development central. Read the timeline for up to date information on commits.
10. Bugs on trac: write patches for bugs that need it, or offer your views on the bugs that need a second opinion. Find your own bugs (these don’t necessarily have to be actual bugs, they could be feature requests or ways things could be done better), and write patches for them. Be sure to give your bugs a keyword of bg|has-patch. Patches are the best way to get your code committed into the core.

At the end of that, you should be pretty involved with the community itself and will hopefully be writing high quality code that makes it into the core. Anyone else got any ideas or suggestions for those looking to get involved?