Monday, 22 January 2018

D8

drupalvm


Uruchamianie i zamykanie

make up
make stop

Docker

Import bazy:
1. Logowanie do mariadb przez portainer
2. Wrzucić dump z mariadb-init do mariadb-manual
3. Dump po zalogowaniu do containera powinien byc dostepny w /var/lib/mysql/dumps
4. Import bazy drupal/drupal/drupal (najpierw drop database, potem create, potem import, potem drush cr w php container).

Free up local storage


With each drupalvm instance setup (by set up I mean git clone of drupalvm and vagrant up) it's downloading new base box image. These images are kept in VirtualBox VM's folder in separated directories like:

packer-ubuntu-16.04-amd64_2232343245445_23344/packer-ubuntu-16.04-amd64-disk001.vmdk
packer-ubuntu-16.04-amd64_3343354343455_33224/packer-ubuntu-16.04-amd64-disk001.vmdk
packer-ubuntu-16.04-amd64_2323434243223_56566/packer-ubuntu-16.04-amd64-disk001.vmdk

etc.


The image that is downloaded is treated as base image to set up your environment based on your settings in yaml file. While vagrant up is running it copies this image into the separate folder with the name of your project eg. drupalvm.dev and installs all the required packages listed in yaml file. However when vagrant up is completed the base file stays in packer-ubuntu-16.04-amd64_2232343245445_23344 directory. And it's not used anymore because new one was generated for you based on this one. This file takes almost 2GB of data. And you can easily delete this file.


Directory structure (let's assume that VirtualBox VMs folder stores all the boxes):

Before any vagrant build it's empty:

/VirtualBox VMs
.
..

After gitclone and vagrant up (in completely separated directory, code of your site and drupalvm code from github has nothing to do with directories below). Assume your projects name is 'drupal':

/VirtualBox VMs
.
..
drupal/
packer-ubuntu-16.04-amd64_2232343245445_23344/

In this case you can delete this folder packer-ubuntu-16.04-amd64_2232343245445_23344/

IMPORTANT UPDATE
It seems like last setup I made has changed. I cloned drupalvm and run vagrant up. After the build base box image located in one of this: packer-ubuntu-16.04-amd64_2323434243223_56566/packer-ubuntu-16.04-amd64-disk001.vmdk is used to run the environment, so it looks like drupalvm no longer copies this file into your projects directory and makes changes on it. I don't really know how it works right now, but there are two possibilities:

1. It makes changes directly into packer-ubuntu-16.04-amd64_2323434243223_56566/packer-ubuntu-16.04-amd64-disk001.vmdk file so it reflects your yaml config.

2. It does not change packer-ubuntu-16.04-amd64_2323434243223_56566/packer-ubuntu-16.04-amd64-disk001.vmdk at all but all the dependencies are located in your project VM directory. This approach is rather not possible, it's really hard to imagine that it changed so much that dependencies are separated into another folder.


Hoteltreats

Sass

This command should be run in main theme directory from main system (not VM):
sass --watch scss/style.scss:css/style.css

Konfiguracja danej domeny/strony

Znajduje się w hoteltreats/private/hotel-x.hoteltreats.test.yml
Wszystkie zmienne znajdujące się w hotelstyles.settings są również opisane w themes/hotelstyles/config/schema/hotelstyles.schema.yml

Logowanie

drush uli

Zarzadzanie Treats

Structure -> Treats
Form: Property -> Le Meridian, published, english
Edit any node -> Micorsie Tab -> In collections field (eg. Best Experiences)

Nadpisywanie zmiennych

1. W pierwszej kolejności zmienne SASS deklarujemy w _default-variables.scss
2. Następnie wpisujemy tą zmienną w _css-vars.scss
3. Następnie używamy jej w plikach w /components jako mixin var (tutaj nie jest deklarowana zmienna, a wywolywana juz wczesniej zdeklarowana w :root)
4. Jesli ostatecznie chcemy nadpisac ta zmienna uzywamy jej w /private/microsites/something.yml

Thursday, 4 January 2018

NodeJS - BC

Auth0


Go to: https://publisher-film.beacon.britishcouncil.digital
Log in with credentials:
dawid.nawrot@britishcouncil.pl
dmj2=DGZVXAChRzh6sk*hkuXd8KHR=ecEZrT)7tVaijLEvHxbtu4pp=zGLwrFQYW

Enable 2 factor auth if needed.

After logging in go to console and get access_token by typing:
localStorage.access_token

in console. It should return access token.

Go to playground and add code to add a page and in http headers add authorization header like so:

{
"Authorization" :"Bearer access_token"
}

it should return an ID of a page.

You can also go to https://jwt.io/
and paste your access_token to get an idea what you can do in scope section and how long this access_token is valid.

Adding a page with test:seed and publishing with graphql playground

Once panda is running go to console and type:
lando yarn test:seed

This is going to create a full page for you bypassing authorization. A structure of a page can be viewed at panda/src/resolvers/__tests__/helpers/data.js (fullSamplePage constance).

Once the page is added, you can log in to mongo db and get pageId value. Copy pageId and go to playground to publish it.



Postgraphile:


Video

Starting the app. First you need to have yarn installed and node > 8.6. I use nvm, so to install another version of node i use:

nvm install 8.9

Check node version with:
nvm version node

With this we can go to /zoo/hedgehog and type yarn which will install project which will display:

dns-MacBook-Pro-2:hedgehog dn$ yarn start
yarn run v1.10.1
warning ../package.json: No license field
$ env NODE_ENV=production node src/index.js
> 🐻 is alive and kicking at:
>> http://localhost:5000/graphql (Apollo)
>> http://localhost:5000/db (PostGraphile)

Several things needs to be done to make this work now. The problem is that postgresql does not have any schema imported and no data. If you try to run yarn seed it will end up with error. So, we need to:

1. Log in to lando service where PostgresDB exists
lando ssh pg

2. Import schema to db
psql -f src/postgres/schema.sql -U hh hh

In result we should get:
CREATE TYPE
CREATE TYPE
CREATE TABLE
CREATE TABLE

3. Log in to db to verify if schema exists.
psql -d hh -U hh

Similar to show databases in MySQL is:
\dt

Which should result with List of relations
Schema | Name | Type | Owner
--------+----------+-------+-------
public | author | table | hh
public | metadata | table | hh
(2 rows)

To exit from db:
\q

