Feeds

Author

Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Aug 11 2020
Aug 11

In conclusion

The challenges of creating a great digital experience today are ever growing, and if you are looking for a more flexible, more customisable alternative to SharePoint, then a move to Drupal should certainly be considered.

Drupal is widely regarded as the world's leading open-source enterprise platform for building content-rich digital experiences. Its highly flexible, scalable and extensible nature enables organisations to build better sites and experiences faster.

Moving away from SharePoint may seem like an insurmountable task, but as this article shows, the challenges can be overcome and you need not remain stuck on SharePoint forever.

If you are considering a move to Drupal, then Annertech is an award-winning Drupal specialist digital agency that can guide you through the process, helping you define a clear strategy and enabling you to make a smooth transition. 

Jul 31 2017
Jul 31

On Friday, all the accepted sessions for DrupalCon Vienna were announced, and we are delighted to report that, once again, 5 of our 8 session proposals were accepted! With Acquia and Pantheon being the only companies receiving more acceptances, we are extremely proud of our achievement. It also means that given our size, Annertech has more speakers, per staff member, than any other agency in the world.

This is the second year in a row, where we have had 5 sessions accepted for DrupalCon, and, along with FreistilBox, are the only Irish web agency to be represented. Our sessions this year span a number of different tracks, namely Project Management, Site Building, Performance and Scaling, Front End and Core Conversations, and cover topics such as building multilingual sites in Drupal 8, project forecasting, debugging performance issues, component-based design/development, and accessibility. Congratulations to all our speakers!

Here's a quick run down of each session.

Live Performance Workshop: A top-to-bottom performance overhaul

Speaker: Anthony Lindsay
Track: Performance and Scaling

In this interactive workshop style presentation, we'll take a terrible, awful, broken sample site, look at all the nasty ways that its performance is terrible, and fix them, one by one. We'll get the audience involved with suggestions at every step of the way.

All examples will be taken from real life experiences, but no real sites will be harmed in the making of this demo/session.

Lessons Learned from Building a Large Multilingual, Multi-region Site in Drupal 8

Speaker: Stella Power
Track: Site Building

Having recently launched a Drupal 8 website with 13 distinct languages across 4 different regions, this session will take you from the basics of configuring your content to be multilingual through to making it localised in different regions and the various pitfalls encountered and lessons learned along the way.

Estimates are dead, long live forecasting!

Speaker: Mike King
Track: Project Management

In his session, Mike will outline the good, the bad and the downright wasteful aspects of estimates and how they’re used, before contrasting it all with the positive benefits of using forecasting to communicate a range of outcomes and how this can be communicated with the wider team. There will also be a follow-up BoF to share open source tools so that everyone can take home this new set of skills.

Back to the Future: No More Static Mockups!

Speaker: Mark Conroy
Track: Front End

This presentation will be an easy-going rant about how to make things better for frontend developers and will start by taking a look at Photoshop, SketchApp and InVision and how these tools fail to deliver (by building up expectations for clients and problems for implementers). We will then move on to talking about designing in the browser and how tools such as PatternLab and Fractal (basically HTML, CSS, and JS - the foundation of the web) can help solve these problems. Finally, we'll look at how we can (easily) integrate PatternLab with Drupal, thereby going 'Back to the Future'.

Core Accessibility: How are we doing, and what can we do better?

Speaker: Andrew Macpherson (and Théodore Biadala and Kristen Pol)
Track: Core Conversations

As we build Drupal websites, our exposure to the world of accessibility is often driven by the client or website owner. If they have accessibility requirements, we learn about these and try to meet their needs. Sometimes, it's driven by our own desire or need to make our websites consumable for more people.

In Drupal core, we've been making great strides incorporating accessibility best practices into the UX and markup. It’s not only important to help increase Drupal product adoption in some markets (e.g. the public sector) that have strict accessibility requirements, but accessibility is important to make Drupal sites reach the most people with varying backgrounds and abilities. This can be good for business. It is certainly good for our humanity.

Congratulations to Anthony, Stella, Andrew, Mike and Mark on their great achievement. We look forward to seeing these and all the other great sessions at DrupalCon Vienna in September. Hope to see you there!

Jul 01 2016
Jul 01

TL;DR

We were already prepared for a scenario like the Aberdeen Cloud breakdown, owing to our disaster recovery plan. Fortunately we didn't have to set it in motion. Each night we have a simple script which takes off-site backups of all of our hosted sites. We've made the source code available on github, so hopefully this will help others prepare for the likes of the Aberdeen Cloud implosion, and perhaps we can share ideas on how to improve each other's disaster recovery plans.

Our experience with the Aberdeen Cloud incident

We have a large number of sites hosted by various cloud services. Since autumn 2013, we'd mainly used Aberdeen Cloud, and in autumn 2015 we started to explore other options to see what else the market had to offer. Platform.sh was the one that we decided to give a serious test for new clients.

Soon after that, Aberdeen Cloud began to seem a bit flaky. Longer response times on support tickets. Solr services started to fail, along with random outages of various other services. We accepted that for a while, but after having lost and regained SSH access to all of our sites (including git and rsync), we eventually decided that enough was enough and we couldn't put our trust in them anymore.

We had to migrate everything to alternative hosting platforms. Given the similar price points and the fact that they seem well funded and offer excellent support, we decided on Platform.sh. And so began Project Exodus. 

