In Firefox, prevents e.g. a slash in a stream name, which we wanted to store as
%2F, from converting back to a literal slash.
There is some appeal to normalizing the URL fragment after parsing, but in
general this way seems better. It may decrease page load time on narrowed
views.
Doesn't yet fix#826; the URL is correct but the narrow is still wrong.
(imported from commit 32e3fa9e968139863f34b9698f1c8b39d06f0c14)
This change could significantly load the database if pushed to prod at
the same time as:
send_message: Save rendered message content to the database.
goes out. So this should go out in a different prod push from that
commit.
(imported from commit 4e5a370bc43defb5083cac3df45c649cf2366abf)
The name of the archive directory doesn't actually matter, but this
is what we're running in prod, so our config in git should match.
(imported from commit c3fbba4f0c988811b11f2c21cf4a2a32327575aa)
Now that we can use our servers' DNS names internally, using
verify-full gives us a little bit of extra security.
(imported from commit 3a3715fa8a59851d4543112a55b5c6b24981442e)
This will automatically fix bugs such as one in which
internal_send_message didn't properly strip() the subject argument
before sending a message.
We change the recipient_type argument to internal_send_message to take
the recipient type name (e.g. 'stream') both to better fit the API and
also because the previous code incorrectly handled huddles.
(imported from commit 78c2596d328f6bb1ce2eaa3eed9a9e48146e3b6a)
This is preparatory for using this new arguments checking function in
internal_send_message as well.
(imported from commit 578e09c50b8a700c019c7dd235b2d9527af34e39)
This is often useful when working on a local development system and so
seems worth putting in the code, but is so verbose that it probably
doesn't make sense to have on by default in development.
(imported from commit ddb7ae4c83136f96d69368a245ed64e7daf66f34)
This cache should save 2 database queries whenever we send a private
message. However, previously it was per-process (which meant it was
mostly useless) and also buggy (it never stored anything in the cache,
so that it was completely useless). Switching this to our standard
memcached setup will address both problems.
(imported from commit 1d807f30704bccf28de33a80523488aedc58a9be)
This fixes a nondeterministic test failure for me.
The first message sent in the test suite appears to get dropped. I don't know
why this is, and I'm pretty sure it was an existing bug. This message used to
be the one disabling the tutorial, which might explain why that didn't always
work.
Regardless, this commit at least makes the test suite usable, and we can work
on fixing that bug later.
(imported from commit 063e40871b9883e3a6dab93a4e0a51c5b2dae4b7)
Previously we only used these caches for Tornado requests, because we
were not updating memcached when e.g. the user's pointer changed, and
so functions like update_pointer would not work correctly.
Now that we are updated memcached when the User and UserProfile
objects change, we can use these for all requests.
This saves 2 database queries on every Django request to the server.
(imported from commit aa5bffd885d14bde38b95e80a226bd5ab66f253d)
This was biting us before when the user would leave a narrow before a
get_old_messages call associated with it finished. Specifically,
search.maybe_highlight_message() would assume a message was in the
DOM when it wasn't any more.
We also have to hide the 'loading more messages' indicator when
reseting the 'load more' status because otherwise it wouldn't get
hidden like normal in the load_old_messages() continuation, causing a
load_more_messages() not to fire when re-entering a narrow.
(imported from commit 4a136dd01305b039c0970f897b07e603b87d5d8e)
This should substantially decrease the amount of server load generated
by the userpresence system.
I tested that this indeed was indeed saving one query on
/json/update_active_status requests on my laptop with 2 users from the
humbughq.com realm logged in.
(imported from commit 03e9d4eb95b9f664d489862684ae162db2076e08)
This cache filling code takes about 5 seconds to run, which means it
will finish before Tornado starts reading from this cache, but if that
were to change, it would be much better to have made at least some
progress.
(imported from commit 60a3420cdb9ddf331d83573a3fdb6be1a5ee5a4f)
Previously we were calling select_related() on Message.client, which
doesn't exist. It seems kinda poor that this doesn't raise an
exception.
I believe this issue was causing us to do very large numbers of
database queries during get_updates calls during server restarts.
(imported from commit b79bd698820fbd9dd82bd61fc175c32cd5ce6d05)
Keegan McAllister
Jessica McKellar
Leo Franchi
Tim Abbott
Jeff Arnold
Waseem Daher
Zev Benjamin