Symbiote

Engineer the web, together.

Symbiote news

Keep in touch with what we're up to.

RSS available too if that's your thing!

Hello Toby Lerone

Nathan Glasl

Posted 3 Nov 2017

On database restore...

Have you ever refreshed your project database, jumped onto the site and been presented with..

Hello Toby Lerone

I'm sorry, but you can't access that part of the CMS. If you want to log in as someone else, do so below.

I don't recall changing my name, so who is this, and why does it think that's who I am? Well, turns out when you refresh a database, if you happened to be logged in prior to it happening, the member IDs may not necessary line up anymore. For example, before..

ID

Name

500

My Default Admin


Then, after..

ID

Name

500

Toby Lerone

501

My Default Admin


The only way this actually happens is when you've logged in as someone that's no longer in the newly restored database, yet your session remains intact. In which case, you're likely to only ever see this on a development or testing environment. As a matter of process (to prevent this from happening), it's a good idea to logout and re-authenticate when refreshing development or testing environments.

Something to keep in mind the next time you're suddenly logged in as Heracles Warshawsky.

More prominent workflow

Marcus Nyeholt

Posted 28 Sep 2017

Making workflow... work.

The Advanced Workflow module is a pretty nifty piece of process management once you get your head around it; editors can create and change things, but can't publish until a prescribed sequence of events have happened. Generally allowing a few cycles of feedback to occur. One of the common complaints with it though is that the "Workflow Actions" (ie the things people need to do...) are hidden and not obvious for content authors to find. Here's a snippet that makes use of the Right Sidebar module to help with that a little...

Once you have advancedworklfow installed, add the rightsidebar module with composer:

composer require micschk/silverstripe-rightsidebar

Create an extension in your project like

class WorkflowSidebarExtension extends Extension
{

    public function updateWorkflowEditForm(Form $form)
    {
        $tab = $form->Fields()->findOrMakeTab('Root.WorkflowActions');
        if (!$tab) {
            return;
        }

        $sb = RightSidebar::create('WorkflowActions');

        foreach ($tab->Fields() as $f) {
            $sb->push($f);
        }

        $form->Fields()->removeByName('WorkflowActions');

        $form->Fields()->insertBefore($sb, 'Root');
        $form->Fields()->fieldByName('Root')->setTemplate('RightSidebar');
    }
}

And lastly, bind that to the CMS editing controllers

CMSPageEditController:
  extensions:
    - WorkflowSidebarExtension
GridFieldDetailForm_ItemRequest:
  extensions:
    - WorkflowSidebarExtension

Enjoy having the workflow actions appearing alongside authors' work!

You need to compile JavaScript now?

Marcus Nyeholt

Posted 12 Sep 2017

A JavaScript build cycle

For years jQuery has been the dominant JavaScript framework on the web. Serve up an HTML page, load in your JS and add functionality after the fact. Times change, and after much experimentation, we're choosing to standardise on React. 

Part of the reason is wanting to try new things, but some key considerations have been

  • Comparatively rigid structure to follow with how components are built, leading to more consistent development in the team
  • More familiar class based layout (helps getting backend developers up to speed) 
  • Strict(er) typing with the use of TypeScript providing a predictable codebase amongst multiple developers

All that aside - one of the biggest hurdles to getting started with these technologies has been "what is a webpack and why does my allegedly current version of node / npm / yarn / babel / brunch / ohwat not work with it?". (Yes, there's a good reason why some of those won't work together...). Rather than deal with all the different quirks each operating system has, and to ensure the same versions of tools, we looked to use Docker to create a define-once-run-everywhere image. 

After much experimentation, we've settled on a JavaScript build set of ES2016, TypeScript, React, jQuery and Bootstrap - depending on need - all managed using Yarn for package management, with Brunch binding everything together. To maintain consistency across the development team, we're using the following Docker file, which gives us a consistent execution environment across the board;

FROM ubuntu:14.04

# allows the use of the 'source' command. 
RUN rm /bin/sh && ln -s /bin/bash /bin/sh

RUN apt-get update && apt-get install -y \
    software-properties-common \
    apt-transport-https \
    build-essential \
    ca-certificates \
    vim \
    git \
    curl \ 
    wget \
 && rm -rf /var/lib/apt/lists/*

ENV NVM_DIR /usr/local/nvm
ENV NODE_VERSION 6.5.0

ADD nvm-install.sh /tmp/

RUN bash /tmp/nvm-install.sh \
    && source $NVM_DIR/nvm.sh \
    && nvm install $NODE_VERSION \
    && nvm alias default $NODE_VERSION \
    && nvm use default \
    && npm install -g grunt-cli \
    && npm install -g yarn \
    && npm install -g brunch 

ENV NODE_PATH $NVM_DIR/versions/node/v$NODE_VERSION/lib/node_modules
ENV PATH      $NVM_DIR/versions/node/v$NODE_VERSION/bin:$PATH

EXPOSE 9485

CMD ["/bin/bash"]

This can be run directly from the CLI, or with a simple wrapper; so a yarn.sh might look like

#!/bin/bash

docker run -i -v $(pwd):/tmp/work -p 9485:9485 -w /tmp/work --name jsbuildtools --rm symbiote/jsbuild bash -c "yarn \"$@\""

which is then usable just like a locally installed yarn binary

yarn.sh start

Simple but effective; we're conscious of the impact learning new technologies has on our teams, so we're doing as much as possible to bypass the frustrating (okay, infuriating) process of getting a working JS build environment in place. 

The repo for the above Dockerfile is available at https://github.com/nyeholt/docker-js-build-tools

1 2 3 4 5 6

Page 4 of 6