(You can download the latest version of WordPress Hook Sniffer here. Please read the readme.txt file for important usage and installation notes.)

After the bug fixes, the most noticeable improvement is that you no longer need to manually install the modified plugin.php file—the file that gives hook sniffer its abilities. The plugin now automatically installs the modified plugin.php file upon plugin activation and then reinstalls the original, stock WP version of the /wp-includes/plugin.php file upon plugin deactivation. This means that when you deactivate the plugin, you can rest assured that WP Hook Sniffer no longer has any influence over the operation of WordPress.

As there are important differences between the /wp-includes/plugin.php files of WP 2.9.2 and WP 3.0, WP Hook Sniffer now requires WordPress 3.0. Upon activation, an automatic version check is performed to make sure that WP Hook Sniffer is installed on the proper version of WordPress. If the plugin is installed on an older version of WordPress, it will not run. A warning message is displayed in the Plugins directory and in the WP Hook Sniffer Settings screen.

Also, I’ve versioned the modified plugin.php file that comes with WP Hook Sniffer. Now, when you activate the plugin, it runs a check to make sure that the proper version of the modified plugin.php file is installed in /wp-includes.

Finally, I added a CSS file to improve proper code separation–the older version simply had inline CSS definitions–and renamed all CSS selectors to make them unique to the plugin.

If WordPress Hook Sniffer has become an indispensable tool in your WP plugin development toolkit, please donate to help me keep this plugin updated and its sniffer healthy! Thank you!

Sponsorship Levels

Supporter $15.00 Donor $25.00 Sponsor $50.00 Benefactor $100.00 Patron $250.00 Open Source Angel $500.00 Holy Cow! $1,000.00

If you are a corporate user, consultant, plugin developer, or theme designer and profit from using my plugin, please consider donating at one of the upper levels. Thank you!

I have been having a few issues with BuddyPress development over the past week. I went through all the usual techniques to isolate the issue, finally deactivating all my 3rd-party plugins. But, the issue remained. Finally, I wondered about my WordPress Hook Sniffer plugin. I realized that although it was deactivated, it might be negatively affecting the operation of WordPress if the modified plugin.php file that comes with the plugin had issues. I replaced the modified version of plugin.php with the original one that ships with my version of WordPress, and bingo, the issues went away. All I could think was crap—especially as I say this in the installation instructions:

“The modifications to WordPress’ standard Plugin API file are used exclusively for WordPress Hook Sniffer. They should not affect the functioning of the rest of WordPress.”

In fact, this statement is still technically correct. The culprit is that when I updated the modified plugin.php file for last week’s version 0.13 update to the WP Hook Sniffer, I failed to use the proper base plugin.php file. I used the one that ships with WP 2.9.2 and not WP 3.0. Even though I thought I had done a sufficient parity check between these two files, I had failed to notice a few important changes.

WordPress Core Developers please note: if you change a function you should indicate as much in the inline documentation. Please use the @version PHPDocumenter tag to indicate that the function has changed. The @since tag version indicator is not helpful if the function has changed.

What issues did I have that caused me to discover this problem? The WordPress “wp” action hook was not firing. Yep. That is a big problem, especially if you are doing development work. Interestingly enough, most of BuddyPress continued to function as expected, except for a few features that used to work but suddenly stopped working—right at the time I installed the updated version of WP Hook Sniffer. Of course, I failed to notice this for several days.

I have gone through the stock plugin.php file–with a very fine-toothed comb–and ferreted out all the changes. I am in the process of updating the modified plugin.php file that WP Hook Sniffer is required to use. I want to make sure that it is adequatley tested before releasing an updated version. Look for the updated version with a fixed plugin.php file to be available either Sunday or Monday.

With this pending update, WordPress Hook Sniffer will require WordPress 3.0. Therefore, if you want to use it in an older version of WordPress, you will have to install Version 0.12 of WP Hook Sniffer. Please note, I will only support the most recent version of WordPress Hook Sniffer.

I apologize if this has caused you to lose valuable development time. I know that I have lost several days of productive coding due to this issue. There were obviously some important changes between WP 2.9.x and WP 3.0. Even though I thought I had properly assessed potential changes within the plugin.php file, I had not. I guess I need more sleep, more caffeine, fewer late-night alien visits, or some combination of those three.

There are differing software tools, protocols, and specifications in the Privacy 2.0 and Identity 2.0 realms. There are also differences between how corporations address privacy policy and identity management. But these are just semantically-packaged terms used for the convenience and profit of startups, conference organizers, rights advocates, and the gurus who coined the terms.

The reality is that, when looking at these supposedly disparate issues from the viewpoint of the individual, the differences disappear. And when looking at the topics of privacy and identity, in my opinion, the only viewpoint that matters is that of the individual.

So, privacy management tools and protocols are nothing more than identity management tools and protocols. Why is this the case?

Defining Identity

In David Kirkpatrick’s book, The Facebook Effect, Facebook founder Mark Zuckerberg states that “Having two identities for yourself is an example of a lack of integrity.” What Zuckerberg is actually saying is that having two accounts on Facebook, or any other social network, is a problem. Whereas this can be a real issue, Zuckerberg makes the same mistake that most people make—conflating a user’s account with their identity.

Identity is not a username and password combination. Identity is not your OpenID, WebID, Facebook, or Twitter account. Those are simply identifiers, of which a user may have many different ones across the Web, one for each social network site. In fact, as mentioned above, it is possible that a given individual might have more than one account, more than one identifier, at a given social network. These alternate accounts (referred to as alts for alternate “identities”), are just another aspect of the individual’s overall identity. Alts are not separate identities—no matter how much the owner of an alt identifier tries to make it.

Now, even if a user has carefully selected to join only those sites that offer the option to register via OpenID Connect, their single OpenID is not their identity. It is just an identifier. So, OpenID Providers are not identity providers, they are identifier providers.

What is identity on the Web, then? Identity is your presence strewn throughout the Web. It is the sum total of all your verified activity on the Web (blog, forum, and social network posts, video, music, and photo uploads, etcetera), your associated interactions with others, and their comments about and interactions with you. That makes up what can best be thought of as your identity graph.

When we talk about privacy control on the Web, then, we are not talking about the ability of users to totally control their identity graph. Obviously, a given user can theoretically control only part of their identity graph. Why is this the case? Because each user can exert only so much control over what someone on the Web thinks and says about them. That part of their identity graph is controlled by others.

So what are we trying to accomplish by allowing users partial access to and control over their identity graph? What kind of privacy, identity controls can reasonably be provided to users?

The IdentitySpace: Privacy and Identity in a Semantic World

From a user’s perspective, identity control on the Web is about offering fine-grained control over the data that they personally generate. It is not about offering tools to control their entire identity graph, to control the subset of their identity graph generated by others.

The IdentitySpace is that part of a user’s identity graph that they personally generated. It is the subset of their identity graph that they create, and therefore should own and have sole access to controlling.

Do users have any options for managing that part of their identity graph that is created and controlled by others? Yes. It is called reputation management and there are some fee-based services that offer users some concrete means with which to do just that. But in a free society whenever two or more people are involved in creating an identity graph, it will never be possible for each individual to be able to control their entire identity graph.

This last issue is where a user’s Web of Trust (WOT) can help. By carefully choosing with whom a user interacts, they can build a network, a web, of trusted individuals. This web of trusted individuals can more easily vouch for the user’s reputation than a more loosely defined network of associates. This Web of Trust can also be used as part of an authorization framework that utilizes FOAF+SSL and WebIDs.

In my perfect Web world, the IdentitySpace would be a global, distributed, decentralized dataspace which any one person, corporation, or government could access. The ACLs of each unique IdentitySpace–the datasets created, owned, and controlled by an individual user–would determine what subset of data a given query would return and how and where that data could be used. Individuals would be free to release more of their data for use, or restrict its consumption.

The key here is that users remain in control of their primary, personal data no matter where their Internet journeys and sojourns may take them. While a user would have little control over what other people may post about them, they would maintain control and ownership over the data that they personally generate. They would control their IdentitySpace.


There are existing ontologies and protocols in the Semantic Web stack that can readily be adopted to offer users the fine-grained identity management that they desire. A wonderful summation of these technologies can be found here.

See Also:

Repackaging the Promise of the Social Semantic Web

Regaining Control of Privacy and Identity: It’s up to Each Individual

Privacy in the Facebook Era

A thought-provoking presentation on open source, freedom, privacy, and identity. It’s by Eben Moglen, the founder, Director-Counsel, and Chairman of the Software Freedom Law Center.

However, there is one comment that Robert makes at the end of his piece that demonstrates that we in the Social Semantic Web space have a ways to go to get our message across. He states that:

If Facebook wants to be trusted it must make a privacy contract with its users that will have real consequences if Zuckerberg throws it under the bus. I don’t know what that looks like. This is why the alternatives to Facebook just don’t matter either. They all could break their privacy contract with us. Even Google or Microsoft could and we all know it. So, we’re just going to have to live in this new world where privacy is a myth.

As someone who is tapped into the pulse of the InterWebs, Scoble’s statement was somewhat of a shock. How can Robert Scoble not have heard about the promise of distributed social networks powered by the Semantic Web? How can he not understand some of the virtues of a fully-actualized Social Semantic Web?

What he states is true only for Facebook alternatives that offer more of the same—the closed data silos that remain under the control of an entity other than its users. What he fails to mention are those proposals that will put each user back in control of their own identity, privacy, and data. The only way that a privacy contract could be broken in that scenario is if a user breaks it with him or herself.

There are a number of us Semantic Web / Linked Data folks who are working on bringing this ideal to fruition. As an example of one such proposal, see my article, A Flock of Twitters: Decentralized Semantic Microblogging. Another recent proposal that has received significant attention is diaspora.

User-centric, distributed platforms like these will remove the issue of who owns our data and who decides its fate as it will be each individual who controls, who owns their data. These platforms will be the next evolution of the Web. As I conclude in my article, A Flock of Twitters:

It’s time to return to the original concept of the Web-based Internet—an interconnected, decentralized and distributed, open and independent cacophony of individuals who control their own Webspace, operate their own communication channel, and freely communicate with others without having to worry about a central point of failure…The only way [for that to happen] is by leveraging the power of the Semantic Web.

The promise of a fully-actualized Social Semantic Web is to firmly place the control of one’s identity and privacy back into the hands of the Web’s citizens. If our work in making that dream come to reality is going to succeed, we must better craft our message, we must better communicate the virtues of a user-centric, user-controlled Social Semantic Web.

Related Articles

Regaining Control of Privacy and Identity: It’s up to Each Individual
Privacy in the Facebook Era
Flocking To the Stream

These are not the normal, run-of-the-mill plugins that extend BuddyPress by adding additional functionality for a site’s members, or allow a site administrator to selectively alter the core functionality of BuddyPress. Instead, the plugins that I’m excited about are specifically targeted to providing site administrators and developers with unique services. I call these tools to differentiate them from the general-purpose plugins.

Although there are currently only a handful of such tools available, I hope that these releases indicate a trend. The WordPress ecosystem needs more specialty tools for site administrators and plugin developers.

So, in no particular order of importance, here is a listing of the more interesting plugins that provide useful tools for the site administrator’s or developer’s toolbox.

Developer Tools

WordPress Hook Sniffer: This is a tool I recently released that helps plugin developers determine the sequence in which action and filter functions are fired. It provides a window into the inner workings of the WordPress Plugin API and can help a developer figure out why a custom action or filter hook or function is not working as intended.

