My first thought was that sitemaps made sense back in the days when dinosaurs roamed the internet. Then I looked at https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview to refresh my memory of why they exist. The main purpose is to enable web crawlers to find pages which aren't reachable by following the link tree from your main page.

How would you feel about having site_detect.py:check_response() raise ServerError if response.status_code == 403?

Interesting. It seems to be platform dependent.

Oh, I see how this works. WikiHTMLPageParser overrides handle_starttag() which calls set_api_url().

I don't understand why this failure is specific to github. It's failing for me as well on my MacOS laptop.

You posted two screenshots (IMG_7394.PNG and IMG_7395.PNG). How did you generate those, i.e. what do I have to do to view those two different versions of the page on my phone?

Could you post the URLs used to generate those? I tried scaling them to phone-size on my desktop, that's not a good comparison because the desktop's monitor doesn't have anywhere near the resolution my phone has.

Sorry, this is a duplicate of T331486

Hi. Sorry it took so long to get back to you. On https://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know, on the page I've got:

The example I gave in T329063 is now working better.

@TheDJ before I do that, is there any value to the people trying to debug this to my leaving things they way they are now, since it seems I can reproduce it and nobody else can?

I'm seeing this again. I again have in my console:

I just saw it happen again on https://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know#Prep_7:_Chicago_station_(CTA_Logan_Square_branch)_(nom)

This reminds me of T326996.

The particular thing I wanted to do today is move a python wheel file which I had built on my local dev machine and wanted to install on toolforge. Checking the wheel into git would make no sense. The way I currently install my app is indeed to push the source to git and pull that down into toolforge, but I'm exploring if doing wheel installs would be simpler.

I'll add one more comment. Sometimes I've copied what I need over to /tmp because it's world writeable and worked with it there. From any rational security analysis, that's the wrong thing to do, but sometimes you need to get something done and you find a way to do it. If you make it easy for people to do the right thing, they'll do it. If you make it difficult for people to do the right thing, they'll do the wrong thing if that's what lets them get their work done.

Just noting that I've run into exactly this same issue (see this thread). So I'll add my voice to supporting getting this implemented.

I haven't seen it again after I reported the original incident. But I'll let you know if I see it again.

FWIW, I described another way to reproduce this on enwiki vpt

Interesting. Yes, I'm seeing javascript errors on page loads (even before I try to edit anything). It's not entirely reproducible, but they're all variations on:

I can even replicate it on my desktop, using Chrome's mobile device emulation. For example, looking at https://en.wikipedia.org/w/index.php?title=User:RoySmith/sandbox&oldid=1138008943&useskin=vector2022, emulating a Galaxy Fold at 280 x 653 pixels. This one is using my normal (User:RoySmith) account, MacOS 12.6.1 Chrome Version 109.0.5414.119 (Official Build) (x86_64)

On the phone, it's my mobile account, which is totally generic. I see the same issue logged out in an incognito window.

With the explicit useskin=vector URL, the high-order digits overflow onto the grey left-side navbar, but they're visible on both the 6a and the X4.

Both of my examples are using Chrome.

On my Moto X4 running Android 9, there's enough room for 3 digits, so this appears to be browser or device specific.

For what it's worth, after working with this system for years, I still have no clue which alerts go under which icon. If I see an icon is activated, I go look at it. I really don't make any kind of prioritization about, "Oh, that's only the XXX icon, I'll look at it later".

OK, so it seems like what has to happen is to define a new subclass of ABUIC, called null_interface. It looks like it could be almost the same as buffer_interface, except that it wouldn't attach any handers at all. Maybe instead of:

I assume the CC button turns on closed captioning? Given that it's going to be illegable at this small size, I don't see the need for the button at all. And showing the user how long the clip is (0:14) seems secondary to me, so I'd leave that out below some size threshold.

And another one:

@taavi Any thoughts?

Could I get an update on progress being made on this? I got another cluster of three of these a few days ago:

Hmmm, yup, working for me now too.

These are still happening. I got two more in the past few days:

OK, I guess that explains my initial confusion, but I'm not sure that's a good thing. People learn were stuff is. If stuff moves around depending on some state which may not be obvious (as in this case), that's confusing.

I tried it on beta. Looks good, thanks.

I already mentioned this on the enwiki RFC, but the current implementation increases the width somewhat, but still enforces a limit. Gadget-wide-vector-2022 does the right thing. Here's some screenshots:

@Urbanecm My understanding of +x for directories is that it it allows the directory to be used as part of a pathname (i.e. translating the path into an inode). Which effectively means you can't access the files in it. The fact that you can't cd into a directory is just a side-effect of that.

I have taken myself off the gerrit review list, as I'm not familiar enough with the code base to give useful input on this change.

@Xqt I don't understand your question.

just for fun, I patched my venv with a symlink:

Oh my, look at the warning message:

Good to see this got reopened by itself :-)

The issue of coordinate location came up on the Vector2022 office hours today. I wasn't paying full attention to that particular discussion, but the gist was "absolute positioning is not a good thing" :-)

Thank you.

My apologies for being unclear. It's with the instance that I patched to use the newer redis-py.

Can the Vector 2022 team publish a spec describing what types of DOM manipulations are allowed, and/or the appropriate hooks to perform them, and provide assistance in figuring out what went wrong in this particular case? In the ongoing RFC, it was stated that the team has committed to "Working in collaboration with gadget creators or other interested developers to fix gadgets by providing support and guidance. This could include anything from advising on why a certain gadget does not work to providing specific code snippets as fix suggestions". Closing a bug report on a incompatibility with a gadget as "invalid" does not seem like it is living up to that commitment.

It's worth noting that since the hash is constant for a given recipient, if you suspect you know who the recipient is, you can verify that by sending that recipient an email and then running CU on yourself to see what the hash is. I don't know if that's a good thing or a bad thing :-)

I think this is due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982756

Just got another one:

Just a status update on this...

I object to this being closed as "invalid". There are lots of gadgets which have been in widespread use for a long time which do similar kinds of DOM manipulation. If the skin is going to break all of them, that's a problem with the skin.

This appears to be triggered by Preferences / Gadgets / Change UTC-based times and dates, such as those used in signatures, to be relative to local time.

Wow, this is weird. It was starting to look like having spaces in the fragment was the problem, but I can't quite reproduce that either. In any case, these two URLs work properly:

It still happens with an empty common.js (https://en.wikipedia.org/w/index.php?title=User:RoySmith/common.js&oldid=1112513431) but safemode=1 makes the problem go away.

I guess I should introduce myself. Others will be taking the lead on mentoring, but I'm available to provide help as required. My main area of expertise relevant to this project is Python. I also have some decent familiarity with the Toolforge environment, but wouldn't call myself an expert in that. I'm only slightly familiar with the front-end javascript stuff, so probably won't be able to help at all on those topics. I'm a big fan of Test Driven Development, and would be happy to help people get up to speed on that.

I see I'm a few releases behind on redis-py (I'm on 3.5.3). I'll upgrade to the latest (4.3.4) to see if that makes any difference. There's a few changes mentioned in the redis-py release notes that have to do with handling connection timeouts better, so maybe one of them will fix this. Worth a shot.

Here's another one from earlier today:

Thanks for the screenshot.

Is there a screenshot of what the new dialog box will look like?

This link gets you direct to the archived discussion mentioned by Alsee.

It looks like there's another example of this reported on enwiki Village pump

Just noting I got mail from a second person caught by this. They noted, "I tried to understand, but could make no sense of the information presented"

As for why it's a png in a pdf, I blocked out the fields using annotations in the MacOS Preview app. The black boxes are undoable in the Preview file, so I did a print-to-pdf to make sure I had securely hidden the data under the black boxes.