freistil News

Yesterday, the Drupal core team made Drupal 8 Release Candidate 1 available. We won’t have to wait much longer for the final release of the best Drupal ever!

Holly Ross from the Drupal Association highlights the improvements in the upcoming release:

“With Drupal 8, the world’s best content management framework just got better. Every built-in theme is responsive. Every single component is translatable out of the box. More elements have configurable fields and there are new field types for better content modeling.

It’s built people-first. The authoring experience is better, with features like in-context editing and enhanced previews. It’s easier to add people-friendly meaning via native schema.org markup. There’s extensive support for accessibility standards.

Drupal 8 also has all the geekery you can Git. All-new configuration management (full exports, easier transitions between environments) means safer, faster site development and maintenance. REST-first native web services enable 3rd-party integrations. And adding Twig is the most complete transformation of Drupal theming in a decade. It allows friendlier syntax, better security, and a separate presentation layer.”

Drupal founder Dries Buytaert is excited as well:

“Historically, the adoption of Drupal has roughly doubled with each new release. We expect no different from Drupal 8, a release I believe positions Drupal most strongly for the future. We’ve undergone some big architectural changes to get more people using Drupal, and to prepare ourselves for the future. I can’t wait to see what the community does with Drupal 8. It’s time to start building!”

Yes, it’s time! Our engineering team has been busy over the last weeks, and we’re happy to say that freistilbox is ready for Drupal 8!

To prepare freistilbox for the requirements of Drupal 8, we’ve made a bunch of changes to modernise our web server setup. All our new freistilbox clusters make use of new software versions to make your website fly.

First of all, your application will enjoy the improvements in functionality, performance and stability that come with PHP 5.5.29. For example, we’ve replaced the APC opcode cache extension with the more efficient Opcache built into the PHP interpreter.

With the switch to PHP 5.5, we’ve also upgraded Apache from version 2.2 to 2.4. Its lower memory footprint leaves more memory to your web application. The Apache team also did a tremendous job at performance tuning. While Apache had a reputation for not being as fast as other web servers such as nginx, the new Apache version definitely measures up with its competition. Many of the new features and options in Apache 2.4 open up opportunities that we’ll use to make freistilbox even better over the coming months.

Due to changes in its configuration syntax, Apache 2.4 may make it necessary to modify your .htaccess files. See the freistilbox documentation for details.

For a quick and easy application setup, you can avail of Drupal 8 versions of our pre-fab configuration snippets. Simply use “d8” in your require_once statements.

Of course, our new and improved Drupal 8 setup is available not only to new customers. So if you’d like your existing cluster upgraded for Drupal 8, just send us a support request!

Until the final Drupal 8.0.0 is released, there might still be slight changes necessary. Rest assured that we’ll be quick to adapt freistilbox so you can launch your shiny new Drupal 8 website on release day!

• Read more

When we launched our Managed Hosting service back in 2010, we quickly found that using Git for application deployment was a bit of a challenge for our customers. At that time, distributed version control systems just weren’t widely used yet and many people had no experience with Git whatsoever when they started hosting on freistilbox. So we did our best to keep Git usage as simple as possible.

This is the reason that up until now our deployment system only used the “master” branch of the website instance repository. While you could use any branch in your local development repository to work on your web application, finally the code had to be pushed to the “master” branch on the hosting platform side. If you use multiple website instances for staging and testing you’d push to multiple remote repositories but it would always be to their “master” branches.

Over time, our customers got more proficient with Git and started to adopt multi-branch development approaches such as “Git Flow”. With their Git skills growing, more and more customers started asking for a more symmetrical deployment concept. They’d expect that their “master” branch would go to the production website’s “master” branch, “staging” should go to the staging website’s “staging” branch and so on.

We’re happy to report that finally, multi-branch deployment is here. From now on, you can choose the branch from which each website instance will deploy code.

At the moment, you’ll still have to push to a separate repository for each website instance. But don’t worry, deployment to different website instances from a single central repository will come eventually, so please bear with us.

