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, ' ' );
};