The consensus for that change has existed for a number of years. It is an excellent ability that works well. As long as the ability exists for users to change it back, then having it as the default would be desired.

In T227377#5341422, @Beetstra wrote:

Bstorm, is there anything you need from my end now? How do I proceed?

In T209565#5336405, @Billinghurst wrote:

In T209565#5312987, @Daimona wrote:

Here is the filtered output.

P8719 normalizeThrottleParameters 4

1	-----------------------------------------------------------------
2	arwiki
3	-----------------------------------------------------------------
4	arwiki: No throttle parameters to normalize.
5	arwiki: normalizeThrottleParameter would beautify 16 rows in abuse_filter_history for the following history IDs: 709, 710, 715, 716, 719, 934, 1030, 1031, 1189, 1239, 1240, 1241, 1242, 1244, 1502, 1529
6	arwiki: Throttle parameter normalization would change a total of 16 rows.
7	-----------------------------------------------------------------
8	cawiki
9	-----------------------------------------------------------------
10	cawiki: normalizeThrottleParameter has found 1 rows to change in abuse_filter_action for the following IDs: 9
11	cawiki: normalizeThrottleParameter would insert 1 rows in abuse_filter_history for the following filters: 9
12	cawiki: Throttle parameter normalization would change a total of 2 rows.
13	-----------------------------------------------------------------
14	cawikinews
15	-----------------------------------------------------------------
16	cawikinews: normalizeThrottleParameter has found 1 rows to change in abuse_filter_action for the following IDs: 15
17	cawikinews: normalizeThrottleParameter would insert 1 rows in abuse_filter_history for the following filters: 15
18	cawikinews: Throttle parameter normalization would change a total of 2 rows.
19	-----------------------------------------------------------------
20	cswiki
21	-----------------------------------------------------------------
22	cswiki: No throttle parameters to normalize.
23	cswiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 1375
24	cswiki: Throttle parameter normalization would change a total of 1 rows.
25	-----------------------------------------------------------------
26	dewiki
27	-----------------------------------------------------------------
28	dewiki: No throttle parameters to normalize.
29	dewiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 6093
30	dewiki: Throttle parameter normalization would change a total of 1 rows.
31	-----------------------------------------------------------------
32	dewikiversity
33	-----------------------------------------------------------------
34	dewikiversity: No throttle parameters to normalize.
35	dewikiversity: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 38
36	dewikiversity: Throttle parameter normalization would change a total of 1 rows.
37	-----------------------------------------------------------------
38	dewiktionary
39	-----------------------------------------------------------------
40	dewiktionary: No throttle parameters to normalize.
41	dewiktionary: normalizeThrottleParameter would beautify 2 rows in abuse_filter_history for the following history IDs: 416, 456
42	dewiktionary: Throttle parameter normalization would change a total of 2 rows.
43	-----------------------------------------------------------------
44	enwiki
45	-----------------------------------------------------------------
46	enwiki: No throttle parameters to normalize.
47	enwiki: normalizeThrottleParameter would beautify 5 rows in abuse_filter_history for the following history IDs: 556, 590, 596, 7409, 19912
48	enwiki: Throttle parameter normalization would change a total of 5 rows.
49	-----------------------------------------------------------------
50	enwiktionary
51	-----------------------------------------------------------------
52	enwiktionary: No throttle parameters to normalize.
53	enwiktionary: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 571
54	enwiktionary: Throttle parameter normalization would change a total of 1 rows.
55	-----------------------------------------------------------------
56	fawiki
57	-----------------------------------------------------------------
58	fawiki: No throttle parameters to normalize.
59	fawiki: normalizeThrottleParameter would beautify 6 rows in abuse_filter_history for the following history IDs: 1854, 2067, 2098, 2345, 2680, 2684
60	fawiki: Throttle parameter normalization would change a total of 6 rows.
61	-----------------------------------------------------------------
62	kowiki
63	-----------------------------------------------------------------
64	kowiki: No throttle parameters to normalize.
65	kowiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 1530
66	kowiki: Throttle parameter normalization would change a total of 1 rows.
67	-----------------------------------------------------------------
68	mrwiki
69	-----------------------------------------------------------------
70	mrwiki: normalizeThrottleParameter has found 6 rows to change in abuse_filter_action for the following IDs: 125, 127, 129, 130, 131, 134
71	mrwiki: normalizeThrottleParameter would insert 6 rows in abuse_filter_history for the following filters: 125, 127, 129, 130, 131, 134
72	mrwiki: normalizeThrottleParameter would beautify 3 rows in abuse_filter_history for the following history IDs: 1106, 1107, 1657
73	mrwiki: Throttle parameter normalization would change a total of 15 rows.
74	-----------------------------------------------------------------
75	ptwiki
76	-----------------------------------------------------------------
77	ptwiki: No throttle parameters to normalize.
78	ptwiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 5381
79	ptwiki: Throttle parameter normalization would change a total of 1 rows.
80	-----------------------------------------------------------------
81	ruwiki
82	-----------------------------------------------------------------
83	ruwiki: No throttle parameters to normalize.
84	ruwiki: normalizeThrottleParameter would beautify 2 rows in abuse_filter_history for the following history IDs: 5454, 5462
85	ruwiki: Throttle parameter normalization would change a total of 2 rows.
86	-----------------------------------------------------------------
87	ruwiktionary
88	-----------------------------------------------------------------
89	ruwiktionary: No throttle parameters to normalize.
90	ruwiktionary: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 363
91	ruwiktionary: Throttle parameter normalization would change a total of 1 rows.
92	-----------------------------------------------------------------
93	trwiki
94	-----------------------------------------------------------------
95	trwiki: normalizeThrottleParameter has found 4 rows to change in abuse_filter_action for the following IDs: 37, 47, 48, 50
96	trwiki: normalizeThrottleParameter would insert 4 rows in abuse_filter_history for the following filters: 37, 47, 48, 50
97	trwiki: Throttle parameter normalization would change a total of 8 rows.
98	-----------------------------------------------------------------
99	viwiki
100	-----------------------------------------------------------------
101	viwiki: No throttle parameters to normalize.
102	viwiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 48
103	viwiki: Throttle parameter normalization would change a total of 1 rows.

