Camo only proxies images hosted somewhere else, so it doesn't make sense
to add the proxied versions to search engines. It only creates traffic
for camo when /camo/* urls are in search results.
closes#7726
I overlooked this when reviewing #6418 since it is excluded on travis
because of the @nophantomjs tag (so it didn't fail). But since we block
http:// embeds now, we need to use https:// for the tests.
This is normalized to "true" in the config after running bin/bundle, so
rerunning script/configure_bundler resets this back to 1 (which is the
same, but we don't need to change this back and forth every time).
When there were posts with many followed tags they were returned
multiple times, resulting in less than 15 unique posts. That resulted in
some posts to be missed in the stream.
Fixes#4503closes#7715
We only return `nil` when we know the person, but don't know the key or
the key is invalid, so it doesn't make sense to retry in this case. When
the person isn't known and can't be fetched we raise a DiscoveryError
which will be retried.
Also the errors were moved to the `Signable` module in the last release.
closes#7717
Use this tag for tests which can't work with PhantomJS, but which we
can run with Selenium using some other profile (not implemented here).
closes#6418
Currently, git checks are performed on server start, even when outside a git
repository.
This commit verify the presence of a git repository (via `git status` exit
code), and perform checks only if it exists.
closes#7712
This is to let the author of the post know, that this pod is interested
in updates about this post.
The sending user is only used to verify that the participation was sent
from this pod, but lets use an admin/podmin account if available.
closes#7708
The limit was added in 2012 to prevent spam, but since the participants
need to be a mutual contact with the author nowadays, I don't think it's
a spam problem anymore.
Some people may remove their birthday date after the notification was
sent, which then breaks the notification page for other users. Let's
just display the date when the notification was created, and not display
the users updated birthday date. When users update from date A to B it
always looks weird anyway, when we display the same new date B twice on
different days, or display two different dates for the same user.
We could remove notifications when users change or remove their
birthday, but that would be way more complex and also we usually don't
remove notifications (not even for deleted posts).
Fixes#7689closes#7691
Some people may remove their birthday date after the notification was
sent, which then breaks the notification page for other users. Let's
just display the date when the notification was created, and not display
the users updated birthday date. When users update from date A to B it
always looks weird anyway, when we display the same new date B twice on
different days, or display two different dates for the same user.
We could remove notifications when users change or remove their
birthday, but that would be way more complex and also we usually don't
remove notifications (not even for deleted posts).
Fixes#7689closes#7691
