All your questions answered: questions from Drupal South
For completely selfish reasons it was great to see Drupal South in Australia again in 2018. I unfortunately wasn’t able to make the trip across the Tasman for 2017. This year was quite a different experience for me. In previous years I was working at an agency, talking to government agencies as potential customers. This year was I was the government agency.
Overall it was another great Drupal South. It’s always great to see what’s going on in the Drupal community across Australia.
For those folks who did get to my session and had unanswered questions, or people who’d like a behind the scenes peek at Single Digital Presence, our Victorian Government web project, I’ve copied out the sli.do questions here with our responses.
How do you share content between sites in a single Drupal instance/distribution?
This became really easy with running headless. We use a taxonomy term to allow content editors to determine which site(s) a piece of content belongs to. We also provide a Primary site field to enable us to print a canonical url tag to avoid SEO penalties. You can see our repo here, https://github.com/dpc-sdp/tide_site. Each individual site has its own Ripple front end, which references the site ID in order to determine what content gets displayed on that site.
Why did you pick vue.js for the front end and how do you tackle server-side rendering/SEO and browser support (e.g. < IE 11)?
The old Vue vs React question. We spent quite a bit of time thinking about it. Part of it was watching the two issues on drupal.org about which JS framework to use for the new Drupal admin UI initiative. At the time we made the decision, it looked like Vue was winning. Also, from experience Vue felt a lot easier to learn, so I figured it would be easier to find and onboard new devs.
All of our content is server side rendered using Nuxt to ensure plain old HTML is delivered to the browser.
Did you find there was internally/organisationally focused content not intended for public view? If so, how did you deal with this content?
In general, there is a lot of internally focused content, but there are numerous intranets and other internal facing websites for that content to sit on. SDP sites are purely for public consumption. We have created an About Victorian Government section on vic.gov.au that is for public servants and people working with government.
How do you control governance and content creation across your domains? Was this developed as part of the project?
We created a governance model of independent, semi-independent and core vic.gov.au content. This was signed off by the head of our department at the start of the project.
We run regular writing for the web workshops and have a community of practice. For many of the Department of Premier and Cabinet run sites, once the content is written, it comes back to content approvers inside the SDP team to make sure standards are met.
Our governance rules are published on the site at: https://beta.vic.gov.au/working-web-publishing-team
This is a huge effort, well done & thanks. What’s the breakdown of your team’s skills? Do you see that changing as the project matures?
We’ve got a multi-disciplinary team that includes content design, user experience and product management plus our devs.
Front end dev and backend dev are pretty equal on the internal team, but we’re still supported a lot by external developers. We only have one internal dev ops person, so we rely mainly on external support. The team structure is likely to change over time. Our intention isn’t to become an internal development agency for the Victorian government, but rather to provide a common toolset for building Victorian government websites. This will provide external developers common tools and infrastructure to build on. Open sourcing the products means everyone benefits from the work of any agency.
What are the major challenges delivering headless wrt development, admin, etc?
Remaining decoupled on tight deadlines can be hard. The temptation is always to build in simple, tightly coupled architectures for quick pieces of work. The way the team has structured the separation between the Nuxt and Ripple layers is really nice and ensures we’re in good shape for the future.
You mentioned “security” — what sort of tools/processes are you using? Static container scanning etc?
OpenShift provides a lot of tools out of the box, e.g. no root user access to containers etc. Static container scanning is part of the stack as well, this automation helps to take the pressure of individuals. Once again, using open source tools ensures we have a lot of eyes on our platform, which further assists in keep on top of things.
How does the approval process for content across sites work?
The current process is fairly basic, Draft, Needs Review, Published. This works for most cases, but is easily updatable with the Core Content Moderation module. It’s easy to overcomplicate workflows in a CMS in my opinion. I’ve seen it many times in the past and it always results in users finding ways of getting hold of an admin account.
How are you integrating transactional activity into the stack? Do you plan to take the same approach with Commerce functionality?
Service Victoria is the transactional service within Victorian Government, https://service.vic.gov.au/. There will be some transactions in SDP sites, such as basic form submissions and the like, but financial transactions are highly unlikely. In order to maximise return on investment, SDP will use Service Victoria where possible to provide any required transaction. Hopefully these integrations can remain completely invisible to the user and provide a great user experience.
How do you deal with front end rebuild and CDN invalidation on content changes?
That’s a tricky problem right now. We’re using Cloudfront and the Cloudfront module can only invalidate a single distribution at a time. We’re looking into some additions to that module to allow for multi-site invalidation. This will cater for invalidating headless as well.
How do you manage permissions between content editors? People say to me (state government) they want to edit “their” content, but no-one else is allowed to.
Currently permissions are quite open, which is intentional. One of the issues found previously was that in reality, users across areas were collaborating on content, but they were using word documents or other means to do it. Adding permissions and forcing people out of the CMS doesn’t really benefit anyone. That said, there are many reasons to implement more complex publishing controls, which is definitely on the current roadmap.
Do you keep a copy of all content offline as a record of all online content?
Not sure where this question was heading, but…
Now that we have access to the CMS, we put content directly into the site where possible. Approvers use a preview link to review and approve. If content owners want or need to keep a copy of content it’s their responsibility to keep a copy in Content Manager, our record keeping tool.
There are also multiple layers of back up we can call on if needed.
Could you please expand on how’s & challenges of technical aspects of content sharing using API between separate sites?
When we first started designing the solution, shared content was the big issue. Shared content is always a big problem across databases. Which database is the source of truth, do you allow changes in both directions, what about nested shared entities, and those are just the first few issues.
Going headless simplified this problem greatly and I think the solution in our module is pretty good, https://github.com/dpc-sdp/tide_site. It’s open source so feel free to take a look.
How did you migrate/cut over to the new site? Did you run a beta phase as you migrated, or in one big launch?
We’ve been running in alpha for quite a while and we’re in beta now. The idea wasn’t to just copy the content over, but to restart the whole content curation journey from scratch.
How did you manage the content api release with jsonapi?
The jsonapi 2.x update has been a difficult one and we’re not quite there yet. We’re in the process of updating all of our enhancers but it should come out in the next release.
The wrap up
My first session was The story of GovCMS. I always like to get along to the govCMS sessions. I’ve been working with govCMS from the very early days on the CASA website. The govCMS team have led the way when it comes to open source in government, so I’m always keen to see where they’re going.
Next up was HashiCorp Vault for Drupalers. This was great session. We still have more work to do on our headless Drupal Webforms, but once we’re a little further along I’m keen to start looking further into Vault.
Next up was WorkSafe Victoria: Service design on headless Drupal. It was good to pop along and see what Si and Dan were presenting and to see some lessons learnt. I’d been involved at a few points along the way with this project, initially with some joint ideation sessions around architecture. Then when the Vue.JS front end sites for Worksafe and Workwell moved over to SDP hosting.
I took a bit of time out at this point to finish my presentation, shh, don’t mention it, I was totally prepared.
I went along Let’s Go Nuxt! from Tim and Guy on my team. I think the guys have built some great stuff.
The ICEMEDIA Keynote was with Jith from our team, and it was good, but, tbh that was my third or fourth run through and second that day, sorry Jith.
For the second day, The Today Design Keynote: Charbel Zeaiter was amazing. A great way to get re-inspired by the possibilities of tech. I’m definitely re-establishing my Ikigai.
Unfortunately, the next session was the one I had to present. I couldn’t believe that it was one of the best time slots of the conference. I missed out on Cloudflare with Sean Hamlin, Build test and audit with Brian Gilbert and Stuart Clarke and a CMS comparison session with Vladimir Roudakov. I was happy with the session on Single Digital Presence (SDP), but I’d heard it all before.
The Open Source for Open Government panel session was a good one. Governments aren’t well known for collaboration and open source. govCMS and SDP are trying to change that. Working within the confines of government doesn’t always make that easy, but so far it’s working!
A few small support spot fires pulled me away from the later sessions unfortunately.
The final keynote, The OPC IT keynote: Sally Young, really was a good one. The Drupal admin UI could definitely do with some love. It was great to get up to date on where things are going with that initiative. I felt for Sally when she ran into demo hell, but I had to head to the airport before seeing if she recovered.
Overall it was another great Drupal South. It’s always great to see what’s going on in the Drupal community across Australia.
