In this post, I list the components of my dev environment. This list can be useful when initializing a new project or starting a new job.

Make use of a cool virtualisation solution

I choose Vagrant. Take the time to create cool provisioning scripts. In case of problem, you will be able to set up quickly your env! VERSION your provisioning scripts!

Reproduce the exact same stack than the prod env

• OS
• php version
• php.ini conf: /etc/php5/apache2/php.ini & /etc/php5/cli/php.ini
• apache version
• apache VHOST
• db version
• system permission

Keep one VM/project do not host several projects under the same VM. If you need a laboratory VM, create a dedicated one!

Turn on debug mode and error printing

Edit in php.ini files:

    error_reporting = E_ALL ^ E_NOTICE ^ E_WARNING
    display_errors = on        

Restart apache:

    sudo service apache2 restart

Make use of a cool source control

I use gitlab: git+wiki+tracker. When you commit, do not forget to make link between commit and ticket reference.

Make use of a cool PHP IDE

I use PHPSTORM because of:

• debugger integration
• completion
• external tools integration
• framework integration
• database integration
• live templates
• source control integration

Set up a cool debugger

I use XDEBUG embed in vagrant VM with PHPSTORM on host machine which is very very very nice.

Look at this article to setup xdebug/vagrant/phpstorm.

Set up a mailer

Setting up sendMail is quiet complicated whereas setting up ssmtp is easy.

Follow that tutorial to install ssmtp.

Do not forget to edit google lesssecureappsoption

Set up a cool build tool

I use Phing to build and deploy.

wget -q http://www.phing.info/get/phing-latest.phar
sudo mv phing-latest.phar /usr/local/lib/phing.phar
chmod +x /usr/local/lib/phing.phar
sudo ln -s /usr/local/lib/phing.phar /usr/local/bin/phing

pear install VersionControl_Git-alpha

Things that must be under source control

• Provisioning script
• Source code
• Build job
• VM configuration (alias, conf file) can also be versioned.

With that you should be able to automate deployment and rebuild solution from scratch!

This post describes how to consume a Moodle core webservice.

Set up Moodle

Enable REST protocol

In Dashboard / ► Site administration / ► Plugins / ► Web services / ► Manage protocols

• enable REST protocol.
• enable Web services documentation too.

Create a custom webservice

In Dashboard / ► Site administration / ► Plugins / ► Web services / ► External services

• add a custom services named test ws for example

Create a custom user for webservice

In Dashboard / ► Site administration / ► Users / ► Accounts / ► Add a new user

• create a wsuser user.

Create a custom role for webservice

In Dashboard / ► Site administration / ► Users / ► Permissions / ► Define roles

• create a ws_user_role.
• allow at least Create a web service token

Assign role to user

Dashboard / ► Site administration / ► Users / ► Permissions / ► Assign system roles

Test

Get a cool REST client

Getting a user friendly REST client is important, POSTMAN is pretty cool.

Get a token

Make a GET request to get a token.

For instance:https://192.168.33.10/login/token.php?service=test_ws&username=wsuser&password=Wsuser123456-. You should get:

        {
          "token": "19f315a127eef1f7f381da40fefd7b75"
        }

Consuming a Moodle core webservice

Now we get a token! So let's consume the core_course_get_courses WS. Results in JSON with moodlewsrestformat=json.

Make a POST request on https://192.168.33.10/webservice/rest/server.php?wstoken=19f315a127eef1f7f381da40fefd7b75&wsfunction=core_course_get_courses&options[ids][0]=1&moodlewsrestformat=json. You should get :

        [
          {
            "id": 1,
            "shortname": "test",
            "categoryid": 0,
            "fullname": "Site de test",
            "summary": "",
            "summaryformat": 1,
            "format": "site",
            "startdate": 0,
            "numsections": 1
          }
        ]

API DOCUMENTATION

This can be found at Dashboard / ► Site administration / ► Plugins / ► Web services / ► API Documentation

Download, install and configure

Sculpin is a static site generator written in PHP. It converts Markdown files, Twig templates and standard HTML into a static HTML site that can be easily deployed. As this site, it can be hosted on GITHUB pages.

• fork the sculpin-blog-skeleton repo

• clone the repo and install Sculpin dependencies:

   git clone git@github.com:benIT/github-blog.git         
   cd github-blog
   composer install
  

• edit blog settings in app/config/sculpin_site.yml

• run a local webserver on port 8000 to see your edits

   php vendor/bin/sculpin generate --watch --server
  

• add content in /source/_posts folder

Create content

• edit your post content
• check result at localhost:8000

• when result is enough good, generate site using :

  php vendor/bin/sculpin generate --env=prod
  

• Your site html content should be available at output_prod, it's the content of that folder that must be hosted on your github page

Deploy on github

About github pages

You can host html generated at 3 different locations :

• on master branch
• or master branch in docs folder

• on gh-pages branch

  But for your personal pages, you can only host in repo named benit.github.io on the master branch. This means, that we need 2 repos : one for source control and another one for hosting our github pages. Thus, I create the following repos : github-blog.git and benit.github.io

How to publish the content to the repo that hosts your github pages ?

I edit the shell script named publish.sh. The script is in charge of:

• generating the html
• rsyncing the output_prod folder of the source control repo with the benit.github.iorepo.
• commiting on the 2 repos with the same commit message
• pushing on the 2 repo

Usage:

./publish.sh "edit post about Setting up a cool php development environment"