Name: programmes-frontend
Owner: BBC
Description: The new frontend for bbc.co.uk/programmes
Created: 2017-03-17 10:19:20.0
Updated: 2018-05-24 15:49:05.0
Pushed: 2018-05-24 15:49:15.0
Size: 3210
Language: PHP
GitHub Committers
User | Most Recent Commit | # Commits |
---|
Other Committers
User | Most Recent Commit | # Commits |
---|
/programmes version 3. Finally.
Using Yarn allows the dependencies to be properly locked, and can abstract away the need to install other packages globally. Install Yarn first.
Then perform yarn install
To perform the development tasks
yarn run gulp
To perform the dist tasks (for ci)
yarn run gulp-ci
To watch for file changes
yarn run watch
The problem: If you run composer install then will be executed a group of
console commands. One of these is bin/console cache:clear
. This command try
to connect to Redis server in localhost, so composer consider that redis
server is in the environment in which is executed, but is only inside the
VM, giving errors. Neither Composer nor cache:clear
accept options to
handle this in a better way.
Replication: If you try to run the clear:cache
console command (with composer install
)
from outside de VM you will have you an error as we cannot connect to redis inside
the VM using composer from outside.
Solution: run composer install
inside the VM.
This is a two step process. You need to update both the programmes.pot template and the English translation file. Sorry, but that's the way GetText expects you to work.
Open translations/programmes/programmes.pot
and add your new
entry.
e English translation
d "my_shiny_new_entry"
tr ""
The comment should contain the full english translation and is needed as guidance for translators in other languages.
msgid can only contain the characters [A-Za-z0-9_:-]. This is a limitation of our translate-tool app and not the PO file format itself.
Entries in the template file should be in alphabetical order. This is so
that we can reduce the potential for merge noise, allowing us to focus on
specific changes rather than automatic re-ordering. You must either add your
entries in the correct order, or add them all at the bottom, then run
script/translate-alphabetiseAll.sh programmes
to move them into the correct
ordering.
After saving the template file, run
script/translate-updateFromTemplate.sh programmes
to add the new entries to
all translation files. Then edit the en.po file and add your english
translation.
e English translation
d "my_shiny_new_entry"
tr "The English translation"
Remove the entry from the programmes.pot template and run
script/translate-updateFromTemplate.sh programmes
There's a script that does most of this for you -
translate-updateLanguageFromSuppliedPO.sh
. For example, to update the Welsh
translation file (language code “cy”) from a new file supplied by a translator:
ript/translate-updateLanguageFromSuppliedPO.sh ~/Downloads/new-translations-cy_GB.po programmes cy
Once you've done that, you'll probably want to run a diff to check everything is OK and remove any superfluous headers added by the .po editor by hand. But the script should take care of any changes in ordering or new/wrong entries that may have been added by the translator's .po editor. It uses msgmerge from the command line internally.
There is a long-lived (hopefully) profiling branch named profiling-build which brings in tideways (basically xhprof updated for PHP7), a GUI and a few other things which you can run on Cosmos INT. It uses https://github.com/bbc/programmes-xhprof to setup the profiling. Got to that repository to see the available configuration options.
How to do this: Checkout the profiling-build branch, rebase it on master and deploy this branch to INT. This assumes that the code you want to profile is on master of course.
Visit https://programmes-frontend.int.api.bbc.co.uk/whatever/your/route/is?__profile=1 (Note the double underscore). Load that at least 5 times to make sure that everything that should be cached is cached. Now visit https://programmes-frontend.int.api.bbc.co.uk/xhprof/xhprof_html/index.php . You should see a list of your visits along with a load of metrics on execution.
The codebase has the ability to switch to a fixture database and a set of fixtured HTTP calls dynamically on the INT and TEST environments.
To load a scenario, simply visit the fixtured page with the query string __scenario=scenario-name in the URL
To view a page using the fixture database (but not fixtured HTTP calls) use the query string __scenario=browse
To create a scenario/fixtures there are a few steps. Firstly you will need to create a file named “fixture.ini” in the script folder on your cloud sandbox. Populate it with the following
WORD="the_password"
you can obtain the password from the usual place.
Now cd to the checkout out programmes frontend code and run `./script/fixture
`. The script can do 3 things,
documented in the help output. Generate a new scenario (the code will error if the scenario name already exits).
Regenerate an existing scenario (this basically uses all the existing HTTP fixtures, but creates new ones for any
unfixtured URLs). Or delete a scenario. Have fun!
If you're developing on the scenario and fixture mechanisms you should make sure all DB writes go to your local database. Make sure all fixture_database_* parameters are pointing at your local database.
The following parameters are especially important:
In order to create and populate the scenario datbase, run the following command (will update scenario_database_name, be careful)
bin/console doctrine:schema:update --em fixture --env dev_fixture
See Release Process
This repository is available under the terms of the Apache 2.0 license. View the LICENSE file file for more information.
Copyright (c) 2017 BBC