+Upstream, this is a issue with facebook, not us.

EN.WP.ST47 wrote:

Wouldn't that be downstream?

bugs wrote:

I think comment 28 is a perfectly fine "WONTFIX" or "WORKSFORME" response, rather than a downgrade to "low priority". If it's not causing a problem and we have an extension to fix this, and we don't want it to go into core, than this can probably be closed.

(In reply to comment #29)

+Upstream, this is a issue with facebook, not us.

(In reply to comment #30)

Wouldn't that be downstream?

Upstream or downstream, Facebook technically already provides support for a
metadata standard.
It's more of a "We just know that we're going to get angry users if we include
Facebook related metadata into core" issue.
Also a "Using $wgLogo in og:image has inadvertent negative side effects that require non-trivial extra coding so we can't just drop it in anyways."

(In reply to comment #25)

w3m and lynx DO NOT...

All I know is I can tell they are there
$ echo '<img src="zzz">'|w3m -dump -T text/html
[zzz]
and I can hit

t runs the command w3m-toggle-inline-image, which is an interactive
compiled Lisp function in `w3m.el'. [emacs_w3m]

But of course not with the wiki logo. But of course real men are supposed to
use real browsers, so never mind.
P.S., Go ahead and close the bug. But like Ernest said, "I like the little logo",
http://www.youtube.com/watch?v=v8aVKTVCJpM

EN.WP.ST47 wrote:

Why would you want to know that the logo is there on a text browser anyway? Seems like it just adds noise?

Anyway, closing per comment 28, comment 31, and comment 33 as invalid.

(In reply to comment #33)

(In reply to comment #25)

w3m and lynx DO NOT...

All I know is I can tell they are there
$ echo '<img src="zzz">'|w3m -dump -T text/html
[zzz]
and I can hit

t runs the command w3m-toggle-inline-image, which is an interactive
compiled Lisp function in `w3m.el'. [emacs_w3m]

But of course not with the wiki logo. But of course real men are supposed to
use real browsers, so never mind.

Text editors are not part of our compatibility guidelines: [[mw:Browser support]]

Rather... I can't think of any website that would sanely consider a text editor a compat target.

• Bug 54830 has been marked as a duplicate of this bug. ***

Reopening after the dupe from 54830.

I just want to mention that this problem affects not only Facebook users sharing URLs of MediaWiki sites, also Google+ users, and probably any other service featuring URLs with an image retrieved automatically. When those pages have no images, these services take automatically the little ugly "Powered by MediaWiki" banner in the footer, or nothing if it has been removed. The prominent site logo is always ignored.

As someone sharing frequently MediaWiki pages in so-called social networks, I believe this problem is being underestimated here. These services are currently the main channel of promotion of URLs, and these services feature prominently the main image contained in those URLs because they make the link more attractive. If you want to promote a MediaWiki page without graphics you will be totally out of luck: there will be no way to use at least your site logo.

Meanwhile, other wikis and CMSs...

is this a dupe of https://bugzilla.wikimedia.org/show_bug.cgi?id=31338 or https://bugzilla.wikimedia.org/show_bug.cgi?id=29242 ?

Bug 29242 – nope, entirely different thing. Bug 31338 sounds related, maybe that approach could be used here (but I don't know enough about this stuff to judge).

For listeners tuning in now, the reasons again regular <img src> were outlined in comment 27.

Can someone make an umbrella tracking bug for "Better presentation of content shared via mediawiki on external sites" I want to make sure whoever works on this doesn't miss anything.

What bugs would that track? If you have a list, just create one.

About comment #27

Ref wiki pages without images being bad. True for Wikipedia, not for all the MediaWikis out there. And even without leaving the Wikimedia context: what about Wiktionary, Wikiquotes, Wikisource...?

Ref wrong images becoming site logos. Isn't that problem obvious when it happens, and isn't the first interest of a sane admin to make sure the logo looks good? I don't see why we should protect admins from themselves. Cutting an image right is not that difficult.

This leaves us purely with the technical problems described when using <img src>. I'm not saying they are not relevant, I just want to focus the discussion in the technical arguments, leaving aside the rest.

My comment? Could you be a little more specific about which parts of the comment you're referencing, I'm having a little bit of trouble matching them up to parts of my comment.

I started with default quotes, but the comment was getting really long. Let me try harder:

(In reply to comment #24)

Also, I hope I'm not the only one who thinks it's rather odd that we're trying
to build an encyclopedia, but "the most important image on the whole site" is
not an image used to illustrate the topic of an article, but the site's logo. I
would hope that people who use our wiki are "painstaking[ly] craft[ing]" their
content rather than a little pretty image.

Heh, I was thinking of saying something along those lines too. A wiki where the
logo is "painstaking[ly] crafted" but the content is not "painstaking[ly]
crafted" is worthless.

True for Wikipedia, not for all the MediaWikis out there. And even without leaving the Wikimedia context: what about Wiktionary, Wikiquotes, Wikisource...?

We can't assume that the quality, completeness, and interest of a wiki page is measured by the existence of an illustrative image or not.

That I know of there are 3 current functional uses of the logo being a
background-image:

• Without any special coding a background-image that is too large gets cut off

(we have skins with various logo area sizes, and the logo can be any arbitrary
url to any unvetted image), unlike an <img> which if allowed to grow will
overlap the content area. (note that since $wgLogo is an arbitrary url we can't
do any ImageMagic stuff with it, iirc MediaWiki also functions mostly in hosts
with url fopen wrappers disabled, so we also can't do anything that would
require MW to download an image from a url)

• Using a background-image with a center center position as we do means we

cater to a variety of logo sizes while still perfectly centering them in all
skins.

• Using a background-image also functions as a way to allow the logo and the

logo area to be customized in various ways by css.

I don't see why we should protect admins from themselves. Cutting an image right is not that difficult.

Our documentation currently says that a logo is expected to be 135x135. Admins playing with other sizes (locally or remotely) do it at ther own risk.

https://www.mediawiki.org/wiki/Manual:$wgLogo

I did some testing to see what can be done with an <img> instead of the
background-image. With use of overflow: hidden; it is possible to have the logo
area cut off overly large logos easily.

Good! One problem less.

The centering however is a bit of good
and bad. A text-align: center; does permit the logo to be horizontally centered
like the background-image. However we cannot vertically center a logo that is
an <img> like we can for a background-image. With some tweaks to the css it is
possible to instead make the logo area vertically shrink to fit the logo of
whatever height. However this has two caveats, both I'm sure we'll end up with
people complaining about. A) Of course, the wiki with vertically small logos
may not be happy about their logo area suddenly changing size. Technically they
can pad their logos or hardcode margins. However that's not going to make wiki
with extra skins including ones where a vertically conservative logo is a good
thing happy. And forcing people to hardcode px margins is not a good practice
for us (actually if they don't enable site stylesheets they can't even do that
without code hacks, another bad tradeoff).

If your logo is expected to be 135x135, then you can place your vertically small logo within a square canvas leaving the rest transparent.

B) More importantly, while the logo
hasn't loaded the navigation will appear higher up in the sidebar, and once
it's loaded will move to accommodate the logo. This will have the effect of
making the sidebar jump around, create a visual distraction during the loading
of the page, and can actually create a usability defect where a user goes to
click a link, the logo loads, the sidebar jumps, and then the user clicks a
different link. (this problem will be particularly noticed by low-speed
Internet users)

Mmm even if you are placing that image inside a fixed size div, in combination with the mentioned "overflow: hidden"?

(In reply to comment #45)

Heh, I was thinking of saying something along those lines too. A wiki where the
logo is "painstaking[ly] crafted" but the content is not "painstaking[ly]
crafted" is worthless.

True for Wikipedia, not for all the MediaWikis out there. And even without
leaving the Wikimedia context: what about Wiktionary, Wikiquotes,
Wikisource...?

We can't assume that the quality, completeness, and interest of a wiki page
is
measured by the existence of an illustrative image or not.

I guess I personally glossed over the "image used to illustrate the topic of an article" part. When I said "content" I literally meant content. I view the logo as a superfluous decoration, what's important is the content.
Tbh, on a wiki like Wiktionary where pages don't have images I don't really think of the logo as a substitute for them. IMHO pages like those that are text-only and don't have a representative image are typically best shared just like that, as text-only shares.

I don't see why we should protect admins from themselves. Cutting an image
right is not that difficult.

Our documentation currently says that a logo is expected to be 135x135.
Admins
playing with other sizes (locally or remotely) do it at ther own risk.

https://www.mediawiki.org/wiki/Manual:$wgLogo

Our recommendation for logo size is pretty much just pulled out of a hat, we've never had a true standard for image sizes.

• In one of MW's first skins, Nostalgia, the logo was simply inserted into the corner as an <img> there was no fixed sidebar area content simply floated around the logo, you could use absolutely any logo size you wanted.
• In Standard/Classic the logo area was somewhere around 135px in height.
• MonoBook's logo area is 155px in height.
• And Vector's logo area is 160px in height.
• And we have no clue what size of logo area other skins use.

Now take note of how I stated "#px in height", I mean that quite literally. Our logos only guarantee a specific number of pixels for the height. While by default the width typically matches the same number of pixels as the height, our logo area widths are actually defined as em numbers. They are explicitly set so that the width of the logo area can both grow beyond what you'd expect and shrink to smaller than it is by default.

So our first skins had no restrictions on logo sizes, our default skins have been changing the restriction each time we make a new one, the width is actually not fixed to a pixel size.

I can also confirm that site authors don't care about what our manual says about $wgLogo. They simply create whatever fits in the logo area on their default skin. And that number grows, back when Wikia had monobook as a default I made plenty of 150x150px and 155x155px logos.

Rather than protecting site authors, cutting off logos is a little more about protecting site users using non-default skins.

There's also the whole bit about customizing the logo by site css. A number of wikis do this in practice. en.wp does it in Common.css to provide mdpi and hdpi logos. And other wikis do it overriding the default logo in some namespaces, etc...

If your logo is expected to be 135x135, then you can place your vertically
small logo within a square canvas leaving the rest transparent.

...

Mmm even if you are placing that image inside a fixed size div, in
combination
with the mentioned "overflow: hidden"?

A fixed size div will fix the jump, but it won't fix the vertical centering of the logo. We can't know the height of the logo beforehand. And fixing the height will simply leave the logo at the top of that region. So small logos still won't be vertically centered.

You are receiving this mail because:

• You reported the bug.

OK that is very nice, but there is no way for me to unsubscribe due to bug 58066 so everybody please stop talking until then.

(In reply to comment #47)

You are receiving this mail because:

• You reported the bug.

OK that is very nice, but there is no way for me to unsubscribe due to bug
58066 so everybody please stop talking until then.

Umm no. Provided comments are on topic, people are going to comment on bug as needed in order to work towards a resolution. If you don't like it, you can:

*Change your email prefs in https://bugzilla.wikimedia.org/userprefs.cgi?tab=email to not email for bugs you created
*Set up an email filter
*Delete the email without reading it
etc

(In reply to comment #48)
In fresh Bugzilla it would take me just one click to unsubscribe, just like the CC people.
Alas, with this old Bugzilla, one needs to make a Spamassassin Filter for just this one bug, lest one mess up ones other settings.

OK I'll use your third option. Certainly this can't last forever.

jidanni: That's really stuff to discuss in bug 49597 (plus your statement is wrong as we will not run unstable development versions in production.)
Feel free to create a bug report here asking to backport the 4.5 fix for https://bugzilla.mozilla.org/show_bug.cgi?id=148564 once we've upgraded to 4.4.

• Bug 59129 has been marked as a duplicate of this bug. ***

In case it wasn't clear from the the discussion above, this only seems to be an issues for article that are shared which do not have any images.

When sharing through a link to a page on wikipedia or other media wiki sites
the software usually correctly picks the lead or first image from an article,
however if the article does not contain any images or only transcluded images .
e.g. https://en.wikipedia.org/wiki/List_of_Colorado_ski_resorts then the
mediawiki logo from the site footer is used instead. (see attached screenshot)
instead of the mediawiki logo, the site logo (at a sufficiently high
resolution) should be used instead, as it would be a more relevant to have the
site logo (where the link goes to) rather than the logo of the CMS the content
is displayed through.

wes.turner wrote:

I see a few possible solutions to this problem:

1. Make the Wikipedia logo an <img> tag
   • Not preferable because accessibility.

2. Make the MediaWiki logo a background-image property of a <div> (or <a>) tag
   • Probably the easiest thing to do.

3. Add an additional <img> tag with the Wikipedia logo (e.g. to the footer)
   • Additional [cacheable] image : https://upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png

4. Specify og: metadata in page headers
   • http://ogp.me/#structured : og:image, og:secure_image
   • I don't know how/whether this takes priority over images found in-page for sites such as Facebook and Google+

TBH, the accessibility argument would also apply to unnecessary <img> tags (with @alt attributes) in the footer.

(In reply to comment #53)

2. Make the MediaWiki logo a background-image property of a <div> (or <a>)

tag

Once upon a time, Facebook's documentation said that all images smaller than 50x50px were excluded from being used as images. Tbh if they actually stuck to that this wouldn't even be a problem.

4. Specify og: metadata in page headers
   • http://ogp.me/#structured : og:image, og:secure_image
   • I don't know how/whether this takes priority over images found in-page

for sites such as Facebook and Google+

Yes, that's generally the point of the metadata, it has precedence over in-page images.

wes.turner wrote:

Not cool when you're trying to share links to non-gender-specific Wikipedia things like motorcycles and stuff and there's a beautiful MediaWiki flower there and you have to choose between the inline summary and the flower image; I'm waiting for the 400MB+ MediaWiki repository to clone so I can edit the HTML in the footer.

wes.turner wrote:

(In reply to comment #54)

(In reply to comment #53)

2. Make the MediaWiki logo a background-image property of a <div> (or <a>)

tag

Once upon a time, Facebook's documentation said that all images smaller than
50x50px were excluded from being used as images. Tbh if they actually stuck
to
that this wouldn't even be a problem.

4. Specify og: metadata in page headers
   • http://ogp.me/#structured : og:image, og:secure_image
   • I don't know how/whether this takes priority over images found in-page

for sites such as Facebook and Google+

Yes, that's generally the point of the metadata, it has precedence over
in-page
images.

Okay, so #4 isn't feasible because specifying og:image would preempt image selection.

#2: I understand that setting opacity: 0 with background-image is acceptable as a replacement for (incomplete) @alt attributes on <img> tags. [1]

[1] https://stackoverflow.com/questions/10009751/background-images-over-hidden-text-bad-for-accessibility

#3: We may need some help with obtaining a Wikipedia image with a similar aspect ratio (88x31)

wes.turner wrote:

Why isn't there an option to select between "a Wikimedia project" and "Powered by MediaWiki" if both images are 88x31?

Not too familiar with the mediawiki codebase [...]

$ grin -i poweredby

$ grin 'getPoweredBy|poweredbyico' . -C 5

I see a getPoweredBy function in includes/Skin.php :

$url = htmlspecialchars( "$wgStylePath/common/images/poweredby_mediawiki_88x31.png" );

And then in includes/SkinTemplate.php a template variable is set:

$tpl->set( 'poweredbyico', $this->getPoweredBy() );

But how/where does 'poweredbyico' get included into the Vector template?

wes.turner wrote:

(BTW I'm following this tutorial in order to learn how to submit a patch to fix this issue: https://www.mediawiki.org/wiki/Gerrit/Tutorial#How_to_submit_a_patch )

wes.turner wrote:

#2: In includes/Skin.php, I believe the following approach to getPoweredBy() would be accessible and ___-COMPLIANT.

"<a href='http://www.mediawiki.org/'><img src='$url' alt='MediaWiki' /></a>";

"<a href='http://www.mediawiki.org/'><span style="background-image: url('$url'); width: 88px; height: 31px; opacity: 0">trans(Powered by) MediaWiki</a>"

I'm not sure why we wouldn't need to do the same for getCopyrightIcon().

wes.turner wrote:

As an aside, with RDFa, we could probably just add property="og:image" to all of the in-page images.

wes.turner wrote:

... For http://schema.org/Organization (which can be expressed in RDFa), we could specify property="logo" content="https://upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png"

(In reply to comment #57)

Why isn't there an option to select between "a Wikimedia project" and
"Powered
by MediaWiki" if both images are 88x31?

Unfortunately you'll have to ask Facebook that, it's their proprietary code that's picking the images out of standardized html.

But how/where does 'poweredbyico' get included into the Vector template?

poweredbyico is deprecated, skins now use footericons.
See https://www.mediawiki.org/wiki/Manual:$wgFooterIcons

(In reply to comment #60)

As an aside, with RDFa, we could probably just add property="og:image" to
all
of the in-page images.

OGP isn't RDFa, they do state "We've based the initial version of the protocol on RDFa" but it isn't actual RDFa and it violates some of RDFa's rules. OGP's "spec" only accepts data from meta tags in the head.

However I have considered extracting the list of images included in the page output and outputting og:image data in the head for them. Actually I've had other ideas like allowing images in content to be marked as presentational/non-presentational so we can intelligently exclude bad images.

wes.turner wrote:

I've submitted a preliminary patch to master to gerrit which implements #2 (with @title attributes instead of opacity:0)

https://gerrit.wikimedia.org/r/#/c/108221/

wes.turner wrote:

(In reply to comment #62)

(In reply to comment #57)

Why isn't there an option to select between "a Wikimedia project" and
"Powered
by MediaWiki" if both images are 88x31?

Unfortunately you'll have to ask Facebook that, it's their proprietary code
that's picking the images out of standardized html.

But how/where does 'poweredbyico' get included into the Vector template?

poweredbyico is deprecated, skins now use footericons.
See https://www.mediawiki.org/wiki/Manual:$wgFooterIcons

(In reply to comment #60)

As an aside, with RDFa, we could probably just add property="og:image" to
all
of the in-page images.

OGP isn't RDFa, they do state "We've based the initial version of the
protocol
on RDFa" but it isn't actual RDFa and it violates some of RDFa's rules. OGP's
"spec" only accepts data from meta tags in the head.

Ah. Good call.

http://schema.org/WebPage .image

http://schema.org/WebPage .primaryImageOfPage

http://schema.org/ImageObject

However I have considered extracting the list of images included in the page
output and outputting og:image data in the head for them. Actually I've had
other ideas like allowing images in content to be marked as
presentational/non-presentational so we can intelligently exclude bad images.

TIL about https://www.mediawiki.org/wiki/Extension:OpenGraphMeta

wes.turner wrote:

• schema:Thing has a schema:image property

wes.turner wrote:

You're probably already aware of https://www.wikidata.org/wiki/Property:P18 (image) and https://www.wikidata.org/wiki/Property:P154 (logo image).

wes.turner wrote:

... Looking at makeFooterIcon() in includes/Skin.php (I had 'tested' the raw HTML w/ Chrome): is there a fancy way to specify inline CSS style attributes (like background-image, width, height, and display) with Html::element or Html::rawElement? (Which templating library is this?)

(In reply to comment #64)

However I have considered extracting the list of images included in the page
output and outputting og:image data in the head for them. Actually I've had
other ideas like allowing images in content to be marked as
presentational/non-presentational so we can intelligently exclude bad images.

TIL about https://www.mediawiki.org/wiki/Extension:OpenGraphMeta

I've actually been hoping to make this metadata part of core and deprecating OpenGraphMeta. This could all be done much better if re-implemented as part of core. And this really is basic stuff no wiki should be without.

Though that depends on stuff implemented alongside this RFC:
https://www.mediawiki.org/wiki/Requests_for_comment/Update_our_code_to_use_RDFa_1.1_instead_of_RDFa_1.0

(In reply to comment #67)

... Looking at makeFooterIcon() in includes/Skin.php (I had 'tested' the raw
HTML w/ Chrome): is there a fancy way to specify inline CSS style attributes
(like background-image, width, height, and display) with Html::element or
Html::rawElement? (Which templating library is this?)

Nope, we don't have such a thing right now. And you'll probably want to consider using the css sanitizing method inside Sanitize:: for stuff besides the background image and checking that nothing tries crossing a ;.

I hacked the logo as first og:image into the header, followed by all other article images. I see no disadvantages so far.

wes.turner wrote:

(In reply to comment #69)

(In reply to comment #67)

... Looking at makeFooterIcon() in includes/Skin.php (I had 'tested' the raw
HTML w/ Chrome): is there a fancy way to specify inline CSS style attributes
(like background-image, width, height, and display) with Html::element or
Html::rawElement? (Which templating library is this?)

Nope, we don't have such a thing right now. And you'll probably want to
consider using the css sanitizing method inside Sanitize:: for stuff besides
the background image and checking that nothing tries crossing a ;.

It's been awhile since I've written any PHP; I'll have to lookup what htmlspecialchars does again. Are there test cases for these? It may be better for someone familiar with the input sanitization codebase to tkae it from here.

Where in the docs would I look for 'trusted' configuration settings? Can these variables be modified?

It looks like Sanitizer::validateAttributes would call Sanitizer::checkCss on the style property; but the docstrings for Sanitizer::checkCss specify:

• Currently URL references, 'expression', 'tps' are forbidden.

so I suppose the following would be needed:

• background-image: '";>
• width: safeEncodeAttribute
• height: safeEncodeAttribute

wes.turner wrote:

(In reply to comment #70)

I hacked the logo as first og:image into the header, followed by all other
article images. I see no disadvantages so far.

Cool! Which networks does it work w/?

Wes: I only tested for Facebook and debugged using https://developers.facebook.com/tools/debug/

wes.turner wrote:

(In reply to comment #73)

Wes: I only tested for Facebook and debugged using
https://developers.facebook.com/tools/debug/

Nice. So Facebook does parse (some?) og:image tags beyond just <meta> tags within <head>?

https://stackoverflow.com/questions/10397510/are-open-graph-tags-just-for-facebook

wes.turner wrote:

(In reply to comment #68)

(In reply to comment #64)

However I have considered extracting the list of images included in the page
output and outputting og:image data in the head for them. Actually I've had
other ideas like allowing images in content to be marked as
presentational/non-presentational so we can intelligently exclude bad images.

TIL about https://www.mediawiki.org/wiki/Extension:OpenGraphMeta

I've actually been hoping to make this metadata part of core and deprecating
OpenGraphMeta. This could all be done much better if re-implemented as part
of
core. And this really is basic stuff no wiki should be without.

Though that depends on stuff implemented alongside this RFC:
https://www.mediawiki.org/wiki/Requests_for_comment/
Update_our_code_to_use_RDFa_1.1_instead_of_RDFa_1.0

Did anyone mention an RDFa 1.0 requirement?

I've been parsing / checking / validating with PyRDFa.

(In reply to comment #71)

It looks like Sanitizer::validateAttributes would call Sanitizer::checkCss on
the style property; but the docstrings for Sanitizer::checkCss specify:

• Currently URL references, 'expression', 'tps' are forbidden.

so I suppose the following would be needed:

• background-image: '";>
• width: safeEncodeAttribute
• height: safeEncodeAttribute

Html::element already handles encoding attributes, you just want to sanitize css.(In reply to comment #74)

(In reply to comment #73)
Nice. So Facebook does parse (some?) og:image tags beyond just <meta> tags
within <head>?

https://stackoverflow.com/questions/10397510/are-open-graph-tags-just-for-
facebook

Besides Google+ there's also a list of OGP parsers to test:
http://ogp.me/#implementations

(In reply to comment #75)

(In reply to comment #68)
Did anyone mention an RDFa 1.0 requirement?

The commit that implements that RFC includes a high level API for managing RDFa prefixes, adding them to <html>, and adding RDFa to the <head>.

$og = $out->getPrefixContext()->prefix( 'og', 'http://ogp.me/ns#', true );
$out->addGraphProperty( $og->curie( 'image' ), ... );

wes.turner wrote:

(In reply to comment #76)

(In reply to comment #71)

It looks like Sanitizer::validateAttributes would call Sanitizer::checkCss on
the style property; but the docstrings for Sanitizer::checkCss specify:

• Currently URL references, 'expression', 'tps' are forbidden.

so I suppose the following would be needed:

• background-image: '";>
• width: safeEncodeAttribute
• height: safeEncodeAttribute

Html::element already handles encoding attributes, you just want to sanitize
css.(In reply to comment #74)

This test fixture seems to indicate that a

'background-image: url(' . $wgFooterIcons['powererdby']['src'] . ')';

CSS attribute containing input from configuration on the filesystem may be stripped:

https://git.wikimedia.org/blob/mediawiki%2Fcore/6a2d25eed09c311c70657789b3f7a841bc5363db/tests%2Fphpunit%2Fincludes%2FSanitizerTest.php#L253

https://www.mediawiki.org/wiki/Manual:$wgFooterIcons

HTML::element states:

			// There's no point in escaping quotes, >, etc. in the contents of
			// elements.

In this case, it is probably good to escape a ' and/or javascript: in the configuration-supplied variable.

It would be helpful if someone more familiar with the codebase could indicate if there is a more appropriate function than htmlspecialchars (with ENT_NOQUOTES/ENT_QUOTES) for this.

wes.turner wrote:

• In this case, it is probably good to escape a '"; and/or javascript: in the

configuration-supplied variable.

(In reply to comment #77)

This test fixture seems to indicate that a

'background-image: url(' . $wgFooterIcons['powererdby']['src'] . ')';

CSS attribute containing input from configuration on the filesystem may be
stripped:

https://git.wikimedia.org/blob/mediawiki%2Fcore/
6a2d25eed09c311c70657789b3f7a841bc5363db/
tests%2Fphpunit%2Fincludes%2FSanitizerTest.php#L253

Yes, all url() constructs will make checkCss consider the css unsafe. So you'll have to sanitize the background-image separate from the rest of the css.

HTML::element states:

// There's no point in escaping quotes, >, etc. in the contents

of

// elements.

In this case, it is probably good to escape a '"; and/or javascript: in the
configuration-supplied variable.

It would be helpful if someone more familiar with the codebase could indicate
if there is a more appropriate function than htmlspecialchars (with
ENT_NOQUOTES/ENT_QUOTES) for this.

Escaping of quotes ('") are already handled by Html::element, ignore htmlspecialchars completely here.

For sanitizing the URL is safe/not javascript: use preg_match( '/^(' . wfUrlProtocols() . ')[^\s]+$/', ... ) to test if the protocol is whitelisted.

It's a shame that Facebook, etc... probably don't take WAI-ARIA's presentation role into account.

Would be nice if we could just do:
<a href="//www.mediawiki.org/" aria-label="Powered by MediaWiki"><img role="presentation" src=".../common/images/poweredby_mediawiki_88x31.png" alt="Powered by MediaWiki" width="88" height="31" /></a>

wes.turner wrote:

(In reply to comment #79)

(In reply to comment #77)

This test fixture seems to indicate that a

'background-image: url(' . $wgFooterIcons['powererdby']['src'] . ')';

CSS attribute containing input from configuration on the filesystem may be
stripped:

https://git.wikimedia.org/blob/mediawiki%2Fcore/
6a2d25eed09c311c70657789b3f7a841bc5363db/
tests%2Fphpunit%2Fincludes%2FSanitizerTest.php#L253

Yes, all url() constructs will make checkCss consider the css unsafe. So
you'll
have to sanitize the background-image separate from the rest of the css.

HTML::element states:

// There's no point in escaping quotes, >, etc. in the contents

of

// elements.

In this case, it is probably good to escape a '"; and/or javascript: in the
configuration-supplied variable.

It would be helpful if someone more familiar with the codebase could indicate
if there is a more appropriate function than htmlspecialchars (with
ENT_NOQUOTES/ENT_QUOTES) for this.

Escaping of quotes ('") are already handled by Html::element, ignore
htmlspecialchars completely here.

For sanitizing the URL is safe/not javascript: use preg_match( '/^(' .
wfUrlProtocols() . ')[^\s]+$/', ... ) to test if the protocol is whitelisted.

It look like Sanitizer::safeEncodeAttribute [would] also reference wfUrlProtocols, though it seems to only escape double single quotes ("''", "&#39;&#39"), expecting the input to have already been run through encodeAttribute and htmlspecialchars with ENT_QUOTES.

The documentation for http://php.net/manual/en/function.htmlspecialchars.php reads:

• '"' (double quote) becomes '&quot;' when ENT_NOQUOTES is not set.
• "'" (single quote) becomes '&#039;' (or &apos;) only when ENT_QUOTES is set.

And:

ENT_QUOTES	Will convert both double and single quotes.

wes.turner wrote:

(In reply to comment #81)

(In reply to comment #79)

(In reply to comment #77)

This test fixture seems to indicate that a

'background-image: url(' . $wgFooterIcons['powererdby']['src'] . ')';

CSS attribute containing input from configuration on the filesystem may be
stripped:

https://git.wikimedia.org/blob/mediawiki%2Fcore/
6a2d25eed09c311c70657789b3f7a841bc5363db/
tests%2Fphpunit%2Fincludes%2FSanitizerTest.php#L253

Yes, all url() constructs will make checkCss consider the css unsafe. So
you'll
have to sanitize the background-image separate from the rest of the css.

HTML::element states:

// There's no point in escaping quotes, >, etc. in the contents

of

// elements.

In this case, it is probably good to escape a '"; and/or javascript: in the
configuration-supplied variable.

It would be helpful if someone more familiar with the codebase could indicate
if there is a more appropriate function than htmlspecialchars (with
ENT_NOQUOTES/ENT_QUOTES) for this.

Escaping of quotes ('") are already handled by Html::element, ignore
htmlspecialchars completely here.

For sanitizing the URL is safe/not javascript: use preg_match( '/^(' .
wfUrlProtocols() . ')[^\s]+$/', ... ) to test if the protocol is whitelisted.

It look like Sanitizer::safeEncodeAttribute [would] also reference
wfUrlProtocols, though it seems to only escape double single quotes ("''",
"&#39;&#39"), expecting the input to have already been run through
encodeAttribute and htmlspecialchars with ENT_QUOTES.

The documentation for http://php.net/manual/en/function.htmlspecialchars.php
reads:

• '"' (double quote) becomes '&quot;' when ENT_NOQUOTES is not set.
• "'" (single quote) becomes '&#039;' (or &apos;) only when ENT_QUOTES is

set.

And:

ENT_QUOTES    Will convert both double and single quotes.

Updated this patch for this issue. Please advise if there is a local function more suitable than Html::safeEncodeAttribute.

https://gerrit.wikimedia.org/r/#/c/108221/

Change 108221 had a related patch set uploaded by Jforrester:
Updated includes/Skin.php footer images #30113

https://gerrit.wikimedia.org/r/108221

My current header (MW 1.16)

<head>
<meta charset="utf-8" />
<meta property="og:site_name" content="My Wiki &minus; With Subtitle"/>
<meta property="og:type" content="Website"/>
<meta property="og:url" content="Article URL > same as link rel canonical"/>
<meta property="og:title" content="The Article Name"/>
<meta property="og:image" content="http://path.to/my/static/Logo.png (forced on every content-ns page)"/>
<meta property="og:image" content="/wiki/thumb.php?w=350&amp;f=Filename_of_article_image_1 (if given)" />
<meta property="og:image" content="/wiki/thumb.php?w=350&amp;f=Filename_of_article_image_2 (if given)" />
<meta property="og:description" content="Foo Bar" />
<meta name="description" content="Foo Bar" />
link rels
css
scripts
</head>

Thanks everyone for all the fast work to get this done, very excited to see it working.

Is this stalled again?

Any particular reason why this is stalled? It is very easy to implement as shown in comment https://phabricator.wikimedia.org/T32113#358539
Live example of a website where I implemented this technique with a simple set of meta properties in <head>: http://cmissync.com

Apparently, it's going to be fixed with T142243: [EPIC] Add open graph meta tags

Change 334789 had a related patch set uploaded (by Ladsgroup):
Add PageImage OpenGraph tag

https://gerrit.wikimedia.org/r/334789

@Ladsgroup for the preview to show up correctly on Twitter as well, we'll need to also add:

<meta name="twitter:card" content="summary_large_image">

to show we've opted in.