We were requesting read, write, and follow for the app, but not
for the user authorization. I've added these scopes to the oauth
redirect when logging in.
Put both show search and run search into the same route. This prevents
Lynx from thinking the search results were from a GET request and
caching the contents of the search page.
Reply-to accounts were compiled by getting the original poster + all the
mentions returned by the API. The OP now seems to be included in the
mentions, which duplicated that account in the list. I've stripped
it down so it just uses the list of mentions returned by the API now.
Implemented search across statuses and accounts. Replaced the old
search that was for accounts only and never quite worked right.
Don't load empty results when visiting the search page.
Implemented searching for accounts using the /accounts/search API
end-point. For some reason Guzzle consistently throws an exception,
so for now I've commented out the nav link to the search page.
If the user is logged in, send their token when querying for a status.
This prevents the API returning a 404 when the status being queried
is private or direct.
Created a new page to display account info. Just shows a link
to the user's home instance and their bio, plus indicators showing
whether the user is a bot and whether their account is locked.
I was re-using the same paths for a bunch of stuff in order to
minimise redirects (POSTing new statuses to the timeline, or performing
actions on a status), but then this breaks the behaviour of the
browser's refresh button. I've moved all those actions to their
own paths, which helps break up the code, makes the URLs more
semantic, and lets you use the refresh button without accidentally
performing an action.
This is at the expense of an additional HTTP request, but I've
tried to minimise the cost by passing through the status from the
previous action so we don't have to requery for it on the server
side.
Implemented a new page that shows a status context, though I'm
calling it a "thread" in the UI because I think that makes more
sense for users. Also moved the action element from the notification
into the event info component itself because I also want to use it
to indicate when a status is a reply.
Created a new page that displays notifications and added it to the
global nav. Abstracted out the pagination methods from the timeline
controller and put it in a helper class. Abstracted out the event info
(account, timestamp, etc.) into its own component.
Status routes were a bit of a mess and involved redirects,
which is only going to slow things down. I've amalgamated them
into one route and used query parameters to determine any actions
being performed.
St John Karp