• Automate your webhook-configuration

    I thought about how to optimize my project-creation-progress and wrote a little script for that.

    In my article about GitLab-Webhooks, I wrote about how to simplify your deployprocess with a few simple steps. If someone pushes to a GitLab-project, a webhook will be run which updates your stage- or production-server.

    In my solution I use a PHP-script, which reads a config-file to determine if the project which runs the webhook is a known one and if so, which branch has to be deployed.

    I still like that solution, but I do not like, that I

    1. have to create the base-directory for a new project and set needed permissions all the time
    2. have to modify the deploy-configuration by myself.

    Because, in my case, the deploy-config is the same most of the time (of course the path to and the name of the project differs), I tried to automate these steps.

    addProject Bash-Script

    So I wrote a little Bash-script, which helps me.

    • It creates the base-directory of the project in the document-root.
    • It modifies the deploy-config with standard-parameters and adds the correct path and project-title.

    To prevent doublications and make sure the script does not overwrite exisiting files, the script checks if the new project already exists.

    cd /var/www/
    if [ ! -d "$1" ]; then
        mkdir -p "$1/logs"
        chown YOURUSERNAME:www-data $1-$2
        chmod -R 775 $1
        cd /var/www/DEPLOYSCRIPTDIRECTORX/
        head -n -2 deploy.json > temp.txt ; mv temp.txt deploy.json
        printf "\t},\n\t\"$1\": {\n\t\t\"path\":\t\t\"/var/www/$1\",\n\t\t\"limit\":\t\"master\"\n\t}\n}" >> deploy.json
        echo Project already exists!

    How to run

    To execute the script, you type:
    /path/to/script.sh projectTitle

    In my script there is a second parameter, which is a running number of the job. I want that to be part of the directory-name. I didn't include it in my sample here, but you can add more parameters by using the vars $2, $3, $4 …

    The command above will create the directory projectTitle in /var/www.

    How it works

    First the script changes the current directory to the apache-document-root, that's /var/www for me, it may also be /srv/http for example. You should modify that for your needs in line 3 and 10 (I modified it a bit, because my client-works are in a subdirectory).

    After that the script checks if the project-directory does exist. If so it will exit with a warning. If not, it will continue.

    The directory will be created and the needed permissions will be set. The group of the directory will be set to www-data and the group gets write-access, so the deploy-script can write into the directory later.
    If the deploy-script or your webserver runs as another user, you may want to change the group-name.

    Then the script changes the directory of your deploy-configuration to extend it. First it will strip off the last two lines, which are the closing brackets of the json and of the last project.
    Then the last projects gets its bracket back appended by a comma (so the next entry can follow).
    After that the new entry will be written, the projectname and the path will be set. As default, the master-branch will be set for automatic deployment. If you want all branches to be deployed, you can change master to null or whatever branch you want to by deployed.
    Finaly the closing bracket of the json is written.

    So, with that the project ist set up and can be used. I put my script in my GitHub-Repository, hope it helps. If you have tips our questions feel free to comment below.

    Read full post
  • Bilingual Kirby

    Maybe some of you have noticed, I am trying to write bilingual. So I wrote some helpers for that.

    My last posts here could be read in english (surprise!), too. Although my written english is a bit rusty, I will keep translating my posts in the future and will try to translate the older ones step by step.

    I am not that enthusiastic by the possibilites which come with Kirby, but it works, as you can see. I wrote a little snippet to switch languages and added a translation-detection I am using in my blog-header.

    The problem is, Kirby will show the german text under a /en/-URL if there is no translated file available. I don't want that. You should not be able to click on the link for a translation which isn't there. So I modified the default-code for switching languages a little bit.

    So it works better (for me)

    First I try to figure out, which template is used by the current article. The templatename matches the first part of the filename. With that information I can look for a translation of the text. If a translation is available the language-switch-link is clickable, if not, the link is not clickable.

    Have a look:

    <?php foreach(c::get('lang.available') as $lang) : ?>
        <?php if($lang != c::get('lang.current')) : ?>
            <?php if($page->files()->find($page->template().'.'.$lang.'.md')) : ?>

    To prevent manual modifications of the URL from "de" to "en" I am using a translation-detection in the header-file. If I would not do so, you could change "de" to "en" in the URL, but you would see the german text, if no translation is available. And I don't want you (and searchengines) to do so.

        $lang = c::get('lang.current');
        $other = ($lang == 'de') ? 'en' : 'de';
        $template = $page->template();
        if($page->files()->find($template.'.'.$lang.'.md') == NULL) {
            header ('HTTP/1.1 303 See Other');
            header('Location: '.$page->url($other));

    First I look which language is choosen and see what its counterpart is. Then again the test if a translation is available. If not, I am redirecting to the german version (which changes the URL).

    I am not sure, if the 303-header is really correct, but it semed the best solution for me. This whole solution only works, if you are only bilingual. If you would like to support more than two languages you need to modify it.

    My snippets can, as always, be found at GitHub.

    Read full post
  • GitLab Webhooks

    Some versions ago, I think it was version 5.2, GitLab introduced Webhooks. I didn't like them at first but that changed since I found a great PHP-script, which I slightly modified.

    I am a big fan of GitLab (even though the updateprocedures are pure horror) and I am using it for all the jobs and projects I am working on. I think GitLab is a great alternative to GitHub.

    To get a smoothly running workflow and because I don't want to copy or pull files after pushing them to see the Changes on the websites, I use hooks.


    Hooks are little scripts, run at a certain time. For example when changes where pushed to a repository. You can use these hooks to update a website automagically after a push, or take a stupid looking picture of yourself with every commit.


    Now there are those webhooks. Principle they work the same as normal hooks. With every push a script is run. Until now, in my case, those scripts where simple BaSh-scripts. But those webhooks are working a bit differnt. You don't create a BaSh-script for every repository, you just tell GitLab what URL to open.
    With every push, this URL will be opened and the relevant data will be submitted as JSON-string.

    The big advantage is, you can execute different scripts by adding additional URLs.
    The disadvantage is, you cannot use BaSh-Scripts anymore, because those normally aren't reachable via an URL.

    The solution

    So I looked around on the web and found a PHP-Script which seems to fit my needs.
    The script evaluate the JSON and updates the corresponding branch. It even creates a folder for branches which didn't exist before.

    So, whenever I push something to my master-branch, the URL (PHP-script) will be opened and the directory "master" will be updated or created if it doesn't exist.

    So far, so good.

    There are two things, I didn't like.

    1. I have to copy the script for every repository and edit the included Path and URL to the repository.
    2. It might happen, that I am working on branches, which do not need to be transfered to the webserver. Particularly when working on bigger projects there might be various branches which are merged from time to time, but must not be available on the webserver.

    My modified solution

    So I took the script and thought about, how to improve it. And this is how my solution works:

    The PHP-script has to be copied to the server on which the webserver is running. I use a vhost for it, so I have a nice domain for that. The script has to exist once only.

    Also I created a config-file. A simple JSON-file which has the following structure:

        "repoName": {
            "path": "/path/to/folder",
            "limit": null

    The name of the repository as to be the exact name as set up in GitLab, because the name will be submitted within the GitLab-JSON and can be referenced that way.

    path is the directory in which the subdirectories for each branch will be created. In most cases this will be within document-root.

    limit can be null, then all branches will be cloned and updated. If you whish just to update certain branches, you can give limit a comma-separated list of branch-names.

    "limit": "master,testing"

    You do that for each repository.

    In this way you just have to maintain two files. The PHP and the config-file. If you make changes to the PHP you do not have to make those changes several times.


    To get the script running, some basic steps have to be done before (creating deploy-key etc.). I will not explain those here, because they are explained in the blogpost of the original script very well.

    Attention meridimus was so nice to give us a tip in the comments. In step 7 of the original article, the directory also needs the execution-flag so the known_hosts file can be created. Do it like so:

    $ sudo chmod -R 0600 /var/www/.ssh
    $ sudo chmod 0700 /var/www/.ssh
    $ sudo chown -R www-data:www-data /var/www/.ssh


    if you are interessted in the script, you can take a look at GitHub.


    I wrote another article about how to automate your deploy-configuration with a simple bash-script.

    Read full post
  • My Sublime Text MarkDown-Setup

    I'm formatting my blogposts in markdown, For that, I set up my Sublime Text installation a bit.

    As I wrote here (sorry, german only), my website runs on Kirby as CMS. And I am still satisfied with that solution.

    Because Kirby is entirely based on MarkDown, I took a look at some applications, to write my MarkDown a bit more beautiful. But in the end I am using Sublime Text for that. The applications had great functions, like syncing around in the cloud and stuff like that. But weren't even able to open a regular file und I had to export my changes all the time. That was a bit annoying.


    So now I am using Sublime Text again. I installed a little Plugin named MarkDown Editing and because I am a industrious guy and have nothing to do all the day, I wrote my own color-theme. I was inspired by some the apps colors and re-used them.
    And that's it concerning Sublime Text.

    To have the ability to see my changes without reloading my browser all the time, I bought a little app. Marked does that job for me. When I am saving my markdownfile, Marked shows me a preview. And I can hide all the YAML Front Matter stuff, Kirby needs. Which is pretty nice. To get a preview which looks nearly as my blog here, I set up my CSS as a theme.

    Of course it would be much cooler, if all that magic would happen in my browser. So I get a preview in there, every time I save. Maybe I'll try to write a javascript for that, if I ever have the time.

    If you would like to have a look at my sublime-color-theme, feel free to download it on GitHub

    Read full post