Wordpress MU Demo Data Creator: Provides a utility for populating your WPMU development sandbox database with dummy data. Why waste time creating your own dummy data to test your plugins when it can be auto generated for you.

BuddyPress Skeleton Component: This is not a new developer tool. In fact, as an example BuddyPress plugin component, it is the grand progenitor of many BuddyPress plugins.

BuddyPress Template Pack: This is not a developer’s tool per say. But I think it deserves listing nonetheless. It is actually a theme designer’s tool that helps make a custom WordPress theme compatible for use as a BuddyPress theme.

Site Administrator Tools

BP System Report: This tool gathers useful network intelligence on a site’s member and group activity. It provides a site administrator with usage trends and statistics, offering important insights into the health of their community.

Import from Ning: I thought I should throw this one in as well as it is a tool that helps social network operators. It provides some utility in helping to migrate a Ning network to BuddyPress. As Ning does not offer too much help in migrating existing networks to competing platforms, this tool is not a panacea to your Ning-networking woes—but it is a great start!

Plugin Developers Need Your Support

Creating a high-quality plugin takes more time than most people realize. In fact, it can take as much time if not more than creating a top-quality theme. But plugin developers rarely receive the same financial rewards that premium theme designers do.

My limited, empirical data shows that with the number of downloads of my current three WordPress / BuddyPress plugins, that less than 0.1% (yes, that is less than one-tenth of one percent) bother to donate. If my plugins received poor reviews, that would be understandable. But, as my lowest-rated plugin received a 4.5-star review out of 5, the lack of donations obviously has nothing to do with perceived quality. Note: Although I am a listed contributor to the BuddyPress Skeleton Component, I do not include that as one of my three plugins.

Whereas the greater WordPress community appears to have no issue with spending money on what are called premium themes, there seems to be a disconnect when it comes to supporting the developers of the plugins that help make their communities successful. Yes, great themes definitely provide an important face to a community, but it’s important to remember that plugins– along with the core functionality of WordPress and BuddyPress–provide the foundation to our networks.

So please generously donate to plugin developers and help keep them coding their wonderful plugins be they general purpose or specialty in nature.

This re-released version is what I call a plugin widget as it is a BuddyPress-specific widget and must be activated like other BP plugins. Widget installation is handled this way so that if BuddyPress is not activated, then this plugin widget will not be loaded—which could cause issues with your WP site. The widget does an internal check to see if BuddyPress is activated, if so then it continues loading. If not, it stops loading and will not be visible in the widget gallery. The widget is automatically activated sitewide so your other members will not see it in their plugins section if you’re running a multisite install.

Download BuddyPress Featured Members Plugin Widget and Donate!

You can download version 1.2 of the BuddyPress Featured Members Plugin Widget from the WordPress Plugin Repository. Even more excitingly, you can help me support this plugin, encourage me to create new ones, and enable me to keep living by selecting a sponsorship level below and clicking the “Pay Now” button. Thank you!

Sponsorship Levels

Supporter $15.00 Donor $25.00 Sponsor $50.00 Benefactor $100.00 Patron $250.00 Open Source Angel $500.00 Holy Cow! $1,000.00

If you are a corporate user, consultant, plugin developer, or theme designer and profit from using my plugin, please consider donating at one of the upper levels. Thank you!

Using the Plugin Widget

Please read the readme.txt file for installation and usage instructions. If you have any issues, please leave a comment in this post, or visit the support forum for this plugin widget.

Personal freedoms, control over one’s privacy, and the ability to manage one’s identity on the Web have never been in more jeopardy. With Facebook’s continued war on personal privacy, the day when a user no longer has any rights to control their own data is closer at hand. The question is, How should society respond?

Of course, Facebook–or any other corporation–is free to offer services and manage their user base in anyway that benefits their stakeholders—as long as they do not break the laws under which they are obligated to operate. Individuals have the freedom to decide whether or not they agree with Facebook’s policies, in particular as they pertain to privacy and the use of their personal data. They can choose not to use Facebook, Twitter, or any other Social Web network.

I have no issue with corporations making a profit, I am a businessman myself. My argument is that society should not feel comfortable when a few individuals (or in this case a single person) make broad, sweeping decisions about how an individual’s data is managed.

Society should not be complacent when a large corporation like Facebook continues to assail personal privacy on one front while purporting to be the de facto provider of Web-based identity on the other. Free societies should strive toward assisting individuals to gain control over their personal data.

Currently, there are inherent barriers to providing users with an easy-to-use mechanism that grants fine, granular control over personal data on the Internet and Web. Most users have their personal data strewn throughout myriad, disparate data silos, across different closed social networks. This makes it difficult to create tools that offer users an efficient and effective way to manage their data, to manage their on-line identity.

Some of the initiatives that open a user’s data up to other applications and networks–the Open Stack, for instance–begin to address this issue. But, as long as users’ personal data remains effectively siloed in government and corporate databases, this vision will not be obtainable.

As the Web matures and new technologies such as Semantic Web protocols and tools become available, solutions to the proverbial Privacy 2.0 and Identity 2.0 debate are possible. Whether corporate adoption rates of those solutions will be sufficient to make them viable is unclear. This is were the wishes and desires of a free society come into play. If there is a sufficient cry to adopt new identity-management protocols, then perhaps we can effect change.

In my article, “A Flock of Twitters: Decentralized Semantic Microblogging”, I offer one such path to a user-driven, user-centric identity management and privacy solution. It does not rely on corporate adoption but instead puts the power back in the hands of individuals.

But there are other solutions that offer great business opportunities to companies that truly listen to users’ concerns over the usurpation of their personal privacy and identity. In the coming decade, those companies that build new interfaces and provide new services that facilitate user-centric identity and privacy management will find their visions rewarded. There is plenty of room for both open source and proprietary solutions in this space.

Whereas Facebook has shown great acumen at growing their small business into a global behemoth, it has lost sight as to the roots of its success—their users’ trust. If the Web’s citizens take a stand and demand that their personal privacy and identity remain their domain, and not the domain of corporations or governments, then companies like Facebook could very well end up being a relic of a Wild-west Web, a bygone time where anything and everything was acceptable in the name of profit.

It is up to society, to the Web’s citizens, to decide how the issue of privacy and identity will turn out. If only a few voice their opinions, if only a few are cognizant of this crisis and its negative ramifications, then Facebook and other corporations will decide how privacy and identity are managed.

If you think privacy and identity are too important to let the few decide how they are managed, then it’s time for you to act. Write about it on your blog, tweet about it, retweet my article, do whatever it takes to get those who trust you in your various social networks to take note, to listen, to understand, and to ultimately act.

UPDATE: May 8, 2010: Jeff Jarvis published an interesting article on this topic. See Confusing *a* public with *the* public.

As a developer, one of the downsides to Open Source projects like WordPress and BuddyPress is that a significant amount of foundational code is already in place. There are hundreds of functions, classes, methods, and general code that you never actually get to know. Sure, you might call them from within your code, you might know how and when to use them, but you more than likely do not understand how and why they work and what they actually do to accomplish their task.

Why? Because you were (more than likely) not part of the team that wrote the code, that figured out what each function was required to accomplish and in what ways that code would interact with other parts of the foundation.

This is exactly the situation I found myself in several weeks ago as I was trying to figure out why one of my custom do_action events in my BuddyPress Privacy Component was not working as I had expected. My investigation into this issue not only opened my eyes into the inner workings of WordPress’ Plugin API, but also helped me figure out why a few BuddyPress action events were not behaving as intended.

Understanding Hook Firing Sequence

How can you know the firing sequence of action functions or filter functions that you attach to existing WordPress and BuddyPress hooks? Why is this even important?

To answer the second question, read my article, WordPress Hooks, Barbs, and Snags. The answer to the first question is more difficult.

Since many internal WordPress and BuddyPress functions may be tying into the same action or filter hooks, there is no easy way to know the firing sequence of action functions or filter functions. Add to that the fact that 3rd-party external plugins can also tie into these same action or filter hooks and the issue becomes even more murky.

As I had a serious issue with a custom do_action event in my BuddyPress Privacy Component not working as expected, I set out to solve the first question. Although my problem appeared to be with my custom do_action event, I soon discovered that it was caused by another hook to which I had tied in to.

The result of my investigation: a new tool for WordPress and BuddyPress developers called the WordPress Hook Sniffer. What does this plugin do? It helps plugin developers determine the sequence in which action and filter functions are fired, providing a window into the inner workings of the WordPress Plugin API.

As with all of my other WordPress and BuddyPress plugins, this plugin is licensed under the GNU General Public License 3.0 (GPL).

Download WordPress Hook Sniffer and Donate!

You can download the WordPress Hook Sniffer via the WP Plugin Repository. Even more excitingly, you can help me support this plugin, encourage me to create new ones, and enable me to keep living by selecting a sponsorship level below and clicking the “Pay Now” button. Thank you!

Sponsorship Levels

Supporter $15.00 Donor $25.00 Sponsor $50.00 Benefactor $100.00 Patron $250.00 Open Source Angel $500.00 Holy Cow! $1,000.00

If you are a corporate user, consultant, plugin developer, or theme designer and profit from using my plugin, please consider donating at one of the upper levels. Thank you!

Using the Plugin

WARNING: This plugin is to be used only in a development sandbox and not in a production environment. It is intended solely for use by plugin developers to help determine the sequence in which action and filter functions are fired. Use at your own risk. As this plugin should not be installed on an active WordPress-based site (a production site), no support for broken sites will be given. You have been warned!

It is important that you carefully follow the installation instructions in the readme.txt file. There are several crucial steps you must take to make this plugin work.

1. Once installed and activated, you will find a new menu option in the Settings menu
   
2. Clicking on that will bring up the WordPress Hook Sniffer Settings screen. The first thing to do is look in the upper left-hand corner of the screen. See that gratuitous “Please Support My Work” section? Go ahead and select a nice, juicy amount and then click the “Pay Now” button. Your donation (in any amount) is greatly appreciated! Okay, enough begging.
   
3. Next, read the “Usage Notes” section at the end of this article for a few additional bits of important information
4. Finally, select “Enabled” in the Main Sniffer Settings section, choose what data you wish to view in the Output Options section, and then select where you would like the output to go in the Output Location section
5. It’s that easy!

Output Settings Options

Whereas getting the WordPress Hook Sniffer to work is relatively straight forward, interpreting the output is a different story. What does all of that crap stuff mean?

Here is a brief overview of each of the output options and what information it can provide. However, to truly understand how to interpret the output and how best to use it in your development work, you will need to read my article, WordPress Hooks, Barbs, and Snags article.

A. Added Functions

Selecting this option outputs the special WP Hook Sniffer array that holds, in the order in which they were encountered during code execution, all add_action calls and add_filter calls. The file and line number from which a given function was triggered is also provided.

B. Removed Functions

Selecting this option outputs the special WP Hook Sniffer array that holds, in the order in which they were encountered during code execution, all remove_action calls and remove_filter calls. The file and line number from which a given function was triggered is also provided.

C. Action and Filter Function Array

This is the grandaddy, grandmommy, grandchild, Grand Ole Opry of output data. It contains the output of the $wp_filter array, the array that holds all of the added action and filter functions and is used by the do_action and apply_filters functions call to determine function firing order—although there is a twist here. You must read my article WordPress Hooks, Barbs, and Snags article to learn what it is.