Until then, you can set up your working repository like this to make things as easy as possible:

git config remote.production.url <production repo URL>
git config branch.master.remote production
git config remote.staging.url <staging repo URL>
git config branch.staging.remote staging

With these settings, a simple git push from the “master” branch will upload your changes to the production instance and a push from “staging” will automatically go to the staging instance.

Are you already excited to test the new branch deployment? Simply send us a support request and let us know the site ID of your website and which branch you’d like us to assign to it.

We hope that this change will make your daily development work a little bit easier. Drop us a quick tweet to @freistilbox to let us know if it does!

• Read more

Coinciding with the opening keynote of their CTO Dries Buytaert at DrupalCon Barcelona, Acquia today announced the expansion of their European business. In their PR statement, Acquia claims:

“With data centres now located in Germany, Ireland, and eight other regions around the globe, Acquia is the only Drupal platform service provider to offer pan-European support for high availability sites that accomodates EU data sovereignity requirements.”

We beg to differ.

Since 2010, we’ve been specialising in Drupal and WordPress hosting focused on high performance and availability; first under the “DrupalCONCEPT” brand and, starting in 2012, with our Managed Hosting Platform freistilbox. As an EU-based business, freistil IT has been compliant with EU data sovereignity requirements for over five years now. The data centres hosting our physical IT infrastructure are not only based in Germany but, equally important, also owned and operated by a German company.

On top of fully accomodating EU data sovereignity requirements, freistilbox is compliant with the German “Bundesdatenschutzgesetz” (BDSG) which is widely regarded as the strongest data protection legislation in Europe. German businesses that process client information protected by the BDSG are required to sign a “Vertrag zur Auftragsdatenverarbeitung”, a contract for the commissioned processing of data in which the hosting provider guarantees that both their technical infrastructure and their IT processes meet the strict requirements of the BDSG. The fact that we do has won us the trust of many privacy-conscious customers, for example the Federation of German Consumer Organisations and Doctors without Borders.

In conclusion, while we happily welcome Acquia’s initiative to strengthen the high-quality Drupal hosting market in Europe, we’d like to set the record straight that they’re certainly not the only provider of high-quality Drupal hosting accomodating EU data protection requirements, much less the first.

If you’d like to learn more about what freistilbox can do for you in terms of excellent website performance, high availability and data protection, shoot us a tweet or an email!

• Read more

In a strange kind of tradition, we’re launching our new website for the freistilbox user documentation today. We’ve copied all articles over from our Zendesk Help Center (and will remove them there soon in order to avoid confusion). We’ve also used this opportunity to update and improve many of the articles and FAQ entries.

The motivation behind starting a new documentation website was threefold:

• Efficient content maintenance
• Fast and effective navigation
• Extensibility

Efficient content maintenance

As every developer knows, documentation is likely to be treated subordinate to implementation. Especially in a small team such as ours, there’s always work waiting either to improve existing or to build new feautures. In this environment, documenting how these features work or how to use them most effectively is often postponed to when customers actually ask about them in a support request. That’s not the quality of user experience we’re aiming at.

Additionally, maintaining content on a web-based system like the Zendesk Help Center is not the most efficient process when you’re used to writing in your finely optimised text editor of choice. That’s why we’ve been creating our documentation articles in Markdown text files stored in a Git repository for a long while now. On the one hand, this made the actual writing convenient and provided us with a change history for every article. On the other hand, publishing a new or modified article meant that we had to first convert it to HTML, then copy and paste it into the web form and then add additional metadata like tags/labels. The prospect of this tedious manual workflow didn’t exactly invite to make changes, so there always was the temptation of making changes directly on the website – and losing them again with the next update done correctly from the stale Git repository version.