This time, no error on logstash aside from the following for labtestwiki:

[snip]

Which, however, seems just something labtestwiki-specific.
The output looks promising, so next steps I'm going to sample-check the filters above and write the announcement. I guess if no concerns arise we'll be ready to run the script for real around next wednesday.

I had a hack at the cawikinews abusefilter/15 it should be resolved.

In T209565#5312987, @Daimona wrote:

Here is the filtered output.

P8719 normalizeThrottleParameters 4

1	-----------------------------------------------------------------
2	arwiki
3	-----------------------------------------------------------------
4	arwiki: No throttle parameters to normalize.
5	arwiki: normalizeThrottleParameter would beautify 16 rows in abuse_filter_history for the following history IDs: 709, 710, 715, 716, 719, 934, 1030, 1031, 1189, 1239, 1240, 1241, 1242, 1244, 1502, 1529
6	arwiki: Throttle parameter normalization would change a total of 16 rows.
7	-----------------------------------------------------------------
8	cawiki
9	-----------------------------------------------------------------
10	cawiki: normalizeThrottleParameter has found 1 rows to change in abuse_filter_action for the following IDs: 9
11	cawiki: normalizeThrottleParameter would insert 1 rows in abuse_filter_history for the following filters: 9
12	cawiki: Throttle parameter normalization would change a total of 2 rows.
13	-----------------------------------------------------------------
14	cawikinews
15	-----------------------------------------------------------------
16	cawikinews: normalizeThrottleParameter has found 1 rows to change in abuse_filter_action for the following IDs: 15
17	cawikinews: normalizeThrottleParameter would insert 1 rows in abuse_filter_history for the following filters: 15
18	cawikinews: Throttle parameter normalization would change a total of 2 rows.
19	-----------------------------------------------------------------
20	cswiki
21	-----------------------------------------------------------------
22	cswiki: No throttle parameters to normalize.
23	cswiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 1375
24	cswiki: Throttle parameter normalization would change a total of 1 rows.
25	-----------------------------------------------------------------
26	dewiki
27	-----------------------------------------------------------------
28	dewiki: No throttle parameters to normalize.
29	dewiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 6093
30	dewiki: Throttle parameter normalization would change a total of 1 rows.
31	-----------------------------------------------------------------
32	dewikiversity
33	-----------------------------------------------------------------
34	dewikiversity: No throttle parameters to normalize.
35	dewikiversity: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 38
36	dewikiversity: Throttle parameter normalization would change a total of 1 rows.
37	-----------------------------------------------------------------
38	dewiktionary
39	-----------------------------------------------------------------
40	dewiktionary: No throttle parameters to normalize.
41	dewiktionary: normalizeThrottleParameter would beautify 2 rows in abuse_filter_history for the following history IDs: 416, 456
42	dewiktionary: Throttle parameter normalization would change a total of 2 rows.
43	-----------------------------------------------------------------
44	enwiki
45	-----------------------------------------------------------------
46	enwiki: No throttle parameters to normalize.
47	enwiki: normalizeThrottleParameter would beautify 5 rows in abuse_filter_history for the following history IDs: 556, 590, 596, 7409, 19912
48	enwiki: Throttle parameter normalization would change a total of 5 rows.
49	-----------------------------------------------------------------
50	enwiktionary
51	-----------------------------------------------------------------
52	enwiktionary: No throttle parameters to normalize.
53	enwiktionary: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 571
54	enwiktionary: Throttle parameter normalization would change a total of 1 rows.
55	-----------------------------------------------------------------
56	fawiki
57	-----------------------------------------------------------------
58	fawiki: No throttle parameters to normalize.
59	fawiki: normalizeThrottleParameter would beautify 6 rows in abuse_filter_history for the following history IDs: 1854, 2067, 2098, 2345, 2680, 2684
60	fawiki: Throttle parameter normalization would change a total of 6 rows.
61	-----------------------------------------------------------------
62	kowiki
63	-----------------------------------------------------------------
64	kowiki: No throttle parameters to normalize.
65	kowiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 1530
66	kowiki: Throttle parameter normalization would change a total of 1 rows.
67	-----------------------------------------------------------------
68	mrwiki
69	-----------------------------------------------------------------
70	mrwiki: normalizeThrottleParameter has found 6 rows to change in abuse_filter_action for the following IDs: 125, 127, 129, 130, 131, 134
71	mrwiki: normalizeThrottleParameter would insert 6 rows in abuse_filter_history for the following filters: 125, 127, 129, 130, 131, 134
72	mrwiki: normalizeThrottleParameter would beautify 3 rows in abuse_filter_history for the following history IDs: 1106, 1107, 1657
73	mrwiki: Throttle parameter normalization would change a total of 15 rows.
74	-----------------------------------------------------------------
75	ptwiki
76	-----------------------------------------------------------------
77	ptwiki: No throttle parameters to normalize.
78	ptwiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 5381
79	ptwiki: Throttle parameter normalization would change a total of 1 rows.
80	-----------------------------------------------------------------
81	ruwiki
82	-----------------------------------------------------------------
83	ruwiki: No throttle parameters to normalize.
84	ruwiki: normalizeThrottleParameter would beautify 2 rows in abuse_filter_history for the following history IDs: 5454, 5462
85	ruwiki: Throttle parameter normalization would change a total of 2 rows.
86	-----------------------------------------------------------------
87	ruwiktionary
88	-----------------------------------------------------------------
89	ruwiktionary: No throttle parameters to normalize.
90	ruwiktionary: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 363
91	ruwiktionary: Throttle parameter normalization would change a total of 1 rows.
92	-----------------------------------------------------------------
93	trwiki
94	-----------------------------------------------------------------
95	trwiki: normalizeThrottleParameter has found 4 rows to change in abuse_filter_action for the following IDs: 37, 47, 48, 50
96	trwiki: normalizeThrottleParameter would insert 4 rows in abuse_filter_history for the following filters: 37, 47, 48, 50
97	trwiki: Throttle parameter normalization would change a total of 8 rows.
98	-----------------------------------------------------------------
99	viwiki
100	-----------------------------------------------------------------
101	viwiki: No throttle parameters to normalize.
102	viwiki: normalizeThrottleParameter would beautify 1 rows in abuse_filter_history for the following history IDs: 48
103	viwiki: Throttle parameter normalization would change a total of 1 rows.