D. Action Event Firing Order

This option contains the output of the $wp_actions array. A simple, one dimensional array that holds the sequential listing of all the do_action events that need to be processed. The events within this array used in conjunction with with corresponding data in the $wp_filter array determines the firing sequence of all action functions

E. Action Event Firing Sequence

Selecting this option outputs the special WP Hook Sniffer array that holds the sequential listing of do_action events with their corresponding fired action function(s). This listing shows you exactly the sequence in which each triggered action event fires its hooked action functions.

F. Filter Event Firing Sequence

Selecting this option outputs the special WP Hook Sniffer array that holds the sequential listing of apply_filters events with their corresponding fired filter function(s). This listing shows you exactly the sequence in which each triggered filter event fires its hooked filter functions.

1. Reporting Bugs: If you find bugs or are having issues using this plugin, you can either post a comment in this article or visit the support forum for this plugin. Assistance in providing patches to this plugin is appreciated.
2. Increasing Precision: If you want to see a more precise accounting of the execution time of a given function, you have to edit your php.ini file to increase the precision displayed for floating point numbers. Search your php.ini file for the entry:

   precision = 12

   and change that to:

   ; precision = 12
precision = 16

   As you can see, I like to comment out any changes to my default php.ini settings just in case I decide to revert the changes later. This allows you to do so easily without having to remember or look up what the default setting is supposed to be.

   Save your modified php.ini file and then restart your development server and you should now see the time-executed stamp displaying 6 significant figures instead of 2. This provides a sufficient level of detail.

3. Text Output Issues: If you’re using SSL or are behind a proxy server, you may have issues when selecting to send the output to a text file. There are a few work arounds for this, but suffice it to say that since this plugin is to be used exclusively in a development sandbox environment, I will not be coding these into the plugin. If you must use this plugin with SSL or behind a proxy server, then simply select the screen output option. You can learn more about this in the PHP manual for the fopen function.
4. Screen Output: When printing to screen, it may take a several seconds for output to finish. The output will start just below your theme’s footer.

This article is my exhaustive study of what I thought was a simple little function—the do_action function. It details how WordPress action hooks really work. It is a long, detailed article. If you want to understanding the inner works of the do_action function, then it will be worth your time. Although this article only briefly mentions the apply_filters function, the lessons learned about the do_action function apply equal as well as the coding of these two functions is nearly identical.

This is not a beginners guide to WordPress action and filter hooks. To benefit from this article, you need to understand what hooks are, why you use them, and how to use them.

Hooks, Barbs, and Snags

Before we start, I need to define two terms. You may be wondering about the title of this article, “WordPress Hooks, Barbs, and Snags.” You should already know the definition of a WordPress hook. But what are barbs and snags?

These are two terms I created to classify the following:

Barbs: salient insights about the functioning of WordPress hooks that stick out and grab your attention. Understanding these barbs help you avoid snags. In this sense, a barb is a good thing.

Snags: WordPress hooks that do not execute as expected, not because the do_action or apply_filters functions are misbehaving, but rather because you do not understand how these functions actually work.

The Hook Loop or Where the Issue Gets Complex

When it comes to code, loops can be tricky constructs to properly implement. What seems like a simple, innocuous operation may actually be more complex than meets the eye. This is the case with the do loops in the do_action and apply_filters functions.

There are two key arrays that WordPress uses to determine the firing sequence of actions and filters— the $wp_actions and $wp_filter arrays. These arrays get built throughout the execution of each page load and are not fully populated until page load is complete and PHP stops execution, waiting for its next command.

The $wp_filter Array

The $wp_filter array is where all added action functions and filter functions are stored for future reference and processing by both the apply_filters function and the do_action function. This array is a very-large, multidimensional array nested to four levels. See the snapshot of the partial contents of this massive array.

Here is a snapshot of what is generated in the $wp_filter array just by navigating to the homepage in my particular setup. Your results will vary depending on which plugins you have activated, which theme you’re using, whether you’re running WordPress in single-site or multi-site mode, whether you’re running BuddyPress, whether a user is logged into your site, and of course which versions of WP / BP you currently have installed.

As you can see, there are a lot of action functions and filter functions listed, each of which result in the grabbing and storing of added actions and filters. Not all of these are necessarily triggered. It is up to the apply_filters and do_action functions to determine which of the referenced functions will be fired.

The $wp_action Array

The $wp_actions array holds all of the current actions invoked by do_action events in the files that are processed when a given page is loaded. Like the $wp_filter array, the contents of this array obviously depend on the page to which a user navigates.

Here is a snapshot of what is generated in the $wp_actions array just by navigating to the homepage in my particular setup.

But read on as knowing about these two arrays is only one aspect to fully understanding the underlying processes, in figuring out the entire puzzle.

Populating the Arrays, Firing the Hooks

Here’s another piece to this complex puzzle. We know that the array $wp_filter holds an array listing all of the currently active action functions and filter functions. But how is this array built?

It’s simple. All action and filter functions that are not enclosed within a function, a loop, or any type of conditional clause currently not triggered, are added sequentially to this array as a given file is executed after it’s loaded (via either an include, include_only, require, or require_only function call). Therefore, as soon as a file is loaded, execution passes to that file and all directly executable add_action, add_filter, remove_action, and remove_filter function calls are processed.

This means that PHP is furiously processing function calls from these four functions, resulting in data being added or removed from the $wp_filter array. When an add_action call is triggered, the parameters are sent to the add_action function in the WP plugin API. When an add_filter call is triggered, the parameters are sent to the add_filter function—and so on.

However, one additional function is called when an add_action call is processed. As soon as the add_action function gets called, it immediately passes on the responsibility to the add_filter function. This means that WordPress looks at action functions and filter functions as the same. This is another key insight and is why both action functions and filter functions are referenced within the same array— the $wp_filter array.

Once the add_filter function gets control, it adds the calling function to the growing list of actions and filters that can be triggered by a given do_action or apply_filters event. This process quickly results in the $wp_filter array growing into a massive, multidimensional array. Of course, action and filter functions can get removed from the array via calls from the remove_action and remove_filter functions.

The reality of code execution is of course more complex. The $wp_filter array is still being populated with action and filter functions when the first do_action events are triggered. This means that it is possible to have a situation where an action or filter that is hooked to a given do_action or apply_filters event will not get triggered if the file in which the hooked function is located has not been loaded before the hook is triggered.

This last point is exactly what was happening in BuddyPress when the bp_init action hook fired. This is the issue that was puzzling me and resulted in this exhaustive study and creation of my new WordPress Hook Sniffer plugin. You can read this BuddyPress Trac ticket to learn more.

A Detailed Analysis to Shed Some Light

Here is a breakdown and partial analysis of the $wp_actions array, the array that holds all of the current actions invoked by do_action events in the files that are processed when the homepage is loaded. We will use this array along with the $wp_filter array to figure out what is really going on.

The contents of this array obviously depends on the page to which a user navigates. This is just what happens when a non-logged-in user visits the homepage of the default BuddyPress theme in my WPMU setup. The only other plugin that is activated is my BuddyPress Privacy Component. For these tests, I am running WPMU 2.9.2 and BuddyPress 1.2.3.

NOTE: To fully understand what is going on, you need to make sure that you are looking at the completed arrays and not the partial arrays grabbed partway through page-load.

Let’s look at the order in which do_action events will be triggered. We will analyze what is happening in the first four elements of the $wp_actions array (index value of “0” through “3”). How is each action triggered and what are the results? This will start off as a detailed look into each hook’s actions, but will provide fewer details with each additional event as the basic processes become evident.

The First Four Triggered Action Events

[0] => muplugins_loaded

[3] => bp_setup_root_components


[0] => muplugins_loaded

When a user navigates to the homepage of a default BuddyPress install running on top of WPMU, the first action hook that is invoked is muplugins_loaded. This is directly triggered on line 547 in wp-settings.php. Any added actions that are tied to this event will next be triggered.

Looking at the $wp_filter array, you will see that there are no actions tied to this hook. This means that there is no subarray element with a key name of muplugins_loaded. In other words, you will not find any reference to that action event within the $wp_filter array. So, this action event does not result in any action functions getting fired.

NOTE: A triggered hook may or may not have actions tied to it. If no actions are tied to the hook, the do_action routine passes by that hook, checking the next invoked hook for added action functions to fire.

Before the next action event is triggered, something important happens.

Execution of the wp-settings.php file continues. On line 703 of wp-settings.php, all the active plugins are loaded—both blog specific plugins and site-wide plugins.

If you look at that line, $current_plugins can be modified by any added filters. That is what happens. On line 2348 of wpmu-functions.php, an add_filter call triggers function mu_filter_plugins_list. This filter modifies the contents of $current_plugins, adding any MU plugins that have been activated site wide. Processing is returned wp-settings.php, resulting in the main file of each activated plugin getting loaded.

There is an interesting item to notice within function mu_filter_plugins_list. On line 2345 of that function, the two arrays $active_plugins and $active_sitewide_plugins are merged and the resultant new array is sorted.

What does this mean? It means that when it comes to the issue of action and filter sequence firing, it does not matter which plugins you activate first. The order in which plugins are added to each of the serialized objects active_plugins and active_sitewide_plugins is immaterial. The sort function will alphabetically reorder the contents of the merged array.

NOTE: Each WPMU blog has it’s own listing of active plugins that are stored in a serialized object in the blog’s wp_x_options table. Look for the entry “active_plugins” within the option_name field of that table. The corresponding active plugins are in the option_value field of that record. All plugins that are to be activated site wide within WPMU are stored in a serialized object in the wp_sitemeta table. Look for the entry “active_sitewide_plugins” within the meta_key field of that table and the corresponding plugins that are to be activated site wide in the meta_value field of that record.

So, in our particular case with two site-wide plugins installed and activated (buddypress and bp-authz), the order in which they were activated is immaterial in determining which file is included (loaded) first by the conditional loop code starting on line 704 of wp-settings.php.

If you look in the wp_sitemeta table for the meta_key “active_sitewide_plugins”, you will see this:

a:2:{s:24:"buddypress/bp-loader.php";i:1270239897;s:28:"bp-authz/bp-authz-loader.php";i:1270396554;}

BuddyPress appears first because I activated it first—as is necessary. But, when the references to these two main plugin files are processed through the mu_filter_plugins_list function, they get sorted. This results in bp-authz-loader.php getting loaded before bp-loader.php.

This could be a big issue as all BP-dependent plugins rely on BuddyPress to be installed, activated, and loaded. Any BP-dependent plugin that comes alphabetically before “buddypress” will have their main file loaded before BuddyPress’ main file.

Barb 1: As a BuddyPress plugin developer, this is the first major insight, the first important barb that can prevent your code from hitting a snag with regards to action and filter execution.

Fortunately, there is an easy way to prevent this barb from snagging you and those that use your plugin. Make sure that BuddyPress is active before your plugin loads its core files.

Since that is exactly what I’ve done with my BuddyPress Privacy Component, there are no issues and execution quickly passes back to the loop and the next file in the $current_plugins array is loaded. This is the main BuddyPress file, bp-loader.php.

[1] => bp_core_loaded

Execution of bp-loader.php begins. On line 22 of bp-loader.php, the first custom BuddyPress action event is invoked:

do_action( 'bp_core_loaded' );

It is directly invoked, directly triggered. It is not enclosed within a function, a loop, or any type of conditional clause. This invoked event is what appears in the second element of the $wp_actions array.

