Best Of

He has fixed the issue by replacing the htaccess file with the old one that comes with 2.1 which looks like this

# Modified
# If you modify this file then change the above line to: # Modified
<IfModule mod_rewrite.c>
   RewriteEngine On
   # Certain hosts may require the following line.
   # If vanilla is in a subfolder then you need to specify it after the /. 
   # (ex. You put Vanilla in /forum so change the next line to: RewriteBase /forum or whatever name you have given your forum if in a subdirectory)
   RewriteBase /
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule ^(.*)$ index.php\?p=$1 [QSA,L]
</IfModule>

Sure thing: http://ds.michael.tyson.id.au/9BIEgL4NX7.php (save it to plugins/Facebook/class.facebook.plugin.php)

Sure, it's a possibiliy. If you backup your .htaccess file, you can try the old version: https://raw.githubusercontent.com/vanilla/vanilla/release/2.2/.htaccess

A warm welcome and congrats for your success so far!

I'm impressed from the solution you were already giving since that looks quite good. There are five things that come to my mind when looking at that problem:

1. Database caching

When you open a page a query is made and when you do exactly the same query, chances are high that the same query has been cached and has no impact. The way you do this creates a new query which is completely "useless" for any other reason.
If you would not limit the result to 1 row, but instead query page one and page three if you are at page two by using the comment models getByDiscussion method, you would initiate the query that the user most probably has made right before the current page view and which he will most probably do right after this page view.
If you attach a ->resultArray() after the getByDiscussion call, you would be able to retrieve the first and the last comment very easily.

2. Simple SQL

Have you taken a look at the getByDiscussion method? The query there is quite complex and includes a lot of extra information which isn't needful for you. I would consider that method a "heavy" method and not use it if there weren't any benefits in there.
A simple SELECT * FROM Comment WHERE CommentID < (lowest comment ID displayed) and DiscussionID = (the current discussions DiscussionID))->lastRow(), would do the trick. Maybe ordering by desc CommentID and limitting the results to 1 would be even better.
Compared to what is happening in in getByDiscussion, that is really lighweight.

3. Change the initial query to include your results

I'm not sure that this would really work, but it could be worth a thought...
Use the "BeforeGet" event in the CommentModels getByDiscussion method. The limit as well as the offset is passed to that event and can be influenced by you. So you could check if the offset is 0 (you are on the first page). If yes, increase the limit by one to include the first comment from page two. If the offset is above zero, increase limit by two and decrease offset by one to also include the last comment of the previous page.
Use the AfterGet event to strip off both of your comments from the resulting dataset and use them as you need to.

4. Whatever you do: would caching be an option?

This is not a solution, just a hint. When 100 people look at a discussion and that results in some more queries, there is no problem. But wouldn't it be great if your plugin would be used in a forum for 100k members or even more? It should scale well, then.
Scaling is best done by using some sort of precalculation and caching.
Precalculation: each comment has an "Attributes" column where you could store "meta" information. Maybe you could use that? Would adding a "PreviousCommentID"/"NextCommentID" be helpful? If yes, don't forget to handle splitted discussions and deleted comments! And whenever you need that information, see if the info is in the first and last comment of the current page. If not, determine if it has to be fetched and if yes, get it and write it to the Attribute column so that it must not be fetched any more.

Caching: if adding meta information to comments isn't helpful in your case, think of caching the result of your query.

$LastCommentID = Gdn::cache()->get('LastCommentIDDiscussion42Page3');
if ($LastCommentID === Gdn_Cache::CACHEOP_FAILURE) {
    $LastCommentID = (sql result)
    Gdn::cache()->store(
        LastCommentIDDiscussion42Page3,
        $LastCommentID,
        [Gdn_Cache::FEATURE_EXPIRY => 3600] // 1 hour
    );
}

That way the impact on your database should be quite low, to. If you often delete comments or split discussions, you should consider using a smaller amount for the cache, since invalidating it with such a cache key is quite uncomfortable.

5. Why? ;-)

Is that really needed? What is it that you try to achieve? You only said what you try to do and not why you want to do so. Maybe there is a better approach if you could explain the reason why you want to fetch those comments.

And without knowing the reason why, I think that I'm not able to advice what's best. But I'm a fan of precalculation. In this case deleting a comment would require a somewhat complicated treatment, but since the benefit of precalculation is that you only have to make extra queries twice per discussion page and afterwards the required info will always be available, would make this my favorite solution.

Is it only you ? make sure it's not a cache issue. Sinking does not put it at the end, it just progressively lowers it in the list. Maybe someone else can chime in..

google is your friend.

http://stackoverflow.com/questions/234723/generic-htaccess-redirect-www-to-non-www

You change the sort order in the config.php

As far as I know the sphinx search plugin offers something like that.