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!

Per above. With reasoning, we can reconsider this.

The same as was mentioned at T9157#185577. Can you please provide an explanation here?

In T9032#185487, @Universal_Omega wrote:

In T9032#185482, @Ugochimobi wrote:

(ー_ーゞ
humm, I think, I just found out that wmgWikibaseRepoUrl is using http instead of https.

That would be why.

In T9032#185482, @Ugochimobi wrote:

(ー_ーゞ
humm, I think, I just found out that wmgWikibaseRepoUrl is using http instead of https.

....hmm, and now everything seems fine now, working atleast as usual.

(ー_ーゞ
humm, I think, I just found out that wmgWikibaseRepoUrl is using http instead of https.

In T9032#184766, @Ugochimobi wrote:

Refused to connect to 'http://gratisdata.miraheze.org/w/api.php?action=query&format=json&meta=tokens&type=csrf ' because it violates the following Content Security Policy directive: "connect-src 'self' *.miraheze.org *.betaheze.org www.wikidata.org *.wikipedia.org www.mediawiki.org *.wikimedia.org *.wikinews.org *.wiktionary.org cdn.jsdelivr.net storage.googleapis.com".

I see this on Console.... I don't know if it will help though.

It definitely helps but I don't know how that makes sense

Refused to connect to 'http://gratisdata.miraheze.org/w/api.php?action=query&format=json&meta=tokens&type=csrf ' because it violates the following Content Security Policy directive: "connect-src 'self' *.miraheze.org *.betaheze.org www.wikidata.org *.wikipedia.org www.mediawiki.org *.wikimedia.org *.wikinews.org *.wiktionary.org cdn.jsdelivr.net storage.googleapis.com".

In T9032#184357, @Ugochimobi wrote:

Did you went through Special:SetSiteLink? Because I still get the error wen trying to add sitelinks. Like I said earlier, adding statements also don't work, even adding description and aliases don't work too.

Did you went through Special:SetSiteLink? Because I still get the error wen trying to add sitelinks. Like I said earlier, adding statements also don't work, even adding description and aliases don't work too.

@Ugochimobi I can't reproduce this error, I was able to add a link just fine after following the steps you set out.

In T8817#183727, @Ugochimobi wrote:

Which we don't want....
Was it reviewed at all?

Which we don't want....
Was it reviewed at all?

In T8817#183722, @Ugochimobi wrote:

In T8817#183703, @Universal_Omega wrote:

I don't know about this extension due to its integration with OAuth, I'm not sure if we will be able to use with with a consumer or not. Additionally I'm unclear on the purpose of the extension.

It uses the QuickStatements to update statements of wikibase entities in bulk.

In T8817#183703, @Universal_Omega wrote:

I don't know about this extension due to its integration with OAuth, I'm not sure if we will be able to use with with a consumer or not. Additionally I'm unclear on the purpose of the extension.

Let me quicly point on something, when you want to update the item's statements directly from the item's page, they fail, for example updating the name, description, aliases, statements, sitelinks from the item's page fails, but updating the name, description, aliases from the /Special:SetLabelDescriptionAliases/, then the sitelinks with the /Special:SetSiteLink/ special pages, they all work fine.

This won't work properly, not until we find a way of creating other site groups that would appear under item pages.

I don't know about this extension due to its integration with OAuth, I'm not sure if we will be able to use with with a consumer or not. Additionally I'm unclear on the purpose of the extension.

Actually still being worked on

PR merged, assuming resolved..

In T9032#182854, @Ugochimobi wrote:

According to @Danniel (see diff), He said he didn't encountered any error when he was making this edit. Hmm, especially weird, but I am still personally investigating this issue.

According to @Danniel (see diff), He said he didn't encountered any error when he was making this edit. Hmm, especially weird, but I am still personally investigating this issue.

And by the way, that setting was to take effect on gratispaideiawiki not gratisdatawiki.

In T9032#182794, @RhinosF1 wrote:

When did it start?

https://github.com/miraheze/mw-config/commit/dc8a6efbc6ed6a61b113408b22503b2a2c5f40c9 was merged yesterday

When did it start?

Well, nothing can actually be edited in the wikibase aspect of the said wiki (gratisdatawiki). Statements can't be added, sitelinks can't be added, aliases and descriptions can't be added too.

Any update on this?

https://github.com/miraheze/mw-config/pull/4537

So according to what I understand (we'll just try it out anyway,) when we don't have the wgWBClientSettings['otherProjectsLinks'] = variable set at all, or when we have it but it's an empty value, then the Other projects sidebar is suppressed, that is, it will not be shown, because the system will not know what wiki to display there, which is a little bit interesting :). So that is why we don't even see the section at all.

I don't want to believe so, if it is then we're probably missing something in our own config.
But u don't believe it's the default, otherwise it should be working well.
I also found out an issue related to i18n.

In T8874#180241, @Ugochimobi wrote:

I think the problem is the below, we actually don't have it on our Wikibase.php, and I don't know how to format it according to our config style;

 	$defaults['otherProjectsLinks'] = function ( SettingsArray $settings ) {
		$otherProjectsSitesProvider = WikibaseClient::getOtherProjectsSitesProvider();
		return $otherProjectsSitesProvider->getOtherProjectsSiteIds( $settings->getSetting( 'siteLinkGroups' ) );
 	};

I think the problem is the below, we actually don't have it on our Wikibase.php, and I don't know how to format it according to our config style;

 	$defaults['otherProjectsLinks'] = function ( SettingsArray $settings ) {
		$otherProjectsSitesProvider = WikibaseClient::getOtherProjectsSitesProvider();
		return $otherProjectsSitesProvider->getOtherProjectsSiteIds( $settings->getSetting( 'siteLinkGroups' ) );
 	};

I merged the submitted PR. Thank you!

No SRE intervention needed

For the record, I resolved this with pywikibot. I use the auto-creation of items from pages on the client wiki, so when it got to the last item number Q1185 or thereabout, it started to create items normally. The script ran for approximately 20 hours.
The script used: newitem.py
and I ran the script from directory mode via pwb.py with newitem -pageage:1 -lastedit:1 -family:gratispaideia -start:Template:!.
These are all for the record.

It should now be possible to set to this content model via Special:ManageWiki/namespaces.

https://github.com/miraheze/ManageWiki/pull/318 will allow it to be changeable through ManageWiki.

In T8281#167195, @Universal_Omega wrote:

Since interwiki is done, closing task as invalid since this required no SRE intervention. You also mentioned you simply wanted the authority to import pages, not for us to. If I misunderstood please reopen this task. Thanks!

Oops!

Since interwiki is done, closing task as invalid since this required no SRE intervention. You also mentioned you simply wanted the authority to import pages, not for us to. If I misunderstood please reopen this task. Thanks!

I'm going to have to decline this due to it being 1) experimental 2) mostly unmaintained and 3) having virtually no documentation on the extension page.