For example the public timeline would show notices from a user with
private_stream configured. (previously it would only hide _new_ notices
by this user as they would be the only ones with notice scoping set).
If a new file is uploaded, it will be matched with a previously uploaded
file so we don't have to store duplicates. SHA256 is random enough and
also unlikely enough to cause collisions.
Should be the last one. If any URLs are longer than 191 chars, it might
require more manual interaction. Any instance with problems running
scripts/upgrade.php will get special treatment, help and a lollipop.
If this merge throws exception on scripts/upgrade.php and you recently
tried a nightly (i.e. during 2015-02-19) then just go back a commit or two
and try again.
Or delete the duplicate entries. Find the entries like this:
SELECT COUNT(*), urlhash FROM file_redirection
GROUP BY urlhash
HAVING COUNT(*) > 1;
then for each urlhash (or come up with a smart SQL query) do:
DELETE FROM file_redirection WHERE urlhash='hashfrompreviousquery' LIMIT 1;
You'll have to remove duplicates more than once if you have >2 identical
urlhash entries. LIMIT -1 might do that for you. I'm not sure.
Internationalization support is required for transliteration, which is
currently used when creating the slugs for hashtags and such. It is a
much more stable and efficient solution than having an unmaintainable
list of unciode characters in an array...
It's too farfetched to assume any text.com in a notice is an HTTP URL.
For example stuff like pasting from log entries, with domain.com:1234
where 1234 is a _PID_ or something, not a port number for http://...
After doublechecking two identities so that they match (like one that was
previously http:// but now is https://) we update the URI in our database
to match.
This has to be verified so it's not easy to fool our script and thus make
us replace legitimate URIs with fake ones. I believe the callback method
is safe, but I'm not sure how well it handles HTTP MITM attacks etc.
We prefer handling a Profile class rather than the User class, as some
functions might be useful for remote users as well, which cannot be
handled via the User class.