Since there are currently no tied-in actions to this particular action event (as can be easily determined by looking at the $wp_filter array), the invocation of this action does not result in further actions being triggered.

The execution of bp-loader.php continues. Right after line 22, a series of conditional clauses include (load) all enabled BuddyPress modules—activity, blogs, forums, friends, groups, messages, xprofile.

As each of these files are included (loaded), any directly invoked (directly triggered) action events within each of them will also be invoked. Since there are no additional, directly invokable do_action calls within any of these files, execution is passed back to wp-settings.php.

[2] =>plugins_loaded

On line 735 in wp-settings.php, the do_action event for plugins_loaded is directly triggered.

do_action('plugins_loaded');

This is when things really start to accelerate. Up until this time, only a few lines of php code within BuddyPress have actually been run.

With the invocation of the plugins_loaded event, we now have our first action hook that has actions tied to it. Understanding what happens next leads us to the second major insight, the second important barb.

To understand what happens next, we need to inspect the elements within the plugins_loaded array of the $wp_filter array. I have extracted just that subarray element below:

plugins_loaded:
Array
(
[0] => Array
(

)


This array element is itself a multidimensional nested array. In fact, the first element (with an index value of “0”) has two action functions referenced.

An important point: each subarray of the $wp_filter array is a numeric array. Read that again. This means that the second level of the nested $wp_filter array contains numeric arrays.

You might be wondering how the index values for these numeric arrays are set. This is simple.

The key, the index value, of each 2nd-level array element is determined by the priority assigned to the event in the add_action and add_filter call. Thus, the priority set for a given action or filter function becomes the key of each element in a given hook’s multidimensional array. If a priority is not set for a given add_action or add_filter call, it is automatically defaulted to “10”. This means that any and all added actions or filters that do not specify a priority are automatically assigned to the proper action array element with an index value of “10”.

As an example, if the priority for a given added action is set to “16”, then that particular action function will be located in the array element for that action with an index value of “16”. Multiple action functions can be added under the same index value, creating an array of action functions associated with the same numeric key element. The order in which they appear is determined by the order in which they were executed.

Barb 2: This is the second major insight, the second important barb that can prevent your code from hitting a snag with regards to action and filter execution.

Now, the next piece of the puzzle is this. The order in which action functions are added to a given action array element is determined by the order in which they are encountered, the order in which their corresponding add_action or add_filter calls were fired. As we will see below, this is what makes determining the firing order of added actions and filters difficult.

Barb 3: This is the third major insight, the third important barb that can prevent your code from hitting a snag with regards to action and filter execution.

Barb 4: The higher the index key, the later the action or filter functions within that index-key grouping will get fired. Therefore, using the example above, if we set a priority of “16” for a given action function, it would get fired only after all the other action functions with a lower priority have been fired.

We have now reached the final piece of the puzzle!

Near the beginning of this article, the complexity of the do loops within the do_action and apply_filters functions was briefly mentioned. And it is within those loops that this story really finally gets resolved.

If you look at lines 166 (within the apply_filters function) and line 339 (within the do_action function) of the wp-includes/plugin.php file, you will find the code lines where the actual hooked functions are fired. Do you see the call_user_func_array() function call? That is a core PHP function. It is what will actually fire the next action or filter function in line, as determined by the data in the $wp_filter array.

The action of the call_user_func_array() function nested within the do loop is not as simple as it may seem. Why is this? Well, currently we are discussing the plugins_loaded action event and all of the tied into functions that get fired.

Look at the next action event to get triggered within the $wp_actions array. It is the action event bp_setup_root_components. But wait. Why is there another action event being triggered? We have not yet finished iterating through all of the added action functions to the plugins_loaded action event.

Once again, the reason is simple. Triggered action functions can themselves have action events. Inspecting the plugins_loaded subarray in the $wp_filter array, we see that the bp_setup_root_components action function is invoked by the plugins_loaded event via an added action call on line 2021 in bp-core.php. Within that action function there is an action event called bp_setup_root_components.

So, the sequential processing of all the added action functions with the plugins_loaded subarray of the $wp_filter function has come across a new action event to trigger. It now gets priority and further processing of the plugins_loaded subarray is put on hold until the bp_setup_root_components action event is finished processing its added action functions.

Barb 5: This can quickly result in a nested grouping of action events with the firing of their corresponding action functions. This is the final piece to the puzzle and the last and final barb that can prevent your code from hitting a snag with regards to action and filter execution.

As you are reading this, the juxtaposed actions of the do loop with the call_user_func_array() function more than likely seem obvious. It may seem this is not unexpected behavior or difficult to understand.

Whereas that is the case when all of the data is clearly laid out before you, the complex actions of these intertwined functions are not apparent when you are coding a plugin. There is no practical way to peek inside this action-event, action-function feedback loop.

This is were the true value of the WordPress Hook Sniffer plugin is revealed.

[3] => bp_setup_root_components

Here’s where we understand the last piece to this confusing puzzle.

Inspecting the $wp_filter array for this action event you will see that there are four action functions that are hooked to this action event: bp_activity_setup_root_component, bp_blogs_setup_root_component, bp_forums_setup_root_component, groups_setup_root_component.

These action functions are fired in that sequence. Since they do not have any action events which they trigger, control is passed back to the plugins_loaded event and the next action function in the plugins_loaded subarray is fired.

Applying the Lessons

When interpreting the results of the WoodPress Hook Sniffer plugin, you need to look at the output of the $wp_actions array and then search out the hooked actions to each of those items (if any) in the $wp_filter array. This will give you a general idea of what gets fired when. You can then experiment and see how changes to action priorities affect the firing sequence of a given added action.

You need to carefully think about the execution timing of each action or filter you add, looking at the corresponding triggering event for the hook or hooks to which it’s tied. Remember, you can hook a function to more than one hook which means that it is possible, if you are not careful, that some of them may fire whereas others may not. It’s all a matter of whether or not the reference to the action or filter function was successfully added to the $wp_filter array before the associated hook is triggered.

Looking at the Action Event Firing Sequence and the Filter Event Firing Sequence will help you precisely tune your added hooks and filters. Remember that execution my temporarily pass to another action or filter event. The output of these two WordPress Hook Sniffer arrays will show you when that happens.

Finally, there is no requirement that you place your add_action and add_filter calls right below the functions in which they are associated. Whereas doing so does facilitate code understanding, you could instead place them all at the top of the file (or the bottom) in which the associated functions are located. Remember, each add_action and add_filter function call that is directly executable is processed as soon as a file is loaded. So it does not matter where within the file those calls are located—with the possible exception of fine tuning the execution order of a particular function.

Final Notes on the $wp_filter and $wp_actions Arrays

The arrays $wp_filter and $wp_actions are repopulated from scratch each time a page is loaded. They do not contain a running accounting of all action and filter functions and all action and filter hooks. The contents of both of these arrays may vary depending on which page you navigate. The contents will depend on the files that are loaded (via include, include_only, require, require_only) when a given page you are on is displayed.

The reality is that, when visiting a given page, there will always be more hooks, action, and filter functions buried deep inside non-loaded files or within function blocks that are not directly hooked. The first is a result of the add_action, remove_action, add_filter, or remove_filter calls not getting fired until that file is loaded. At file load, any directly-executable do_action or apply_filters will be triggered as well. The second is the result of functions that have hooks that only get triggered if the file is loaded and the function is fired.

Although the WP Hook Sniffer will locate all action and filter hooks, and action and filter functions no mater the source–core files, custom themes, or 3rd-party plugins–what is captured depends on one simple rule—that the hooks and function calls are actually fired during page load.

As an example, WP Hook Sniffer cannot locate add_action calls that get fired on a different page than the currently loaded page. It can also not locate add_action calls that are buried inside a function that does not get triggered unless a special criteria is met. To sniff out those added actions, you have to navigate to that page so that those calls get fired or cause the special criteria to be met so that the function containing the buried action call is triggered.

Remember, the way that the WordPress Plugin API processes added and removed actions and filters is by storing (or deleting) a reference to them in the $wp_filter array. But that only happens for hooked functions that are actually encountered during page load. The $wp_filter array is wiped clean with each page load and rebuilt from scratch. The same holds true for the $wp_actions array and the action hooks it tracks.

Therefore, if you have action or filter functions that are supposed to be fired on a given page but you are not seeing that they’ve been fired, then that indicates that they are hooked to an action or filter event that finishes firing before the file in which the target action or filter functions are located even gets loaded. This is exactly what happened to me and caused me to write WP Hook Sniffer.

Summary of Barbs: the Key Insights

1. When it comes to the issue of action function and filter function sequence firing, it does not matter which plugins you activate first.

2. The key, the index value, of each 2nd-level array element within the $wp_filter array is determined by the priority assigned to the event in the add_action and add_filter call.

3. The order in which action functions and filter functions are added to a given action or filter subarray element in the $wp_filter array is determined by the order in which they are encountered during code execution.

4. The higher the index key, the later the action or filter functions within that index-key grouping will get fired.

5. Action hooks (events) –> trigger action functions –> which can have additional action hooks –> which can trigger additional action functions –> until control is passed back to the the originally-triggering action hook.

This is the action-event, action-function feedback loop caused by the juxtaposed actions of the do loop with the call_user_func_array() function.

I wrote a response but decided to share it here as I periodically receive similar DMs, PMs, and emails. So, the next time that someone asks my opinion on this issue, I can simply point them to this post and be done with it.

Although this topic seems to rear its ugly head periodically, it clearly will not die. This is not an attempt to reignite any of the heated debates of the past.

Please respectfully add your comments and thoughts. I will include all that stay civil.

My Response

You have specific freedoms with all GPLed themes and plugins. To find out what those are, you should read the appropriate version of the license under which a given theme or plugin is licensed.

Here are a few things to consider:

1. If you turn around and release any premium GPLed theme or plugin to the public, you will have to offer support to anyone who uses it or tell them that there is no support offered. Most authors of premium themes and plugins will not provide support for thier work if it was obtained from another site.
2. The community in general frowns upon people who take someone else’s work and profit from it—even though it may be perfectly acceptable under the GPL. So, if you decide to redistribute someone else’s premium work for a fee, then you should be aware that it may cause some backlash. If you are using someone else’s premium work as the basis of a new product, in other words you will be adding additional value to it, that is a different issue. The value added should be appreciable, you must always give credit to the original creator, and the work must remain licensed under the GPL.
3. You will have to provide your own download site. Since you are not the author of the theme or plugin, the WordPress repository will most likely not accept it for inclusion. The exception to this would be if you are creating a new version of the original theme or plugin, if you are adding additional, substantive value to it as detailed above. One scenario would be updating and rereleasing a GPLed theme or plugin that the original author no longer supports.
4. Many people within the greater WP community frown upon such maneuvers in general. Both premium theme designers and premium plugin developers donate a considerable amount of time to designing their themes and coding their plugins. They are simply trying to earn an honest living from their generous contributions.
5. There is nothing in the GPL that disallows theme designers or plugin developers from charging a distribution fee or a support fee for their work. The GPL is about usage freedoms, not about free-as-in-cost software. There is nothing in the GPL that differentiates between a designer’s work being fundamentally different than a developer’s work. So designers and developers are operating within the rights of the GPL when they offer their work for a premium—as long as they are only charging a distribution and/or support fee. When it comes to offering premium themes or plugins, any talk about the differences in rights between designers and developers is outside of the GPL, is a matter of opinion more than legal fact.
6. Currently it seems that in the WordPress community, premium theme designers are accepted in general whereas many premium plugin developers are not. I believe this disparity, this inequity, cannot last for long. The community needs both designers and developers. If developers are not afforded the same opportunities, then some will move on.
7. See my post in the following thread for my additional thoughts and opinions on this topic.

I went looking for a solution. The result, 15 lines of PHP you can use to accomplish the goal. No need to mess with plugins. Instead, you pull your tweets from your own Twitter RSS feed using the simpler Twitter Search API, not the Twitter REST API.

Here’s the article I found and used as the basis for my own solution. I’ve made a few modifications to the parsing function that I think provides a better, more flexible outcome. One change is that I add the rel=“nollow” attribute to each “a” tag. Since the content you are displaying (in your tweet) is your own, Why would you want the search engines sending some of your hard-fought link juice back to Twitter?

The second change I made was to parse the array an additional time so as to separate out the body of the tweet from the metadata. I just want to display my tweet. That’s all. But, the new array can be used as you see fit.

<div id="my_tweets">
	<?php
		// Your twitter username; replace below; keep username in quotes
		$username = "blahblah";

		// Content you want to include before your tweet; I'm using this for a quick title
		$prefix = "<h2>My Latest Tweet</h2>";

		// Content you want to include after your tweet
		/*$suffix = "<br /><br />You should follow me on Twitter";*/

		$latest_tweet = "http://search.twitter.com/search.atom?q=from:" . $username . "&rpp=1";

		function parse_feed( $latest_tweet ) {
		    $tweet_array = explode( "<content type=\"html\">", $latest_tweet );
		    $tweet_array2 = explode( "</content>", $tweet_array[1] );

			$tweet = $tweet_array2[0];

			//No need for search engines to follow twitter links or tags; add no follow
			$tweet = str_replace( "&lt;a ", "&lt;a rel=\"nofollow\" ", $tweet );
		    $tweet = str_replace( "&lt;", "<", $tweet );
		    $tweet = str_replace( "&gt;", ">", $tweet );

		    //some extra tweet metadata you can use if you want
		    $tweet_extra = $tweet_array2[1];

		    return array ( $tweet, $tweet_extra );
		}		

		list ( $tweet, $tweet_extra ) = parse_feed( file_get_contents( $latest_tweet ) );

		echo stripslashes( $prefix ) . $tweet;

		// If you want to include more content after the tweet, use this instead
		/*echo stripslashes( $prefix ) . $tweet . stripslashes( $suffix );*/
	?>
</div>

I simply placed this code in a division within my index.php file. You can place the code wherever you like—in a sidebar, the footer, a separate page, etcetera. Of course, you could also add it to your functions.php file and simply call your custom twitter-feed function in your template. It’s your choice.

Also, I imagine this simple code could be adapted for use in BuddyPress as well.

To see how it looks on my site, just go to my homepage.

By the way, it may come as little surprise to you, but I am not a design genius nor even a moderately-skilled designer. I choose to spend my WordPress time either coding or actually creating content for my site. So, you are on your own as far as positioning the output. But, I hear that you can use CSS to do that.

Have fun!

Why do I say this? It’s simple. For those of us that are hundreds or thousands of miles away–which could be many of your followers–tweeting your current location provides zero value. In fact, it is a (big) waste of your followers’ time.

In a recent article, I stated this:

…for absolutely every person I currently follow on Twitter, I don’t care who just booted whom out as the mayor of whateverville. I don’t want that drivel polluting my pleasant paddle down my River. It adds zero value to my day and provides little if any entertainment.

I also rarely need to know (nor care to know) whenever someone has just stopped by a Starbucks, or is eating at this and such restaurant 1000 miles away, or is on a treadmill listening to Kid Rock on their fancy Zune.

I am not against the occasional fun, non-work-related tweet. It is one of the things that makes a social network social. But, at some point, my Twitter stream started to resemble a scrolling marquee of useless drivel and it became clear that the location-based tweets were the big offenders.

The Foursquare, Gowalla, and other location-based auto-tweets are nothing more in my opinion than a form of advertising. They do not fall into the idle chatter that occurs between friends and colleagues. They are not the type of content that makes sense plastering all over your various social networks.

To Follow or Not to Follow

One of the reasons I am not following more people on Twitter at this time is that when I check out many people with whom I do actually have a genuine interest in following, I discover that their Twitter stream is too cluttered with location-based tweets. When I consider how many location-based tweets will be added to my Twitter stream, I quickly decide to pass them by.

Here’s why.

If I follow 150 additional people each who easily auto tweets on average seven Foursquare or Gowalla check ins each day, that is a total of 1050 location-based tweets added to my stream each day. Since I scan my tweet stream at about 1.5 seconds per tweet, only stopping on those that appear to have worthwhile content, that means I will waste more than 26 minutes each day looking at worthless location-based tweets. In a week that adds up to more than 3 hours* wasted!

I don’t know about you, but that is A LOT of time. I sure could use that time more productively. And I do by simply not following more people. It’s too bad because I really would like to follow more tech-centric people.

Now, I am not against location-based services in general, nor the fun-natured gaming aspect of Foursquare. I think Gowalla, Foursquare, and others have created interesting services that provide value when appropriately used.

I’m arguing that it is best for users to keep their location-based check ins isolated within the location-based services they are using. If I want to find out where you are, to discover if anyone in my network is nearby, I’ll simply fire up my Foursquare or Gowalla app on my smartphone. So please turn off the auto updates to your various networks. They truly provide me with little value and zero useful content.

#Nosquare and #Nowalla

I think it is time for those of us that are fed up with having our Streams polluted with location-based check ins to stand up and make a point. Tweet to your network that you’d appreciate the cessation of your followees auto-tweeting their Gowalla, Foursqaure, and other location-based check ins. Post to your Wall that you’re sick and tired of having to wade through updates that provide little value to your day.

In fact, I’m considering unfollowing those whom I deem abuse my time by virtue of auto posting their location-based check ins to Twitter. I’m not going to share what I consider an abuse of my time, but you can get some hint of my criteria above.

Finally, start using these hashtags to communicate that you’re fed up with this nonsense: #Nosquare and #Nowalla.

* ((( 150 people x 7 useless tweets each x 1.5 seconds per tweet ) / 60 seconds per minute ) x 7 days ) / 60 minutes per hour = 3.0625 hours per week. To be fair, it is more than likely that most of those 150 people would not pollute my Twitter stream with that many location-based auto tweets every single week. Some weeks (maybe many weeks), it might be a lot less, some weeks more. But, you get the idea.

UPDATE March 18, 2010:

I found an interesting post that argues for the need for people to manage their own flow: Manage Your Social Network Flow…NOW!

Chris Messina made a Google Buzz post today where he announced an experiment to “remove Twitter and Flickr as connected sites in Buzz” to see how that is received.

…as the number of streams continue to increase and as the flow rate of each stream picks up, people will grow tired of having to subscribe to, having to join yet-another-stream phenomenon (YASP). Does the Web truly need additional stream providers each with their own data silos? Is there a user-centric solution to this rapidly growing, overflowing-stream issue that puts YASP to rest once and for all?

This article answers these two questions in great detail but the succinct preview version is as follows:

1. The Web does not need additional stream providers each who exert significant control over a vast number of individuals, each who require their users to have a separate new user account (a new digital identity)
2. The Web does not need additional closed data islands (data silos)
3. The Web does need a means with which each individual can create, maintain, and control their own identity, efficiently and effectively manage stream conversations, and therefore not be beholden to a few, large data-silo stream providers
4. The only way to accomplish point three is for the emergence of a distributed, decentralized, Open Source microblogging ecosystem that leverages the power of the Semantic Web

Table of Contents

Since some of the following may be too generic for more advanced readers, I’m providing this Table of Contents to help readers navigate to those parts with which they may have the most interest. The first four sections are a general review of the problem and solution. The rest of the article provides my detailed thoughts on this issue.

• A Web of Damned Streams
• A Flock of Twitters
• Why Decentralized?
• Why Semantic?
• Evolving Nova’s Stream Concept
• A Drop of An Idea
• Channeling Your Stream, Seining Your River
• The MicroBlogOcean
• Social Web Versus Social Network
• Anatomy of a Drop
• Some Technical Thoughts
• Some Early Players in This Space
• Conclusion

Although you should feel free to skip ahead, doing so might result in missing a crucial connection.

A Drop of An Idea

In keeping with the metaphor of a flowing body of water, I envisioned a water-cycle like flow from a single idea to an ocean of open discussion. Therefore, I call my model of a decentralized microblogging ecosystem the Meta-Hydrological Model.

With that concept in mind, you can think of a single idea posted by a user as a drop. Just as a user of Twitter adds to a conversation by posting a tweet, and a user of FriendFeed or Facebook makes what is generically called a micropost, a user in this new conversation ecosystem posts a drop. So a drop is equal to a tweet is equal to a micropost.

Here is a simplified, graphical representation of the Meta-Hydrological Model (also called the Meta-Flow for short).

Click to see full size

The aggregation of all of a given user’s Drops is that user’s Stream. Viewed in this way, if a Stream is what a single user produces, then the River is the confluence of disparate users’ Streams. I’ll describe this in more detail later.

Within each user’s Stream, ideas might coalesce into specific topics. I call these Channels (Stream Channels). Channels are Drops that are grouped under a specific topic to form substream categories.

The final part of the Meta-Hydrological Model is what I call the MicroBlogOcean (MBO). The MBO is the sum total of all microblogging activity in the global conversation ecosystem. It is all the conversations, represented by all the Rivers.

Below is a natural, visual representation of this model as seen from space.

Satellite image of the Amazon River delta from NASA's Landsat GeoCover Program

The MicroBlogOcean

As mentioned above, the totality of all microblogging activity is called the MicroBlogOcean (MBO). In this global conversation ecosystem, Drops are constantly being pushed to and pulled from the MBO cloud.

To provide and manage the myriad MBO services, a new type of SaaS model needs to be created. I call this software-based service a Confluence Hub. A confluence is the point where two or more bodies of water meet. Therefore, a Confluence Hub is the place where Drops sent by various users meet up, are processed, and wait for further action.

Notice User has only subscribed to User 3's Channel. Click for full size

This is how the process works. A user’s client sends a Drop to the closest Confluence Hub where an amalgamator combines them for transmittal to all that user’s subscribers. The Drops are organized by Channels, if any, and cached. If a Confluence Hub (CH) is down, then the Drop is automatically rerouted to the next closest hub.

An aggregate is a collection of items that are gathered together from different sources. The role of the client-side aggregator then, is to poll, to query the primary Confluence Hub Server (CHS) of each user Stream to which a user is subscribed, pulling the resultant dataset into their River on a predefined, regular interval.

Only the content the User wants gets through. Click for full size

So, whereas a user’s Drop is pushed to the closest, active Confluence Hub, the Drops of each user that they follow are pulled into their River from the MBO cloud.

Using our hydrological-based metaphor, Drops are created and stored on each owners’ site. This means any Drops that are de facto responses to someone else’s Drop are contained within disparate sites across the Web. Whereas the user’s client would cache all incoming Drops (in their River) and the application might even have an option to save a discussion to disk, the original Drop remains located in the owner’s Stream.

The Meta-Flow concept is not a perfect analogy to a natural hydrological flow. Whereas Drops do travel to Confluence Hubs, copies of those Drops are pulled into each subscribing-user’s client to form their unique River. The MicroBlogOcean therefore contains multiple references to the same original Drop and the Rivers actually flow out of the MBO rather than into it.

Although I personally believe this hydrological-based metaphor does a sufficient job of breaking down and describing the component parts of the overall decentralized microblogging ecosystem, for purposes of user understandability, the terms may need to be replaced with a more generic, globally-recognized nomenclature. Although, what is more globally recognizable than the water cycle?

Social Web Versus Social Network

When talking about the Semantic Web, it’s important to differentiate between social networks and the Social Web. These terms are not synonyms. In fact, the Social Web is not even the sum of all social networks.

Why is this the case?

Today’s social networks are nothing more than the famous walled gardens of the Web—as was previously discussed.

With their closely-guarded data silos, social networks are not full participants in the Web, they are not participants in the interconnected data ecosystem. So, unlike an ecological web (think of a food web), the Web-based Internet is not as much of an intact web as it is a land of social network islands that punctuate an ocean of truly connected websites.

The Social Web, on the other hand, is a fully functioning and healthy ecosystem were all data are globally connected. In my view, the only way to bring to fruition the promise of the Social Web is to embrace the Semantic Web.

The term Social Semantic Web is often used to differentiate between the current social-network based Web and a truly connected Web of Data. Since I believe that the Social Web requires the Semantic Web, I view the two terms as synonyms.

What might a truly connected Social Web look like?

I use this image as a graphical representation of what an open, fully linked, global Social Web would look like (see the caption for the actual description of the image). Imagine that each end point is a user creating their Drops that freely flow down their Stream, into their River, finally ending up in the MBO cloud. Each node, the point were multiple Streams converge, would be a Confluence Hub Server.

This image is a tracing of all the Internet traffic circa late 2006. It is licensed under a Creative Commons License (by-nc-sa/1.0) and created by http://opte.org/

Where would the big social networks appear on this graph?

Twitter would be a single point in this image with a few tenuous tendrils extending out representing the limited access that Twitter allows to their data silos via their proprietary APIs. There would be no lines representing conversations between users as the totality of conversation all occurs within the walled-off Twitter space.

The same holds true for Facebook, Google Buzz, FriendFeed, LinkedIn, and many of the other social networks. The lines connecting these services would be nothing more than gossamer strands representing the brute-force pushing of limited duplicate content between these data silos.

You might be thinking that conversations regularly occur between users of these platforms. For instance, I can choose to show my latest tweets on Facebook or LinkedIn, I can choose to display my latest Facebook or LinkedIn status updates on Twitter, and so forth. But these are not conversations. They are just snapshots of conversation that are occurring within other data silos.

Anatomy of a Drop

A Drop contains more than just the visible content, more than just the human-readable layer. A Drop is a packet composed of several layers, each providing additional metadata that makes the management and discovery of data more feasible.

Click to see full size

Content Layer: that part of the Drop that is actually intended to be seen by humans; also referred to as the droplet

Metadata Condensate: when the Drop is being assembled, different metadata layers are aggregated together, which are then deposited into a super-metadata layer. This layer encodes all the supporting data that makes extensibility, management, delivery, and discovery of the user’s Drop possible.

The Metadata Condensate layer is composed of five sub layers:

Rich-media Layer: pointers to associated audio, video, or picture files

Semantic Layer: the machine-readable, semantically-marked up metadata

Rights Layer: the granted usage rights for the Drop

Using the proposed Protocol for Implementing Open Access Data as a model, Drops, Channels, and even entire Streams could be marked with usage rights

Security Layer: WebID to tag Drop to specific user; whether Drop is public, private

Stream Management Layer: unique Drop ID; time stamp; GIS metadata (location-based tagging for mobile microblogging); Channel tag for grouping Drop content (allows filtering by other users); whether Drop is to be broadcast to all, a specific user group, or to one specific user; Drop broadcast delay; Drop time decay (a finite lifespan for Drop if desired); client metadata (whether Drop was sent via Web client, desktop client, via a CHS service, etc.)

Semantifying the Drop addressees several key issues that hinder current microblogging platforms. First, by providing a mechanism where machine-readable metadata can be effectively and efficiently associated with Drops, this unlocks each micro data silo, opening it up to outside services to access via query. Second, organizing, grouping, classifying Drops into Channels allows for meaningful filtering of users content. Third, by using a FOAF+SSL backed WebID, privacy and identity management across the MBO becomes possible.

Whereas users can still add tags (via micro and nanoformats) when composing each Drop–and maybe even some basic html markup, like the “a” link tag–the real benefit accrues from the automatic encoding of semantic metadata into the Drop.

Additional ontological encoding could occur on each Drop via a Semantic Interface Options box on the Drop composition panel.

It’s important to note that although each individual user will have the right to determine how much of their microblogging content is shareable across the Web and even with whom it can be shared, in concept, if a user is wishing to participate in the global microblogging community, it is assumed that they will wish others to see what they have to say.

This is just an initial concept of the structure of a Drop. It may be that one or more of the Metadata Condensate layers (or parts of a given layer) should be included under the Semantic Layer.

Since I’m basically working through Nova’s article archive in reverse chronological order, it may very well be that in the future, I’ll scribe thoughts on some of his even older ruminations. So, if that occurs, please pardon this information time dilation.

The Stream

I read Nova’s article, Welcome to the Stream – Next Phase of the Web, with great interest. With all the buzz about Google Buzz over the past eight days or so, this article made me think about the yet-another-stream phenomenon (YASP). *1

What is YASP? It is that somewhat exciting but ultimately frustrating realization that there is yet another social networking, microblogging, threaded-conversation service that you might have to join so that you don’t get left behind.

The idea of user streams is interesting. As I read Nova’s article, the imagery of a kayaker navigating down world-class rapids came to mind.

There is a qualitative difference in streams. Some streams may drizzle like a gentle shower, while others furiously flow like class-5 rapids.

Unfortunately, a higher flow rate does not necessarily equal higher quality. In my experience, there is a noticeable decrease in the signal versus noise ratio as the flow of each stream increases. This is why it is crucial to follow only those people with whom you are genuinely interested in hearing their thoughts. Simply following someone (or following them back) to build your follower numbers is a sure-fired way to increase the noise in your stream.

High Flow Is Not Always Healthy Flow

As users begin to tap into more streams, those streams usually start flowing faster. As Nova states, we need to create filters, or gates, that can discriminately select the signal from the noise, that can help to slow the flood of information.

Look at Twitter. As you follow more and more people, the rate of flow increases. In turn, you must work harder to fish the nutritious data from the swollen data stream. Eventually, the stream can become too treacherous to navigate. So, you either drop a number of people, thereby reducing the flow and hopefully increasing the signal to noise ratio, or you portage on over to another stream with more gently moving data.

This is exactly what some people did last year when they tried an experiment, switching from primarily using Twitter to only using FriendFeed. Of course, that stream quickly became a fast moving torrent as well. So, what’s next? Will these users jump ship once again, looking for the next, best, newest, and maybe calmer body of data to sail?

Well, we already have a new test underway with the introduction of Google Buzz. Many Twitterers have Gmail accounts and many of them activated their new Buzz stream. However, the early consensus from Buzz users is that Buzz is a Twitter-FriendFeed hybrid.

I tried using Buzz for several days but found that it was too much information being shared by too few people. It was a lot of noise and not enough signal.

Of course, my impression could also be the inevitable result of information overload. When you have too many concurrent streams to navigate–Twitter, Facebook, Skype, iChat, an IRC channel or two, email, and Buzz–it becomes a little too much to take in. So, what’s the answer?

Taking a Break From and Portaging Your Streams

The key to navigating successfully and safely in any fast moving, constantly changing environment is to get out of the flow every so often to rest and reassess the situation. Let the flow pass you by and take a break. The stream will continue to flow without you.

Even the best world-class paddlers have to get out of the rapids periodically and take a break. When they return to the stream, they concentrate only on what is ahead and never worry about what has already passed them by.

Sometimes, though, you have to take your kayak out of the water and portage to another stream. That’s an important lesson to us all. You cannot successfully navigate every stream at the same time. Pick a few streams to monitor at a time. Then portage on over to another stream or two for awhile, taking a break from the others.

What does this mean for Google Buzz’s future? What does this mean for other microblogging service providers that inevitably will come to the party, trying to get you to put another kayak into their stream?

Well, as the number of streams continue to increase and as the flow rate of each stream picks up, people will grow tired of having to subscribe to, having to join yet-another-stream phenomenon (YASP). Does the Web truly need additional stream providers each with their own data silos? Is there a user-centric solution to this rapidly growing, overflowing-stream issue that puts YASP to rest once and for all?

There is, which is the subject of my next post coming tomorrow this Friday—A Flock of Twitters: Decentralized Semantic Microblogging.

NOTE

1. YASP: Yes, I just made this phrase and acronym up. Feel free to spread it around the Web, turning it into yet-another-disgusting buzzword (YADB).

During the chat, Andy Peatling (lead BP developer and Automattic employee), presented an idea about breaking up development work into component teams:

I’d like to start breaking BP down into chunks, and find people that are really interested in specific features…so for example if you really love the activity stream functionality you could focus specifically on that, and stick to patching just this area…so the long term goal is to get teams on components and have that transition into core commit teams.

This has merit. As the complexity of the BuddyPress codebase expands, it will be increasingly difficult for a one- or two-person team to do all the core lifting. BuddyPress is a complex suite of plugins. It is a social-network-creating ecosystem full of hundreds of functions and classes. Breaking the workload into project teams is a sensible approach.

More Hands to Watch

But, this notion of modularizing BuddyPress core development made me realize that a single guy–that would be me–cannot effectively continue to maintain and update the BuddyPress Privacy Component. It is impractical.

As you already may know from my very successful fundraising drive for my BuddyPress Privacy Component, keeping the BP Privacy plugin up to snuff with each new release of BP is quite challenging. In effect, I have to be an expert on all the BuddyPress components.

If there will be project teams managing the future development of the BuddyPress suite of components, that means two things: 1) there will be too much information created by too many hands on which I need to stay caught up; 2.) there’s an opportunity to streamline privacy filtering.

