User talk:Evad37/SPS.js

• I think the text is not complete, it starts with an incomplete sentence anyway. You might like to check this, please.--Aschmidt (talk) 15:37, 31 March 2019 (UTC)[reply]
  • @Chris troutman: I think the script did this at Special:Diff/890305353. Could you please take a look at this? — Newslinger talk 15:42, 31 March 2019 (UTC)[reply]

  @Chris troutman, Newslinger, and Aschmidt:  fixed. @Evad37: the script assumed that the earliest set of }} was the end of the description template, but it wasn't. Maybe add a sanity check that there were no other {{ before it? --DannyS712 (talk) 15:45, 31 March 2019 (UTC)[reply]

  @DannyS712: Yeah, the script was expecting plain text (or no text) for the RSS description, not wikitext. Let's continue discussion on the script talkpage. - Evad37 [talk] 22:54, 31 March 2019 (UTC)[reply]

BTW, this was fixed in this edit, which started using extraJs.parseTemplates to properly parse templates which might contain other templates. - Evad37 [talk] 23:43, 30 April 2019 (UTC)[reply]

@Chris troutman: I noticed that script-assisted publishing for this most recent 30 April Signpost edition added duplicate discussion templates to the bottoms of some (but not all) of the articles. I've removed duplicate comment section templates from: [1], [2], [3], [4], [5], [6], [7], [8]. Edits like this appear to have added the extra comment box. I'm not sure what the cause is or if I'm missing something, but I just wanted to give a heads up. Airplaneman ✈ 20:10, 30 April 2019 (UTC)[reply]

@Airplaneman: Thanks for your intervention; yes, I had noticed that. We have more than one editor making interface changes and as always, some crossed lines occurred. Chris Troutman (talk) 20:12, 30 April 2019 (UTC)[reply]

@Chris troutman: On the other hand, I believe that my change to the publishing script to automatically request watchlist notifications worked like a charm - did you see any errors? --DannyS712 (talk) 20:23, 30 April 2019 (UTC)[reply]

Yeah, I missed that this template move happened, which is why it only affected some of the articles – those using the old (redirected) template name worked fine. Will be fixed for the next issue. - Evad37 [talk] 23:39, 30 April 2019 (UTC)[reply]

While trying to publish, I got as far as moving the "next issue" pages into the WP namespace and hit "(API error: internal_api_error_DBQueryError)". To editor Smallbones: I'll be proceeding manually. Chris Troutman (talk) 00:39, 31 May 2019 (UTC)[reply]

@Chris troutman: Sorry to hear that. The only thing I can guess is the last edit I did to the Recent Research article, which got rid of the "Unexpected < operator" error message (like last month). I wish I could help more but I'm clueless. Thanks for your efforts. Smallbones_(smalltalk) 00:44, 31 May 2019 (UTC)[reply]

The internal api error means the problem was on the MediaWiki software side of things, possibly phab:T223175 or similar. That error only came up 29 times over a few weeks (across multiple wikis) according to the bug report, so maybe you were just unlucky? - Evad37 [talk] 03:51, 28 June 2019 (UTC)[reply]

In its most recent use to publish the Signpost the template {{pp-semi-indef}} was removed, the script should be updated to include it. The Editor's Apprentice (talk) 03:18, 31 August 2019 (UTC)[reply]

@Evad37: Could we make a tweak to the script to restore this edit in future runs? The class helps when targeting the signpost page with userstyles. It looks like we'd only need to modify topwikitext and bottomwikitext (L677 and L680 respectively) to do this. Also the same would be needed for the section above this one. — AfroThundr ^{(u · t · c)} 02:33, 25 January 2020 (UTC)[reply]

@AfroThundr3007730: I've created Wikipedia:Wikipedia Signpost/Templates/Main page top and Wikipedia:Wikipedia Signpost/Templates/Main page bottom, which can be subst'ed by the script. This way the community can make changes via (something approximating) the normal editing process, rather requiring script updates. - Evad37 [talk] 04:10, 25 January 2020 (UTC)[reply]

Thanks a bunch! — AfroThundr ^{(u · t · c)} 04:17, 25 January 2020 (UTC)[reply]

 Done. Pinging @Smallbones, Chris troutman, and Bri: as a notification that this has happened. It's a relatively minor change to the script[9], and I tested it here and at the newsroom with the script in dry-run mode. - Evad37 [talk] 05:07, 25 January 2020 (UTC)[reply]

