Before: each one linked to separate page that contained "static" search.
After: each one links to generic search that is aware of current search.
Example: if you searched for "snow" and clicked "upvoted", you would see
all upvoted posts ever regardless of what you just searched for. After
this change, you will see upvoted posts that have tag "snow". Now, if
you go back to "all posts", you will see again all posts tagged with
"snow" with or without the upvotes. Similarly if you click favorites,
favmin:1 will be appended to your search. In order to totally reset your
search, click "browse".
Additionally, typing favmin:1 and scoremin:1 manually now selects proper
tab. Previously tabs were marked only if you clicked the tab.
Unfortunately, all of this had to happen at expense of URLs like
/upvoted and /random - now everything is represented with plain /posts/.
Rationale: some services thought that images linked from /posts/upload
are hotlinked. This is because they were receiving referrer set to a
host that is unknown for them. By using proxying, referrer is blank,
which increases thumbnail coverage at the expense of increased
server-side traffic.
- Moved thumbs folder to public_html/
- Users can supply custom thumbs of any size and the system will treat
them like normal image
- Removed distinction between various thumb sizes in file system
- Introduced custom rewrite rule, which isn't exactly good-looking, but
its benefits far outweigh its shortcomings
- Loading up to 75 times faster (was: 100-300ms, is: 4-10ms on my
machine) thanks to removal of PHP proxying
Restored JobArgs approach. Previous introduction of hierarchic argument
definitions has backfired: it was confusing what class to take arguments
from, the concept of sharing arguments between different jobs was
unintelligible and one never knew where given argument was actually
defined.
This appraoch makes it easier to maintain the arguments list and
simplifies the code a lot.
Reason: trying to make unique string for every possible argument in
global fashion is difficult. For example it would make sense for
EditPostRelationsJob to accept argument named "post-ids", but it
wouldn't make much sense for AddPostJob to accept "post-ids" since it
doesn't tell much. Thus, common arguments are going to be defined in
top-level AbstractJob for ease of control, while more job-specific
arguments are going to be specified in respective job implementations.
Since the purpose that StatusHelper was mainly created for no longer
holds, it was simplified to Messenger. It is now is used to transport
simple messages to views and still transports info whether the message
is about success or failure.