This time, no error on logstash aside from the following for labtestwiki:

[snip]

Which, however, seems just something labtestwiki-specific.
The output looks promising, so next steps I'm going to sample-check the filters above and write the announcement. I guess if no concerns arise we'll be ready to run the script for real around next wednesday.

In T226875#5293536, @Isarra wrote:

And done. Do we need to cherry pick or something for actual deployment (and see what else we broke rather immediately), or are folks happy with waiting for the usual trains this time?

In T214888#5284313, @mcruzWMF wrote:

Hi @Billinghurst, @Eric_Luth_WMSE : can we please add the page about Learning Days under the category Activities on the sidebar? It could go below Hackathon. Thanks!
I also realized that the subtab feature of the navbar is not working at the moment. Does anyone know how to fix this? Is there a component in the Lua Module that needs to be imported, maybe?

Again I am needing to undelete a Commons image, view the metadata, then delete the image, and then continue the conversation with complainants. Being able to call up the metadata from an undelete page, similarly to how one can view the image or the page text would be most useful.

For those of us involved in the legwork of resolving xwiki spam and vandalism, we continue to have limited ability to investigate and respond. When one tries to do this work, and there are continually hurdles put in one's way it is particularly dispiriting. I understand the need for change and modernisation, however, the continued disconnection with a holistic multi-wiki environment disturbs me.