Our new freistilbox documentation website is built with the Middleman static site generator. As until now, we write articles in Markdown and commit all changes to Git. But now, we can publish changes simply by making a git push to the central repository on Github. This push then triggers a CI process which runs a number of tests and (if they were successful), publishes the generated HTML files to Amazon S3 where the website lives.

Yes, we actually run tests on our documentation. At the moment, they only check that our source files adhere to a common Markdown style guide. In the future, there could also be tests for bad writing style such repeated words or overlong sentences.

Our new content publishing workflow will enable us to extend and improve our user documentation with the least effort.

Fast and effective navigation

We felt that using the Zendesk Help Center not only was less efficient for writing content, it also didn’t provide the best user experience to our customers. Finding the right article quickly is essential when you’ve got a question or issue and you’d like to check the available documentation before contacting technical support.

That’s why we’ve added a powerful search function to our new docs site that offers auto-completion and starts showing search results even while you’re typing. Behind the scenes, we’ll also get statistics that’ll help us improve our documentation based on actual search behaviour.

At the bottom of each page, you’ll also find a list of related articles that touch the same topics as the article you’re currently reading.

These improvements will help you find relevant content faster than before. We also hope they’ll reduce the number of support requests so that our engineers can spend their time on more demanding issues.

Extensibility

Search is just one example of how we wanted to make our documentation website as extensible as possible. This requires having full control over its inner workings, which we can’t get by using a third party solution.

Another small example is the link at the bottom of each page that actually allows editing the article in true open source fashion. Since we manage the content in an open repository on Github, everyone who’d like to make improvements to an article can fork the repository, make the necessary changes and send us a pull request. Simply click on the edit link and send us your suggestions!

Over the coming weeks, we’re going to add more features and, most importantly, more documentation that will help you using freistilbox better. If you have any feedback for us on the new website, write us an email or ping @freistilbox on Twitter!

• Read more

In the first week of August, we met for the latest installment of our company retreat named “freistil Days”. As a remote team, we come together every 5 months in order to strengthen our relationships and to do things we can’t do otherwise. On each retreat, we learn something that helps us improve the next one. In this post, I’ll explain what we learned this time.

Schedule

The question of how long our retreat should be and how the schedule should look like is now pretty much settled. A whole week from Monday to Sunday has proven long enough to get a good bit of work done and short enough to limit the impact of our absence on the business and our families. We’ve arranged the schedule in a symmetrical way:

• Monday and Sunday are designated travel days.
• Midway through, Thursday is a good opportunity to do sight seeing so we get out and about a bit.
• This leaves two pairs of work days where we focus on projects.

Just like the previous times, we had prepared a schedule for these work days with time slots for project work, daily business, eating breaks and spare time. It hadn’t occurred to us until this time how hugely different this was from our normal year-round modus operandi. As a remote team, we trust that everyone knows their objectives and goals, and will work towards them. We don’t dictate when or how this work is to be done, though. This freedom creates a space for everyone to find their individual approach to working effectively. Halfway through these freistil Days, the Emperor’s Clothes question was finally spoken: “Why is our company retreat, of all things, the complete opposite?” We weren’t able to find a valid reason, so we decided to ditch the time slots, allowing everyone to decide individually when they’d work on freistilbox Solo, on support tickets or on other urgent business and when they’d rather lie down and read. From there, things got a lot more relaxed and (as expected) we still got a lot of work done.

Taking a break from work in the middle also does for a nice change. This time, we visited Hamburg’s Speicherstadt with the “Miniaturen Wunderland”, the world’s largest model railway. The amount of effort that went into building hundreds of square meters of model landscapes is amazing. And the control centre (see photo) was quite impressive, too. (Hey, we’re IT geeks.)

Projects

In advance of a retreat, we identify two or three projects on which we’d like to focus while we’re sitting around the same table. This time, we’ve decided to work on one customer-facing and one internal project.

The launch of our entry-level hosting plan freistilbox Solo has been delayed for months because we decided to base it on a new IT architecture that will also help us improve our existing enterprise hosting platform at a later time. freistil Days gave us the opportunity to focus on getting the new architecture further ahead and while it’s not finished, we’re much closer to a usable product now.

