Last modified: 2014-02-19 00:49:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T59939, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 57939 - WikimediaShopLink should insert the shop link in PHP, not JavaScript
WikimediaShopLink should insert the shop link in PHP, not JavaScript
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Other (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Ori Livneh
: javascript, performance
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-03 19:22 UTC by Ori Livneh
Modified: 2014-02-19 00:49 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ori Livneh 2013-12-03 19:22:19 UTC
Visual elements that appear out-of-sequence prolong the interval of time that users perceive as latency. It's also very distracting to have things blink in and out of existence when you've already started reading the article.

Let's add the shop link via PHP, instead. This could be done by removing the JavaScript module and replacing it with the following hook handler:

	$wgHooks['SkinBuildSidebar'][] = function ( $skin, &$sidebar ) {
		global $wgWikimediaShopLinkTarget, $wgWikimediaShopEnableLink;

		if ( !$wgWikimediaShopEnableLink ) {
			return;
		}

		$sidebar['navigation'][] = array(
			'text'  => $skin->msg( 'wikimediashoplink-linktext' ),
			'href'  => $wgWikimediaShopLinkTarget,
			'title' => $skin->msg( 'wikimediashoplink-link-tooltip' ),
			'id'    => 'n-shoplink',
		);
	};


The only thing missing from this implementation is the use of GeoIP information to control the display of the link, but using GeoIP on every page load is problematic for a host of reasons anyway. In my opinion, we could live without it; it doesn't seem like the end of the world if the shop says "Sorry! the Wikimedia Shop is not available in your country", and tracking such visits might help us identify countries to which service could be profitable expanded.
Comment 1 Gerrit Notification Bot 2013-12-03 19:35:21 UTC
Change 98885 had a related patch set uploaded by Ori.livneh:
Unconditionally insert shop link via PHP

https://gerrit.wikimedia.org/r/98885
Comment 2 James Alexander 2013-12-03 19:39:16 UTC
The GeoIP script is loaded on every page load anyway (and is not likely to change because of CentralNotice and other targeted extensions. The only reason I have it checking in this extension is in case someone installed it on a non WM wiki.

That said I'm not horribly against this as long as fundraising (copied in now) is ok with it and with the added load from international. The store itself is available for other countries (and so people would not get an unavailable message) but is less reliable (much more expensive shipping, which we sometimes subsidize etc) there.

That said, while I highly prefer a PHP insert over a js insert in general I don't agree that this is currently a huge issue. On English Wikipedia (and on most other languages where this extension would be activated in anywhere close to the near future) there is quite a bit of other javascript insertions in the interface (both the sidebar and up top) which are significantly more obvious then the shop link.
Comment 3 Ori Livneh 2013-12-03 19:45:34 UTC
(In reply to comment #2)
> On English Wikipedia (and on most other languages where this extension would
> be activated in anywhere close to the near future) there is quite a bit of
> other javascript insertions in the interface (both the sidebar and up top)
> which are significantly more obvious then the shop link.

Fully agree; I didn't intend to single out the shop link. One at a time, though. :)

Thanks for the reply, James -- let's wait to hear from FR.
Comment 4 Caitlin Cogdill 2013-12-10 00:34:09 UTC
Hi Ori — thanks for bringing this up. For the time being, I believe the GeoIP is in the best interest of the shop and potentially international customers. We are working out ways to make international shipping more affordable and reliable, but until we do so, we think it's best to keep the shop's scope relatively limited.

This is related to other bugs I've looked into recently such as bug #37797. If we are going to be exposing the shop on a global level, we'll want to be able to support multiple languages, currencies, *and* have a shipping option that is sustainable. Our goal is to perfect the shop in English, then expand our reach.

We are looking into global shipping as the first step in this process, but the earliest we will move on this will be mid-2014.

I'm sorry I can't give much more detail at the moment, but please feel free to ask questions if there is anything I can clarify.

(In reply to comment #0)
> Visual elements that appear out-of-sequence prolong the interval of time that
> users perceive as latency. It's also very distracting to have things blink in
> and out of existence when you've already started reading the article.
> 
> Let's add the shop link via PHP, instead. This could be done by removing the
> JavaScript module and replacing it with the following hook handler:
> 
>     $wgHooks['SkinBuildSidebar'][] = function ( $skin, &$sidebar ) {
>         global $wgWikimediaShopLinkTarget, $wgWikimediaShopEnableLink;
> 
>         if ( !$wgWikimediaShopEnableLink ) {
>             return;
>         }
> 
>         $sidebar['navigation'][] = array(
>             'text'  => $skin->msg( 'wikimediashoplink-linktext' ),
>             'href'  => $wgWikimediaShopLinkTarget,
>             'title' => $skin->msg( 'wikimediashoplink-link-tooltip' ),
>             'id'    => 'n-shoplink',
>         );
>     };
> 
> 
> The only thing missing from this implementation is the use of GeoIP
> information
> to control the display of the link, but using GeoIP on every page load is
> problematic for a host of reasons anyway. In my opinion, we could live
> without
> it; it doesn't seem like the end of the world if the shop says "Sorry! the
> Wikimedia Shop is not available in your country", and tracking such visits
> might help us identify countries to which service could be profitable
> expanded.
Comment 5 Faidon Liambotis 2013-12-11 22:20:42 UTC
GeoIP being used in other extensions already doesn't say much about whether it /should/ be used for this purpose, as the same could be argued for any of its other uses :) In fact, the current usage of the GeoIP lookups in general is problematic for other reasons already and we have plans of changing it in the future (see #57126, as filled by Ori).

If the shop has restrictions on where from it can be used, then this certainly shouldn't affect each and every page load on every project of ours. Having every Wikipedia reader's browser compute in Javascript whether the shop link should be displayed or not (and modify the DOM for a large percentage of our user base) sounds, frankly, crazy to me. Unless you have evidence to support that a significant percentage of readers shop from the site *and* you have a lot of false positives of users entering the site and saying "bummer, this is expensive", merging this sounds extremely obvious to me. 

Having a link is fine, but the extra computation because of application logic is not. If you think this functionality is useful for the shop, then this logic should be pushed into the shop site itself; the extra pointless click will only affect a tiny minority of users who I'm sure wouldn't mind seeing the "sorry it's so expensive to your place" notice that much.

On a more general note, the site currently is full of "small harmless snippets" like that that overall make the performance horrendous; it's essentially death by a thousand cuts, and we finally have someone who's actually going around and providing patches to fix all of these cuts, so I'm inclined to just let them make those calls :-)
Comment 6 Gerrit Notification Bot 2014-01-26 20:44:21 UTC
Change 98885 merged by jenkins-bot:
Unconditionally insert shop link via PHP

https://gerrit.wikimedia.org/r/98885
Comment 7 Nemo 2014-01-26 20:48:19 UTC
\o/
Comment 9 Ori Livneh 2014-01-27 08:59:25 UTC
(In reply to comment #4)
> Hi Ori — thanks for bringing this up. For the time being, I believe the GeoIP
> is in the best interest of the shop and potentially international customers.
> We are working out ways to make international shipping more affordable and
> reliable, but until we do so, we think it's best to keep the shop's scope
> relatively limited.

The shop link is still enabled exclusively on the English Wikipedia, so it is still fairly targeted, inasmuch as Americans and Canadians make up a substantial portion of its traffic. If it is actively harmful to display the shop link to English Wikipedia users in other countries, we can remove the link altogether, but we can't continue injecting it late into the page based on GeoIP data, because it degrades the user experience of substantially more users than the number that ever make it to the shop.
Comment 10 Nemo 2014-01-27 09:13:45 UTC
(In reply to comment #9)
> The shop link is still enabled exclusively on the English Wikipedia, so it is
> still fairly targeted, inasmuch as Americans and Canadians make up a
> substantial portion of its traffic.

Namely, about 46 %: <http://stats.wikimedia.org/wikimedia/squids/SquidReportPageViewsPerLanguageBreakdown.htm>.
Rather than the 54 % of unreachable users, I'd care about the sidebar real estate "stolen" to the 99.9999 % users (estimate based on comscore stats and number of shipped items) who don't use the shop. Is the PHP link shown to unregistered users too? If yes I'll file a bug, seems the next obvious step.
Comment 11 James Alexander 2014-01-27 09:32:17 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > The shop link is still enabled exclusively on the English Wikipedia, so it is
> > still fairly targeted, inasmuch as Americans and Canadians make up a
> > substantial portion of its traffic.
> 
> Namely, about 46 %:
> <http://stats.wikimedia.org/wikimedia/squids/
> SquidReportPageViewsPerLanguageBreakdown.htm>.
> Rather than the 54 % of unreachable users, I'd care about the sidebar real
> estate "stolen" to the 99.9999 % users (estimate based on comscore stats and
> number of shipped items) who don't use the shop. Is the PHP link shown to
> unregistered users too? If yes I'll file a bug, seems the next obvious step.


Yes, it is, they were always the main target of the link in fact. I think it is completely reasonable there and is a relatively unobtrusive way for people to find it (especially since there is no other real public link to the shop). 

In the end it would be up to the Caitlin and the fundraising team since it isn't my role anymore but personally I'd say if you were going to remove it for anonymous users I'd just remove it completely. However if that is a goal I think it would be something that should get consensus on wiki, rather then bugzilla.
Comment 12 MZMcBride 2014-01-27 09:35:44 UTC
(In reply to comment #11)
> In the end it would be up to the Caitlin and the fundraising team since it
> isn't my role anymore but personally I'd say if you were going to remove it
> for anonymous users I'd just remove it completely. However if that is a goal I
> think it would be something that should get consensus on wiki, rather then
> bugzilla.

Was there (on-wiki) consensus to add the link to the sidebar?
Comment 13 Nemo 2014-01-27 09:36:00 UTC
(In reply to comment #11)
> Yes, it is, they were always the main target of the link in fact.

Ah, ok. I had understood the opposite, that editors were the main target of the shop. My bad. I agree on-wiki discussion first would be best then.
Comment 14 James Alexander 2014-01-27 09:44:37 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > In the end it would be up to the Caitlin and the fundraising team since it
> > isn't my role anymore but personally I'd say if you were going to remove it
> > for anonymous users I'd just remove it completely. However if that is a goal I
> > think it would be something that should get consensus on wiki, rather then
> > bugzilla.
> 
> Was there (on-wiki) consensus to add the link to the sidebar?

There was not, I did it on my own after speaking with others (both volunteer and staff) and agreeing with the unanimous (unscientific) consensus that it was more of a fundraising type link that was reasonable to put up on my own. For some reason my memory says one of them may have been you... but I don't have my logs from back then (new computer type) and I am in no way positive so I can't be positive on that :).
Comment 15 MZMcBride 2014-01-27 09:50:09 UTC
(In reply to comment #14)
>> Was there (on-wiki) consensus to add the link to the sidebar?
> 
> There was not, I did it on my own after speaking with others (both volunteer
> and staff) and agreeing with the unanimous (unscientific) consensus that it
> was more of a fundraising type link that was reasonable to put up on my own.

The same unscientific consensus may be able to guide us going forward as well. :-)

It's not uncommon for sites to put a "shop" link in the footer. We could consider moving the shop link in a separate bug report.
Comment 16 MZMcBride 2014-01-27 09:53:30 UTC
(In reply to comment #15)
> It's not uncommon for sites to put a "shop" link in the footer. We could
> consider moving the shop link in a separate bug report.

Filed as bug 60466, if anyone's interested.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links