Project:Support desk

v • d • e   Welcome to MediaWiki.org's Support desk, where you can ask MediaWiki questions!

There are also other places where to askCommunication: IRCCommunication#Chat, mailing listsMailing lists, Wikimedia Developer Support, Q&A, mwusers (unofficial forum) etc.

Before you post

• Make sure you have read our fundamental introduction.
• Please carefully check our FAQManual:FAQ and Errors and Symptoms pages.
• Project:Current issues is where you should discuss issues about the mediawiki.org website itself.
• If your question is about a specific function, please read the relevant technical manualManual:Contents, end-user helpHelp:Contents or extension page and consider asking on its talk pageHelp:Talk pages.
• Test wiki editing at the Project:Sandbox.

Post a new question

1. To help us answer your questions, please always indicate which versions you are using (reported by your wiki's Special:Version page):
   • MediaWiki
   • PHP
   • Database
2. Please include the URL of your wiki unless you absolutely can't. It's often a lot easier for us to identify the source of the problem if we can look for ourselves.
3. To start a new thread, click "Start a new topic".

Previous page history was archived for backup purposes at Project:Support desk/LQT Archive 1 on 2015-07-30.

the phrase "put the declaration at the bottom of localsettings.php" is very UNhelpful, since MANY extensions say the same thing!

It's more useful to explain exactly which declares must come before the extension, such as protections, etc. Example here under Important

Or, if it doesn't matter, simply say "below the default settings".

Developers, especially unexperienced developers often add duplicate code to LocalSettings.php. That is one of the reasons for saying "put it at the end". Then at least the newest lines are getting used.

that only works until some new declaration is placed under the last one, breaking the previous one. So, doesn't really make sense.

This isn't a transclude, but does return a list of all namespaces:

/api.php?action=query&meta=siteinfo&siprop=namespaces

API:Siteinfo#Namespaces

How to transclude all namespaces (including custom namespaces)?

thx

You transclude pages, not namespaces. Do you mean transcluding a page on a specific namespace? Or transclude a list of namespace names?

A list of namespace names

You can use Lua for that: Extension:Scribunto/Lua reference manual#mw.site.namespaces

is that the only way to query MySql tables, and display result on a wiki page?

Namespaces are not in the database. They're configured in PHP. This is one option. Another option is to code a parser extension yourself to do that.

the page you linked says "mw.site.namespaces - Table holding data for all namespaces"

Is that a text file, and not a table?

I do have some custom namespaces in my localsettings.php, but are you saying all default namespaces are defined in localsettings.php?

It's a Lua table, not an SQL table, like there are HTML tables and such.

Default namespaces are in core code and your namespaces in LocalSettings.

what is "mw.site.namespaces"?

If you install Extension:Scribunto you can use Lua to give more functions to templates. It is one of variables, arrays you can acces to read certain data.

If you have a specific namespace you want to get the name of and you have its id number, you can do {{ns:number here}}

There is no way in MediaWiki core to get a full list of defined namespaces from wikitext. As others have mentioned above, the information can be obtained using the scribunto extension, which adds Lua as an alternative language for writing templates.

This isn't a transclude, but does return a list of all namespaces:

/api.php?action=query&meta=siteinfo&siprop=namespaces

API:Siteinfo#Namespaces

i noticed my wiki v1.30 didn't seem to contain a "Project" namespace. So i created one, in localsettings.php, using same index nums as mediawiki.org. Manual:Namespace_constants

# PROJECT NAMESPACE
define("NS_PROJECT", 4); 
$wgExtraNamespaces[NS_PROJECT] = "Project";
define("NS_PROJECT_TALK", 5); 
$wgExtraNamespaces[NS_PROJECT_TALK] = "Project_Talk"; 

But, i just read:

all wikis have a "Project:" namespace, but the actual namespace name is normally changed to the name of the wiki (on Wikipedia for example, the "Project:" namespace is "Wikipedia:")"  

API:Siteinfo#Namespaces

and i noticed the default localsettings.php contains:

$wgMetaNamespace = 'Project';

• Has my custom "Project" namespace broken anything?
• If i remove my custom namespace declaration, will my pages with "Project:" prefix still load and work correctly? Should i change their prefix to my wiki-name?
  • Currently, if i substitute MyWikiName for Project prefix, i get "page doesn't exist".
• I added explicit protections for Project. If i remove them, will default protections be the same? Or should i keep my custom protection:

  $wgNamespaceProtection[NS_PROJECT] = array( 'editprotected' );

• I also added Flow support for PROJECT_TALK. Do i need to keep that, even if i remove the custom namespace declaration?

  $wgNamespaceContentModels[NS_PROJECT_TALK] = 'flow-board';

Hello, I want to rollback a page using JavaScript. for that, I use the following syntax:

new mw.Api().postWithToken('rollback', {
   action: 'rollback',
   title: 'pageName',
   user: 'userName'
});

If the rollback has not succeeded (e.g., if the user does not have the necessary right), I would like to display an error message. How can I check if the rollback has been succeeded?

You'll need to look at the returned parameters and possible errors in API:Rollback#Returned_fields.

@Ciencia Al Poder: Thank you, but I didn't understand how can I get the returned parameters using JavaScript. I tried the following:

new mw.Api().postWithToken('rollback', {
    action: 'rollback',
    title: 'pageName',
    user: 'userName'
}).then(function (data) {
    if (data && data.error) {
        alert( data.error[info] );
    }
});

If the rollback fails, I expect to see an alert box with the error message; however, nothing happens...

According to the documentation, you should use .done()

Try to add console.log( data ); and see the console output for the details

Hello, I want to embed a slideshare document. For that, I use Slideshare12 extension. I have one mediawiki where it works, and one another that don't works. Is there another solution that works all the time?

Regards, Fabrice

Which exact MediaWiki versions and extension versions are used on both wikis?

Thanks for the help!

I think there is only one version of the Slideshare2012 extension : Extension:SlideShare2012

The Mediawiki version which works is 1.31.0 : http://www.wikipratiquesnarratives.fr/index.php?title=Sp%C3%A9cial:Version

The Mediawiki version which doesn't work is 1.30.0 : https://wikiagile.cesi.fr/index.php?title=Sp%C3%A9cial:Version

Regards, Fabrice

I am encountering this exception when trying to use the Html2Wiki extension to import a plaintext html file. I have the rest of the Backtrace here:

Backtrace:

#0 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(814): Language::formatSize(integer)

#1 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(857): SpecialHtml2Wiki->formatValue(integer)

#2 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(964): SpecialHtml2Wiki->addFileToResults()

#3 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(655): SpecialHtml2Wiki->processFile()

#4 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(519): SpecialHtml2Wiki->doUpload()

#5 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(220): SpecialHtml2Wiki->doImport()

#6 /usr/share/mediawiki/includes/specialpage/SpecialPage.php(479): SpecialHtml2Wiki->execute(NULL)

#7 /usr/share/mediawiki/includes/specialpage/SpecialPageFactory.php(577): SpecialPage->run(NULL)

#8 /usr/share/mediawiki/includes/MediaWiki.php(282): SpecialPageFactory::executePath(Title, RequestContext)

#9 /usr/share/mediawiki/includes/MediaWiki.php(735): MediaWiki->performRequest()

#10 /usr/share/mediawiki/includes/MediaWiki.php(509): MediaWiki->main()

#11 /usr/share/mediawiki/index.php(43): MediaWiki->run()

#12 {main}

What can I do to resolve this issue?

Please ensure that Html2Wiki extension version matches MW core version.

I upgraded everything to 1.31, same error different line:

[e51f192c19e9217fef6b5ed5] /mediawiki/index.php?title=Special:Html2Wiki&action=submit Error from line 4829 of /var/lib/mediawiki/languages/Language.php: Using $this when not in object context

Backtrace:

#0 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(814): Language::formatSize(integer)

#1 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(857): SpecialHtml2Wiki->formatValue(integer)

#2 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(964): SpecialHtml2Wiki->addFileToResults()

#3 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(655): SpecialHtml2Wiki->processFile()

#4 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(519): SpecialHtml2Wiki->doUpload()

#5 /var/lib/mediawiki/extensions/Html2Wiki/specials/SpecialHtml2Wiki.php(220): SpecialHtml2Wiki->doImport()

#6 /var/lib/mediawiki/includes/specialpage/SpecialPage.php(522): SpecialHtml2Wiki->execute(NULL)

#7 /var/lib/mediawiki/includes/specialpage/SpecialPageFactory.php(568): SpecialPage->run(NULL)

#8 /var/lib/mediawiki/includes/MediaWiki.php(288): SpecialPageFactory::executePath(Title, RequestContext)

#9 /var/lib/mediawiki/includes/MediaWiki.php(861): MediaWiki->performRequest()

#10 /var/lib/mediawiki/includes/MediaWiki.php(524): MediaWiki->main()

#11 /var/lib/mediawiki/index.php(42): MediaWiki->run()

#12 {main}

Is there some other element I am missing?

Did you also upgraded Html2Wiki as well? If you've also done that, the extension may not be compatible yet with the latest MediaWiki version.

Mediawiki is on 1.31, HTML2wiki has a package for 1.31 which I have installed as well. These together are producing this error. I have updated all dependencies and packages to the best of my abilities in an attempt to resolve this error but have come up empty.

Though this question (topic) may seem as a duplicate of this previous topic (Topic:Ucy8sfl44i6n6i51) posted on Support desk but that contained more discussions on the effect of GDPR than how to make it compliant. So, thought of starting this thread in an attempt to list all the practicable methods to make a MediaWiki installation (website) "more" GDPR compliant.

Just to avoid confusion -

1. This topic is NOT on how to change MediaWiki software to make it GDPR compliant (if at all necessary), it is on any website build on MediaWiki software. So, this focuses on extensions, scripts, or anything you can think of that may make the website more GDPR compliant.

2. Absolute compliance is not possible on public MediaWiki websites, at least for the website administrators, as most of the content are posted by the users. So the title is how to make it “MORE” GDPR compliant.

3. Please try to suggest anything about general MediaWiki websites that can be a problem due to GDPR and all the possible ways to correct or at least circumvent this problem.

I request all the active members to please share your valuable thoughts on this matter.

P.S.

I found this support desk to be the most helpful and active part of this website, so decided to ask it here.

One discussion from Topic:Ucy8sfl44i6n6i51 -

Problem (mentioned by @Rocketpipe) - the username is attached to every edit make by the user. The user has no ability to remove any of those references.

Possible solution (also suggested by @Rocketpipe) - It might be sufficient if the user is told of this limitation during the account creation process.

From topic Topic:Ucy8sfl44i6n6i51

Problem (mentioned by @CayceP) - the account e-mail addresses are stored in MySQL databases unencrypted/in plain text.

Possible solution (suggested by @Ciencia Al Poder) - this should not be a problem, as

1. the email addresses are accessed only by the system admin.
2. MediaWiki software is able to decrypt the email addresses even if encrypted, to use them for sending emails.
3. Anyone with access of MediaWiki code or shell can decrypt them using the software
4. The users have control to see their email addresses and delete them if they want to.

From Topic:Ucy8sfl44i6n6i51

Problem (anonymous user) - the problem arises when the user wants to delete or hand over their data.

Possible solution (suggested by @TheDJ) -

1. a user can delete his/her email address by removing it in the preference. Email address is not required by MediaWiki.
2. The user releases his/her contributions under the license mentioned in the specific website.
3. Database user can delete a specific contribution if needed.

A note - The requirement of email address during account creation can be specified by the system admin using localsettings.php. So, the first point in the solution may not be applicable to all websites.

Please see my reply to the other topic (is there way to merge them?)

ETA: Copy and paste from the other thread:

I'm not a lawyer but was appointed DPO by my company and I spent the last weeks and months with this topic:

• Old, existing laws (like the Cookie policy) are still applicable when GDRP become effective (as it has been for the last two years). So if your Wiki's server is located in the EU and/or you are catering to EU based users, you may want to use Extension:CookieWarning, if you aren't already. Text of warning/explanation may have to modified accordingly.

• GDRP demands implementation of "appropriate, cost-effective controls" to protect the personal data of EU residents. It's still debated whether GDRP demands encryption, per se. Text uses words "such as encryption", "may include encryption", "as appropriate (...)pseudonymisation" etc. so this are more suggestions than a demand For SEO reasons and because Google Chrome will marks web pages without SSL/TLS certs as "not secure" soon, you may want to use a SSL certificate for your wiki anyway. Maybe your hoster can offer free Let's encrypt certs?
• If your wikis' SQL DB is breached, you have to inform authorities and your users which information were affected/stored (usually IP address for all editors) and e-mail address, user names First and last name if you request them from your user for logged users) (see GDPR Article 34).
• You may want to ask your users whether they are older than 16 years upon sign-up or if they have the consent by their parents.

• I would update the wiki privacy, if not done already, that IP address (for all editors), E-mail addresses and User names (for registered users) are stored which is technically required for tracking and roll back of edits and that user agree to that upon sign-up or editing your wiki, that who they have to contact if they want to have their account deleted.

• I would add the part with unset e-mail as mention above. Since an e-mail address is not required for registering this may only affect wikis that use emailconfirmed for editing privileges (for example for Anti Spam measures, YMMV).
• I would also add the name of an Admins/Mod(s) on the privacy article in case somebody wants information about their stored data. I would add link how they can close their account.
• Also add which data protection legal authority is responsible for your country/(or federal state like in Germany), this is also required by GDPR,

Hi, you can copy-paste the reply here. So that all the answer can be found in one place. Thank you for the all the solutions suggested by you.

There was a workshop at the Wikimedia Hackathon 2018 in Barcelona.

Here you can find the task at phabricator: https://phabricator.wikimedia.org/T194901

And here is the documentation of the workshop:

• Public YouTube stream on MediaWiki channel: https://www.youtube.com/watch?v=uxTIpr4Ybcg
• Slides: https://docs.google.com/presentation/d/1TYbJoZ8SRUe_37mYjIvnVDwpyrrpUNwk6d7ShG3A7Bk/edit?usp=sharing
• Etherpad: https://etherpad.wikimedia.org/p/gdpr

Thanks for Links for Wordpress. Unfortunately the automatically generated Privacy Statement in Wordpress 4.9.6 is currently only available in English :( . Better than nothing for Wordpress users, though. Jetpack has a GDPR generator of it's own, but also only in English at the moment.

Back to MediaWiki Topic: MediaWiki could use an extension where user can export their data (still to be defined what that would includes besides the username, IP address etc what additional information was stored, if the changes/edits would have to be included), similar to Wordpress - although given the nature of how wikis works this might become a major headache (basically if a editor decides to have their personal data scraped, which is their right to do so, this means Wiki admins would have to change the user name to some anonymized version like "deleted user" or something, same for edits that were done by not logged in users where the IP is shown). https://www.mediawiki.org/wiki/Extension:UserMerge might come in handy if one merges the user to an existing generic one set up by the Wiki Admin.

Which extension (if any) could one use if they want to edit the sign-up form (for example to add a check box that a user is older that 16 years or the add a link to the privacy statement? Semantic Forms?

I agree to the problem with deleting a user's contributions - it leaves behind the username (or IP address if the user is not logged in) in deletion log - thus, is not a clean process.

Your solution using UserMerge extension is a good and easy process to delete the username.

The record of user's contribution in revision history can be deleted using the Manual:DeleteOldRevisions.php . Read this thread for more info - Topic:Tf2bj711f0x48dba .

Also Extension:DeletePagesForGood was recommended in the above thread, but I never used it - so don't know if it's effective.

Also you can directly delete from the database (though a bit risky).

> Which extension (if any) could one use if they want to edit the sign-up form?

You can use Extension:NewSignupPage to do so.

From what I can see (or what I can't see, to be more precise), WMF is handling GDPR with extreme secrecy, or is not going to be compliant on May 25.

No responses in mailing lists: https://lists.wikimedia.org/pipermail/mediawiki-l/2018-May/thread.html

Nothing in Phabricator. Nothing on this thread...

I wonder if WMF is excluded from compliance because it's not a for-profit company.

Any software hosted in EU or has users in EU has to comply with GDPR according to the regulation. So, being a non-profit organization won't relieve them of this problem, I believe.

They have to be compliant to GPDR, because they save personal data, regardless of wether they are a for-profit company or not (and they actually make profit thanks to donations).

What Sturmjäger said. If you have a website located on a server in the EU or which may be accessed by people from the EU, you need to GPDR compliant since even IP addresses are considered data that is protected by that. Since you can't access a website without logging the IP address, your site also affected. (Even if you yourself are not logging the IP on your site, your hoster will in some log files you have no idea of.

Today English Wikipedia is showing a banner with link to this page - https://blog.wikimedia.org/2018/05/21/wikimedia-foundation-privacy-approach/

So, they are also addressing this problem.

Funnily enough, German Wikipedia doesn't show anything yet...

> they are also addressing this problem.

Are you sure? GDPR is more than doing a few minor changes to a privacy policy. Also, the way they're posting this only 3 days before the law is enforced, looks like this is a rather rush and last-minute move.

For example, I'm unable to find in the privacy policy how I can close my account or hide my user name if I want to remove it from the public.

GDPR has already came into effect on May 24th 2016, May 25th 2018 is date it's applicable. There was a 2 year transition period but it looks like nobody really paid attention what GDPR really means for anyone hosting or running a website. Looking at all the law blogs that post about this there are also lot of confusion going on, especially concerning direct marketing. I guess the next months will become very interesting.

I agree. But this may be the first step. Let's see what follows.

I asked a similar question on Quora - https://www.quora.com/How-do-I-customize-a-website-running-on-MediaWiki-software-to-make-it-compliant-with-GDPR-General-Data-Protection-Regulation

The answer by " Jeremy Lee-Jenkins, Wiki creator and developer, Mediawiki, Wikibase and related" contains some useful tips; I am quoting the whole answer here -

"

It should be quite easy. Mediawiki is not great at stealing people data.

Firstly, read A note on our approach to privacy from Wikimedia, and use their changes to their privacy policy as a guide to update yours.

If you have the Checkuser extension installed, you will want to limited people who can access it to registered data controllers only.

You will want to stay up to date with any changes Wikipedia makes to their user-interface to allow for GDPR. Despite the fact it’s happening *now*, they haven’t done anything to change this yet.

If you use analytics of any type, like google analytics, you will need to make sure this is included in your privacy policy. Likewise make sure any nocaptcha/recaptcha solution you use is noted as well.

Don’t sell your users data to third parties.

Keep your user data private. This includes email addresses, names, and IP’s.

"

My another question (https://www.reddit.com/r/WikiInAction/comments/8lhr68/wikipedia_mediawiki_and_the_gdpr_fear_opinion/?st=jhk58rci&sh=e806940e)on Reddit WikiInAction subreddit got this answer from EtherMan -

"

MediaWiki is... special in this regard... On one hand, it is already compliant really as a software. GDPR basically says that you have to agree to any data that is stored. Well that's easy enough, MediaWiki only stores what you specifically supply it, and every single edit you make, comes with the clause that you are resigning ownership of whatever you entered. And the second part is that you have to be able to on request of the owner to release everything that is stored on you, to you. Well that's simple enough through MediaWiki by searching for any edits you made because that in theory, should be all data on you.

Unfortunately, on the other hand... Wikipedia will never be compliant with it, because technically, it does require you to turn over ALL data stored ON you... Not BY you. Basically, any and all data they have ever received in regards to you. That would mean all the private arbcom mails that is in regards to any case you're involved in. It means any and all mentions of you on any talk or article page and so on. Heck it even technically covers any admins that have a stick it note on their monitor with a list of their most hated users if that involves you. This is ALL covered...

Point is, MediaWiki does from a technical standpoint allow a company to be compliant. But Wikipedia is never going to be because it's just fundamentally incompatible and it would be a MASSIVE workload to fix, and the whole structure is not set up to handle any sort of freedom of information on the processes which GDPR requires but that's a problem of Wikipedia, not MediaWiki specifically.

Buuuuuut, WMF doesn't care about GDPR, because WMF is a US company and only cares about US laws. They've made this abundantly clear in the past, and the EU is too chicken to go through with bans on the company which would include cutting off access to the site from and to the EU. And the WMF knows it. It would simply be political suicide to try to block Wikipedia, no matter how much of a criminal organization they may become.

"

@Ciencia Al Poder the last paragraph in the answer may be one explanation to the silence from WMF you talked about.

@all: Wouldn't it make sense to create an article on mediawiki.org on GRDP where we collect possible solutions to increase compliance and the (currently three, the number will sure increase as of tomorrow) threads here so people have a place to start for getting information?

I think, this is a great idea. Please create a page. We can add the sure-shot solutions by editing time to time as new customization options/extensions are created or discovered regarding this matter.

Here you go: GDPR (General Data Protection Regulation) and MediaWiki software

Wow! That's a tremendously helpful article from the very beginning. Thank you.

Is there anyway to edit the displayed content/form fields of Special:CreateAccount? My MediaWiki asks for an optional "real name" that I would like to remove, but I don't know where. MediaWiki.org doesn't show this real name field in CreateAccount so I guess it's possible?

I also may want to add a checkbox that users have to check where they confirm that they are older than 16 years.

You should be able to remove the "real name" with this code in LocalSettings.php: $wgHiddenPrefs[] = 'realname'; (see Manual:$wgHiddenPrefs).

Checkbox: You can use Extension:NewSignupPage to do so.

N vdhdkkxjd oz Dunlop ssjishs d, gfs hdjdhdhdjddjeodhd poi hdeoeje dfffdj v virheee eihriefeoe gee idon't r e geeige e u eiyeueeuuryrur dvejhejeehehrrhhrjrjrh rhrhrjrhjrrhdhrjr rjdbjeheve fgvrjrbr rj egg rivr

I'm currently re-skinning my wiki and want both the main navigation and the page content to be seperated from the background image as "one unit", ie having the same background color and matching borders/box-shadows, so that it looks like one page and not like here in the default Vector, where the main menu is completely seperate on the left side.

To do this I first tried to give both the content and the navigation the same background-color, but the problem was that I couldn't stretch the main navigation div all the way down to the bottom/footer. I tried several stuff, including the display:flex property, but nothing worked out.

Then, I tried assigning the backgorund-image to html and the background-color and a reduced width to the body:

html {
background-image:url('https://domain.tld/background.jpg');
background-size:cover;
background-attachment:fixed;
}
body {
    background-color: #fdfdfd;
    width: 85%;
    margin-left: auto;
    margin-right: auto;
    box-shadow: 10px 0 10px -10px rgba(0,0,0,0.30), -10px 0 10px -10px rgba(0,0,0,0.30);
margin-top:2em;
}

However, now the body doesn't go all the way down to the bottom, as you can see here: https://abload.de/img/mediawikic0sb5.png

What's the problem there? How to stretch the body to the bottom?

Hi, we are downloading wiki dump from https://dumps.wikimedia.org/cswiki/latest/, and checking if files are up to date using https://dumps.wikimedia.org/cswiki/latest/cswiki-latest-sha1sums.txt. Now (21.6.2018 12:54) is possible to see, that wikidump data are updating. But it is doing on the fly, and at the link /latest are both old and new data, but in file cswiki-latest-sha1sums.txt are only new files.

So is it possible to make link /latest AFTER data dump is done ? Or is it possible to move https://dumps.wikimedia.org/cswiki/20180620/dumpstatus.json to pernament link for example https://dumps.wikimedia.org/cswiki/latest/dumpstatus.json, then i can check, if build is done and i can download dump.

Thank you

Roman

Seems when i hide TOC, headlines reposition correctly, but body text doesn't reposition correctly. But if i resize the window, then it the body text repositions itself correctly.

Before collapsing, headline and body wrap around the TOC:

After collapse, headline moved, but body-text didn't:

After shrinking window, then re-maximizing it, body-text moved to right place:

This vid shows that body text repositions correctly only after changing window size-- which doesn't make sense.

http://pc.cd/TJIctalK

Theory: My custom CSS creates taller margin-top for headlines. Maybe the core TOC code that forces text to reposition is confused by that?

MW v1.30

Chrome v67