issue with editing templates in Visual Editor, Mediawiki 1.35.0 - MediaWiki-l

13 Nov 2020

MW 1.35.0, TemplateData 0.1.2: I have an issue editing via Visual Editor (VE) templates
defined using TemplateData once the pages containing these templates have been saved. I am
not using subpages for the documentation.   The templates work except for this issue with
editing.

Specifically, editing these templates works fine in VE up through the first save (i.e.,
for initial template population and any editing before save), for example:
https://imgur.com/a/dTKW7xv <https://imgur.com/a/dTKW7xv>

but upon subsequent edits it cannot find the template as shown here:
https://imgur.com/a/q9kla6J <https://imgur.com/a/q9kla6J> : It strangely believes
that :index.php?title=Template:<Template Name> is the name of the Template page!

I would like to know if others have experienced this issue.  I have attached some
technical analysis outlining what the problem may be.

Ben

Analysis of the javascript in the VE module indicates tha3t there seems to be a problem
with how the template page names are being extracted:

1) the href referring to the clicked-on template is passed to
normalizeParsoidResourceName

dm/models/ve.dm.MWTemplateModel.js
----------------------------------
	ve.dm.MWTemplateModel = function VeDmMWTemplateModel( transclusion, target ) {
	        // Parent constructor
	        ve.dm.MWTemplateModel.super.call( this, transclusion );

	        // Properties
	    this.target = target;
	    for	(var i in target)
	    {
		console.log("BJS "+i+" "+target[i]);
	    }
	        // TODO: Either here or in uses of this constructor we need to validate the
title
	        this.title = target.href ? mw.libs.ve.normalizeParsoidResourceName( target.href )
: null;   /// BJS ********* href ./index.php%3Ftitle=Template:Book
	        this.sequence = null;
	        this.params = {};
	        this.spec = new ve.dm.MWTemplateSpecModel( this );
	    this.originalData = null;
	};

2) normalizeParsoidResourceName is essentially a wrapper to parseParsoidResourceName,
which in turn passes the decoded URI to decodeURIComponentIntoArticleTitle

modules/ve-mw/preinit/ve.utils.parsoid.js
————————————————————
mw.libs.ve.normalizeParsoidResourceName = function ( resourceName ) {
        return mw.libs.ve.parseParsoidResourceName( resourceName ).title;
};

mw.libs.ve.parseParsoidResourceName = function ( resourceName ) {
        // Resource names are always prefixed with './' to prevent the MediaWiki
namespace from being
        // interpreted as a URL protocol, consider e.g.
'href="./File:Foo.png"'.
        // (We accept input without the prefix, so this can also take plain page titles.)
    var matches = resourceName.match( /^(\.\/|)(.*)$/ );
    console.log("BJS utils.parsoid matches "+matches);
    console.log("BJS utils.parsoid matches decoded
"+mw.libs.ve.decodeURIComponentIntoArticleTitle( matches[ 2 ] ));

        return {
                // '%' and '?' are valid in page titles, but normally
URI-encoded. This also changes underscores
                // to spaces.
                title: mw.libs.ve.decodeURIComponentIntoArticleTitle( matches[ 2 ] ),
                rawTitle: matches[ 2 ]
        };
};

3) However, and I believe this is where things go horribly awry,
decodeURIComponentIntoArticleTitle does nothing of the sort, it simply runs
decodeURIComponent against the string, without extracting the article title (which is
presumably what is intended per the function name) - so everything that subsequently uses
template.title is in fact still using the URI, not the article name.

modules/ve-mw/preinit/ve.utils.parsoid.js
————————————————————

mw.libs.ve.decodeURIComponentIntoArticleTitle = function ( s, preserveUnderscores ) {
        try {
            s = decodeURIComponent( s );

        } catch ( e ) {
            console.log("BJS error");
            return s;
        }
        if ( preserveUnderscores ) {
                return s;
        }
        return s.replace( /_/g, ' ' );
};