apt-get install debian-wizard

Insider infos, master your Debian/Ubuntu distribution

  • About
    • About this blog
    • About me
    • My free software history
  • Support my work
  • Get the newsletter
  • More stuff
    • Support Debian Contributors
    • Other sites
      • My company
      • French Blog about Free Software
      • Personal Website (French)
  • Mastering Debian
  • Contributing 101
  • Packaging Tutorials
You are here: Home / Archives for Random

How to create custom RSS feeds with WordPress

January 7, 2011 by Raphaël Hertzog

WordPress has many alternate built-in feeds: per category, per tag, per author, per search-keyword. But in some cases, you want feeds built with some more advanced logic. Let’s look at the available options.

WordPress advanced built-in feeds

You can create feeds for “unions” or “intersections” of tags, you just have to use a URL like /tag/foo,bar/feed/ (all articles tagged with foo or bar) or /tag/foo+bar/feed/ (all articles tagged with foo and bar).

You can also have feeds excluding a category, although that requires you to know the category identifier (and hardcode it in the URL like this: /?feed=rss2&cat=-123 where 123 is the category id that you want to exclude).

But there’s no simple way to have a feed that excludes articles with a given tag. The best solution found involves creating a custom feed. I’ll show you a variation of this below.

Creating a custom feed

  1. First of, install the Feed Wrangler plugin, it will take care of registering our custom feeds with wordpress.
  2. Go to “Settings > Feed Wrangler” in your WordPress administrative interface and create a new feed, let’s call it “myfeed”.
  3. You should now create a “feed-myfeed.php” file and put it in your current theme’s directory. The initial content of that file should be this:
    <?php
    include('wp-includes/feed-rss2.php');
    ?>

    <?php include('wp-includes/feed-rss2.php'); ?>

  4. At this point, you already have a new feed that you can access at /feed/myfeed/ (or /?feed=myfeed). It’s a complete feed like the main one.

Now, we’re going to look at ways to customize this feed. We’re going to do this by changing/overriding the default query that feed-rss2.php’s loop will use.

A feed excluding articles with a tag

If you want to create a feed that excludes the tag “foo”, you could use this:

<?php
global $wp_query;
$tag = get_term_by("slug", "foo", "post_tag");
$args = array_merge(
        $wp_query->query,
        array('tag__not_in' => array($tag->term_id))
);
query_posts($args);
include('wp-includes/feed-rss2.php');
?>

<?php global $wp_query; $tag = get_term_by("slug", "foo", "post_tag"); $args = array_merge( $wp_query->query, array('tag__not_in' => array($tag->term_id)) ); query_posts($args); include('wp-includes/feed-rss2.php'); ?>

That was relatively easy, thanks to the “tag__not_in” query parameter. Now you can further customize the feed by adding supplementary query parameters to the $args array. The documentation of query_posts details the various parameters that you can use.

A feed excluding articles with a custom field (meta-data)

I went further because I did not want to use a tag to exclude some posts: that tag would have been public even if it was only meaningful to me. So I decided to use a custom field to mark the posts to exclude from my new feed. I named the field “no_syndication” and I always give it the value “1”.

This time it’s not so easy because we have no query parameter that can be used to exclude posts based on custom fields. We’re going to use the “post__not_in” parameter that can be used to exclude a list of posts. But we must first generate the list of posts that we want to exclude. Here we go:

<?php
global $wp_query;
$excluded = array();
$args_excluded = array(
    'numberposts'     => -1,
    'meta_key'        => 'no_syndication',
    'meta_value'      => 1,
    'post_type'       => 'post',
    'post_status'     => 'published'
);
foreach (get_posts($args_excluded) as $item) {
        $excluded[] = $item->ID;
}
$args = array_merge(
        $wp_query->query,
        array('post__not_in' => $excluded)
);
query_posts($args);
include('wp-includes/feed-rss2.php');
?>

<?php global $wp_query; $excluded = array(); $args_excluded = array( 'numberposts' => -1, 'meta_key' => 'no_syndication', 'meta_value' => 1, 'post_type' => 'post', 'post_status' => 'published' ); foreach (get_posts($args_excluded) as $item) { $excluded[] = $item->ID; } $args = array_merge( $wp_query->query, array('post__not_in' => $excluded) ); query_posts($args); include('wp-includes/feed-rss2.php'); ?>

A feed with modified content

You might want to add a footer to the articles that are syndicated. I use the Ozh’ Better Feed plugin for this but it applies to all your feeds.