Behind the scenes we had noticed that our development workflows needed improvement. Now that there’s a whole team working on automating our IT infrastructure, the usual issues around collaboration, testing and releasing changes made us rethink how we do “infrastructure as code”. On a lovely Wednesday, walking along the green riverbanks of the Alster, we came up with a simple Continuous Deployment process that will give us everything we need with much less manual effort than before.

Group dynamics

Spending a whole week together as a group certainly is a big difference to our normal team experience. All the unavoidable social interaction tends to draw a lot of energy, especially for introverts (which all of us seem to be to different extents). After a few days, our lunch conversations became less engaging and silent pauses got longer. Towards the end of the week, we all felt a bit exhausted.

So it was a good decision to get rid of the rigid schedule because this will allow us in the future to take time off the group whenever we like, whenever we feel it’s necessary.

On the plus side, we got a better understanding for each other and more clarity about our strengths and weaknesses.

Conclusion

Third time’s the charm! Our freistil Days in Hamburg advanced us as a team and as a company. We deepened our relationships and made progress on our products and internal processes. And most importantly, we had a lot of fun!

If you’d like to see for yourself what freistil Days (and the rest of the freistil year) are like, get in touch!

• Read more

Sometimes you need to jump back in your git history to an old state. Most of the times you already published your commits to other remotes so a git reset --hard $OLD_COMMIT is not a solution.

This is where git revert comes in handy.

If you want to jump back to a specific commit id 48b616601cab02df84297dcf7246d17072ac32fb all you have to do is

git revert -n 48b61660..HEAD

Now check everything and create a new commit that reverts everything from the old state to the current.

• Read more

When our monitoring alerts us of a server because of a full root file system, determining the cause is a bit harder than with other file systems because many directories under / are actually mount points of separate file systems.

There is an easy way to isolate the root file system content, though: mounting it a second time elsewhere.

A normal mount will fail:

mount: /dev/mapper/vg0-root already mounted or /mnt busy
mount: according to mtab, /dev/mapper/vg0-root is mounted on /

But a bind mount does the trick:

$ mount --bind / /mnt
$ du -sh /mnt/*

• Read more

As Palasthotel CEO Benjamin Birkenhake announced on their company blog, the web agency based in Bielefeld and Berlin recently finished the relaunch of the German Rolling Stone Magazine.

The result of their work is, and I’m really not exaggerating, awesome. Not only did Palasthotel give the website a fresh design, they also did great development work behind the scenes:

• 130.000 articles needed to be migrated from Escenic to WordPress. Inspired by Drupal’s “Migrate” module, Palasthotel developed a WordPress migration framework which they’re going to make Open Source.
• The site uses 79 plugins, 69 of which were developed in-house.
• Homepage and landing pages were built with PalastHotel’s plugin Grid.
• Not only is the website responsive but it also uses “responsive images” technology that loads images only on demand and in the right resolution.
• For maximum search speed, Palasthotel developed their own interface plugin for Apache Solr (soon to be published, too).
• In order to simplify collaboration between three editorial teams, Palasthotel built a solution for sharing image galleries between separate WordPress setups.
• The site uses 8 custom post types for artists, concerts, festivals etc. For connecting these post types, Palasthotel developed a “Post Relationships” plugin (which they’re going to publish as well).
• Their new “Postqueue” plugin allows creating hand-picked content lists, just like the “Nodequeue” module in Drupal.
• And as if this list wasn’t impressive enough already, Palasthotel built and integrated Octavius into the site, their own real-time click tracking service.

Shortly after the relaunch, Ben teamed up with our Chief Uptime Officer Markus for a session at WordCamp Cologne where they presented how our teams cooperate to run High Load Websites reliably, with the Rolling Stone Magazine being only one example.

Congratulations to our friends at Palasthotel for a job well done!

• Read more