Occasionally, the Facebook-style Statuses module has problems. Usually, these problems are actually a result of a bad upgrade or a misunderstanding rather than an actual bug in the code. This page aims to help you solve problems of this type.

Something's broken.

Oh, that's too bad. [Read How to report bugs effectively and see the next question.]
 

Something's broken. Here are the exact errors I got on the page, here are the errors in my log; this is what I expected, and this is what happened; and here's how you can reproduce the problem, which appears on these pages for users with these permissions. My PHP version is... and my SQL type and version are... and the browsers I'm using to test are... other relevant modules I've installed include... steps that I've taken to solve this issue on my own include... This site is [multilingual / on a subdomain / not in the root directory]... This FBSS installation is [fresh / an upgrade].

Great. Try these steps:

1. Delete the facebook_status folder from your modules directory.
2. Replace it with a copy of the latest development version, or a stable version if it is newer.
3. Run update.php.
4. Go to admin/build/views and click "revert" next to all the views offered by Facebook-style Statuses, if a "revert" link exists.
5. Try using FBSS again. If your problem persists, check the issue queue and the rest of this page to see if the problem has already been reported. If it hasn't, open a new issue with the information indicated above.

If you get sent to read this from an issue, the point is probably that you didn't provide nearly enough information. Give as much information about your problem as you possibly can, and then some. Also, if someone who is helping you asks for specific information, provide it -- all of it -- exactly as requested, even if you think it's obvious or not relevant.
 

The list of statuses shows up with the statuses on their own line, but I want the statuses inline with the author name and date.

You have assigned an input filter to run over the statuses which automatically wraps the status in <p> tags, causing the behavior you're seeing. You should switch input formats, and you should probably create a new input format specially designed for statuses.
 

Authorized users only see "n/a" when they look at statuses, but administrators see the correct status text.

You have assigned an input filter to run over the statuses which has permissions too high for ordinary users to see. You need to switch to an input filter with lower permission levels, and you should probably create a new input format specially designed for statuses. (This does not happen in versions after 2.3.)
 

PHP source code appears where the empty text for my Views should be.

That's because there is PHP in the empty text of your view. Either edit your view and enable the PHP input filter (you must have the PHP module enabled) or edit your view and clear the empty text.
 

When I click on a #hashtag in a status, instead of going to a listing of statuses with the same tag, I get a "404 Page Not Found" error.

There are several things that might be configured incorrectly. First, on the advanced settings page at admin/settings/facebook_status/advanced, you must set a vocabulary where the #hashtags will be stored, and you must have the path for the status listing filled in (the default should be fine). Then, you need to edit the view that generates the hashtag list (admin/build/views/edit/facebook_status_tags). First check that the path is the same as the one you filled in on the settings page (it is by default). Then click on Facebook-style Statuses: Tag Name under "Arguments" and make sure that the vocabulary enabled for #hashtag validation is the same as the one specified on the settings page. The last step is usually the one most people miss, although it works by default for many people. Also note that Views has a bug when dealing with arguments with hyphens in them, so for the moment this problem is unavoidable for tags with hyphens.
 

When I look at a status form, I see an error like warning: preg_match_all() [function.preg-match-all]: Compilation failed: support for \P, \p, and \X has not been compiled at offset 14 in /facebook_status/facebook_status_tags.module on line 348.

Your server is probably running CentOS, which by default comes with a poorly customized version of PHP which includes a version of PCRE compiled without UTF8 support. What that means to you is that the Facebook-style Statuses Tags submodule will not be able to support international characters in your tags. (Complain to your hosting service, not to me.)
 
Luckily, there is a way to at least avoid the errors. Go to node/add/page or equivalent, set the Input Format to PHP, copy-paste the following code in the body textarea, and click the Preview button. You can then exit that page and try FBSS again.

variable_set('facebook_status_tags_alt_pattern', TRUE);

I installed the jQuery Autogrow plugin following the instructions on the FBSS project page, but the textarea doesn't grow enough in certain browsers.

You're probably using a theme that does something unusual with the CSS line-height property. Try adding this to your theme's stylesheet:

#edit-fbss-status {
  line-height: 1em;
}

I can't figure out how to get status streams on nodes.

1. Put the Facebook-style Statuses block on nodes.
2. Profit.

The status update form will automatically know to post status updates submitted on node pages to the relevant node, and the default facebook_status_stream view associated with the form will automatically know to show only statuses posted to that node.
 

Statuses posted on one node show up in the streams on all nodes. OR The status update box appears but the stream of statuses does not.

You may have mixed up the order of the stream contexts at admin/settings/facebook_status/contexts. The default (and recommended) order is:

1. Organic Groups (if you have OG enabled)
2. Nodes
3. User profiles
4. Terms
5. General

If you want statuses to attach themselves to taxonomy terms, put the "Terms" context above "User profiles." The "General" context is site-wide, i.e. any statuses posted in the general context will be visible on all "general" streams, so it should usually go at the bottom.
 

If a status message starts with a # the word won't turn into a term with the Convert line breaks into HTML input filter enabled.

The problem is that the Convert line breaks into HTML (i.e. <br> and <p>) input filter (which is enabled in Drupal's default input format) wraps status updates in <p> tags. When the Tags submodule gets the status, it looks like <p>#term status</p> and the sequence >#word doesn't register as being a separate term. To fix this, disable that input filter and use the module's "Convert line breaks" advanced setting instead. See #1353590: If a status message starts with a # the word won't turn into a term with the Convert line breaks into HTML input filter enabled for more information.
 

You're awesome. How can I be awesome like you?

Help out in the issue queue by answering support requests. Or, learn the API and help write patches for some larger issues. Even better, learn the Drupal APIs and create your own awesome (but well-maintained) modules that can help the community.