If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Status

Websites
plugins.mozilla.org
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: ibai, Assigned: espressive)

Tracking

Details

(Whiteboard: u=dev c=content p=3)

(Reporter)

Description

5 years ago
We need to update the Plugin Check site.

I'm adding this bug as a tracker.

More info: https://etherpad.mozilla.org/D0BDUL8l9e

Assigning it to Schalk based on Laura's request.
(Reporter)

Comment 1

5 years ago
We have the design and we should be able to move forward with the actual implementation. See https://bugzilla.mozilla.org/show_bug.cgi?id=796204 for PSD of the new design.

For the Firefox Download button:

- Show the Firefox Download button only when the browser is outdated or the site is access with a different browser (Chrome, IE, Opera, etc). At the moment it shows us for everyone and is distracting.
(Assignee)

Comment 2

5 years ago
Awesome stuff! Will take a look and get started.
(Assignee)

Comment 3

5 years ago
One quick question I have is whether this should be integrated into bedrock or whether this is a standalone 'wpp/site'? If standalone, are we simply going to do this from scratch using Playdoh or is there a code base that will be used as the basis?

Updated

5 years ago
Flags: needinfo?(igarcia)
(Reporter)

Comment 4

5 years ago
Good point.

This has more to do with the browser than with www.mozilla.org so I think it's a better idea to create it as a separate entity.

I'm wondering if we know where the code of the actual site lives. (www.mozilla.org/en-US/plugincheck/) We should inherit the majority of the logic of that site.

I know that Kev wanted some additional changes to the back-end, so him or Tomcat can have more requirements.
Flags: needinfo?(igarcia)
(Assignee)

Comment 5

5 years ago
From what I know it lives in AMO, but needs to be moved out. So a new playdoh site would make a lot of sense unless it needs to remain PHP for some reason.
(Reporter)

Comment 6

5 years ago
AFAIK there's no reason not to migrate to Playdoh. At least from my side I have no interest to keep it on PHP.
(Assignee)

Comment 7

5 years ago
:ibai

I found the current code base for plugin check:
http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/en-US/plugincheck/

There is in face no back-end and everything is client side so, we do not even have to go the playdoh route. I am gonna start a new repo for the plugincheck site and get cracking.
(Assignee)

Comment 8

5 years ago
Ok, repo created: https://github.com/ossreleasefeed/plugincheck
(Assignee)

Comment 9

5 years ago
Even though I created a repo, I think the best home for the plugin check page will be inside Bedrock as a separate app. Thoughts?
(Reporter)

Comment 10

5 years ago
I honestly have no preference. I see that it will be more organized that way. Who owns Bedrock?

Comment 11

