I recently attended an inspirational Open Source event. This was kindly hosted by Brighton company Omnis Systems. It was really inspiring to see the range of Open Source systems available as alternatives to the usual proprietary offerings.
A central theme of the day was privacy - despite all the recent revelations over the past couple of years, I think we're still unable to grasp the full meaning of the shift towards proprietary systems on the cloud and what this means for privacy.
We recently had a requirement to add a sign up form for a series of events. We've produced a number of bespoke solutions in the past which required a fair amount of coding but this use case was for a straightforward generic event registration procedure so it seemed obvious to turn to one of the standard Drupal modules to do this.
CGL is a social care & health charity working throughout England & Wales with clients that are affected by drugs, alcohol, crime, homelessness, domestic abuse & antisocial behaviour. It is a large & growing organisation.
We've written a huge number of forms over the years (mainly using PHP or Symfony) and can pretty much produce most customisable forms that are required. But using Webform within Drupal has been a real game-changer for us. While we'll still create custom code for some specific form tasks, I'd say that Webform answers at least 50% of the typical use cases that face us on a daily basis.
When you are new to a technology like Drupal, it can be difficult to find your own learning path. Coming to Drupal with a PHP background, I reached for the top shelf & grabbed the heaviest-looking manuals available. I dived straight into coding. In retrospect, while this felt like a shortcut into the dark interior of Drupal at the time, it was probably a long way round. It was hard to get a bird's eye view of Drupal & all too easy to lose the thread of what I was trying to achieve.
Sereno has been migrating a Drupal 7 intranet of several thousand content items from a menu-based system to one using taxonomy tags. We looked at coding the migration, but found a much quicker route using the Views Bulk Operations module (VBO) to crunch through the menu items, allocating each & every one anew taxonomy tag based on their pre-existing menu.
Git makes me happy in controlling the versions of a project's code base & allowing you to recover from wandering off in wrong directions.
But when you want to throw away some ill-considered changes to your code on your development machine, git can obstinately refuse to 'pull' from your repo. Try to do a git pull & you'll get an 'error: Your local changes to the following files would be overwritten by merge: ...' If you want to throw away your local changes and re-sync with the repo (yes, you'll lose any commits since your most recent push), you can do this:-
In this post I wanted to highlight our recent experiences developing an intranet in Drupal.
In this it has been really important for us to not over-engineer our solution as our client is currently undergoing a major restructure - so while the need for a new intranet was pressing, this has to be built during a period of great organisational change. Having developed many applications over the years in different technologies, I was naturally a bit apprehensive about the impact of changing architecture on the build.