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.
Dec 10 2019
Dec 6 2019
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.
Dec 5 2019
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.
Nov 5 2019
Oct 18 2019
Oct 9 2019
@osorio-juan-microsoft you are planning to look into the screenreader issue on your side? Thanks!
Oct 4 2019
New design has a few benefits over the old (icon based) design. I'll try to address all the points.
Will check with @osorio-juan-microsoft about whether screen reader would read this out...
Sep 18 2019
Sep 12 2019
- 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.
Sep 9 2019
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.
Jul 25 2019
Jun 14 2019
There is now an mw.widgets.CopyTextLayout in core, as used on the URL shortener (https://meta.wikimedia.org/wiki/Special:UrlShortener):
Jun 12 2019
Jun 3 2019
May 31 2019
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)
- 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?
May 30 2019
This is the current implementation I have pushed:
May 19 2019
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.
Apr 9 2019
It seems like things may not be as "plaintext" under the hood as I thought.
@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.
Apr 5 2019
Apr 4 2019
So that's pretty much "how it's supposed to work". Changing this would be wikitext 2.0-scope work.
Apr 3 2019
Mar 5 2019
Looks like the commit dcf408fc8e7816715a0a203b1c4ed1f873579750 has already fixed this.
Mar 1 2019
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)?
Feb 5 2019
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.
Feb 1 2019
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
Jan 28 2019
@MarkAHershberger The output from MS Word Online is the following:
Jan 24 2019
@MarkAHershberger Hi! Any update on this?
Jan 23 2019
@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?
Jan 22 2019
Jan 16 2019
Jan 14 2019
Jan 11 2019
Jan 9 2019
I see, that makes sense, thanks matmarex! This specific issue seems to have been fixed on VisualEditor (master, 9e2b9c6). Thanks!
Jan 7 2019
Dec 14 2018
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?
Dec 13 2018
Nov 29 2018
Nov 14 2018
Nov 13 2018
@Samwilson I've submitted a new patch for single setting items. Let me know if this is better!
Nov 8 2018
@Samwilson You're right! Sorry I missed this.
Nov 6 2018
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?
Oct 25 2018
@Samwilson Thanks for all the help! I've added a test alongside the fix. Is anything missing for getting it merged?
Oct 24 2018
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?