You could do that sort of transformation only in your customized feed by using the WordPress filter named the_content_feed.

Here’s a simple example:

<?php
function myfeed_add_footer($content) {
        return $content . "<hr/>My footer here";
}
add_filter('the_content_feed', 'myfeed_add_footer');
include('wp-includes/feed-rss2.php');
?>

<?php function myfeed_add_footer($content) { return $content . "<hr/>My footer here"; } add_filter('the_content_feed', 'myfeed_add_footer'); include('wp-includes/feed-rss2.php'); ?>

I’ll stop here but obviously you have lots of options and many ways to tweak all the snippets above. They have been tested with WordPress 3.0.4.

Note that in all those examples, I took care to not duplicate the code from feed-rss2.php, instead I used include() to execute it. That way my custom feeds will automatically benefit from all the future enhancements and fixes made by the WordPress developers.

But if you have to modify the XML structure of your custom feeds, you can paste the content of feed-rss2.php in your file and change it like you want…

Librement: a new way to help people who want to contribute to free software

December 3, 2010 by Raphaël Hertzog

Find your way in the free software worldI have this project in my head, I want to work on it but I always lack the time. In order to go forward, I thought I could write about it, at least it would let me clarify my ideas and the core goals. So here I am, I will present you Librement (I have registered the alioth project but it’s empty).

The core goal is to make it easy for every user to contribute to free software in some way. I will now present the main features that I envision.

Defining skills and interests

In order to propose tasks that the user can do, we must have an idea of his skills. So on the first run (and later through a preferences menu) the user will be invited to define his skills:

  • his native languages (multiple allowed)
  • other languages he can understand
  • programming languages he knows
  • version control systems he can use
  • markup language he knows (HTML, DocBook, Wiki-like formats, etc.)
  • etc.

Maybe we can also ask which skills he would like to learn. Because contributing to free software is a nice opportunity to learn new skills!

We should also find out what the user is interested in. What are his favorite free software projects? What kind of contributions would he like to do (documentation, translation, coding, bug fixing, bug triaging, creating artwork, donations, etc.)?

Choose activities and pick concrete tasks

Based on the user’s skills and his interests, the software shows a list of possible activities. The user can then sort that list, from the most interesting one to those that he doesn’t want to do.

Each activity can generate concrete tasks. For example, the activity “Do translation for Debian” could generate a task “Translate strings in debconf/fr.po” or “Review translations in partman/fr.po”.

Work on tasks

When the user decides to work on a task, a step-by-step assistant helps him/her. It can automate some steps and provide explanations for the remaining ones, for example in the case of a translation for Debian:

  • grab the PO file (from a VCS, from an HTTP URL, from a translation server, etc.);
  • select and install a software to work with PO file (if not already done);
  • edit the PO file with the preferred program;
  • check the PO file (is it complete? is there no mistakes like missing substitutions?);
  • send back the completed PO file in a mail to the Debian bugtracking system.

If the tasks is not completed in one go, the user can resume it the next time.

Each free software project must provide some meta-information describing the various workflows involved for contributing to the different parts of the project. If necessary the project can also provide new plugins to support new operations that are not available in the default library.

Setting goals

In order to keep the user motivated, the software could track how much time he spent contributing to free software and it could verify if the user reached the goals he picked up for himself. Maybe it can also hook into the OMG Trophy Awarding System.

The sky is the limit

I hope that you now have a clearer idea of what this desktop application is supposed to be. There are literally hundreds of ways to contribute to free software and I like the idea that we can streamline the process for most users.

All the plugins implementing activities can use local information (list of packages installed with their versions, configuration settings, etc.) to propose tasks targetted to the user and highly beneficial for the corresponding free software projects. For example, a bug tagged unreproducible might benefit from a few more users trying to reproduce it. The software could direct the user to this bug report if it detects that he/she runs the same version on the same architecture and that this software is regularly run on the system.

Many projects have created “operations” or “events” to encourage people to contribute, they could all be implemented as dedicated activities in Librement. I’m thinking of stuff like Gnome Love, Ubuntu’s 5-a-day, Ubuntu’s 100 papercuts, etc.

Even for people who have no time to contribute, the application can still be useful by referencing the various ways to donate money (or material) to projects that they are using.

Feedback welcome

I’m excited by the potential of such an application, but it’s normal since it’s my idea. Do you believe it can be useful and popular? Do you have ideas of exciting activities that such a framework can offer?

