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.
For some reason the "retweeted to me" part of the Twitter API was removed
when Evan made some inbox changes back in the StatusNet days. We might
recover this functionality, but not yet. The proper function calls are
however fixed in this commit.
We should actually not allow remote images to be given in the src attribute
because they can be used for tracking and other nasty stuff without being
seen by the enduser.
Also, allowing remote images linked like this won't work for users who run
plugins like RequestPolicy etc. anyway. A better method would be to make
them listed as attachments instead. Then we can use that subsystem for
making thumbnails to store locally, hotlinking sources and whatnot.
It seems to have caused a problem with at least an older codebase of
remote GNU social sites, but either way we shouldn't present the user
as aliased on an insecure connection if there is no real reason to.
