User ID 1 takes precedence at other User Logins

This is with the Facebook Status block I assume? D6.4, PHP5, MySQL5?

1) The module is designed to show the status of the author of the node you're viewing on pages with a URL of node/*, so what you're seeing is probably almost correct if you were just looking at nodes created by the administrator. If you don't want this behavior you need to build a custom block using the hooks provided; you can look at the module's code for assistance (look under hook_block() at case 0).

2) The problem you're having is because your site is located at /main/* instead of the root directory, and I completely didn't think about that when I built the module. The module detects if it's on a node or not based on whether arg(0) == 'node' && is_numeric(arg(1)). There's probably a similar issue on your user pages. So I'll have to go back through the module sometime today and rewrite some of the page-detection code.

*Sigh*... it's really difficult for me to test this, because I don't have any test sites set up that way and it takes too much time to go set one up...

Will you do something for me? Before I go override some core functions, can you create a page with the PHP input filter and this code?

  print $_GET['q'] ."<br />";

  global $profile;
  $file = 'install.php';
  $uri = preg_replace("/\?.*/", '', $_SERVER['REQUEST_URI']);
  $dir = str_replace("/$file", '', $uri);
  $url = drupal_substr($dir, drupal_strlen(base_path()), drupal_strlen($dir));
  print $url;

If my original diagnosis was correct, the first result will look something like /main/node/nid and the second result will look like node/nid. If I'm wrong, then everything should be working as expected, and I'm going to have to take another look at this one.

Hmm. That means arg() works as it should, so I was wrong about the cause of this problem.

...it looks like I was using db_result() instead of db_fetch_array() on a query on node pages that was supposed to grab both the UID and username. In an earlier version of the module there were two separate queries so it worked to use db_result(), but since I combined them I apparently forgot to switch to db_fetch_array().

Change committed to CVS, and the next dev build will be compiled at noon GMT. Let me know if it works for you, and if it doesn't go ahead and change the status of this issue back to active. If you don't want to wait for the build (it's only a very minor change) just change line 105 to use db_fetch_array() instead of db_result(), like this:

        $fbs_user = db_fetch_array(db_query("SELECT u.uid, u.name FROM {users} u LEFT JOIN {node} n ON u.uid = n.uid WHERE u.uid = n.uid AND n.nid = %d", arg(1)));

However, do update to the dev build when it comes out, because I fixed another problem where the status update form wasn't showing up on pages that aren't nodes or user profiles.

Yes, I meant the text box doesn't show up on non-user/node pages.

...that's how it used to be. It's not how it was supposed to be. If that's not what you want, you should copy-paste the code in facebook_status.module in hook_block() under case 3 into a custom block, and do this:

        || (arg(0) == 'node' && is_numeric(arg(1)) && db_result(db_query("SELECT uid FROM {node} WHERE nid = %d", arg(1))) == $user->uid)) //add an extra closing parenthesis on the end of this line (already added in this example)
        || (arg(0) != 'user' && arg(0) != 'node' && !is_numeric(arg(1)))) //remove this line

That will ensure that you get the functionality you want, but won't cause problems when you upgrade the module.

Thanks. :D

1) I personally use the Image module and a freetagging vocabulary combined with Views. This lets users create their own galleries with whatever name they want. The problem is that the galleries are open - in other words, anyone can add images to them. Taxonomy Access Control Lite may be one solution; I haven't tried it. Alternately, you could just create a gallery view that shows only images with a certain term from your vocabulary that are also by a given user. I hadn't thought about that until just now... probably a good idea to look into.

2) The issue will close itself after two weeks of inactivity, because it's marked as fixed.