Enter the BuddyPress Privacy API

Privacy should be a core feature of any social network. BuddyPress is no exception to this rule. So, I’m now thinking that the best approach to privacy in BuddyPress is via a Privacy Layer that provides a basic Privacy API which any and all components can access.

I’m now investigating how practical and possible it will be to create a Privacy Layer using my current privacy codebase. If it is something that can successfully be created without a significant amount of additional work, I will switch my efforts toward creating the BP Privacy Layer.

This means, that going forward, it will be up to each BuddyPress component development team to utilize the Privacy Layer (if they choose to), to tie their component into the Privacy API, and provide privacy filtering. That way, providing privacy will become a team effort and not just one guy playing catch up, running behind Andy, jjj, and all the component-team members who are furiously evolving the BuddyPress codebase.

Do you think a BuddyPress Privacy Layer is the best way to ensure that privacy becomes a core element of each component? Do you think a BuddyPress Privacy API is a desirable feature?

Here’s why I ask. Over the past several years, whenever Facebook has made a change to its privacy policies, it has caused great uproar—not only with civil liberties advocates (as you would expect), but also with Facebook’s user base.

The recent brute-force change to the privacy settings of all 350 million of its users is just the latest in a series of moves that exposes more of Facebook’s users’ information.

According to the above linked article, here’s what Zuckerberg said about the recent change:

Doing a privacy change for 350 million users is not the kind of thing that a lot of companies would do. But we viewed that as a really important thing, to always keep a beginner’s mind and what would we do if we were starting the company now and we decided that these would be the social norms now and we just went for it.

That last statement, “we decided that these would be the social norms,” is the telling truth. It is not that lack of privacy has become a social norm. It is that Facebook believes that it should be.

It is as if Facebook issued a decree to its global citizens. Privacy is no longer something you should request. Privacy is not in the best interests of our society (as in Facebook’s “society” or corporate mission).

Exposing more of its users’ data to the world is, of course, attractive to Facebook’s business alliances. It offers a number of new opportunities for profit. To a company rumored to be heading toward an IPO in 2010, new revenue streams and growing profits are a good thing.

But open data and opening up of personal data are two different issues. What pieces of your data should be open? Where do we draw the line? In general, as long as they are not breaking any laws, I believe it should be up to individuals to decide which pieces of their personal data are made public.

In a free society, we should strive toward letting individuals, not governments or corporations, be in control of their personal data. Collectively society should “own” the data with individuals given control over a subset of their personal data.

There are compelling reasons why opening up personal data to the world is desirable. But it should not be up to governments or corporations to make that choice on behalf of their citizens and users. In a free society, it should be the citizens who drive the push toward more open data, not a few elite power players who force the issue.

