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.
Statuses don't always start/end with block elements, which can
cause them to join up with the previous or next lines of text.
I've wrapped them in a div to make sure they're properly separated.
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.
Added an icon to show the visibility of a status (public, unlisted,
private, or direct). This goes next to the up arrow indicating
a reply, so this area can be used for other symbols regarding the
status' properties.
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.
Switched from using horizontal rules to divide articles to
making each article a list item. This is invisible to graphical
browsers, but makes identifying posts and reposts much easier
in text browsers.
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.
St John Karp
Alexander Yakovlev