Monthly Archives: September 2010

New BuddyPress plugin: BP Lotsa Feeds

· 1 Reply

I’ve been working on a project recently with Kevin Prentiss and the other fine folks at Red Rover. Kevin is a big believer in the power of feeds, and I’m a big believer in the power of BuddyPress’s activity component, and together we realized that BuddyPress’s RSS support for its rich activity content is a bit lacking.

This new plugin, BP Lotsa Feeds, is meant to address the issue. It activates RSS feeds for just about everything in BuddyPress, from an individual member’s sitewide comments, to new group memberships for specific groups, to individual forum topics.

Read more about the plugin on its home page, and follow its development on Github. Thanks to Red Rover for sponsoring a cool plugin.

Fake Retweets

· Leave a reply

Twitter communities are built on trust – sometimes too much trust. Recent XSS and XSRF exploits on Twitter have shown that the Twitter platform has been designed in a way that accidentally allows such trust to be used for evil purposes. My Fake Retweets experiment suggests that not all Twitter exploits are platform-level, architectural problems.

First things first: The real point of fake retweets is that they’re funny. What better way to make fun of your friends (or enemies) than to pretend to retweet stupid things that they allegedly said? I am not a performance artist, online or off.

Yet fake retweets do seem to say something worth saying about the medium. FRTs only work as a vehicle for jokes because there is a general assumption that all retweets are genuine. To some extent, this has nothing to do with Twitter. The only reason why jokes (or lies, or metaphors, or irony) work at all is because there exists a contrary convention that the jokester (liar, ironist) consciously flouts. In a world where people only tell lies, lies do not work in the same way that lies work in our world. I might lie about my dog eating my homework so that the teacher will give me an extension; but if there is no presumption in favor of truth, teachers will have no reason to grant an extension based on such a claim. (Echoes of Kant.) Jokes seem to work in a similar way: if we all spoke in puns all the time, for instance, then the utterance of a pun would have no element of surprise, robbing the joke of much of its value.

Thus the efficacy of fake retweets is at least in part an instance of a broader phenomenon. Anecdotally, though, it seems like Twitter is a particularly fertile yet underutilized environment for this kind of convention-flouting. With limited exceptions, people on Twitter generally seem to believe that everyone else is being genuine. There are some counterexamples, like Mark Sample‘s #MarksDH2010 or accounts like FakeAPStylebook. But both are either so absurd that no one could possibly think that they weren’t fake, or actively wear their fakeness on their sleeves with hashtags, or both. (This fact doesn’t necessarily take away from the funniness of the jokes in question. It just means that they don’t have the intent to deceive.) Aside from these sorts of extravagant Twitter charades, it’s hard to think of examples (from personal experience) where real live lying takes place on Twitter.

That’s not to say that my Fake Retweets were meant to deceive. (But they did. In one instance, a follower who commented on the fakeness of one retweet took another one as serious just a few minutes later.) The spirit of Fake Retweets in this case is to poke fun at friends, which means that my FRTs were mainly friendly and totally directed at friends. Yet I have to admit a little trepidation to the FRT, even with such benign content. There’s something about faking another person’s voice (perhaps especially in a community of academics) that seems to cross a sacred line.

The sense of violation in FRTs, it seems, is related to the fact that we all spend so much effort cultivating a specific persona via Twitter. Yet again, such cultivation is not a Twitter-specific phenomenon – surely there’s a sense in which personae are necessarily self-constructed – but it seems to be especially evident on Twitter. Maybe it’s because on Twitter, you control your own stream. In real life, all my eloquence and fashion won’t prevent the occasional piece of food in my teeth; in meatspace, there are infinite vectors for our self-constructed selves to get out of hand. Twitter, in contrast, has very few dimensions for self-presentation to run amok: tweets are finite in length and in number, you get to choose your avatar, you can spend hours crafting your 140-character pearls, you can even edit and delete mistaken tweets. The FRT threatens to cleave this controlled space, to taint our carefully manicured self-images.

The aspects of Twitter that make FRTs so uncomfortable aren’t necessarily bad things. Maybe the world would be a better place if it were as trusting as the Twitter community. (Though I wouldn’t want to be vulnerable to cross-site scripting in real life.) But certainly there is room for a little more skepticism when you see something come across your screen. Think before you click that link, before you believe that RT.