What do you think? Is Facebook engineering the expectation of lack of privacy? Are they forcing the issue and making it become a social norm by brute force? Is this truly what their users want? What rights should individuals have to control their personal data?

UPDATE February 24, 2010: See my article A Flock of Twitters: Decentralized Semantic Microblogging to see how users can take control of their own on-line communication streams.

UPDATE March 19, 2010: As this year’s keynote speaker at South by SouthWest Interactive (SXSWi), Danah Boyd presented a very thought-provoking keynote presentation on privacy in social media: Making Sense of Privacy and Publicity.

UPDATE May 2, 2010: The Electronic Frontier Foundation recently published a very illuminating article on this topic, Facebook’s Eroding Privacy Policy: A Timeline.

UPDATE May 8, 2010: An interesting graphic depicting what I call the devolution of Facebook privacy.

It means that you must disclose any financial relationship that you have with a product, service, company, or industry that you tweet about.

To make disclosure easy on Twitter, I’m proposing a set of Twitter-disclosure slashtags.

First My Disclaimer

I disclaim any liability. I am not an authority on this matter. I am not an attorney. This is not legal advice. I am only proposing a possible approach in this article. It is up to each individual or entity to understand fully and to follow properly the FTC’s new disclosure guidelines. You should review the new FTC guidelines and this proposal with your attorney.

Now, the Background Stuff

The newly-revised FTC guideline, “Guides Concerning the Use of Endorsements and Testimonials in Advertising,” is dry and not really a great read. It applies to all forms of advertising, not just online media.

In a nutshell, the FTC’s new guidelines require disclosure when you mention in any online medium:

• any product or service you’ve received as a free gift which you review / test / endorse
• any product or service you’ve been paid to review / test / endorse
• any company for which you work
• any industry in which you work

All of these constitute some sort and degree of financial relationship which you must clearly disclose on any blog, tweet, forum post, or any other social media format that exists.

Hey, I don’t make the rules. You can choose not to follow them at your own peril—up to $11,000 in fines for each infraction.

Examples, Please!

Here are two examples.

Yesterday, Google held a big media event to unveil officially their Nexus One phone. Soon after the event, Robert Scoble tweeted this:

.@gruber everyone at the Google Android event was given a choice. Either take a loaner phone for 30 days or take a free phone.

He then followed that with this tweet:

.@gruber I took a loaner phone because I’m not paying $300+ to cancel my Verizon account that I just bought just to switch to a nicer phone.

Anyone who attended that event and received a free Nexus One is required to disclose that fact if they make any type of comment about that product in any online medium. It does not matter if they were given a “loaner phone” for 30 days. The point is that they were given a product from a company for free. Even if it is for a limited time, there is an implicit assumption that they’ll derive some benefit and their views may be influenced by the gift.

Like Robert, a number of people openly tweeted that they were given the Nexus One at the event. I assume his disclosure should be sufficient in meeting the new guidelines.

Here is another example. Last week, Twitter was aflutter with reports that Kim Kardashian may be getting paid as much as $10,000 per tweet for product endorsements. I missed that because I do not follow her or bother paying attention to entertainment gossip. She has disputed this claim, so take the claim for whatever its worth.

The point is that if she gets paid any amount or is simply given free product or service, then she needs to disclose that fact in her tweets whenever she mentions the product or service.

Now, as tweet real estate is limited, I do not think that every time a person tweets about the company or industry in which they work, that they have to necessarily mention this fact. Although I could be wrong.

I would think it matters how well a particular person is known by the community at large. For instance, if you are well known in the industry, if most people know where you work, you can probably skip disclosing that fact each time. Only use it for new announcements. However, if few people know you, then it is wise to use the appropriate disclosure slashtags when talking about your company or industry. But again, it is up to you to verify this with your attorney.

More Details

I’m sure that you’re wondering which rules specifically apply to your blogging and tweeting. The part of the FTC’s new guidelines that appear to me to be the most relevant to this discussion is Section 255.5—Disclosure of material connections (see Examples 7 and 8 under that section).

Also, these three links discuss the issue in more detail:

• Boston.com article on bloggers and product placement
• New FTC Guides: disclosure comes to the social media masses
• What do the “FTC Guides re: the Use of Endorsements and Testimonials” mean for Social Media Marketers?

Disclosing in a Tweet-tight space

For purposes of our discussion, we will use the two example-disclosure statements suggested in the body of the post of the second link:

I work for Acme Widgets

and also

I’m an Acme Widgets customer. Acme Widgets has paid for my travel to attend this conference and golf tournament.

The first sentence is 23 characters long. The second, more verbose sentence, is 112 characters long.

Obviously, this is unacceptable for Twitter usage. You can’t afford to waste most of your tweet’s space with a disclosure of that length. With character space at a premium on Twitter (140 maximum), the first example is 16 percent of allowable message length, the second is 80 percent.

There needs to be a better, universally-recognized way to minimize character count while communicating a disclosure.

Enter the Twitter-Disclosure Slashtag

This set of proposed Twitter-disclosure slashtags is designed to be clear and concise, using only six characters each. The “$” symbol in the slashtag indicates that you have some type of reciprocal, financial relationship with the company, organization, industry, or product about which you are tweeting.

1. /$empl –> I’m an employee of this company / organization; I work at the firm that manufactures this product; I’m in the industry being discussed
2. /$exec –> I’m an executive at this company / organization; I manage the firm that manufactures this product; I’m in the industry being discussed
3. /$paid –> This company pays me to review / test / endorse their products; the company that manufactures this product paid me to review / test / endorse it
4. /$prod –> This product was given to me to review / test

Examples Using the Proposed Twitter-Disclosure Slashtag

Here are three example tweets:

IMO Xbox is the best gaming platform in the universe.

and

Apple just announced this game-changing product that will …

and

I love Stringy’s String Cheese. It’s the best!

In the first example, if you were given the product to test and review, then you should qualify your tweet with the appropriate disclosure slashtag like this:

IMO Xbox is the best gaming platform in the universe. /$prod

In the second example, if you worked as an executive at Apple, you should do this:

Apple just announced this game-changing product that will … /$exec

In the last example, if you were paid to endorse, or review, the product, you should do this:

I love Stringy’s String Cheese. It’s the best! /$paid

Making a Twitter-Disclosure Standard

As Andy Sernovitz states in his blog post:

Disclosure must be “clear and conspicuous”—understandable to the “average consumer.” This has always been the FTC standard. That means that hidden or unclear disclosure doesn’t count, and may even be interpreted as an attempt to evade the rules.

In other words, the use of these proposed Twitter-disclosure slashtags, while arguably conspicuous, may not be sufficiently clear in meaning to the average consumer.

The solution to this potential issue? I’m not sure.

However, there are many idiosyncrasies with Twitter that at first confuse all new users. If enough people blog about, tweet about, and actually use these proposed disclosure slashtags, then I think it could be argued that the FTC’s “clear and conspicuous” requirements would be satisfied.

When using Twitter, the average consumer already is required to learn the rules, quirks, and lingo. So what might confuse a new user should not be viewed as “hidden or unclear disclosure.” It is simply their lack of experience with the platform. A new Twitter user is not the average Twitter consumer.

To help push this proposal to the forefront of Twitter-disclosure debate, please tweet and blog about my proposal.

My Disclosure

For full disclosure on my part, I was not paid by anyone to endorse this proposal. I was not given free slashtags to test or use. I am not associated with the slashtag industry nor employed by any of its member companies.

What do you think

Will the new FTC guidelines change the way you blog, tweet, or participate in social media? Do you plan on following the FTC’s new disclosure guidelines? Do you plan on using these new, proposed Twitter-disclosure slashtags?

In a recent post, I asked for ideas on how WordPress ecosytem developers can earn a living doing what they love to do—coding great-quality plugins for WordPress, BuddyPress, and bbPress. This post is my attempt to try the time–honored (but more than likely ineffective) request–for–donation approach for my BuddyPress Privacy Component.

Please Note: The BuddyPress Privacy Component is not yet available. The below PayPal button is for donation to support development. It is not a paywall that provides access to a download link for the Privacy Component. All of my WordPress and BuddyPress plugins to date are GPLed and are freely available on the WordPress Plugin Repository. Once the BuddyPress Privacy Component is ready, I will make it available in the same manner. Only donate if you want to provide development support.

Support Level

Supporter $15.00 Donor $25.00 Sponsor $50.00 Benefactor $100.00 Patron $250.00 Open Source Angel $500.00 Holy Cow! $1,000.00

If you are a corporate user, consultant, plugin developer, or theme designer and profit from using my plugin, please consider donating at one of the upper levels. Thank you!

But, I’m going to go about this in a slightly different way. This approach is a serious attempt at doing things differently. I hope it does not provoke the ire of my readers.

How is my approach going to be different? Well, I’m going to be upfront and honest about the time commitment on my part to code, update, and support my BuddyPress Privacy Component. Then, I’m going to appeal to your sensibilities. If that doesn’t work, I’m then going to leverage your needs!

Please click the first link above and read that, if you have not already. Then, come back to this post and continue reading.

First a Caveat

Please be advised that the approach I’m about to detail will be controversial. This is my attempt at one possible solution to the question posed in the first link above. It is an experiment at best.

Do I think that this approach will be warmly received? No. Do I think that it will be successful? No.

But perhaps it will stir up healthy conversation and some tangible solutions.

The Ever-Changing BuddyPress Landscape

BuddyPress version 1.2 is fast approaching its public release. However, the underlying codebase has undergone major code refactoring and even significant changes in functionality. So much has changed that it will require a significant amount of time to refactor my Privacy Component codebase to function properly in the newly-overhauled BP platform.

I’m not complaining about the changes. I’m just stating a fact. I believe that BP version 1.2 will be superior to previous versions.

I’ve had discussions with a few other BuddyPress plugin developers who wonder if we’ll see similar codebase changes in future versions of the BuddyPress platform. At this stage, we have to assume that this is a real possibility. Therefore, it is only wise to plan accordingly, to assume that with each major new release, that parts of our plugins may require significant TLC. But again, when the dust settles, version 1.3 of BuddyPress will be superior to previous versions.

