For the last couple of weeks I've been intermetently pestering people about bug 527907 and my inability to generate Firefox's All systems & languages page in my local copy of Bedrock. It seems to be still generated with the old PHP scripts, but I cannot find which particular ones and how to run them. The only ones I have located (with other people's help) are the details ones, used to generate the tables and download buttons (and the ones I will update for the bug), which are in http://svn.mozilla.org/libs/product-details/
Could someone indicate me how to generate the whole page? And will it be enough to place the new all.html in the corresponding bedrock apps folder for it to run properly?
If there is documentation on that process somewhere, pointing me there would placate my lust for a while =)
Thanks,
Enrique J. Gil
P.S.: Are there plans to move that page to bedrock in the near future? Maybe my efforts would be put to better use in the new version, if the old processes are to be deprecated in a matter of weeks.
> From: trasuntopendie...@hotmail.com
> To: dev-web...@lists.mozilla.org
> Date: Wed, 7 Nov 2012 00:35:17 +0100
> Subject: [webdev] Generation of all.html
> Hello.
> For the last couple of weeks I've been intermetently pestering people about bug 527907 and my inability to generate Firefox's All systems & languages page in my local copy of Bedrock. It seems to be still generated with the old PHP scripts, but I cannot find which particular ones and how to run them. The only ones I have located (with other people's help) are the details ones, used to generate the tables and download buttons (and the ones I will update for the bug), which are in http://svn.mozilla.org/libs/product-details/
> Could someone indicate me how to generate the whole page? And will it be enough to place the new all.html in the corresponding bedrock apps folder for it to run properly?
> If there is documentation on that process somewhere, pointing me there would placate my lust for a while =)
> Thanks,
> Enrique J. Gil
> P.S.: Are there plans to move that page to bedrock in the near future? Maybe my efforts would be put to better use in the new version, if the old processes are to be deprecated in a matter of weeks.
I was just talking with sgarrity in #www about this today. There apparently
is a bug to move this page to bedrock along with a new design. I don't have
the bug number, but work has started I believe. I'll find the bug tomorrow
and set 527907 to depend on it. I don't think that putting the work into
the php page would be the best use of your time since it is being ported
now. But if those builds don't make it into the initial release of the
bedrock page then adding it there definitely would be. I'm pretty sure
however, that since we're catching this very early in the page porting
process we can get both of these bugs done simultaneously.
One thought about this… I am not sure if this specific page qualifies but…
If we have content that is tightly coupled to the product but does not have anything do with the marketing site I would suggest having these live separately.
For example something like firefox.mozilla.org.
Right now in legacy SVN we have a mix of marketing content and items our products like firefox require. I would like to avoid repeating this in bedrock.
---------------------------
Benjamin Sternthal
bsternt...@mozilla.com
Web Product Engineer
Mozilla
skype: booboobenny
(m) 503.702.0963
On Nov 6, 2012, at 5:20 PM, Paul McLanahan <p...@mozilla.com> wrote:
> I was just talking with sgarrity in #www about this today. There apparently
> is a bug to move this page to bedrock along with a new design. I don't have
> the bug number, but work has started I believe. I'll find the bug tomorrow
> and set 527907 to depend on it. I don't think that putting the work into
> the php page would be the best use of your time since it is being ported
> now. But if those builds don't make it into the initial release of the
> bedrock page then adding it there definitely would be. I'm pretty sure
> however, that since we're catching this very early in the page porting
> process we can get both of these bugs done simultaneously.
> Thanks!
> Paul McLanahan
> Mozilla Webdev
> --pmac
> _______________________________________________
> dev-webdev mailing list
> dev-web...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webdev
I see no problem with marketing and product content living in bedrock
together. The PHP site was much more loosely organized, so I can see why
there'd be pain. But with bedrock and Django we can keep things fairly
nicely separated within their own apps, or even split them into separate
repos and pull them in with git submodules. With all this I don't think
it's as useful or important to keep things like this on separate servers or
domains. If we just want these things more visually separated then that's
another thing, but technically I think we're fine.
I'll join the efforts to fix bug #808762 and collaborate in getting the 64bit builds into the page, sooner better than later, so all effort is focused on the bedrock pages.
> From: p...@mozilla.com
> Date: Wed, 7 Nov 2012 09:04:57 -0500
> To: bsternt...@mozilla.com
> CC: dev-web...@lists.mozilla.org; dev-mozilla-...@lists.mozilla.org
> Subject: Re: [webdev] Generation of all.html
> I see no problem with marketing and product content living in bedrock
> together. The PHP site was much more loosely organized, so I can see why
> there'd be pain. But with bedrock and Django we can keep things fairly
> nicely separated within their own apps, or even split them into separate
> repos and pull them in with git submodules. With all this I don't think
> it's as useful or important to keep things like this on separate servers or
> domains. If we just want these things more visually separated then that's
> another thing, but technically I think we're fine.
On Wed, Nov 7, 2012 at 7:27 PM, <trasuntopendie...@hotmail.com> wrote:
> I'll join the efforts to fix bug #808762 and collaborate in getting the 64bit builds into the page, sooner better than later, so all effort is focused on the bedrock pages.