PS: If you wonder how I came up with the name “Librement”, here’s the explanation. It’s a French word which means “freely”. And users who want to give back are trying to live up to the principles of free software, which I sum up by “they are trying to live freely”.

Follow me on Identi.ca, Twitter and Facebook. Or subscribe to this blog by RSS or by email.

The secret plan behind the “3.0 (quilt)” Debian source package format

October 21, 2010 by Raphaël Hertzog

New source package formats do wondersWhile I have spent countless hours working on the new source format known as “3.0 (quilt)”, I’ve just realized that I have never blogged about its features and the reasons that lead me to work on it. Let’s fix this.

The good old “1.0” format

Up to 2008, dpkg-source was only able to cope with a single source format (now named “1.0”). That format was used since the inception of the project. While it worked fine for most cases, it suffered from a number of limitations—mainly because it stored the Debian packaging files as a patch to apply on top of the upstream source tarball.

This patch can have two functions: creating the required files in the debian sub-directory and applying changes to the upstream sources. Over time, if the maintainer made several modifications to the upstream source code, they would end up entangled (and undocumented) in this single patch. In order to solve this problem, patch systems were created (dpatch, quilt, simple-patchsys, dbs, …) and many maintainers started using them. Each implementation is slightly different but the basic principle is always the same: store the upstream changes as multiple patches in the debian/patches/ directory and apply them at build-time (and remove them during cleanup).

Design goals for the new formats

When I started working on the new source package format, I set out to get rid of all the known limitations and to integrate a patch system in dpkg-source. I wanted to clear up the situation so that learning packaging only requires to learn one patch system and would not require modifying debian/rules to use it. I picked quilt because it was popular, came with a large set of features, and was not suffering from NIH syndrome. This lead to the “3.0 (quilt)” source format.

I also created “3.0 (native)” as a distinct format. “1.0” was able to generate two types of source packages (native and non-native) but I did not want to continue with this mistake of mixing both in a single format. The KISS principle dictated that the user should pick the format of his choice, put it in debian/source/format and be done with it. Now the build can rightfully fail when the requirements are not met instead of doing something unexpected as a fallback.

Features of “3.0 (quilt)”

This is the format that replaces the non-native variant of the 1.0 source format. The features below are specific to the new format and differentiate it from its ancestor:

  • Supports compression formats other than gzip: bzip2, lzma, xz.
  • Can use multiple upstream tarballs.
  • Can include binary files in the debian packaging.
  • Automatically replaces the “debian” directory present in the upstream tarball (no repacking required).
  • Creates a new quilt-managed patch in debian/patches/ when it finds changes to the upstream files.

Features of “3.0 (native)”

This format is very similar to the native variant of the 1.0 source format except for two things:

  • it supports compression formats other than gzip: bzip2, lzma, xz.
  • it excludes by default a bunch of files that should usually not be part of the tarball (VCS specific files, vim backup files, etc.)

Timeline

Looking back at the history is interesting. This project already spans multiple years and is not really over until a majority of packages have switched to the new formats.

  • January 2008: the discussion how to cope with patches sanely rages on debian-devel@lists.debian.org. My initial decisions are the result of this discussion.
  • March 2008: I have implemented the new formats and I request feedback. dpkg 1.14.17 (uploaded to experimental) is the first release supporting them.
  • April 2008: I ask ftpmasters to support the new source packages in #457345.
  • June 2008: Lenny freeze. dpkg is not supposed to change anymore. Several changes concerning the new source formats are still accepted in the following months given that this code is not yet used in production and must only be present so that lenny can cope with new source packages once squeeze starts using them.
  • February 2009: Lenny release.
  • March 2009: Work on squeeze has started, ftpmasters have done nothing to support new source formats, I submit a patch in #457345 to speed things up. I start a wiki page to track the project’s progress and to answer common questions of maintainers.
  • November 2009: After an ftpmaster sprint, it’s now possible to upload new source packages in unstable. This draws massive attention to the new format and some people start complaining about some design decisions. The implementation of “3.0 (quilt)” changes a lot during this month. dpkg in lenny is even updated to keep up with those changes.
  • March 2010: Up to now, I was planning to let dpkg-source build new source packages by default at some point in the future. After several rounds of discussions, I agree that it’s not the best course of action and decides instead to make debian/source/format mandatory. The maintainer must be explicit about the source format that s/he wants to use.
  • October 2010: The new source formats are relatively popular, a third of the source packages have already switched: see the graph. The squeeze freeze in August clearly stopped the trend, hopefully it will continue once squeeze is released.
  • June 2013: Project is finished?

