Doing unset on array leads to the final array turning into associative array
and gets blocked by the validator.
You can check that it's broken in Persian Wikipedia, beta cluster or
localhost. Tested locally, fixes the issue.
Bug: T337431
Change-Id: Ib1be294bae1ae057dfb9a4445a8e13ac72b333b9
Regarding array building: Instead of adding to array with
$array[] = 'foo' and then doing array_flip(), simply do
$array['foo'] = true;
Regarding tests: I originally wanted to create a unit test but I ended
up mocking so many things that it wasn't worth it and the config variable
is globaly which first we need to clean up after deployment is done.
Bug: T337431
Change-Id: Iac8dca7078668ee3441d19b6aafe499c1aa0d732
This is a direct follow up for I6373fa6 where we apparently fixed
half of the cases while breaking the other half. There was actualy
a code path that can return null, and anther one that can return a
status object.
Since there is never anything done with the status object we can as
well get rid of it and always return null in case of an error.
Bug: T337431
Bug: T279275
Change-Id: I2ccb58756182897bcd6649c9f589e2f7a0321b20
We will have a pretty large list of blocked domains that we need to
swift through in each edit for any added domain. In order to cacth
subdomains being added, we have to do all sorts of complicated
operations and string search in large set of strings which is quite
slow. To fix that, let's simply pretend a user who has added
foo.bar.com, also added bar.com and com and do exact match in array of
strings making it much faster.
h/t Krinkle for the idea
Bug: T337431
Change-Id: I96795ed7d1a25f051db0b591dde21b032b138ded
It is behind a feature flag. Improvements on it can happen in follow
ups. The patch is already quite massive.
Bug: T337431
Bug: T279275
Change-Id: I3df949c4d41ce65bb4afa013da9c691ac05fc760