It’s Just Time, Right?

I currently estimate that it will take at least 30 to 40 hours of code refactoring and functional code changes to bring the current version of my BuddyPress Privacy Component up to working order for BP v1.2. Of course, not all of this time is for coding. A noticeable amount of this time is studying the changes to the BP codebase and figuring out how key object arrays, actions, and filters have changed. When version 1.3 comes out later this year, it may require a similar amount of effort. This estimate does not even take into account the incremental versions (1.2.x, 1.3.x) that could require fixes here and there. But, leaving the incremental version changes out of the equation, I estimate that this phase of the project will require between 60 and 80 hours of work in 2010.

Along with updating the plugin, support is another time sponge. I estimate that once my plugin hits the mainstream, that I could be looking at at least 5-10 hours a week for support requests during the first two weeks of a version release and then 10 hours a month until the next version is released. With two major BP privacy plugin versions assumed to be released in 2010, that equates to an estimated total of 100-140 support hours in 2010.

Finally, there is at least one big, missing piece of the privacy puzzle—group privacy filtering. Until development of BP v1.2 is frozen, I will not be able to provide an accurate estimate of how many hours it will take to code a full-featured suite of group privacy filters. But, I do know that there is talk of possible, significant changes to the groups component in version 1.3. So, once again, this is my best guesstimate. I’m assuming roughly 80 hours of coding to bring to fruition group privacy filtering.

What does this all add up to? The total estimated time required in 2010 to upgrade, maintain, augment, and support my BuddyPress Privacy Component is 240-300 hours. At my standard, weekly work schedule, that is roughly 4 weeks of my time!

This is more than likely an underestimate of the amount of time that will be required, but I’m using that figure to help me determine a realistic financial support request. Also, it does not include the hundreds of hours already invested in the current version.

An Appeal to Your Sensibilities

Now, of course I cannot possibly donate four weeks of my time on this plugin or any of my other not–yet–released BuddyPress plugins. Can you donate four weeks of your time for anything? Would you give up your vacation time (and then some) to provide free software programming and consulting services?

My goal is to recoup some of the time I’ve already put into developing this plugin, to fund the current and future upgrades and enhancements to this plugin over the course of this year, and to cover some of the support time I will inevitably be requested to provide.

Supporting Development, Developing Support

How is my donate button different than others? Well, it is not a donate button. It is a support this project button. It’s a request for action, an opportunity for you to show your support by buying into the project. If there is not sufficient support, then the project will be discontinued.

Without sufficient financial support, I cannot continue to develop this, or any other plugin. I need to have a reasonable cash flow. I have to contribute to the support of my family.

Based on my above estimates of the number of hours that I will be required to put into my BuddyPress Privacy Component in 2010, I’ve set a goal of $9,000. That adds up to an hourly rate of between $30 and $37.50. This, in itself, is a greatly reduced hourly rate from my previous consulting days. That is okay. I’ll consider the difference as my continued donation to the cause.

What Happens in 2011?

This request for financial support is only for 2010. So, you rightfully may ask, what will happen when 2011 rolls around?

By then, privacy in some form or other should be a core BuddyPress component. It will thus be maintained by the core development team—and I’d be willing to help them maintain it as well.

Of course, it’s possible (but I think unlikely), that privacy will become a core feature of BuddyPress this year. If it does, I very much doubt that it will be the fined grained, fully-featured privacy suite that I offer in my plugin. But Andy and JJJ are very clever guys. So, you never know!

What Happens if You Don’t Raise the Entire Amount?

Since PayPal allows for refunds to be sent within 60 days of receiving a payment, I plan to hold all proceeds in my PayPal account. In 58 days from the date on this post, I will assess the results. If the goal has not been met, I will decide if I’m willing (and able) to provide the entire year’s worth of work discussed above for the amount raised. If I decide to proceed, I’ll withdraw the funds from my PayPal account. If I decide not to proceed, I’ll issue a refund through PayPal.

So, on Monday, March 1, 2010, the final decision will be made.

BuddyPress Privacy and BP Version 1.2

Just to allay any fears, I have already committed to bringing my privacy component up to code to work under BuddyPress version 1.2. That will happen no matter how this little experiment turns out. The real issue is what happens from that point.

Wait, Open Source is Supposed to be Free

Most people expect software to be free these days, especially with Open Source projects. But the spirit of Open Source is not providing free (as in no cost) software. It is in providing freedoms in how you use the software. These two pages on Gnu’s website–the maintainers of the GNU GPL license which WordPress is licensed under–explain it very well:

• Selling Free Software
• The Free Software Definition

So, although it is customary in the WordPress ecosystem for plugin developers to offer their work for no cost, it is not what is intended by the GPL, it is not what Open Source is truly about.

Has the misguided assumption about free (as in cost) software become too ingrained in our community? Whereas designers who offer GPLed–premium themes seem to be accepted into the community without issue, developers who offer GPLed–premium plugins are often treated differently. There should not be a double standard. Both designers and developers should have the right to earn a living from providing great-quality free software.

My Plugins will Always Be Free

I believe in the free software movement, in the spirit of open source. I will always freely provide my plugins to the greater community. I’m truly not looking to sell my code. I am just looking for an acceptable vehicle (besides the consulting route) that provides some financial support so that I can continue offering high-quality (I hope!) plugins.

An Appeal to Your Needs

Now, I’m in no way intending to hold the BuddyPress community hostage. I’m trying to see if this idea will work.

Is privacy something that you think is important in BuddyPress? Is privacy filtering for your members’ data something that you need for your BuddyPress-based community?

If you have read this far, and have not unfriended me over at BP.org or unfollowed me on Twitter, then I am amazed! Actually, it does not surprise me. I assume that you agree that Privacy is of paramount import in BuddyPress, in any social network.

If privacy is something you value in BuddyPress, then I ask that you please help support my efforts. Tweet about this post (you can use the Tweet This! button on top), blog about my post, draw attention to my efforts in other ways, and finally, put a few dollars into the project’s coffers. I’ll then do all the heavy lifting!

Thank you!

Support Level

Supporter $15.00 Donor $25.00 Sponsor $50.00 Benefactor $100.00 Patron $250.00 Open Source Angel $500.00 Holy Cow! $1,000.00

If you are a corporate user, consultant, plugin developer, or theme designer and profit from using my plugin, please consider donating at one of the upper levels. Thank you!

The bar chart below and at top will update as support rolls in. The question is, will it roll in at all? If not, what are my options?

I think it is not only fair and appropriate, but also necessary for plugin developers to have the opportunity to make a living, or at least part of their living, writing great code that extends the base functionality of the BuddyPress platform.

To be clear, I am not an employee of Automattic. Like the vast majority of BuddyPress developers, I do not get paid a single cent for my contributions. In fact, as a salaried employee of Automattic, Andy Peatling, the lead developer of BuddyPress, is the only one who gets paid for his time working on this Open Source project (as far as I know).

Again, I am not looking to fan the embers of previous debates. I do not have any issue with how Automattic runs the WP plugin repository or care if they never list commercial plugins. That is not my point.

All I’m asking is how can plugin developers exist on an equal footing with theme designers when it comes to the issue of earning a living? Currently, the only three options that developers have, it seems, are to advertise a donate button for each plugin, accept consulting gigs, or accept advertising on their website. But donate buttons rarely provide much support and providing consulting services to clients is not for everyone. Furthermore, for me, I do not care to turn my personal website into a billboard.

The argument that plugin developers benefit by offering their work for free is flawed. It assumes that all developers are looking for consulting work, and two that all developers who offer their work for free will receive consulting work. Whereas it is certainly the case that some plugin developers have built a nice consulting business as a result of their donated work in the WordPress community, that does not mean that this route is for everyone.

What if a developer just wishes to code great-quality plugins like a theme designer designs high-quality themes? What if he or she does not want to provide any other service? How should this developer be compensated for their time?

But, since you asked, I do have a donate-like button for my BuddyPress Privacy Component. You can read more about my version of “donate” here.

I would like to hear some ideas on this topic as I have contributed much time to the BuddyPress community but have not earned a single penny. I am not looking to provide programming services or start a consulting company. I have a significant project that I’m working on so I don’t have time for much else.

Since I am not yet making an money on my project, I need a vehicle to earn some semblance of a respectable cash flow. Just as some theme designers earn a decent income from their premium themes, I would like to think that my income vehicle could be BuddyPress component development.

So, ideas and civil discussion, please!

After learning the rudimentary workings of OAuth, it quickly became clear that it did not offer a mechanism for internal access control, nor was it even intended to be used as an authorization protocol. I’ll discuss this last statement in more detail later.

So, to educate my fellow social media gurus, I decided it would be helpful to jot down what I learned and determined about OAuth, its intended use in any social media application like BuddyPress, and how privacy control needs to be implemented within BuddyPress.

What is OAuth?

From the OAuth Core 1.0 Specifications:

The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.

Therefore, OAuth is a set of rules and procedures that facilitate the exchange of data between websites without the requesting website requiring the user to provide his or her sensitive authentication credentials. This enables a greater level of security for all users.

Imagine if you had to provide your Twitter credentials (username and password) when installing the Twitter Facebook Application in your Facebook profile. Fortunately, Twitter now uses the OAuth protocol so your password does not need to be provided to and stored by Facebook. Instead, a token with defined rights is created and used by the Twitter Facebook Application to gain access to your Twitter data.

How Privacy Needs to be Implemented in BuddyPress

Whereas OAuth can provide access control to a user’s private data, or any URL with a need for access restrictions, it does so only between sites. OAuth is not a protocol used for internal access control; it is not an internal authorization protocol.

(Visit this post to learn more about Authentication Versus Authorization)

Again, from the OAuth Core 1.0 specification:

It is important to understand that security and privacy are not guaranteed by the protocol. In fact, OAuth by itself provides no privacy at all and depends on other protocols to accomplish that.

Therefore, BuddyPress requires its own internal privacy protocol. Enter, BPAz, my BuddyPress Privacy Component

BPAz is a necessary protocol for providing privacy to all BuddyPress users’ personal data. Once a given user’s data is sufficiently controlled by their BPAz access control list (ACL), they can feel more confident in exposing any data they wish to share across the Web.

BPAz is internal to a given BuddyPress install. It provides the mechanism whereby a give authenticated user can establish access rights—via an ACL—to their internal objects. The focus is on allowing users to have fine-grained control over their personal data. OAuth, on the other hand, is a protocol that facilitates the cross-site sharing of user content.

With BPAz, users can compartmentalize their data, to decide which pieces can be shared and with whom. OAuth can then generate tokens based on a given user’s ACL that allow clearly defined access rights to users in outside networks. Without the privacy filtering of BPAz, OAuth tokens would be very broad in scope, potentially allowing access to all of a user’s data with a single token.

Now, it is not as simple as installing my Privacy Component and suddenly your BuddyPress site is ready to safely communicate your users’ data to the outside world via OAuth. WPMU and BuddyPress first need to properly communicate with OAuth. This is on the roadmap for a future version. Once that happens, I will take a look at the code and figure out what, if any, I need to alter in my Privacy Component to properly communicate with OAuth.

So, the take home message is this. Authentication within BuddyPress is currently handled by a few internal core WPMU scripts. Authorization, however, is not yet a core feature of BuddyPress. My Privacy Component is an important first step in molding BuddyPress into a platform that can safely and effectively interact with other social media sites.