In T226616#5727002, @Seppl2013 wrote:

If there is an external command to render as with graphviz/plantuml and other extensions i think it's not much more of an effort to create a local git repository to keep track of the rendered/cached results - with tagging it would be quite easy to access the information and supply it for rendering.

For the preview scenario, we figured out a way to base64-encode the rendered PNGs and display them with data URIs (data:image/png;base64,...) instead of saved wiki images. This way no previews end up in the FileRepo or Database. The old revisions is a good point! I think it would be okay to do the same in that case.

I don't mind too much storing the graph images on the wiki side...it's helpful for abstracting image auth, hosting and caching. Also it provides users with an easy way to track graph changes over time visually. We've had some success doing this and storing the md5 hash of the image source in the file metadata (in the image table). You can do the actual rendering locally or remotely depending on what you need.

In T18691#5561503, @kchapman wrote:

@osorio-juan-microsoft you are planning to look into the screenreader issue on your side? Thanks!

New design has a few benefits over the old (icon based) design. I'll try to address all the points.

In T18691#5541651, @Msftwikipmey wrote:

Will check with @osorio-juan-microsoft about whether screen reader would read this out...

In T18691#5488544, @daniel wrote:

2. We don't know if this is proposed purely as a third party feature, or for deployment on WMF systems. If it's just for 3rd parties, it may not even need an RFC, and could perhaps be done as an extension as well. If it's for WMF production, we will have to look very closely on the implications for caching and overall performance.

In T18691#5476125, @WDoranWMF wrote:

I'm going to move this into CPT's clinic duty for review but we'll need the merge conflict resolved first if that's ok.

@Esanders @alexhollender I have removed some of the extra styles so that the copy field looks the same as the other CopyTextLayouts.

In T18691#5258846, @Esanders wrote:

There is now an mw.widgets.CopyTextLayout in core, as used on the URL shortener (https://meta.wikimedia.org/wiki/Special:UrlShortener):

In T18691#5227523, @Quiddity wrote:

I think I mean the former? I'm not entirely clear on what the technical distinction would imply. :-) The main thing I want to avoid, is having to manually replace the underscores with spaces, which I currently have to do whenever I copy part of the URL from the browser-address-bar. (I/we remove the underscores because otherwise they lead to linewrap issues, as well as being not an actual part of the title).

I have to think about this one because it should still be valid Wikitext for subsections with special characters like ] (closing square bracket)

In T18691#5226571, @Quiddity wrote:

2. Would it be possible to strip the underscore _ character out of the Heading_text in the Wikitext version?

By this, do you mean we should place the subsection title as-is after the # on the Wikitext version? Or just replace underscores with spaces?

This is the current implementation I have pushed:

I ran into an issue where graphs were being regenerated because of a bug in LocalFile. I have since pushed a fix for it, and now our graphs are not being regenerated unless their source changes.

In T129546#5098710, @mingle wrote:

It seems like things may not be as "plaintext" under the hood as I thought.

In T129546#5098455, @mingle wrote:

@DLynch hmm, am I going crazy or missing something?

Also, I'm pasting from sources within the browser outside of the Mediawiki instance. Either from the URL bar, or copy/pasting from plain text on a page. Both seem to be converted to external links on test2.

In T220055#5084977, @cscott wrote:

So that's pretty much "how it's supposed to work". Changing this would be wikitext 2.0-scope work.

Looks like the commit dcf408fc8e7816715a0a203b1c4ed1f873579750 has already fixed this.

I like the idea of the share button, even though it adds an extra click to a relatively simple action. However, what are we doing to address the earlier concern of placing more actions next to the Edit action, when Edit is the most important action on a wiki? Also, do we need to consider the mobile case as well (i.e. creating a solution for mobile browsing parallel to a desktop version)?

Pinging stakeholders: It seems to me that a good potential solution would be to use the image (rather than the HTML) if and only if the HTML content only contains metadata node, empty text nodes, and the image(s) themselves. In other words, if the HTML contains any actual content (text or otherwise) other than the image(s), it should be used instead of the image. I have some working fix that I validated by pasting a single image from multiple popular sources, such as Chrome, One Note, and Word. If nobody has objections to the implementation, I'll go ahead and submit a patch.

No worries, I'll take a look to see if this is an easy bug to fix, and if so I'll submit a patch

@MarkAHershberger The output from MS Word Online is the following:

@MarkAHershberger Hi! Any update on this?

@Krinkle Do you think you could help me take a look at this one?

I'm guessing this is something one of the WMF teams wants to own, but in terms of community contributions, is there anything we can do to help move this along?

I see, that makes sense, thanks matmarex! This specific issue seems to have been fixed on VisualEditor (master, 9e2b9c6). Thanks!

Bumping this thread. Maybe making this configurable would be the best option (i.e. via LocalSettings.php or such)? With external links being blocked by default?

@Samwilson I've submitted a new patch for single setting items. Let me know if this is better!

@Samwilson You're right! Sorry I missed this.

For the bug linked, there is an added benefit of having the test scripts on a path with spaces (running shell commands with executables/arguments located in a path that has spaces is a common issue in Windows). Although the linter may complain in this setup, some MediaWiki developers may want to run shell commands with spaces in them, and the tests must validate that such shell commands work as expected. Is there a way to mark files as not linted?

@Samwilson Thanks for all the help! I've added a test alongside the fix. Is anything missing for getting it merged?

I have an easy fix for this issue in particular (does not fix the other shell issue related to non-blocking pipes in Windows). Should I send a PR against master for mediawiki/core repo?