Over the next three weeks we migrated over 20 sites to Platform.sh in a staged approach. I wouldn't say that it was a straight-forward process. Lots of clients had specific quirks to their setup. For example, some needed a PHPBB forum, others had FTP access for uploading files, some integrated with external systems that required firewall changes, etc, while others had custom .htaccess redirection rules that needed to be rewritten for Nginx. However, we were very lucky and had completed Project Exodus nearly a month before Aberdeen Cloud finally came tumbling down.

So what if you were not as fortunate as us, and still have sites whose assets are no longer accessible? Stuck in cyberspace, or maybe just plain deleted?

Well, I'm not sure there is a lot you can do. Maybe read Code Engima's blog post about the different things they've tried. However, to put it bluntly, it sucks! Enough said about the matter.

Now it's time to ensure you're never caught out again.

But what can we do to prevent this from happening again?

All companies probably have their own way to deal with this kind of scenario, but I'll tell you about how Annertech deals with backups and recoveries.

We have two sets of backups. A backup from each day, for each production/live/master environment, which is hosted by the cloud service. Then there is an off-site backup (again, daily) used for disaster recovery. The latter one is the important one in this scenario.

The idea is that even if Amazon (which hosts Aberdeen Cloud services) pulled the plug, we would still have access to our clients' data.

We have a server, hosted by a different company, that: 

  1. Pulls down a copy of the database, from every cloud-hosted site, every night, and saves it for four days, before it deletes it again.
  2. Runs `rsync` on every cloud-hosted site, to get an up-to-date version of the files folder, every night.

Sounds simple? It is. All it requires is that your hosting partner supports running Drush on your remote sites and you're good. If you run Drupal sites, and your hosting partner doesn't support running Drush on the remote sites, find somebody else who does. It's that important!

Regarding the code for the sites; we keep our source code repositories on dedicated git services. And, more than likely, we'll also have a copy or two on developers machines.

I'd like to show you the two backup scripts that I made, one for Aberdeen Cloud and one for Platform.sh.

The code is meant to work in our setup only, and is not (yet) generic enough to just work out of the box elsewhere. The release of the scripts is meant to give you a leg up and some inspiration. This is by no means the final end point for these scripts - we are continually evaluating and improving our system, and I look forward to hearing what ideas you have on where we could take it from here too.

The entire repository of code can be "stolen" from github.

When you have a disaster recovery plan you also need to make sure that it actually works. You can do this by downloading the latest backup from each of your sites once a month, installing and then testing them. I've tested a site, where the DB file was corrupt, but only for that site, so make sure that you test all of them. The setup of test sites can also be automated by a script so you don't have to setup 10, 50, or 300 sites and test each manually. Scripts are your friends. Make good use of them and have them do all the hard work.

Now, if you really want to push this further, you should implement a "Smoke test" in all of your installation profiles, so that you can trigger that to see if the site is alive; or perhaps tie it in with a Jenkins server.

If something is unclear, feel free to put a comment below. If you feel like this could be improved, feel free to contribute with a pull request. We are all ears.

Nov 12 2011
Nov 12

A good night out at the Eircom spiders for two of the Annertech team this week. After Stella's little arrival came a bit early, a flu-ridden Edward was drafted in to fill the void.

Two of our clients were up for Awards. Trócaire had been nominated for two awards - best charity and best campaign, while runireland.com were in the running for the community award. Trócaire unfortunately left empty-handed this time around, but RunIreland were successful in their category.

It's a first Eircom spider award for Annertech - one of many to come hopefully!

Aug 08 2011
Aug 08

At DrupalCon Chicago earlier this year, Stella spoke with Kent Bye from Lullabot. They discussed recent improvements to the Coder module which can help you automate code reviews and upgrade your modules. They also discussed future plans for the module that will increase the number of security checks on Drupal modules.

The interview has now been released as a Drupal Voices podcast.

Apr 07 2011
Apr 07

I recently came across LiveReload and was impressed. Actually impressed is an under statement. I was amazed. LiveReload has really improved the way I work with css. As it says on its github page LiveReload is browser extension & a command-line tool that:

  1. Applies CSS and JavaScript file changes without reloading a page.
  2. Automatically reloads a page when any other file changes (html, image, server-side script, etc).

Getting it to work is straightforward. You simply need to download the LiveReload gem and install the extension/plugin in your browser of choice (as long as your browser of choice is Chrome, Safari, or Firefox!). When you have all that set up you can make edits to your files and have the changes display instantly in the browser. Even better if you are doing css and js changes the page will only load the css or js file. As such it is like using firebug to tweak properties except that you can do it in your IDE of choice.

I got this to work fine on Drupal 6 but I ran across a bit of a problem using Drupal 7. I was not sure what the problem was but eventually tracked it down to the fact that LiveReload will not work with css files imported using @import. As anyone who has been using Drupal 7 or following its development knows Drupal 7 uses @import extensively to get round the IE 31 link/style tag limit.

LiveReload has such a positive impact on my workflow that I was not going to let something small like that stop me using it! After a little bit of digging around I came across a solution to the problem.

Thanks to the new hook_css_alter it is easy to change the properties of a css file. So something simple like this

function MYTHEME_css_alter(&$css) { // Alter css to display as link tags. foreach ($css as $key => $value) { $css[$key]['preprocess'] = FALSE; } }

will render css links as a link tag rather than a style tag with @import. Perfect! It works because the default style if you do not preprocess is a
tag. You can dig into to drupal_pre_render_styles to learn about how css files in Drupal 7 are rendered.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web