Mailing List Archive

issue with editing templates in Visual Editor, Mediawiki 1.35.0
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, ' ' );
};
Re: issue with editing templates in Visual Editor, Mediawiki 1.35.0 [ In reply to ]
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@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, ' ' );
> };
>
>
>
Re: issue with editing templates in Visual Editor, Mediawiki 1.35.0 [ In reply to ]
I've seen several issues with links in VisualEditor on wikis that do not
have short URLs set up. We don't properly support URLs like
"/w/index.php?title=Article".

Setting $wgArticlePath and appropriate rewrite rules to use URLs like
"/wiki/Article", is indeed the best solution.

If you can't do that, then you can instead set $wgUsePathInfo=true,
allowing you to use URLs like "/w/index.php/Article".

--
Bartosz Dziewo?ski

_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l