Sorry, I have belatedly realized that setting $wgArticlePath (which I only just found out
about) to “/$1” (appropriate for my wiki) solves this problem as it casts the internal
reference to the Template correctly, i.e. without any URI cruft. However I do feel that
this VE logic should work correctly even when $wgArticlePath is unset / operating at its
default value of index.php?title=<…>.
On Nov 13, 2020, at 6:26 PM, B JS
<bjsdaiyu(a)gmail.com> wrote:
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, ' ' );
};