Special:WantedFiles does not pick up images used in infoboxes, for that they would need to be used elsewhere using mediawiki format for files. There is no way that I am aware of to make it pick up from infoboxes. I apologise for the inconvenience.

On my own wiki, both those mentioned issues seem to work as expected, Can you please link me to yours so I can see if the issue happens for me?

Per the documentation:

How does it select images?

All images in the page are collected and a score for each image is calculated.
The image with the highest score is selected as the page image.
If the wiki is configured such that images contain metadata that specifies images are not freely licensed, the image with the best score that is also freely licensed is also stored.
If no suitable image is found or all the images score badly (i.e. has a negative score), the page will not have any images.

If $wgPageImagesLeadSectionOnly is true, only images in the lead section will be considered.
Currently it is true for only Wikipedia projects, all other projects can pull images from outside the lead.

How are images scored?

The best possible page image on Wikimedia wikis is one of the first four images in an article which has a width/height between 400-600px and a height/width which is twice the value of the other dimension.

• The algorithm is configurable.

• Scores are calculated by a combination of:
  • Image widths as defined in $wgPageImagesScores['width']
    • In Wikimedia wikis, images smaller than 119 pixels are weighted highly negatively. Images with widths between 400px-600px are favoured, with a preference for the lower bound.
    • Images inside galleries are scored separately using $wgPageImagesScores['galleryImageWidth']
      • In Wikimedia wikis gallery images which are smaller than 100 are disregarded.
  • Position in document is also considered as defined in $wgPageImagesScores['position']
    • On Wikimedia wikis, only the first 4 images that appear in the document are considered.
  • The ratio of the image's width to height is considered $wgPageImagesScores['ratio']
    • On Wikimedia wikis a ratio of 0.4 to 3.1 is allowed, with 0.6 to 2.1 preferred. Any other images will score negatively and be discarded.

Per above. I will update the skin soon.

Thanks for the report! It is now fixed in upstream.

Per above this is likely to be resolved in this way. If it isn't please feel free to reopen

Was this fixed by https://github.com/miraheze/puppet/commit/1eb05e3?

In T9372#190891, @Reception123 wrote:

@Universal_Omega How come I'm getting this?

reception@mwtask111:~$ sudo -u www-data php /srv/mediawiki/w/extensions/MirahezeMagic/maintenance/assignImportedEdits.php --wiki=islamwikiwiki --import-prefix="islamwiki" --from="WikiSysop" --to="IslamWiki Manager"
Invalid 'from' user.

In T9428#190882, @Reception123 wrote:

@Universal_Omega this seems quite upstream to me

https://phabricator.miraheze.org/P386 last updated mid may.

we have 10g left on cloud10 according to grafana. 50g in use right now although I guess that's in use and that in actual total it'll be closer.

Seems fine with me if we have the necessary RAM to allocate.

Ran puppet on both gluster101 and gluster111 and there were no issues. Not sure what caused this but seems resolved now.

Reported upstream: https://phabricator.wikimedia.org/T311053

Moving to normal as users have been notified afaik and there's nothing much we can really do?

@Universal_Omega How come I'm getting this?

After a short discussion on IRC, I think it's best that this is declined for the time being. We don't have many resources to spare and without a larger number of people asking for a service we can't afford to spend 6GB memory on such a project.

closing for now. Please try Special:Export on Wikipedia and then Special:Import on your Miraheze wiki. If that does not work please see Special:RequestImportDump

@Universal_Omega this seems quite upstream to me

I would point out that in the survey responses I've seen many users complain of 503/502 issues so I definitely think this is something we need to prioritise and fix ASAP

I have closed. The cause of this issue was the URL, not the Extension.

No worries, and thank you very much!

You should be able to use chrome to connect to it now, I used https://chrome.google.com/webstore/detail/smartproxy/jogcnplbkgkfdakgdenhlpcfhjioidoj

In T9425#190855, @John wrote:

The switch seems non-responsive to web logins, so my thinking is currently that the switch could be at fault - but would need MTRs to back this up.

Yes

The switch seems non-responsive to web logins, so my thinking is currently that the switch could be at fault - but would need MTRs to back this up.

Ok, thank you.
Stupid question, I apologise in advance: do you mean I have to go to Special:ManageWiki and activate this extension, correct?

Please try again

What? I sent an email to sre@miraheze.org.

In T9425#190850, @John wrote:

Do we have dates and time periods? Original description is vague and this would be needed to do log diving hardware side.

Do we have dates and time periods? Original description is vague and this would be needed to do log diving hardware side.

Afaik no

Has anyone pulled any MTRs for these periods?

Now done, and no idea why it returned that for other way.

But why does it returns that?

Okay, do it without that then.

It does not work:

universalomega@mwtask111:~$ mwscript extensions/WikiSEO/GenerateDescription.php gratispaideiawiki 0,4 --force --cleanSentence
Will execute:
sudo -u www-data php /srv/mediawiki/w/extensions/WikiSEO/maintenance/GenerateDescription.php --wiki=gratispaideiawiki 0,4 --force --cleanSentence
Type 'Y' to confirm: y
Generating description for 'Gratispaideia:About'
[72b28a76ae4ae5d404e0e707] [no req]   TypeError: Argument 3 passed to MediaWiki\Extension\WikiSEO\DeferredDescriptionUpdate::__construct() must be of the type bool, int given, called in /srv/mediawiki/w/extensions/WikiSEO/maintenance/GenerateDescription.php on line 85
Backtrace:
from /srv/mediawiki/w/extensions/WikiSEO/includes/DeferredDescriptionUpdate.php(66)
#0 /srv/mediawiki/w/extensions/WikiSEO/maintenance/GenerateDescription.php(85): MediaWiki\Extension\WikiSEO\DeferredDescriptionUpdate->__construct(Title, NULL, integer)
#1 /srv/mediawiki/w/maintenance/doMaintenance.php(114): GenerateDescription->execute()
#2 /srv/mediawiki/w/extensions/WikiSEO/maintenance/GenerateDescription.php(94): require_once(string)
#3 {main}
Logging via /usr/local/bin/logsalmsg "sudo -u www-data php /srv/mediawiki/w/extensions/WikiSEO/maintenance/GenerateDescription.php --wiki=gratispaideiawiki 0,4 --force --cleanSentence (END - exit=65280)"
Done!

This has now been fixed again. Apologies for the inconvenience

Per above. It seems it was accidentally reopened and closed when initial running.

I can.

Your import has now finished!

Hello Rhino1,
Thank you for your answer.

You just need to enable TemplateStyles

We also can't see your screenshot. It needs attaching to the task.

Hi, You can now use the RequestImportDump page. Please try using that to speed up the process!

Thank you,
Malcolm

There's only no native support for multiple wikis so this would be 6GB memory needed and a fair bit of sysadmin time.

Blazegraph is far too unstable. This would be a massive hog on resources.

Will any of the pages here work: https://islamwiki.miraheze.org/wiki/Special:Contributions/WikiSysop

In T9372#190438, @AhmadF.Cheema wrote:

Kindly, on islamwiki.miraheze.org reassign the edits from WikiSysop to IslamWiki Manager.