@Evad37: I had some extra time, and took a look through the code for this (looking for any techniques I didn't know) and wanted to do some minor cleanup. Would you mind looking at these changes? Since this is an onwiki script, I can't submit a pull request, but what it does is

• Remove trailing whitespace
• Replace calls to postWithToken( 'csrf', ... ) with just postWithEditToken
• Remove unneeded joins for multiple values for api calls
• Fix a typo promiseWihoutExistsError -> promiseWithoutExistsError

And other such tweaks. There should be no resulting change to the code running. I ran it in dry mode, and everything worked. Thanks, --DannyS712 (talk) 05:37, 25 January 2020 (UTC)[reply]

At first glance it looks mostly fine, except for changing the == null to === null. The loose comparison matches both null and undefined (ie when second parameter isn't passed), whereas the strict comparison only matches null. e.g. the following

(function(a, b) {
    console.log(`${a}==null`, a==null);
    console.log(`${a}===null`, a===null);
    console.log(`${b}==null`, b==null);
    console.log(`${b}===null`, b===null);
})(null);

logs

null==null         true
null===null        true
undefined==null    true
undefined===null   false

- Evad37 [talk] 05:56, 25 January 2020 (UTC)[reply]

@Evad37: yes, but I checked every caller, and all provide a string (i.e. the null part could be removed entirely) --DannyS712 (talk) 06:05, 25 January 2020 (UTC)[reply]

Actually, that makeLink function and the makeErrorMsg function are duplicating code from extraJs. It's quite close to publication time now, so I'll wait till after to update the script. - Evad37 [talk] 10:48, 26 January 2020 (UTC)[reply]

@Evad37: I found some more things to update DannyS712 (talk) 02:47, 27 January 2020 (UTC)[reply]

Okay. https://en.wikipedia.org/wiki/Special:ComparePages?rev1=937459621&rev2=937778355&diffmode=source includes

• Remove trailing whitespace
• Replace calls to postWithToken( 'csrf', ... ) with just postWithEditToken
• Remove unneeded joins for multiple values for api calls
• Fix a typo promiseWihoutExistsError -> promiseWithoutExistsError
• Use consistent spacing of function(, ({, })
• Adds an edit protected template for the request to bump the watchlist message ({{
  sudo
  }})
• Tweaks indentation to be more clear and consistent
• Remove makeErrorMsg in favor of extraJs.makeErrorMsg

It still shouldn't affect the result, with the exception of the addition of {{

 Done, thanks Danny - Evad37 [talk] 09:49, 27 January 2020 (UTC)[reply]

@Evad37: I ran through the script a bunch of times in dry mode in preparation for being the publication manager this month, and noticed that for the main page wikitext preview (and rendered preview) the links to everything but the first article are wrong. Looking at the wikitext, I see that there are a bunch of {{Wikipedia:Wikipedia Signpost/Templates/Issue|1}} instances which, while correct for the actual edit, render the preview wrong - the first instance is replaced by the code

		var previewMainWikitext = request.text
			.replace( // Use today's date
				"{{Wikipedia:Wikipedia Signpost/Templates/Issue|1}}",
				new Date().toISOString().slice(0, 10)
			).replace( // Increment issue number. Won't be correct for first issue of the year, but probably good enough for a preview.
				"{{Str right|{{Wikipedia:Wikipedia Signpost/Templates/Issue|2}}|10}}",
				"issue {{#expr:1+{{Str right|{{Wikipedia:Wikipedia Signpost/Templates/Issue|2}}|16}}}}"
			);

but this does not replace *all* of the occurrences, just the first. Would it be possible to switch this to replace them all? Thanks, --DannyS712 (talk) 20:16, 28 March 2021 (UTC)[reply]

That code was actually just meant for correcting the header, since the visual preview isn't affected much by the other uses (just means some of the story links will be blue links instead of redlinks). But this doesn't work anymore, since the header is now subst'ed from Wikipedia:Wikipedia Signpost/Templates/Main page top instead of coming from a string directly in the script. While it's pretty easy to do the global replace you suggest by changing the third line to

new RegExp(mw.util.escapeRegExp("{{Wikipedia:Wikipedia Signpost/Templates/Issue|1}}"),"g"),

that won't change the instance that comes from the subst'd header. - Evad37 [talk] 00:53, 29 March 2021 (UTC)[reply]

@DannyS712:  Fixed with a little help from a new Lua module Module:Wikipedia Signpost/Main page top preview - Evad37 [talk] 01:49, 29 March 2021 (UTC)[reply]

Eg for the page Wikipedia:Wikipedia Signpost/2021-09-26 - this gets transcluded in the mass message, and eventually the bot comes and protects it as widely transcluded (last month Special:PageHistory/Wikipedia:Wikipedia Signpost/2021-08-29) but the faster the better. DannyS712 (talk) 20:57, 26 September 2021 (UTC)[reply]

Just ran across what appears to be a bug: [10]. The word "nullified" was changed to "ified" as the script did its thing. GorillaWarfare (she/her • talk) 22:25, 30 January 2022 (UTC)[reply]

I suspect the fault is in these two statements, introduced in Special:Diff/892576225:

var helperPatt = ( helperTemplate ) ? new RegExp('\\n?'+mw.util.escapeRegExp(helperTemplate.wikitext)) : null;

var updatedWikitext = article.wikitext.replace(helperPatt, '')

The null is implicitly turned into the string "null" and then used as the needle for the find-and-replace operation. Krinkle (talk) 02:41, 31 January 2022 (UTC)[reply]

RUH ROH!!!!! I am just seeing this now. I guess that is a problem because I am now the only one who maintains this darn script... jp×g 11:50, 22 December 2022 (UTC)[reply]

@JPxG (and other page watchers), I have a note for the future and what appears to be a bug to report with the current implementation.

1. Right now, massmsg at the end of the message definition puts the bullets on the same line as the div surrounding them. This causes them to fail to display correctly as a list; see [11]. This is the bug. (Should be trivially fixable without consideration for item 2.)
2. hlist will Sooner rather than Later be in TemplateStyles rather than in Common.css (see MediaWiki talk:Common.css/to do#description and section Hlist). That means massmsg will instead need to use one of the templates that will provide the class and styles. In this context, either {{flatlist}} or {{hlist}} will be sufficient. The use of {{hlist}} will also make item 1 simple to implement, separate to a fix for item 1.

Izno (talk) 05:34, 22 December 2022 (UTC)[reply]