Closed Bug 507143 Opened 15 years ago Closed 15 years ago

set up a staging site for svn.mozilla.org/projects/one-billion/trunk/

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: pascalc, Assigned: dmoore)

References

Details

We need a staging website to be set up to show the content on svn.mozilla.org/projects/one-billion/trunk/ and a cron job updating from svn every 20mn.

Thanks
Bug 506062, comment #2 makes it seem like a staging site isn't necessary?
Assignee: nobody → server-ops
Component: Server Operations: Projects → Server Operations
it's necessary for QA of  l10n pages
Assignee: server-ops → dmoore
Can we get an ETA for when the staging server up?
We may need to push the en-US version of this site live tomorrow so I'm going to make this critical. Having this setup will allow for QA and will allow us to be ready to push to production right away.

The decision to push this campaign site live tomorrow or not will be made early on Friday so we need to have this staging site ready ASAP. Thanks!
Severity: major → critical
This bug is effectively blocking all of my teams work on this project, no staging site, no localization. Setting as blocker.
Severity: critical → blocker
What is the status on this?

This is blocking us from launching the en-US version of the site today.
Staging site is now live at http://onebillion.stage.mozilla.com/
Dave, Ryan and Jeff -- could you guys take 15-30 minutes today to review this code?  Want to make sure it's not doing anything risky or exposing itself to XSS.  Thanks.
Derek, has a cron job been setup to update from svn every 20 mins? This was mentioned in the first comment.

We need to have this cron job running so that we can tweak the site before going live. Thanks!
Jeff took a look and didn't see any security issues.  Thanks Jeff.
Couldn't find any security holes (not that I'm adept at that), but I had some other complaints.  Overall, the site looks really good.

There's 5 CSS includes and 4 Javascript includes.  That's 9 HTTP requests, which means everything loads slower and fewer people look at the site.  Please concat those so we only have 2 requests for that stuff.  This page takes 2 seconds to load from localhost, presumably because there's so many resource requests.

Then there are 36 image requests.  A lot of those could be collapsed into a couple of sprites.

For the picture box, it would be nice to use -moz-box-shadow and -webkit-box-shadow for the drop shadows in browsers that support it (https://developer.mozilla.org/en/CSS/-moz-box-shadow).  That shows off features of modern browsers and saves 4 image requests.

http://onebillion.stage.mozilla.com/en/ should be a 404 (same with other locales?)

The page looks good without javascript, but the pictures in the middle don't line up with the text and the containing box doesn't expand to keep all the pictures in.

getHttpLocales should sort by the q= parameter, not a blocker

Locales::displayMenu could put the English defaults for $title and $submitTitle in the parameter list instead of the less-useful empty string

<hr class="hide"> is display:none.  Why have it at all?

../img/billion-header.png shouldn't move to the parent directory if everything if being served from onebillion.com/?lang=.. -- it's fine now since the site is served from root, but has the potential to break.  All the other images are served from ./img, the same level as the page.

# wonders.inc.php
All the divs with `class="wonders-feature-contents"` could be matched with a single CSS rule, `.pager-content > div`.  Those all have inline `style="display: block"` which is the default anyway, so it's a waste of space/bytes.  Same with `class="photo"` and `class="text-block"`

Every .wonders-feature-contents div has its id immediately switched with some javascript.  I'm not sure why you would do that.  If it's a CSS-only-for-js thing, putting a class="has-js" on the body is more efficient.
Jeff, thanks for making those comments. Our goal is to push this site live this afternoon so we are tight on time.

While I understand that your suggestions would improve the performance of the site, do any of your suggestions need to be implemented for the site to function properly? Thanks
The site is functional.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
The site is not updating from the SVN server, reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pascal,

The site last updated to r48920 automatically at 16:59. Is there an additional change which has not propagated?
Correction, r48290
r48291 was picked up at 17:20, assuming SVN update is functional
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
sorry, my bad, I looked at the wrong tab and was looking at silverorange's staging site
Jeff, thanks, I've taken a look at some of the code again myself and implemented some things you mentioned and also some stuff I noticed myself in order to optimized.

- moved the portal-page.css code into the one-billion.css file and removed the portal-page.css request and file
- inline `style="display: block"` removed from the wonder features div
- added css to the wonders slides to make the images and the text blocks line up

Simplifying CSS:
- removed the 'class="photo"' from the wonders photos, they were the only img tags in those divs anyhow
- removed the 'class="wonders-feature-contents"' from each of the wonders slides
- removed the 'class="text-block"' from the wonders slides
- removed the 'class="social-links"' from the bottom facts items

I've avoided the -moz-box-shadow property because we'd *like* this to also work in older/dumber browsers as well. The image requests should also be reduced by two.

Mike fixed the following:
- sort http locales by q-value
- mark current language as selected in locale switcher

Comments re Comment #11
- Locales::displayMenu() already defaults the text if an empty string is passed.
- the div id switching with JavaScript is required to make links to specific pages in the JavaScript pagination work correctly in all browsers.
(In reply to comment #19)
> Jeff, thanks, I've taken a look at some of the code again myself and
> implemented some things you mentioned and also some stuff I noticed myself in
> order to optimized.

Awesome, thank you!


> I've avoided the -moz-box-shadow property because we'd *like* this to also work
> in older/dumber browsers as well.

Yes, it's unfortunate we have to do that.  I'd like to find a way to use the right markup when possible, but it probably won't be worth it for long-term maintainability.


> the div id switching with JavaScript is required
> to make links to specific pages in the JavaScript pagination work correctly in
> all browsers.

Could you tell me more about this trick?  I haven't seen it before.
>> the div id switching with JavaScript is required
>> to make links to specific pages in the JavaScript pagination work correctly in
>> all browsers.

> Could you tell me more about this trick?  I haven't seen it before.

Sure. Currently you can link to http://one-billion-trunk.mozilla.silverorange.com/#feature-interaction and the 'Interaction' page (page 2) will be set by default.

Without div id switching, when you link to the page using an anchor, Firefox and other browsers will scroll down the page to the location of the #features-interaction div.

Ideally, the id renaming would take place in the initialization of the JS pager object, but by the time the JS object initializes, some browsers will already have scrolled the page.
Also note, if the ability to link to a specific page is not needed at all, it can be turned off fairly easily and the inline JS will no longer be required.
+1 for concatenating JS & CSS. This can easily be done manually. Considering this will be viewed around the world with varying internet connection speeds, this will benefit many people.

Other than that I don't see anything show-stopping.
Regarding Comment #23, I've managed to reduce the requested css files and put everything needed into the one-billion.css and YUI reset-fonts-grids.css

This reduces the size of the load of CSS from 26k to around 15k. A significant improvement. It should also reduce the number of requests. These changes are in trunk.
(In reply to comment #24)
> Regarding Comment #23, I've managed to reduce the requested css files and put
> everything needed into the one-billion.css and YUI reset-fonts-grids.css
> 
> This reduces the size of the load of CSS from 26k to around 15k. A significant
> improvement. It should also reduce the number of requests. These changes are in
> trunk.

Great, thanks again.  We're working on getting some server-side help for this in bug 508093; hopefully that will be ready soon.
http://onebillion.stage.mozilla.com up and running
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.