Using Github with wordpress.org plugin SVN

· 12 Replies

Like this tutorial? Check out my updated and more comprehensive Git/Github/wordpress.org tutorial at https://teleogistic.net/2011/05/revisiting-git-github-and-the-wordpress-org-plugin-repository/.

I’m on a never-ending quest to come up with a good local environment that will support the kind of WordPress plugin development that I enjoy So Very Much. I’ve only just recently begun using Github for version control and already I can’t imagine living without it. But doing WP plugin development in Github is not totally straightforward, because wordpress.org’s plugin repository uses SVN. When it comes time to release a new version on the wordpress.org repo, it’s simply not practical to merge changes manually and manage two different version histories. I wanted a setup where I could use Github for everyday development, but would connect to WP SVN when I was ready to release.

There are lots of posts out there on how to use git-svn:

I couldn’t get any of the methods to work the way I wanted. But by mashing a few of them together, I have what is, I think, a workable setup. Here are the steps.

  1. If you don’t already have one, create a Github repository for your work. I’ll assume here that you have configured Git on your machine, with git-svn installed as well.
  2. Create a directory for your working copy. I use several local WP installations for plugin development, the main one of which is named Doris. So I’d do the following, for an imaginary plugin I’ll call awesome-plugin:
    [bash]
    cd /sites/doris/wp-content/plugins
    mkdir awesome-plugin
    [/bash]
  3. Before connecting to WP SVN, it’s a good idea to check for the revision number of your most recent commit. If you don’t, git-svn will sift through all 280,000+ revisions on svn.wp-plugins.org.
    [bash]
    svn log http://svn.wp-plugins.org/awesome-plugin
    [/bash]
    Scroll to find the most recent reversion number. Let’s say that in this case it’s r287228.
  4. Clone the svn repository to your newly created directory. Because I want this working copy to actually work as a WordPress plugin, I’m not going to check out the entire awesome-plugin tree. Instead, I’ll just get the trunk, and when I want to tag new versions of the plugin, I’ll do it in a separate working copy on my machine. (This is perhaps not the ideal way to work, but for me it works – probably irrationally, I like having “clean” instances of the trees somewhere on my machine that are used only for tagging new versions.)
    [bash]
    git svn clone http://svn.wp-plugins.org/awesome-plugin/trunk awesome-plugin -r287228
    [/bash]
    git svn clone will create the git-svn link and then do the initial fetch into the awesome-plugin directory.
  5. Depending on how you’re planning to use Git, you might want to create a branch that tracks the svn trunk, just for stable svn releases:
    [bash]
    cd awesome-plugin
    git checkout -b svn remotes/git-svn
    [/bash]
  6. Now that we’ve connected Git to WP SVN, we can connect to Github:
    [bash]
    git remote add -f origin git@github.com:boonebgorges/awesome-plugin.git
    [/bash]
    I’m calling Github ‘origin’ because I’m so used to push and pulling to and from ‘origin’, but you can call it whatever you want. Of course, make sure to change ‘boonebgorges/awesome-plugin.git’ to reflect your username and repo name.
  7. Let’s test the connections. If your Github repo is empty, you can push stuff up right away:
    [bash]
    git push origin svn
    [/bash]
    Remember that I am working on a branch called ‘svn’; you might use ‘master’ or something else altogether if you’d prefer. If your Github repo already had some files in it, you might find that you have to pull and merge them before pushing. Now make a change to your local:
    [bash]
    touch test.txt
    nano test.txt # Type something in the document and save it
    git add .
    git commit -m "testing git-svn"
    git push origin svn
    [/bash]
  8. Finally, let’s test to make sure that we can commit to SVN.
    [bash]
    git svn dcommit
    [/bash]
    The first time you try this, you will be prompted for your wordpress.org password. If your local username is not the same as your wordpress.org username (mine isn’t), just hit enter and SVN will ask for your full creds. You should get a “Committing to…” message, followed by “Committed r123456” or something along those lines. You can check to see that your commit has gone through by visiting http://svn.wp-plugins.org/awesome-plugin/trunk in your browser.

Good luck!