5 years ago
(In reply to :ibai from comment #10)
> I honestly have no preference. I see that it will be more organized that
> way. Who owns Bedrock?

Talk to Chris More...he can help.
(Assignee)

Comment 12

5 years ago
The code for the new plugincheck is 90% complete and a request for a dev server has been logged. The app is now a standalone Playdoh app and uses an updated version of Perfidies of the Web to build the plugincheck.js and plugincheck-badge.js files.
I don't see any reason this shouldn't be in bedrock. Seems like a waste to setup new infra for a static page or two. This is bedrock's wheelhouse.
After looking at the mockups on the design bug it's clear that this should absolutely be in bedrock. We have helpers for the download buttons, and the newsletter signup at the bottom and overall blue sandstone design come for free.
(Assignee)

Comment 15

5 years ago
I have moved this into Bedrock.
(Assignee)

Comment 16

5 years ago
(In reply to :ibai from comment #1)
> We have the design and we should be able to move forward with the actual
> implementation. See https://bugzilla.mozilla.org/show_bug.cgi?id=796204 for
> PSD of the new design.
> 
> For the Firefox Download button:
> 
> - Show the Firefox Download button only when the browser is outdated or the
> site is access with a different browser (Chrome, IE, Opera, etc). At the
> moment it shows us for everyone and is distracting.

How do we know it is the latest version of Firefox? Is there a property on navigator object one can check or perhaps navigator.buildID?
(In reply to Schalk Neethling [:espressive] from comment #16)
> How do we know it is the latest version of Firefox? Is there a property on
> navigator object one can check or perhaps navigator.buildID?

We do something similar on /firefox/whatsnew/. Up-to-date Fx sees the page, other Fx versions are redirected to the update page, and other browsers go to a new download page.

https://github.com/mozilla/bedrock/blob/master/apps/firefox/views.py#L70

So I'd detect this in the view and set a context var to show the button or not.
(Assignee)

Comment 18

5 years ago
Created tracking bug tracking all current bugs against plugincheck: https://bugzilla.mozilla.org/show_bug.cgi?id=821279

Updated

5 years ago
Whiteboard: u=dev c=content p=3

Updated

5 years ago
Component: Pages & Content → plugins.mozilla.org
Product: www.mozilla.org → Websites
QA Contact: cbook
Why was this moved to the Websites product? Unless something has changed this page is going on www.mozilla.org.

Comment 20

5 years ago
Kohei: Why did you move this from www.mozilla.org to Websites? This page is being part of Bedrock.

Comment 21

5 years ago
Just curious - when will this new design be live?
(Assignee)

Comment 22

5 years ago
I am aiming for early next week unless there are any major issues.
(Assignee)

Comment 23

5 years ago
BTW, so far it is going as planned

Comment 24

5 years ago
What is the ETA on this page going live?

Comment 25

5 years ago
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/d3b6e76b4ae9db01280d4efd7b8e60b436abc9c0
Fix bug 797192: Redesign and port plugincheck.

https://github.com/mozilla/bedrock/commit/e6c6bb066562396a55e6d6c571405c105edda45b
Bug 797192: Add apache passthrough for plugincheck.

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 26

5 years ago
Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/06b40a7df3701644ff08f59ab48f4e446050225c
Bug 797192: Revert apache passthrough for plugincheck.

This reverts commit e6c6bb066562396a55e6d6c571405c105edda45b.
Last-second decided to postpone until we can roll all locales at once (hence the roll back in comment #26). Please reopen when ready.
Resolution: FIXED → INCOMPLETE

Comment 28

5 years ago
Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/ecfa90aa6e258a7772069043debbc1f38d06d563
Bug 797192: Add apache passthrough for plugincheck.

en-US only so far.

Comment 29

5 years ago
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/f93fa80ec6e02ca4ba7cc1df01af6845d3cbc390
Bug 797192 - some CSS fixes for plugincheck page

Adjusted column widths and margins.
Improved responsiveness.

https://github.com/mozilla/bedrock/commit/5d5b7e6c62e9f97e62ce76a0b1c78e0702ad5b80
Merge pull request #770 from craigcook/master

 Bug 797192 - some CSS fixes for plugincheck page
fixed for en-US on stage. https://www.allizom.org/en-US/plugincheck/ for push on 04/11/2013

Updated

5 years ago
Depends on: 707493

Comment 31

5 years ago
I'm monitoring the traffic to this page on GA and it is looking stable. I will report in another week if the load time from the end user's perspective is higher or lower.

Comment 32

5 years ago
Did anyone consider dropping the bottom section about the banners and just sending users over to affiliates.mozilla.org where they can sign up for a plugin checker banner, get the code, track clicks, and more? It would also make the page lighter and smaller, which is helpful on a page like this.
(In reply to Chris More [:cmore] from comment #32)
I think :mkelly did mention this at one point, not sure if it was an official suggestion. I like it though. +1
(In reply to Paul McLanahan [:pmac] from comment #33)
> (In reply to Chris More [:cmore] from comment #32)
> I think :mkelly did mention this at one point, not sure if it was an
> official suggestion. I like it though. +1

yeah good point, will file a bug for this
(Assignee)

Comment 35

5 years ago
(In reply to Chris More [:cmore] from comment #31)
> I'm monitoring the traffic to this page on GA and it is looking stable. I
> will report in another week if the load time from the end user's perspective
> is higher or lower.

Thanks Chris! Interested to hear the results of this.
(Assignee)

Comment 36

5 years ago
(In reply to Chris More [:cmore] from comment #32)
> Did anyone consider dropping the bottom section about the banners and just
> sending users over to affiliates.mozilla.org where they can sign up for a
> plugin checker banner, get the code, track clicks, and more? It would also
> make the page lighter and smaller, which is helpful on a page like this.

If affiliates.mozilla.org does carry the badges for plugincheck, then I totally +1 removing it. It would be one of the easiest and quickest performance wins ever ;)

Updated

5 years ago
Depends on: 865590
(In reply to Schalk Neethling [:espressive] from comment #36)
> If affiliates.mozilla.org does carry the badges for plugincheck, then I
> totally +1 removing it. It would be one of the easiest and quickest
> performance wins ever ;)

filed bug 865590 to track this

Comment 38

5 years ago
+1 to move affiliates.

Updated

5 years ago
Depends on: 866046
ok reopen 

we will push (in coordination with pascal) de, sv-SE, eu, it to the new page
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

Updated

4 years ago
Depends on: 892470

Updated

4 years ago
Depends on: 892807
(Assignee)

Updated

3 years ago
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.