If "logged in" is being forced anonymous on certain routes, trigger
the protection for any requests that spend 50ms queueing
This means that ...
1. You need to trip it by having 3 requests take longer than 1 second in 10 second interval
2. Once tripped, if your route is still spending 50m queueuing it will continue to be protected
This means that site will continue to function with almost no delays while it is scaling up to handle the new load
Previously under some conditions message bus could continue firing
even if a user is logged off.
This change ensures that under all conditions once server informs
client of a log off, client stops talking to server
If a particular path is being hit extremely hard by logged on users,
revert to anonymous cached view.
This will only come into effect if 3 requests queue for longer than 2 seconds
on a *single* path.
This can happen if a URL is shared with the entire forum base and everyone
is logged on
When there is a topic draft in place instead of showing "+ New Topic"
we will show "+ Open Draft", this allows topic drafts to be much less
intrusive.
Also, fixes draft handling of tags
This stops crawlers from hitting tags and category rss feeds to discover
new content, instead they should focus on latest/posts if they need to
consume something regular
Crawlers love hitting the rss feeds (confirmed that both Google and Bing do)
Experimenting with the impact of blocking these feeds and forcing Crawlers to hit
the content direct. It is better if they hit the actual page to start with as opposed to
1. Hit RSS feed
2. Find new content
3. Hit post link
4. Get canonical
5. Hit canonical
Lots of pointless work.
We do not know for sure what impact this will have on newsreader apps,
we will listen for feedback.
In some cases add_groups and remove_groups is too much work, some sites
may wish to simply synchronize group membership based on a list.
When sso_overrides_groups is on all not automatic group membership is
sourced from SSO. Note if you omit to specify groups, they will be cleared
out.
Also moved to default crawl delay bing so no more than a req every 5 seconds is allowed
New site settings:
"slow_down_crawler_user_agents" - list of crawlers that will be slowed down
"slow_down_crawler_rate" - how many seconds to wait between requests
Not enforced server side yet
bing is crawling our properties 10x faster than any other crawler,
until default behavior is improved we are blocking it out-of-the-box
You may enable it by setting the blacklist back to empty
Note, current practice if for plugins to submit PRs to core for any
migrations required for plugins, so we can better control schema.
Especially if core tables are being touched.
In this case index has close to zero cost unless akismet is installed
This reduces the akismet admin query from 20ms on every new page load to 0.5ms
Often we need to amend our schema, it is tempting to use
drop_table, rename_column and drop_column to amned schema
trouble though is that existing code that is running in production
can depend on the existance of previous schema leading to application
breaking until new code base is deployed.
The commit enforces new rules to ensure we can never drop tables or
columns in migrations and instead use Migration::ColumnDropper and
Migration::TableDropper to defer drop the db objects
We trust staff + tl2 and up to perform edits in grace period.
Allow them significantly more edit room in grace period prior to storing
a revision.
editing_grace_period_max_diff_high_trust applies to users with tl2 and up.
So
tl0 / 1 : we store an extra revision if more than 100 chars change
tl2 and up : we store an extra revision if more than 400 chars change
We may tweak these numbers as we go.
If a user performs a substantive edit of 20 chars or more during grace period
we will store a revision to track the change
This allows for better auditing of changes that happen during the grace period
In the past we debounced all dock check this causes situations where
sometimes timeline would not dock in time especially on slow computers
This works around it by performing the dock by hand.
Also there was missing integer casting causing over aggressive re-rendering
In the past we used suppress_from_homepage, it had mixed semantics
it would remove from category list if category list was on home and
unconditionally remove from latest.
New setting explicitly only removes from latest list but leaves the
category list alond
Sam