In T224930#5239143, @TheDJ wrote:

@Billinghurst well it's not a production level tool, so outages like these are to be expected.
/me whispers something about technical wishlist

It has been two or three days

Trying a search for Charles Darwin in ns:102 which is the author ns at enWS, and the Page: ns in deWS, and obviously others in others.

Thought bubble of what may be a nice search isolations—if it is easy

• search by sister, eg. just show me searches for wikimedia domains, or wiktionary domains
• search by language, eg. an easy means to limit a search by the set natural language of the wikis, just show me results from German language wikis

In T224358#5213549, @MusikAnimal wrote:

In T224358#5213525, @Billinghurst wrote:

Supplementary: with this tool when running a search on a url as a general search, the period in a url is presumably ignored, so the parts of the url become separate searches so something like casertadeluxe.com becomes a search for casertadeluxe and com. So I suppose I am asking whether there is a means to fine-tune for urls in the searches.

I just deployed T224359. You can now simply wrap any query in double quotes and you will get only exact matches, e.g. https://tools.wmflabs.org/global-search/?q="casertadeluxe.com"

One of the biggest issues that I have in spam management is the limitations on looking at LinkSearches, especially as we have the unresolved protocol differences of http and https type urls that require separate searches.

A regex search, is that case sensitive or not, here I am doing phrase searches quickly.
If it is case sensitive, can one easily flick between the two?

It is case-sensitive, as regex would be by default. I need to do testing but you should be able to prepend your regex with (?i) to make it insensitive. I will add some messaging to explain this to the user. I plan to have a separate option for exact (non-regex) searches, see T224359: Use regex for exact searches.

In T224154#5206871, @bd808 wrote:

The downside of course is that @Beetstra would need to maintain the virtual machine instances rather than relying on the Toolforge admins to do so for them. Ideally one or more new folks could be attracted to the project to help with this administration burden. Getting more help seems like a good idea generally to ensure that the bot services can survive @Beetstra taking a wiki break from time to time.

We cannot have both worlds of no breaks or breaks, and only one can be automated. This is why the Wikisources have their {{nop}} templates to indicate the end of a paragraph.

Thanks for the merge @Tgr

In T222536#5158047, @Aklapper wrote:

By "wikimedia application", did you mean "MediaWiki"?
Since T85327 in 1.27, https://www.mediawiki.org/wiki/Manual:Combating_spam is linked right after installing MediaWiki.
T194746 proposes to ship StopForumSpam by default.
This task is pretty similar to T173055: Saner defaults for preventing spam and I'm not convinced that it should be a task.

In T221061#5126611, @Legoktm wrote:

This is going to be so abused for political statements and by LTAs once they find its availability.

Sure, anything can be abused. They also could just do https://en.wikipedia.org/wiki/This_is_something_not_constructive or whatever. What vulnerability is there in allowing fake domain names?

In T221061#5114011, @Jc86035 wrote:

I don't think a checklist would be easily maintainable. Perhaps a three-character limit for arbitrary subdomains, plus a separate whitelist (or alternately one regular expression with both)?
In any case, the main issue is probably the data after the domain name (e.g. https://en.wikipedia.org/wiki/YOUR TEXT HERE). There's virtually no way of completely preventing that without disallowing legitimate links, although a check on whether the URL is a 404 could prevent some low-effort spam. (You'd still have to allow arbitrary section links and Wikidata queries, at minimum.)

Yes, and no. This in actuality was undertaken on 4 April.

Set a priority on the images. Clearly there is the need to set a preference.

Page: and Index: have different page content models. They are not wikitext.

Works for me. I have purged the few pages that I have done, and they were more predominantly test edits, so less fussed on their updatedness. Thanks @Ladsgroup

In T217730#5041173, @Mbch331 wrote:

I don't see the links to other wiki's on Wikimaniawiki. Also checked nlwiki and there I see a link to Wikimaniawiki.

Working for me
https://www.wikidata.org/w/index.php?title=Q7605021&diff=prev&oldid=888844922
https://www.wikidata.org/w/index.php?title=Q5622198&diff=prev&oldid=888844164

I will rephrase that. It works when done as the converted hex text, though not as unicode text. It would be most useful to not have to do a conversion.

@Aklapper Are we able to reopen this or do I need to do a new bug report

Can I flag this one again to the community. We are back facing issues at meta for spamblacklist. The above workarounds are not working, and I believe that I have followed the stated conventions. Thanks.

There are some links above which have custom policy, though I am unaware of any private tasks that were mentioned at that time.

Other bits:

• In all cases, I think a list of migrated pages should be generated per namespace and stored on wiki in Wikimania:Migration/YYYY/Namespace
• WD linking is not initiated at this point, though I don't see that it is going to be an issue as we have a standard implementation, with the additional content wikis. There is no existing WD configuration that would need to be amended for this migration. All uncharted!
• I am guessing that we would update the interwiki maps to relink to wmania:YYYY:$1 respectively. Guessing that internal mapping

'''Category pages'''

This is the area that could be most problematic, as it has the biggest overlap, though my light cruising through the wikis doesn't show a high use of the project namespaces. It would be useful to generate a report to see what exists needs to be managed. I would think that we could just move Wikimania:pagename to wikimania:pagename/YYYY and we can manipulate from there.

Mediawiki: ns pages

translations pages

help pages

'''User pages''' should be unique per user since the update for SUL, presuming that username overlaps where resolved for closed wikis when SUL migration occurred.

Templates and modules are each going to need to be merged into the one namespace for each so that they function with imported pages.

Content pages for each wikimania 2005 -> 2018

I would like to have a better understanding of the likelihood of the what and when for the migration of these wikis into wikimaniawiki, so the ongoing design can be considered and look to be consulted.

Just wondered where this is currently sitting. I truly (for the 1000+th time) could do with the ability to search both Special:Log/spamblacklist, Special:DeletedContributions and Special:Abuselog by IP range. Where we have spambot activity, it is next to impossible to identify where the spambots are happening by any reasonable functionality than browser search.

In T215433#4934224, @Billinghurst wrote:

If on wiki, we should do in the Project:/Wikimania: namespace.
As a general comment. We will have three active content namespace to manage

• Wikimania:/Project: mechanics of operating the wiki
• Main (ns:0) which will be enduring
• 2019: for all specific WMSE WM content; though it may have some parent components in main; or may simply be redirects to 2019:

If on wiki, we should do in the Project:/Wikimania: namespace.

it is just a matter of shuffling, so it is easy to reposition if/when we change our minds

Import rights done @Trizek

In T214704#4921490, @Billinghurst wrote:

In T214704#4921454, @Eric_Luth_WMSE wrote:

@Billinghurst 's proposal seems reasonable. Such a structure is something along the lines of what I envisioned.

rights requested https://meta.wikimedia.org/wiki/special:diff/18837115/prev

'crats assigned

In T215031#4921397, @Peachey88 wrote:

Each year will have a namespace (2019s already exists) on the new wiki, so it can still work that, instead of (Main NS):2019/Schedule it would just be 2019:Schedule the namespaces that people will need to be careful will be Template, File, Category etc.
From memory, I have also read that the search system has been set to default to the 2019 namespace as well.

In T214704#4921454, @Eric_Luth_WMSE wrote:

@Billinghurst 's proposal seems reasonable. Such a structure is something along the lines of what I envisioned.

In T214704#4921394, @Eric_Luth_WMSE wrote:

@Billinghurst It would be great if the WMSE employees had admin rights in order to do smaller tasks until the next host organization takes over, but my goal is that the main work is carried out by volunteers. Thus, I'd like to delegate as much as possible. In the case that there's crucial tasks that no volunteers want to do, we do have capacity at the office.

In T215031#4921038, @Trizek wrote:

Don't forget to import translations if you import things that were marked for translation.

In T214704#4921041, @Trizek wrote:

In T214704#4916708, @Billinghurst wrote:

I would suggest that any admin rights can be managed through this ticket for the foreseeable future [...]

Excellent idea. As I can work on translations, I'm looking for translation admin rights (I have them on Meta). If possible, I would request sysop rights, which is always convenient to have when you work on translations (I have those rights on fr.wp).

In T215031#4920987, @Harej wrote:

WikiConference North America does “Year/Pagename” e.g. “2018/Schedule” along with per-year templates that strip out the year prefix in the displayed page title and add a year-specific tagline. We have done five of these conferences now and this system has worked well for us.

The one thing that has been tumbling over in my mind is now that there is one wiki for many years, there will need to be the hierarchy to cover many years. In previous wikis, they could do it all one level down from root, and not have to worry about next year, that is no longer the case.

volunteers and head label back

I can just roll it back if you don't like it, that is easy.

Imported common.js
imported common.css and removed megaheader components

I am no css expert either, though know the basics

Can I start off with asking for full import rights, so I can import translated labels for Commons gadgets. Doing them all by hand (with my typing) will just introduce errors.

Questions. Looking at WM2018, I am wondering whether as some basics, whether you wish to have the following brought over

I can talk about stewardry processes from a previous life, they are looking for a process to know that an authority process has been undertaken. I would suggest that initially some names are put forward to be crats and approved here on phab. I would suggest that any admin rights can be managed through this ticket for the foreseeable future, and that they are set time limited (up to one year). The rights process for a permanent wikimaniawiki can be developed as things progress.

@Eric_Luth_WMSE We are going to need to work on rights pretty soon at least for allowing for translation admins. Probably best if the wiki can get bureaucrat(s) so that can be assigned locally; otherwise we can just lay them on the stewards through meta as long as you line up an approval process that sits outs outside of standard wikis

I have imported wm2018, rem'd the lines leaving

Current sidebar from wm2018 is

You always have a means to over-complicate what should be kept simple. Anyway, none of what you are talking about belongs in proofreadpage. If you wish to discuss that at English Wikisource, then go for it. None of it belongs in phabricator.

It is not a function of transclusion, this solely is part of English Wikisource's page numbering javascript, there is nothing for a phabricator ticket.

Have you tried writing it into the help pages for the extension? A parenthesis shouldn't be considered a page number, and the instructions are specific about what are available page numbering styles
https://wikisource.org/wiki/Wikisource:ProofreadPage
Why would you be adding some decorative aspect? If there was any part to be added, it would be better added to the page numbering style anyway.

This is completely part of the javascript page numbering functionality, and how it hides page numbers when they are squashed together preventing overlap, as that they don't fit in the same space. Simply use the exclude functionality of <pages> to omit the first blank page so it doesn't obscure the subsequent page number.

@Daimona <shrug> I am just nuff nuff spam handler and typical end user who needs some abilities to better handle the abusefilter/log which has become a morass. I talk about desires in tools that allow me to work efficiently; and to better and more effectively protect our wikis. I generally put up with the inefficiencies in the system, however, when I get to the point of "f*** it" and am throwing my hands up (again) that this is wearing me down, then I will speak up.

Is it possible to look at something other than a binary solution (off/on). For those of us who do the unheralded work in the background — spambots, vandals, LTA — having something to make our life easier would be most helpful; most especially at meta for the global filters where the spambot hits drown out others. Is there an intermediate measure other than at a point of call generation. Is it possible that this could be updated hourly, of six hourly?

@Mahitgar for you at mrwiki