4. Edit seed.js file to uncomment part which adds users and comment out part which adds metadata.
5. RUN yarn start
5. In another console tab run yarn seed to generate users.
6. Edit seed.js file to comment out users and uncomment metadata.
7. Run yarn seed again to generate metadata.
8. Go to ChromiQL and provide backend url to db (http://localhost:5000/db)
9. Check if schema is there.
10. Go to Apollo graphql endpoint and run example query or mutation.

Easy, right?

Apollo graphql endpoint usage:
Query and mutation:



Connecting to DB issue

Whenever you get an error about port allocated for database the issue is that you run wrong command or use wrong direcotory for command. Scenarios:

1. If you decide to run all the apps (Panda, Rhino, Puma) at the same time with lando start from /zoo direcotory you need to run commands from /zoo direcotory. For example:

lando panda test:watch
lando panda user:add --username='admin' --password='admin' --email='admin@example.com'

and so on.

2. If you have three apps at once, but you run only one at the time, eg.: lando start panda then commands should be quite different. First of all all the commands should be run from panda directory. For example:


lando yarn test:watch
lando yarn user:add --username='admin' --password='admin' --email='admin@example.com'

And that's it.

Working with panda on platform.sh

Login to ssh with platform.sh on desired branch
from /app directory we run:

yarn user:add --username='dawidnawrot' --password='dawidnawrot' --email='dawidnawrot@example.com'
yarn user:role --username='dawidnawrot' --role='admin'

voilla

Document describing project

Document

Updating libraries

If someone updates package.json file, so it has new dependencies (dev or standard) we need to get those to make project work. So, assuming we already have pulled changes with new dependencies we need to type:

lando panda add mongoid-js@1.1.3 --dev

This example shows how to add mongoid, which was added by someone else to package.json. I'm pretty sure it might be done better way, so we don't have to list dependency, there should be some update command.

Update: and there is: lando yarn upgrade (note it's upgrade, not update)


As far as the command itself:

lando - run lando
panda - use panda project
add - this is one of yarn commands, so if this was provided without lando we would type: yarn add mongoid-js@1.1.3 --dev but I assume lando is configured the way we don't have to use yarn command because it's a default one.
mongoid-js@1.1.3 - it's a package and version of it
--dev - it's the same as --save-dev in npm

Cheetsheet for yarn vs npm commands: https://github.com/areai51/yarn-cheatsheet

Running tests against panda


Assuming we're working in consolidated version of zoo:

1. We run tests from /zoo directory (not from panda)
2. In /zoo directory we can run:

lando panda test
lando panda test:watch

And so on. So all the scripts that are defined in panda/package.json are run from /zoo directory but with
lando panda
prefix.

In addition, because we use yarn, rather npm for running test commands we don't have to add
run
for non default scripts. So, if were using npm it should be something like this:

lando panda npm run test:watch

But, becasue we use yarn and it's already aliased, we run:
lando panda test:watch

As we run tests we need to have some users. Tests that run mostly defines some users (eg. a username or password or role). So, we need to generate those users or roles in order to pass tests. To add user or role we can use scripts developed by Simon. It's described down below, in next section.

And that's it.

Adding a page from scratch


1. Go to /zoo directory
2. We have to create a user if there's no users in DB:

lando panda user:add --username='admin' --password='admin' --email='admin@example.com'

It should give us a note in green: "User added".

3. We have to assign a role to this user. Available roles are: guest, contributor, editor, admin, superadmin. It's all from in db.acl_roles.find() collection.

To assign a user to specific role:

lando panda user:role --username='admin' --role='superuser'

It should give us a note in green: "Role added to admin".

4. Open up a ChromeiQL extension. Endpoint should be set up to: http://panda.lndo.site/graphql

5. Write a login mutation to login:

mutation login {
  login(username:"admin", password:"admin") {
    username
    id
  }
}

6. To check if we're logged in query DB:
query currentUser {
  currentUser {
    id,
    email,
    username
  }  
}

7. To add a page we need to use two window sections, first we provide a mutation and second we add query variables like so:

Mutation:
mutation addPage($input : PageInput) {
  addPage(input : $input)
  {
    id
  }
}

Query variables:
{
  "input": {
    "language": "pl", 
    "type": "whatever"
  }
}

By running this mutation with those variables we should end up with that kind of response:

{
  "data": {
    "addPage": {
      "id": "5b4734f38dbeba047107ee29"
    }
  }
}


Using scripts made with babel-node

Being in zoo direcotory (not panda) type:

lando panda user:add --username='admin' --password='admin' --email='admin@example.com'

General note

It's better to use chromeIQL extension rather than Playground Tool. The second one is buggy, it does not send a cookie, so there's no way to find out whether user is logged in or not.

Adding user:




Simplest query:




Current user:




Multiple queries

You can choose the one you want on play. Basically it just needs a name right after the query or mutuation:



Basic facts about node

  1. npm = bower (2013) = yarn (2017)
  2. to start new project we use npm init which generate package.json file
  3. npm init command will only generate package.json file, it's not checking anything (if the index.js file exists, or similar
  4. npm is using package.json file to keep project dependencies
  5. npm is a package manager, so you don't have to download each library, but declare it in package.json file
  6. Installing package: npm install package_name --save or npm install package_name --save-dev. This will do two things, first it'll modify package.json file. Second it'll download a package to node_modules folder.
  7. If you have node.js installed, you already have npm installed

  8. Node.js -> Webpack and require function

    Loading external files: php have its include() function. Javascript didn't have this feature until a new project CommonJS started in 2009. The output of this project is node.js which is server software and it does allow to do this. Previously all the files had to be loaded each by each in html. Today we can use something like that with nodejs. Instead of loading all of moment.min.js with an HTML script tag, you can load it directly in the JavaScript file as follows:



    This is how module loading works in node.js, which works great since node.js is a server side language with access to the computer’s file system. Node.js also knows the location of each npm module path, so instead of having to write require('./node_modules/moment/min/moment.min.js), you can simply write require('moment') — pretty sweet.

    Ok, but this won't work right now, as browser does not know what is require function. To make it work we need to have module bundler, which will make an output as one big file, for example bundle.js with all libraries in it. The bundler we need is a Webpack.

    Installing webpack:



    Running webpack:



    This is going to analyze index.js file, it'll find all the occurences of require and replace it with actuall js files and output it as a bundle.js file. It's all working fine, but with any change in index.js file we would have to run it over and over again. To automate this process we have to create webpack.config.js file in root directory of our project.



    This will allow us to regenrate everythis with simpler version:



    To make it work even easier we can run task runner that comes with npm. We can do it by modifying package.json file like so:



    Running npm run build will rebuild everything and will minimize our code for production because it uses -p option.
    Running npm run watch will rebuild everything on the fly with every change to index.js file.

    Let's go deeper and run a tool (webpack-server-dev) that will automatically refresh our site in browser with every change we make in index.js file.



    Now, we have to add another script / command to our package.json file to make it work:




Mongo CLI

  • To open mongo db cli just type: lando mongo in project directory
  • To login to main: lando mongo main -umain -pmain

  • Commands

    • db.getCollectionNames() - displays list of collections
    • db.[collectionName].find() - similar to select * from collectionName
    • db.contents.find().pretty()
    • db.users.find().pretty()
    • db.roles.find().pretty()
    • db.components.find(ObjectId("5b55bad212161c05e9fa5e2c")).pretty()
    • db.components.find({}, {}).pretty() - get IDs only

    • db.components.find({ col1: "A" }, { column, column, column }) - similar to: select col1, col2 from components where col1 = A














Lando

  • lando logs -t -f
  • lando start
  • lando stop
  • lando restart
  • lando rebuild

Useful links

Link to testing branch for PR (different then with drupal)

Quote from Vin: "when a PR is open, go to the PR, scroll down, open up "checks passed", next to platformsh, details link".

Thursday, 8 June 2017

English phrases

  • gaslighted - eg. He was gaslighted - czyli ktoś nim manipulował, np. przedstawiał wersję nieprawdziwą i wmawiał, że tak było. To jest termin psychologiczny.
  • framing someone for something - wrabiać kogoś w coś (przerzucić winę na kogoś w sprawie jakiegoś przestępstwa)

decay

rozkład

kingpins

 - szpilki (mozna tak powiedziec o kims waznym, o kims w srodku). He is a kingpin of art.

strive

starac się, walczyć
The blood bank must continuously strive to maintain supply as 1.2 million people across the country have never given blood.

loo

toilet

Either that or...

albo to (cokolwiek), albo..

climb down out of my ass

zejdz ze mnie

turf

terytorium w kontekscie twojego ogrodka, dzialki, domu, stanowiska pracy czegos nad czym masz kontrolę.
Np.: You better watch your turf. - Lepiej pilnuj swojego terytorium.

sufficiently

dostatecznie, wystarczająco dobrze

sufficient

wystarczający

scribble

bazgrać

engage

angazowac się
np.: They attempted to engage Anthony in conversation. - Postarali się aby zaangazowac Anthonego w dyskusję.

attempt

probowac, usilowac, postarac sie
They made no attempt to escape. (Oni nie podjęli próby ucieczki.)
Soon he gave up the attempt. (Wkrótce on porzucił próbę.)
The reason for his imprisonment was his attempt to rape somebody. (Powodem jego uwięzienia była jego usiłowanie zgwałcenia kogoś.) 

slapping

policzkowac

tiara

korona

baffling

zaskakujący

peeps

people

firecracker 

petarda

labor

praca (głównie umysłowa)

on the lark

dla zabawy
np. I bought this old car on the lark. Kupiłem ten samochod dla zabawy (zeby go wykonczyc).

slit my wrists

poderżnąć sobie żyły

profitable

opłacalny, np. this mortage is more profitable the the other one.

distracted

rozkojarzony

remedy

złoty środek, np. It's a remedy for your problem. To jest złoty środek na twój problem. Generalnie chodzi o rzeczownik w sensie jakiegoś radzenia sobie z problemem.

elephantine (wym. elefantajn)

duży, ogromny

amend

modyfikować, poprawiać, zmieniać,
np. This is the slightly amended text of an address he gave.
To jest trochę zmieniony adres, który Ci dał.

assumption

założenie, hipoteza

vigilant

czujny

restrain

ograniczac, hamowac,

intimidate

zastraszac

tentative

wstępny, np. tentative date

sanitize

czysty, make clean and hygenic, sterilize

refine

oczyscic, uszlachetnic

ballpark

przybliżony zakres, przyblizony czas, przyblizony koszt

elusive

nieuchwytny

inconvenience

niedogodnosc

Thursday, 2 March 2017

BC

Crediting author of a patch

1. Clone repo
2. By default it should be on dev branch, mostly 8.x-1.x
3. Download a patch locally and apply it by git apply -v filename.patch
4. Delete filename.patch
5. git add .
6. Copy commit message from issue where patch exists. In the bottom of the page there should be Credit and commiting section where full commit message should be available. Like so, git commit -m 'Issue #3117195 by joy29: Filter unnecessary code' --author="rudranil29s "
This way you will add a message with an author flag.
7. Push the changes.
8. Create new tag and push it to drupal repo.
9. Create a new release on drupal.org
10. Voilla.

Creating a new release of contrib module (example for svg_icon_field)

Clone module locally, with https://www.drupal.org/project/svg_icon_field/git-instructions instructions AND SET YOUR GIT USER, SO IT'S GOING TO SHOW YOUR COMMIT IN DRUPAL.
Like so: git clone --branch 8.x-1.x git@git.drupal.org:project/svg_icon_field.git
Next checkout to branch 8.x-1.x (this branch should be used by default). Next provide your changes on this branch or create a new branch and provide changes there. If the changes are not yours, someone has added a patch you have to download a patch to module's dir, next apply the patch with git apply -v [patchname.patch] and make a commit with relevant message so you credit an author there - like so: git commit -m "Issue #555555 by drupal_username: Description of a change". You can find more info here (Applying a patch section) and here. There's no much of a difference whether you commit your changes to 8.x-1.x branch or new one because right after commit this changes should be pushed to 8.x-1.x - not the branch you created locally. When changes are commited and pushed to 8.x-1.x you need to create a tag with:
git tag 8.x-1.0-alpha6

next git tag to check if it was created, you should be promped with:
8.x-1.0-alpha1
8.x-1.0-alpha2
8.x-1.0-alpha3
8.x-1.0-alpha4
8.x-1.0-alpha5
8.x-1.0-alpha6

next push the tag to origin:

git push origin tag 8.x-1.0-alpha6

new tag is going to mark last commit. Since last commit was the one provided a step before new release is going to contain this change. So all you have to do now is to go to "Add new release" on module page and select a tag you want to release. Select alpha-6 and release it. Now the module should contain the change you've provided. To see the effect on drupal page you have to wait like 5 minutes, then the new version / release of module is going to be presented.

What's the most important is the order. You have to provide, commit and push the changes first and then create a tag and push it. Otherwise it won't work. If tag was created first and commit and push after that you would create the same version of the module because the release will be based on last commit right before tag. So tag is like a mark, so what tag does it saves the last commit hash. Based on it new release is created.

Cross browser testing

link

Change Node version with NVM

It's quite easy, we don't have to tweak $PATH, we can do:
nvm ls

This will show us the list of installed node versions with arrow pointing to the currently used one.

nvm use 8.9.4
this will change the version to 8.9.4. To prove that we can type:
node -v
and it says:
v8.9.4

Need a new node version? Easy:
nvm install 10.12.0

Local PHP developemnt / Laravel

To run new instance of Laravel just type:
laravel new name_of_your_app

or

go to your dir and type:
laravel new

Laravel comes with this handy CLI tool that allows to create new laravel installations.

To serve your app just type:
php artisan serve

Change public to public_html laravel

https://stackoverflow.com/a/53208776/567058

Mac local mariadb service

It's been installed through brew.
To start it just type:
mysql.server start

And after that you're able to log in mysql with:
mysql -u root

Laravel comes with node.js oriented front end development

Which means you can use:
npm run watch - to watch changes for js and scss
npm run production - which is going to minify your css and js


Convert mov to mp4 with 30fps output file

ffmpeg -i input.avi -r 24 output.avi

Show unpushed commits

git log origin/branch..branch
eg for site story: git log platform/solas-0000..solas-0000

Unmount Platform.sh and make it work again without restarting Mac

Having vagrant running we type:
sudo diskutil unmount force ~/Documents/Platform.sh
vmunmount
Then vagrant reload and again we have files mounted in Platform.sh directory.

Mount mydevil with sshfs

cd ~/mydevil_ssh
sshfs dnawrot@s18.mydevil.net:./domains ./

Stand up Zoom:


IELTS

Database:
mysql -u root -p
pwd: root

database: ielts
dump ~/ielts_tiny.sql

describe content_type_ro;
select nid, field_organisation_id_value, field_ro_country_value, field_ro_city_value, field_unique_id_value from content_type_ro limit 20;

select count(nid) from node where type = 'ro';
select * from node where nid = 290731;
select * from content_type_ro limit 10;

Show table sizes in active db:
SELECT table_name ,
round(((data_length + index_length) / 1024 / 1024), 2) as SIZE_MB
FROM information_schema.TABLES
WHERE table_schema = DATABASE() ORDER BY SIZE_MB DESC;

Find longest value. Display length of longest value:
select LENGTH(field_application_type_value) from ro_content_field_application_type order by length(field_application_type_value) DESC LIMIT 1;
select field_application_type_value from ro_content_field_application_type order by length(field_application_type_value) DESC LIMIT 1;


Salesforce

URL: https://test.salesforce.com/
user: dawid.nawrot@britishcouncil.pl.developer3
pwd: standard
Campaign ID: 7019E000000IW77QAG

New test data after refreshment:
org id: 00D1w0000000RpD
campaign id: 7011w000000B1TiAAK

Standup


Monday: Gwen
Tuesday: @Simon Yeldon
Wednesday: @Vincenzo Russo
Thursday: @Dawid Nawrot
Friday: @Marcin Grabias

Skroty:

ATs - automated tests
ACs - acceptance criteria
TB - testing branch

LUDZIE:
Marios Ioann - grek
Dakala - Deji
Raj Bhargav Kosara - siniak
Bertan Atalay - gosc z dlugimi wlosami i broda
Naveed - ten sepleniący
Raheem Ali - to ten z orzechami zamiast oczu
vincenzo russo - włoch (zna się na vm)

PROJEKTY:
sklep
solas2 - ogolny projekt z ktorego korzystaja wszystkie wersje jezykowe
wersje jezykowe - z niewielkimi zmianami
white labels

TEST NA PLATFORM.SH:
admin
6603Q~140z3962ia4.9gnf9On
hW41z80mq&gS9Ik%h@c32Hb!l
4H78(d2SvJWX6LFs.ks5U

DEVELOPMENT WORKFLOW:
https://bcdigital.atlassian.net/wiki/display/DEV/Development+Workflow


----
Budowanie testowego srodowiska
----

1. Mozna sprobowac z komendą:
platform te -p [site_id] [branch_name] -r



Przykład dla Russia (zqlbujr46j5to) dla branchu solas-5686-vkontakte-test
platform te -p zqlbujr46j5to solas-5686-vkontakte-test -r



Zwykle to przebuduje srodowisko, ale nie bedzie widoczna zmiana z tego branchu dlatego trzeba to trochę inaczej zrobić.

2. Wchodzimy do katalogu sites
3. Robimy deploy strony np. ru, czyli 
platform deploy -d -A -p zqlbujr46j5to
4. Wchodzimy do katalogu /ru
5. Przechodzimy na branch qa: git checkout qa
6. Ściągamy najnowsze zmiany: git pull
7. Wpisujemy: git co test-5686


Pojawia się komunikat:

Branch test-5686 set up to track remote branch test-5686 from platform.

Switched to a new branch 'test-5686'



I tutaj nie wiem czy przy tym commicie ta branch jest tworzona, czy jak ale z tego co pisze to ta branch chyba juz istniała i jest sledzona zmiana pomiedzy branchem zdalnym, a lokalnym. Prawdopodobnie tak jest, bo to środowisko już wcześniej istniało, utworzyłem je w punkcie pierwszym. 


8. Wpisujemy: cat project.make

Wyswietli nam clay plik project.make

9. Wpisujemy: nano project.make
I zmieniamy linię z:

projects[solas2][download][branch] = qa

na taką:

projects[solas2][download][branch] = solas-5686-vkontakte-test

10. Następnie: git add project.make
11. Następnie: git commit -m “Rebuilding env test-5686” (trzeba zmienić te cudzysłowy, bo są inne)
12. Następnie: git push origin test-5686

Tutaj powinna się zacząć przebudowa całego środowiska. Jeśli się skończy można wejść na link podany na końcu lub sprawdzać na bieżąco w platform.sh
13. Teraz środowisko ze zmianami powinno być dostępne do testowania.

Jeżeli potem byly wprowadzone jeszcze jakieś zmiany w PR i chcesz przebudować już istniejące środowisko to nalezy wprowadzic jakas zmianę w pliku CHANGELOG, zwykle jest plik CHANGELOG dla konkretnego branchu i zrobic commit, a nastepnie push i srodowisko jeszcze raz sie przebuduje.


----------------------------------
FIX for creating remote branches
----------------------------------

platform deploy -d -A -p [site_id]

Edutation is Great fix:
Jeśli przy komendzie push pojawia sie blad ze tylko administatorzy moga tworzyc branche na serwerze (remote) i nie da sie wypchnac zmian to nalezy uruchomic komende:

platform branch solas-0000-info qa

Ta komenda pozwoli na uruchomienie nowego buildu na serwerze i jednoczesnie stworzy ten branch. W zasadzie ten build jest nieistotny, bo jeszcze nie sa wypchniete zmiany. W kazdym razie jesli wszystko poszlo ok to powinienem otrzymac taki komunikat:

The environment solas-5663-title-update has been created.
From git.bc.platform.sh:yemse4pemhngo
* branch solas-5663-title-update -> FETCH_HEAD
* [new branch] solas-5663-title-update -> platform/solas-5663-title-update


nastepnie wystarczy zrobic:
git push origin solas-0000-info i zmiany zostana wyslane na server, bo ta sama galaz istnieje juz i lokalnie i na serwerze. Tym samym uruchomi sie tworzenie nowego buildu. Po zbudowaniu dostaniesz linki do nowej wersji buildu z twoimi zmianami.

Inna zmiana:

jesli po git status pojawi sie dodatkowy plik np. yml ktory nie byl zmieniany to dlatego, ze jeszcze nic nie bylo nigdy zmieniane w tej stronie to wystarczy wpisac:

git checkout nazwa_pliku

to powinno go usunac, po kolejnym git status nie powinno go juz wiecej byc.


------
BRAK MOZLIWOSCI STWORZENIA NOWEGO SRODOWISKA TESTOWEGO
------

Jesli nie da sie utworzyc nowego srodowiska testowego to nalezy usunac jedno z istniejacych (tych stworzonych przeze mnie), a jesli sie okaze, ze wszystkie sa nadal w trakcie testow to trzeba sie zglosic do Simona lub Vincenzo, aby stworzyl pusty slot. Mozliwy komuniakat swiadczacy o braku wolnych slotow:

[HttpException]
An API error occurred.

Details:
[url] https://bc.platform.sh/api/projects/dfcocujp5d3mg/environments/qa/branch [status code] 402 [reason phrase] Payment Required [message
] This action would raise the count of environments over its limit. [title] Subscription issue


----
SKLEP NA LOCALU
----

http://shop.local.solas.britishcouncil.digital/en


----
Solas UI - environment
----

https://github.com/bcteam/Solas-UI


----
DRUSH
----

drush @co._local cc all
czyli trzeba dodac kod kraju np. @pl._local


----
KONCZENIE ZMIAN ROZPOCZETYCH PRZEZ INNEGO UZYTKOWNIKA
----

Zalozmy, ze ktos pracowal nad ticketem 5652 i go nie skonczyl. Ale jest branch i chodzi o stworzenie takiego samego branchu lokalnego i polaczenie go ze zdalnym branchem.
1. Budujemy srodowisko
1. bedac na qa: git pull
2. Wpisujemy: git branch -a (to nam wyswietla wszystkie branche i te zdalne i te lokalne wlacznie z tym zdalnym solas-5652)
3. Wpisujemy: git branch solas-5652 remotes/platform/solas-5652 (ta komenda tworzy lokalny branch i matchuje go z branchem zdalnym, czyli solas-5652 to nowa branch loklana, ktora ma byc skojarzona z branchem zdalnym o nazwie remotes/platform/solas-5652)
3. Wpisujemy git checkout -b solas-0000-test
4. Będąc juz przełączonym na ten branch wpisujemy: git pull origin solas-0000-test
5. Dla pewnosci mozna wpisac: git diff qa..solas-0000-test (to nam wyswietli zmiany jakie sa wprowadzone - w tym momencie powinny juz byc widoczne zmiany jakie osoba ktora wczesniej pracowala nad tym ticketem zrobila) - jesli jest cos wiecej niz powinno to:
- wpisujemy: git merge qa
6. kolejny git diff qa..solas-0000-test powinien juz byc bez dodatkowych zmian
7. kontynuujemy prace

----
Przebudowa istniejacego buildu w przypadku kraju
----

Jesli masz juz istniejacy folder z danym krajem i dziala sobie lokalnie, ale wprowadziles jakies zmiany (np. w przypadku solas2, a konkretniej stworzyłeś jakiś nowy moduł, ktory musi byc widoczny w nowym lokalnym buildzie ru), ktore wymagaja przebudowy tego srodowiska to wchodzisz do katalogu np. /sites/ru i wpisujesz:

platform deploy -d -A ru
Ta komenda przebuduje całość wraz z nowym sciagnieciem modulow i uruchomieniem pliku make. (prawdopodobnie bedziesz chcial uzyc tej komendy)

platform deploy -d ru
Ta komenda przebuduje całość, ale moduły z solas2 zostaną niezmienione.


----
Dwie f. hook_update w jednym projekcie - kwestia numeracji
----

Jesli sa dwa tickety ktore dotycza tego samego projektu i obie zmiany wymagaja f. hook_update to mozna:
1. zrobic z tym samym numerem obie zmiany, a potem jak cos bedzie mergowane jako pierwsze to rozwiazac konflikt - preferowane rozwiązanie
2. wstawic identyczny kod z dwoma f. hook_update do obu ticketow i wtedy jesli jest identyczny to nie bedzie zadnego konfliktu
3. zrobic branch pod brancha (ale tu nie znam szczegolow)


----
Test branch - SKLEP
----
Aby utworzyć branch testową na sklepie wpisujemy:



platform te -p xojmvqut5i7jc solas-5401-email-field-type

Jeśli się utworzy to pojawią się linki do sklepu. Należy pamiętać, że te linki i tak nie działają, bo sklep jest w katalogu shop, dlatego zamiast np. takiego linku:

http://test-5401-xojmvqut5i7jc.bc.platform.sh/

należy użyć takiego linku:

http://test-5401-xojmvqut5i7jc.bc.platform.sh/shop


----
Sytuacja w ktorej TB nie bierze pod uwagę hook_update
----
Załóżmy taką sytuację. Pracujesz sobie nad jakąś funkcjonlanością, w której jest hook_update. Następnie tworzysz sobie TB i zmiany są widoczne. Ale jeśli chcesz wprowadzić jakieś dodatkowe modyfikacje to już przy kolejnym tworzeniu TB te zmiany nie będą widoczne. Dzieje się tak dlatego, że TB mimo przebudowy pracuje na starej bazie, wiec ma juz numer twojego hooka wykonany. Zatem, aby zresetowac numery hook upateow nalezy w konsoli (bedac na branchu ticketa nad ktorym pracujemy) wpisac:

platform sync

I dla kodu nalezy odpowiedziec nie, a dla data (bazy danych) nalezy odpowiedziec tak.

Lepiej od razu zrobic commit i push zmian, a dopiero potem platform sync, bo inaczej trzeba bedzie robic rebuild 3 razy (platform sync (1), commit i push (2), znowu platform sync(3)).

----
usuwanie i ponowna budowa testowego branch w sklepie na pl.sh
----
W bcshop:
1. platform environment:delete -p xojmvqut5i7jc -e test-5680

The environment test-5680 is currently active: deleting it will delete all associated data.
Are you sure you want to delete the environment test-5680? [Y/n] y

Delete the remote Git branch too? [Y/n] y
Deleting environment test-5680

Waiting for the activity mm3lsldgrqm4g (Dawid Nawrot deactivated environment test-5680):
No package to build: environment is inactive.
Deleting environment xojmvqut5i7jc-test-5680.
[============================] 1 min (complete)
Activity mm3lsldgrqm4g succeeded
Deleted remote Git branch test-5680

2. platform te -p xojmvqut5i7jc solas-5680-marketing-default-statement
wynik: linki do sklepu

Teraz w sites/shop:
na qa: git pull

platform checkout test-5680
jesli w katalogu sites/shop jest pusty plik project.make to go usuwamy
jesli sklep jest w katalogu sites/shop/shop to w tym katalogu w pliku project make zamiast qa wpisujemy nazwe swojego branchu np.
nastpenie git commit i git push origin test-0000
powinien zbudowac sie nowy testing branch

----
Lokalne testowanie zmian wprowadzonych przez innego uzytkownika na SOLAS2
----
Jesli chcemy przetestowac zmiany jakiegos uzytkownika lokalnie, bo z jakigos powodu pl.sh nie dziala czy cos to robimy tak:

1. machujemy sobie lokalna branch z branchem zdalnym na SOLAS2, a robimy to tak:


  • przechodzimy na branch qa
  • sciagamy najnowsze zmiany
  • tworzymy branch z poziomu qa przez: git checkout -b nazwa_branchu_taki_jak_zdalny, np.: git checkout -b solas-0000-test
  • juz jestesmy na odpowiednim branchu, wiec robimy: git pull origin nazwa_branchu_taki_jak_zdalny np.: git pull origin solas-0000-test
  • przy komendzie git diff qa..solas-0000-test powinnismy zobaczyc tylko te zmiany, ktore dotycza tego branchu
2. przechodzimy na ta branch, zmiany w plikach juz teraz sa widoczne na SOLAS2
3. przechodzimy do dowolnej lokalnej strony i mozna sprobowac juz sprawdzic czy dziala.
4. jesli nie dziala to mozna wyczyscic cache, moze sa jakies hooki, ktore wymagaja odswiezenia
5. jesli nadal nie dziala to przebudowujemy cala strone (czyli przechodzimy na qa i platform deploy -d -A fr)

zmiany powinny byc widoczne.


----
Budowanie środowiska testowego na lokalnej stronie, jesli zmiany byly wprowadzone w SOLAS2
----
Załóżmy, że pracujemy na branchu solas-0000-dupa
1. Jesli mamy juz caly kod napisany w SOLAS2 i jest zrobiony PR to przechodzimy do wybranej lokalnej strony np. cd ~/sites/fr
2. Ściągamy najnowsze zmiany w qa
3. Tworzymy branch testową np. git checkout -b test-0000
4. W pliku project.make wprowadzamy zmiany i wpisujemy swoj branch, zamiast qa wpisujemy: solas-0000-dupa
5. Git status
6. git commit -am "test build"
7. Git push origin test-0000
8. Tutaj pojawi sie informacja, ze tylko administratorzy moga tworzyc branche
9. Wpisujemy: platform branch test-0000 qa
10. Uruchomi sie tworzenie testowego branchu, ale jeszcze bez widocznych zmian.
11. Nastepnie git push origin test-0000, ta komenda jeszcze raz nam uruchomi build, ale tym razem majac wprowadzona nazwe branchu w pliku project.make odbuduje strone ze zmianami ze wspomnianego branchu.


----
Zmiany w CSS
----
Jesli pracujesz nad jakims ticketem typu SUI, np. SUI-152 i zrobisz zmiany, commit i push, a nastepnie te zmiany przejda i zostanie zrobiony merge to i tak nie beda widoczne dopoki Vin lub Simon nie zrobi rebuildu i nowego releasu tych zmian css-owych. Nowy build i relese jest robiony na żądanie, wiec trzeba się z ktoryms z nich skontakowac, aby taki zrobil. Jesli nie chce to napisac w komentarzu do Rengin, ze potrzebny jest nowy release.

Tak naprawdę to chyba Mark się zajmuje nowym releasem, ale zeby to zrobic to nie jest takie proste, bo to musi przejsc jakies testy i tak dalej, wiec lepiej dodac zmiany w lokalnym pliku css, a potem i tak ktos doda to do SUI. Tutaj mark mniej wiecej to wyjasnil:

Dawid Nawrot If you need to get something out without wanting to wait for a SUI release the best thing to do is to add it in solas-ui-overrides.css in the theme. It's not ideal but it's somewhere to put it and I try and use that file as a 'staging area' of stuff that needs to go back into SUI and I usually try and clear out that file when we do a SUI version bump.
Don't get me wrong, if we can do it straight away in SUI (as we did then) then it's all good but often it's not possible/practical as the two releases are not tied together (they are separate products) and if it's a breaking change then it stops us having to version bump SUI for Drupal's sake, which can be a pain due to the sub themes like Shakey also requiring a version bump (version sits in the .info file). Obviously it's not an issue here but just an FYI. It's almost like using proper Bootstrap, we might add a fix in our local override stylesheet then report a bug to Bootstrap and when they fix it we can remove our fix. I.E we wouldn't wait for Boostrap to fix our bug if you know what I mean.

---
Update VM
---

Różne tagi służą do różnych procesów i tak np. tag 3.3.1-PHP56 jest tylko do update. Z tego tagu nie da się zbudować od nowa VM. O to do czego służy tag należy zapytać Vincenzo. Jeśli jest potrzebny update VM-a to pytasz, ktory tag updateuje VM, wchodzisz na gihub i tam przełączasz się na niego, następnie klikamy na releases i przy tym tagu powinna byc instrukcja. Acha, update wykonujemy w katalogu istniejącego VM-a.

i teraz tak, bedac w katalogu psh-vm wpisujemy git pull tym samym pobierzemy wszystkie nowe branche / tagi. Aby przelaczyc sie na dany tag wpisujemy git checkout v3.1.2-PHP56.
No i dalej wg instrukcji z release notes - z reszta git checkout .. tez jest w release notes.


New solas site rollout

1. W pierwszej kolejności ixis przygotowuje środowisko.
- w ramach przygotowania powinniśmy dostać: master, qa, stage i snapshot. W ramach snapshot powinniśmy mieć zdefinionwane 4 zmienne: disk = 2048 (inherited), group = solas (inherited), mysqldisk = 2048 (inherited), site_code = russia-music

Teoretycznie powinniśmy pracować na branchu master, ale nie miałem uprawnień do pushowania do master, mimo że Simon je podobno ustawił. To jest problem z vagrantem i konfiguracją gita. Z poziomu Maca bez problemu można się logować do master i pushowac do master, tak że rollout powinien być w zasadzie zawsze prowadzony z poziomu maca.

2. Jeśli mamy przygotowany projekt na platform.sh i lokalnie platform projects potrafi go wylistować to musimy go sklonować. Nie robimy platform deploy, bo to nie zadziała na takim projekcie. Natomiast musimy zrobić platform get -p ID_projektu i to w katalogu sites/ (w zasadzie w katalogu release_sites). Zapyta nas do jakiego katalogu ma być sklonowany projekt i zasugeruje nam katalog. Wprowadzamy nazwę taką jaka nam pasuje np. 'russia-music' i repo jest sklonowane.

3. Wchodzimy do katalogu i łatwo zauważyć, że jest zupełnie inna struktura plików niż w przypadku istniejącej strony. Musimy go doprowadzić do stanu standardowej strony (czyli w kat. site powinna znaleźć się większość danych, itd). W tej chwili jestesmy na branchu master - można spróbować zrobić jakiś push, jeśli nadal będzie kwikał o brak uprawnień do pushowania do master to robimy nowy branch od master i na nim pracujemy (ale z poziomu Maca nie powinno byc problemów). Dodajemy katalog /site i tam przenosimy to co nam się przyda, to co nie to usuwamy i możemy też skorzystać z site-template, który znajduje się w solas2/sites/site-template. Jak już wszystko ustawimy jak trzeba to robimy commit i push - niestety trzeba to robić trochę na ślepo, bo nie ma możliwości przetestowania tego lokalnie - w każdym razie ja nie wiem jak to zrobić. Po commit i push zobaczymy, że środowisko jest nieaktywne (inactive) (komentarz dodatkowy: to niekoniecznie tak jest, jesli faktycznie byl robiony branch od master to tak, ale jak sie robi push do master to powinno być ok). Tutaj była potrzebna pomoc Simona, żeby aktywował środowisko. Okazało się również, że repozytorium solas2 profile nie mogło się zaciągnąć, bo IXIS zapomniał dodać ssh key do projektu. To dodał Simon manualnie. Dzięki temu jak już środowisko jest aktywne to można wbić się na platform ssh -e branch i zainstaować stronę. Ale zanim to zrobimy z dates usuńmy 'short' - jeśli tego nie zrobimy instalacja się wywróci. Najlepiej to zrobić z opcją --verbose np.:

drush si -y --verbose solas2

Dzięki temu będziemy mieli cały output na ekranie. Jesli wszystko poszło ok to w następnym kroku dodajemy datę short, hook_update i robimy push. Hook update powinien wykonać się w trakcie przebudowy, nie ma potrzeby wchodzenia przez ssh i uruchamiania drush updb. W ten sposób zainstalowaliśmy drupala na master. Teraz należy zrobić sync danych i plików na pozostałe branche. I tutaj troche dziwna rzecz, a mianowicie sync na snapshot był nieaktywny. Dopiero po jakichś 5 minutach zrobił się aktywny, więc trzeba chwilę poczekać. A jak już zsynchronizujemy snapshot to reszta idzie z górki (qa i stage). Na koniec można zrobić platform deploy lokalnie, powinno wszystko działać. W kadym razie tak było w przypadku active-citizens.


----
Rollout sklepu
----
Aby stworzyć rollout sklepu dla danego kraju bedziemy potrzebowac dwoch lub trzech branchy. Pierwsza z nich to zmiany globalne w bcshop. Druga to zmiany dla testing branch w katalogu /sites/shop. Trzecia natomiast, najistotniejesza - tam gdzie jest wiekszosc konfiguracji dla danego kraju to katalog danego kraju np. /sites/br (Brazil). I teraz tak, jeśli story ma numer 5555 to:
- branch w bcshop powinna miec nazwe: solas-5555 (a w zasadzie to chyba przydaloby sie dodac jeszcze opis tak standardowo)
- branch w sites/shop powinna miec nazwe: solas-5555-shop (to jest TB) - ja bym to nazwal test-5555, no ale...
- branch w sites/br powinna miec nazwe: solas-5555-shop (a to bym nazwal solas-5555)

Prawdopodobnie nie trzeba będzie wprowadzać żadnych zmian do bcshop, to jest podobna zmiana do sui enable, wiec teoretycznie powinna się zamykać w obrębie zmian dotyczacych kraju. Poki, co najlepszym przykladem zmian jest solas-5826, wiec jak się przepniemy na tą gałąź wg powyzszego schematu to powinniśmy dostać kompletne rozwiazanie dla uruchomienia sklepu (rollout) dla Brazylii. Póki, co tam jest jeszcze problem z platnosciami, bo nie dzialaja, ale zakutalizuję ten opis w momencie jak nie bedzie juz zadnych problemow.

Generalnie zmiany lokalne (br) sa wprowadzane w katalogu shop (ktory z reszta jest tworzony) czyli /sites/br/shop (dlatego tez strony zostaly przeniesione do sites/br/site zeby nie mieszaly sie pliki. Oto lista plikow, ktora zostala zmieniona:

.platform/local/project.yaml
.platform/routes.yaml
.platform/services.yaml
shop/.platform.app.yaml
shop/CHANGELOG-QA
shop/libraries/README.txt
shop/modules/README.txt
shop/modules/custom/bcshop_install/bcshop_install.info
shop/modules/custom/bcshop_install/bcshop_install.install
shop/modules/custom/bcshop_install/bcshop_install.module
shop/modules/features/bcshop_site_settings/bcshop_site_settings.features.field_instance.inc
shop/modules/features/bcshop_site_settings/bcshop_site_settings.features.inc
shop/modules/features/bcshop_site_settings/bcshop_site_settings.features.language.inc
shop/modules/features/bcshop_site_settings/bcshop_site_settings.info
shop/modules/features/bcshop_site_settings/bcshop_site_settings.module
shop/modules/features/bcshop_site_settings/bcshop_site_settings.strongarm.inc
shop/modules/features/bcshop_webtrends/bcshop_webtrends.features.inc
shop/modules/features/bcshop_webtrends/bcshop_webtrends.info
shop/modules/features/bcshop_webtrends/bcshop_webtrends.module
shop/modules/features/bcshop_webtrends/bcshop_webtrends.strongarm.inc
shop/php.ini
shop/project.make
shop/settings.php
shop/themes/README.txt

----
Pokaz liste zmienionych plikow w obrebie branchu
----
Jesli jestes na branchu np. solas-5555 to aby pokazac sama liste (bez zmian / kodu) plikow nalezy wpisac: git diff --name-only qa
I w ten sposob wszystkie pliki zostana wylistowane.

----
Jak usunąć całkowicie istniejący kraj (lokalnie)
----
1. Usuwamy bazę danych, bądź obie, jesli jest sklep np.: drop database psh_itd
2. Usuwamy pliki, bedac w katalogu sites wpisujemy: rm -rf pl
gdzie pl to nazwa katalogu do usuniecia. Teoretycznie po tym zabiegu jak sobie wpiszemy platform deploy -d -A -p [project_id] wszystko powinno zadzialac jak nalezy.

----
Restart REDIS-a przy bledach
----
Jesli z jakiegos powodu podczas deploymentu lub czyszczenia cache redis się wysypie, zaczną się pojawiać błędy typu:

EVAL failed: ERR Error running script (call to f_480b498a45897bea144749414832ecbca2df61d8): @user_script:3: @user_script: 3: -MISCONF [error]
Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are
disabled. Please check Redis logs for details about the error. PhpRedis.php:137

to nalezy zrestartowac serwer komendą: sudo service redis-server restart

----

Uruchamianie sklepu

----
1. Najlepiej skopiowac caly katalog /shop do danego kraju i na nim wprowadzac zmiany
2. Ponadto nalezy wprowadzic zmiany w .platform/routes.yaml oraz .platform/services.yaml
3. Po wprowadzeniu wszystkich niezbednych zmian nalezy zrobic git commit i git push.
4. Oczywiscie system bedzie krzyczal, ze nie moze stworzyc zdalnego branchu
5. Nalezy go stwrzoyc komenda: platform branch solas-0000-mx-shop qa
6. Nastepnie jak juz sie stworzy branch to wysylamy zmiany komenda: git push origin solas-0000-mx-shop
7. Jak juz wszystko sie przebuduje to wchodzimy na platform.sh i odwiedzamy strone, po wpisaniu /shop powinien nas przekierowac do install.php?profile=bcshop lub cos podobnego.
8. Oznacza to tylko, ze jest wszystko ok tylko nalezy zainstalowac sklep, zatem wracamy do konsoli i wpisujemy: platform ssh -A shop
9. Zaloguje nas po ssh do branchu na ktorym jest sklep.
10. Nastepnie nalezy wejsc do katalogu /shop i zainstalowac sklep komenda: drush site-install
11. Po poprawnej instalacji (bledy dotyczace wysylania maili nalezy pominac) pojawi nam sie info, ze sklep jest zainstaloway.
12. drush -y cc drush
13. drush -y fra
14. drush -y cc all
15. drush -y upwd admin --password='6603Q~140z3962ia4.9gnf9On'
16. Nastepnie nalezy wyczyscic redis. I tu jest troche problem, bo nie wiadomo jak wyczyscic redis dla sklepu. W kazdym razie redis dla strony czyscimy w nastepujacy sposob:
17. W katalogu /shop wpisujemy: redis-cli -h redis.internal
18. W tym momencie powinien nas polaczyc z usluga redis, czyli konsola powinna wygladac tak: redis.internal:6379>
19. Wpisujemy: redis.internal:6379> flushdb
20. W odpowiedzi dostajemy OK. Czyli redis wyczyszczony. Wiecej informacji tutaj: https://docs.platform.sh/configuration/services/redis.html na dole przyklad. Niestety dla sklepu to nie dziala, mimo ze moim zdaniem powinno. W ten sposob powinno wygladac logowanie: redis-cli -h shopredis.internal wg tej dokumentacji.
21. Na serwerze juz mamy wszystko. Teraz pozostaje zrobic deployment lokalnie. W pierwszej kolejnosci trzeba sciagnac dumpy bazy danych. Robimy to tak: platform drupal:db-sync -e solas-5835-mx-shop
22. Troche to potrwa, bo bazy sa spore. Ta komenda sciaga dump bazy danych do katalogu /tmp tam znajdziemy dwa pliki, ktore sa dumpami baz danych. Wazne, aby oba pliki byly spore, bo zdarzylo mi sie tak, ze w jednym nie bylo struktury bazy. Pewnie wczesniej wykonalem taka komende (przed instalacja) i ponowne wywolanie komendy niczego nie zmienialo. Dlatego, jesli zajdzie taka sytuacja to nalezy usunac te pliki z katalogu tmp i ponownie wywolac komende.
23. Nastepnie w katalogu np. sites/mx wpisujemy: platform deploy -d -A
24. Ta opcja -d wymusi uzycie tych plikow dump bazy danych i zaimportuje je podczas deploymentu.
25. Calosc dziala jak nalezy.

Lista projektow

platform projects

Theme debug


https://www.drupal.org/docs/7/theming/overriding-themable-output/working-with-template-suggestions
drush enable: drush vset theme_debug 1

Homestad laravel - make it work

To nalezy dodac do pliku Vagrantfile do konfiguracji:

https://github.com/mitchellh/vagrant/issues/7648#issuecomment-235282382

Jesli z jakiegos powodu domena nie dziala, a na tych ustawieniach nie dziala (przechodzi przez SSH, ale doemny nie dzialaja) to trzeba ja dodac manualnie. W konsoli macox wpisujemy: sudo nano /etc/hosts i na koncu dodjemy nowa linie z zapisem:

192.168.88.88 drupalvm.dev

i powinno dzialac.
Tutaj wiecej: http://davebaker.me/articles/setting-up-a-local-dns-server-on-osx

Konferencja - numer na ktory trzeba dzwonic

00 800 1114 593
potem trzeba podac kod, ktory podadza podczas rozmowy i na koncu dodac #

Praca z tiger quiz

Repozytorium znajdziemy w /Users/dn/tigerquiz/tiger-quiz
Glowny branch nazywa sie master.
Dodawanie nowej funkcjonalnosci:
1. Sciagamy najnowsze zmiany z gita: git pull origin master
2. tworzymy nowa galaz: git checkout -b solas-0000-dupa
2a. wpisujemy npm install (ta komende teoretycznie powinno sie uruchamiac zawsze przy przelaczaniu na inny branch)
3. Wprowadzamy zmiany
4. Robimy commit i push, powinny byc dostepne na githubie.
5. nastepnie wpisujemy w katalogu glownym projektu: npm start
6. Jesli wszystko dobrze pojdzie to powinno pojawic sie: webpack: Compiled successfully. (jesli cos nie dziala to nie wpisujemy kolejnej komendy tylko nalezy znalezc problem i dopiero jak mamy pewnosc, ze sie dobrze kompiluje to przechodzimy do pkt 7)
7. I teraz mozna wpisac: npm run deploy (ta komenda robi deploy na serwerze czyli pliki quizu, ktore sa uzywane na testowych branchach sa juz dostepne, wiec nic wiecej nie trzeba robic tylko wejsc na uprzednio przygotowany branch i uruchomic aplikacje, wszystko powinno dzialac).

Sublime Text 3 - instalowanie rozszerzeń

1. Klikamy w Tools -> Command Palette lub wcistamy command + shift + p
2. Wpisumey install package
3. Następnie wyszukujemy pakietu do dodania
4. Instalujemy / Konfigurujemy






Test PHP


 <?php  
 drupal_add_js($source);  
 print $source;  
 ?>  

Test - numery kart kredytowych


Przede wszystkim tutaj: https://github.com/britishcouncil/bcshop/blob/qa/modules/custom/commerce_gopi/README.md

Visa
Number: 4142621111111112
Expiration date: default
CCV: any

Master Card
Number: 5473551111111117
Expiration date: default
CCV: any

Moduły contrib

/sites/pl/.platform/local/builds/php/public/sites/all/modules/

DB Sync
platform drupal:db-sync -e solas-5826-shop - ta komenda sciagnie obrazy baz do katalogu tmp
nastepnie robimy platform deploy -d -A zeby zrobic deployment

Kopiowanie z output

proszę: cp --verbose -rf  katalog /home/vagrant/sites/uk

Webmail

http://webmail.digitaltest.email/
username: catch-all@digitaltest.email
password: kbHDxxfX

Tworzenie testowej branchy z poziomu konsoli

Jesli jestes np. w kat. sites/pl na QA i chcesz zrobić testową branch to wpisujesz:
platform environment:branch test-6287