As you can see this project is not over yet, although the most difficult part is already behind me. For my part, the biggest lesson is that you won’t ever get enough review until your work is used within unstable. So if you have a Debian project that impacts a lot of people, make sure to organize an official review process from the start. And specifying your project through a Debian Enhancement Proposal is probably the best way to achieve this.

If you appreciate the work that I put into this project, feel free to join Flattr and to flattr dpkg from time to time. Or check out my page “Support my work“.

5 reasons why I still contribute to Debian after 12 years

October 11, 2010 by Raphaël Hertzog

Debian is packaging the free sofware world.If you’re using Debian, you know that this distribution is built entirely by volunteers that form a very diverse community. And you could be part of it. But why should you do that? I can’t tell for you but I can share my own experience. It’s been 12 years since I joined Debian and I’m going to tell you what keeps me on board.

1. Technical excellence

When facing a new challenge, Debian will strive to do the right thing. This pays off in the long term. In many cases, it means that we will take more time to implement our solution compared to other distributions out there, but this is also the reason why our packaging infrastructure allows us to offer painless upgrades and consistency across all packages.

Debian is committed to quality and builds up on his experience thanks to the Debian Policy. My time is precious, I like to spend it on something useful in the long term.

2. Inspiring goals

In its social contract, Debian has set out to create a 100% free — as in freedom — operating system. The criteria defining what constitutes a free work are listed in the Debian Free Software Guidelines (DFSG).

While the above is relatively ambitious in itself, it doesn’t inspire me much. What makes the difference to me is the emphasis given by the social contract on our users and free software. We don’t build a free operating system in the void, we build it for people.

Debian’s motto — the universal operating system — can also be interpreted in multiple ways: universal as in “for everybody on the world”, “on all kinds of computers”, or “for every possible usage”.

3. High impact work

Knowing that my work is useful to people is important, but it’s even better when I know that it will benefit to lots of people. With Ubuntu and the hundreds of other derivatives, there are nowadays literally millions of users impacted by my work. Even an insignificant one second improvement experienced by 10 millions of people represent 115 days of time saved for something else, you get the idea…

4. Working with great people

Debian has the chance to have lots of smart people on board. There’s always someone sharing valuable advice when you read Debian’s mailing lists. When I joined in 1998, I was a real newbie and I learned a lot of things by reading and interacting with people more knowledgeable than me. You can still experience the same thing nowadays but there’s one caveat: you must cope with various kinds of mailing list contributors including the “smart but uncivilized” (don’t be offended too quickly!) and the occasional troll (best ignore it, don’t feed it!).

5. Recognition of work

When you contribute to Debian, people get to know you through your contributions. It’s very rewarding to be thanked by your peers and by Debian’s users. Check out thanks.debian.net to convince you that many people are grateful for the work we put into Debian.

So that’s it for me. But what about you? What motivates you to contribute year after year, or to start contributing if you’re a prospective contributor?

Subscribe to this blog (it’s free!) by RSS, by email, or on Facebook.

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • …
  • 15
  • Next Page »

Get the Debian Handbook

Available as paperback and as ebook.
Book cover

Email newsletter

Get updates and exclusive content by email, join the Debian Supporters Guild:

Follow me

  • Email
  • Facebook
  • GitHub
  • RSS
  • Twitter

Discover my French books

Planets

  • Planet Debian

Archives

I write software, books and documentation. I'm a Debian developer since 1998 and run my own company. I want to share my passion and knowledge of the Debian ecosystem. Read More…

Tags

3.0 (quilt) Activity summary APT aptitude Blog Book Cleanup conffile Contributing CUT d-i Debconf Debian Debian France Debian Handbook Debian Live Distro Tracker dpkg dpkg-source Flattr Flattr FOSS Freexian Funding Git GNOME GSOC HOWTO Interview LTS Me Multiarch nautilus-dropbox News Packaging pkg-security Programming PTS publican python-django Reference release rolling synaptic Ubuntu WordPress

Recent Posts

  • Freexian is looking to expand its team with more Debian contributors
  • Freexian’s report about Debian Long Term Support, July 2022
  • Freexian’s report about Debian Long Term Support, June 2022
  • Freexian’s report about Debian Long Term Support, May 2022
  • Freexian’s report about Debian Long Term Support, April 2022

Copyright © 2005-2021 Raphaël Hertzog