Probably isn't related to StructuredDiscussions , https://test.wikipedia.org/w/index.php?title=Talk:Templete:TestOS&action=edit doesn't work either (under same conditions as described in task's description). Ending with tests for now, I'm in rush and noticed it when looking for something entriely different.

Viewing another exisitng talkpage doesn't work as well: https://test.wikipedia.org/wiki/Talk:Tto_page_536 .

I also get this on https://www.mediawiki.org/wiki/Wikimedia_Audiences?action=edit incognito in the office (where the IP is blocked to remind us to log in). Possibly related to the recent Partial Blocks work?

I think this is a train blocker.

d67121f6d3961bb7dfc44f71e8b5a4b8b9279eef touched the User::isBlockedFrom code specifically:

- public function isBlockedFrom( $title, $bFromSlave = false ) {
+       public function isBlockedFrom( $title, $fromSlave = false ) {
-         global $wgBlockAllowsUTEdit;
+               $blocked = $this->isHidden();

-         $blocked = $this->isBlocked( $bFromSlave );
-         $allowUsertalk = ( $wgBlockAllowsUTEdit ? $this->mAllowUsertalk : false );
-         // If a user's name is suppressed, they cannot make edits anywhere
-         if ( !$this->mHideName && $allowUsertalk && $title->getText() === $this->getName()
-                 && $title->getNamespace() == NS_USER_TALK ) {
-                 $blocked = false;
-                 wfDebug( __METHOD__ . ": self-talk page, ignoring any blocks\n" );
+               if ( !$blocked ) {
+                       $block = $this->getBlock( $fromSlave );
+                       if ( $block ) {
+                               $blocked = $block->preventsEdit( $title );
+                       }
                }

+               // only for the purpose of the hook. We really don't need this here.
+               $allowUsertalk = $this->mAllowUsertalk;
+
                Hooks::run( 'UserIsBlockedFrom', [ $this, $title, &$blocked, &$allowUsertalk ] );

Thanks for all the info. We are looking into this right now.

Change 470856 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Follow-up d67121f6d: Blocks can apply to non-User objects too

https://gerrit.wikimedia.org/r/470856

Thank you @Jdforrester-WMF

Change 470856 merged by jenkins-bot:
[mediawiki/core@master] Follow-up d67121f6d: Blocks can apply to non-User objects too

https://gerrit.wikimedia.org/r/470856

User::newFromName can return false with an IP address or IP/range (anything passed in other than a valid username. However, the code will throw the same fatal error with this patch since $user will be false

Change 470867 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@wmf/1.33.0-wmf.2] Follow-up d67121f6d: Blocks can apply to non-User objects too

https://gerrit.wikimedia.org/r/470867

(From gerrit.) @dbarratt: $validate is set to false, so this will always return a user, whether valid or not.

Change 470867 merged by jenkins-bot:
[mediawiki/core@wmf/1.33.0-wmf.2] Follow-up d67121f6d: Blocks can apply to non-User objects too

https://gerrit.wikimedia.org/r/470867

Mentioned in SAL (#wikimedia-operations) [2018-10-31T17:04:25Z] <jforrester@deploy1001> Synchronized php-1.33.0-wmf.2/includes/Block.php: Hot-deploy train blocker T208398 with rMW3a1f95d4d74c (duration: 00m 56s)

OK, this is fixed for the repro steps I had (both viewing https://test.wikipedia.org/wiki/Talk:Main_Page or https://www.mediawiki.org/wiki/Wikimedia_Audiences?action=edit from an IP that's individually blocked no longer throws a PHP fatal but work as expected).

Some concern about IP range-blocks and how they work, will check now.

Works for me (tested from hardblocked /24 range), thank you.

Thanks James!

Just tested on production testwiki: https://test.wikipedia.org/wiki/Talk:Main_Page

Appears to be working as expected. I can view the page while logged-out, logged-in as an admin, and logged-in as a non-admin. I cannot edit the page (which has Flow) as either logged-in or logged-out.

ping @Anomie, since this appears to be an interaction between the Actor refactoring and the new "partial block" code. The concept of a "block target" doesn't seem to properly align with the concept of actors.

In T208398#4711975, @daniel wrote:

ping @Anomie, since this appears to be an interaction between the Actor refactoring and the new "partial block" code. The concept of a "block target" doesn't seem to properly align with the concept of actors.

Yes, only blocks with TYPE_USER or TYPE_IP are actors. TYPE_RANGE and TYPE_AUTO are not, because a range or an auto-block can't "act" in the sense of creating a log entry, a revision, or the like.

Change 471018 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] Block: Clean up handling of non-User targets

https://gerrit.wikimedia.org/r/471018

Change 471018 merged by jenkins-bot:
[mediawiki/core@master] Block: Clean up handling of non-User targets

https://gerrit.wikimedia.org/r/471018