By the way, using

I used --prefix ZZZ to get things moving.

OK, from LocalSettings.php I took out

function JidanniLessSpecialPages(&$list){
  foreach(array('Uncategorizedimages','Unusedimages','Withoutinterwiki','Newimages','Listfiles','MIMEsearch',
		'FileDuplicateSearch','Filepath','Booksources','Mostimages','Tags','Disambiguations')as $i){
    unset($list[$i]);}global $wgUser;if(!$wgUser->isAllowed('editinterface')){unset($list['Ipblocklist']);}
  return true;}
$wgHooks['SpecialPage_initList'][]='JidanniLessSpecialPages';

and now it works. Gosh, I was just trying to reduce the clutter.

Suddenly on my wiki after the latest upgrade:

@Nemo_bis And here is the super fast HiNet connection in the city, which I am even more sure always succeeds uploading.

Now in the better connected city, 15 km. away, using
https://en.wikipedia.org/wiki/FarEasTone
I get

@Nemo_bis

Thanks. I submitted https://github.com/htacg/tidy-html5/issues/766 .

I found the share links:

Yes Google didn't say what line number the problem lay.
But e.g., on my pure html (non-wiki) site, jidanni.org, I simply started fixing from the closest placed elements, like <a>...</a><a>...</a> and before long pressing Google's "test again" button said "all OK".

1. Run your wiki through https://search.google.com/search-console/mobile-usability

OK as it turns out, it only affects http, and not https.
As I was planning to redirect all traffic to https anyway... I'll close the bug!

(It turns out that user really did forget his password. And I discovered the bug when I was unable to login and change it for him. One moment please...)

OK I can log in with a fresh chrome installation... so it is something on my $HOME/.config ... one moment please...

Compare UNIX
$ passwd
one can only change it via the terminal.

Yes I read
https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems
Also I can't tell if this is some cloudflare interaction...

Today I found a 4G+ high speed cell tower and uploaded from there instead.

The HAR file from the network tab is confusing because it is many
transactions glued together. 'nft flush ruleset' didn't help either.
Is there some way to ftp or email large (800 KB) .jpgs?

Chromium Developer Tools has these warnings

We try the alternative form, and before long:

Also one would think that pushing the retry button offered would start where it left off.
Instead it tries the whole failed escapade again.

"Could not proceed due to network connectivity issues. Make sure you have a working internet connection and try again."
with both Firefox and Chromium.

And here on http://wiki.osgeo.org/wiki/Taiwan_datums
we observe the final results end up in the wrong spot,
blocking the title.

(In fact there are even more movements visible to the user before this. Just not as obvious.) P.S., no other websites do this, unless intentionally.

On my wiki users are not supposed to mistakenly edit categories.

I don't think there is much chance I would be able to figure out how to make my function work again.

Oops. I see. I can no longer use this in LocalSettings:

I commented any extension out of LocalSettings.php. Problem still there.

1. Update Mediawiki
2. Click on a Category
3. Get Internal Error

OK but then need a --conf LocalSettings.php --conf Extra.php for convenience.

Simple, Special:Contributions/New_User_Name .

In fact even if we see breadcrumbs when viewing an existing page, they disappear when in the editor. or preview. Yes, saves one line of screen, but then one sees a less realistic preview... and thinks "looks like I will need to put some breadcrumbs there by hand."

Still not fixed. I tried
https://en.wikipedia.org/w/index.php?title=User:Jidanni/A&action=submit

There at the bottom there isn't even a "back to the place at top where I can push to get the next page" link.

Maybe have a mouseover that says "you can edit this in the URL bar."

I found the action=parse extremely useful for getting the table in
https://wiki.debconf.org/wiki/DebConf18/DayTrip#Industry_Tour_A
just right offline, before finally connecting to the network to send it to the server.

GitHub and Phabricator use smaller <textarea>s, (but I'm worried that they might have accessibility problems on text browsers where pure HTML is important...)

Yes!
And the update script should have
echo "**** ADMINISTRATOR: THERE WILL BE PROBLEMS....
echo ....
echo OK\?
read
exit 1

All I know is this is what happens when I try it on protected pages. I didn't try it on non-protected pages.
I see user_token = '* INVALID *':

This talk page button:

Yes, it should be clear to the user if the link contains content. That way he wouldn't have to waste a click just to find out that there is nothing there in the first place.

I saw the ":)" so assumed it wasn't a question to me.

In T173135#3525720, @Aklapper wrote:

• They are required for ensuring the correct display of brackets in mixed rtl/ltr environment.

So it is a bug that they are missing.

I'm thinking that if many pages depend on the broken behavior, then maybe there could be a zero width {{no-op}} operator, that one could put in the A or C positions, to ensure whitespace is not eaten... but this seems like just more badness...

But OK. if indeed they always mean what @Tgr says. Well then I'll close this. OK it is already closed.

@Tgr OK but I think this case is aggravated by the fact that sometime the
Mobile view looks just like the Desktop view..

As I mentioned they are at the bottom of every page (of every wiki I've ever seen. Even https://www.mediawiki.org/ has them.)

( It turns out T173133 was the actual issue here.)