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.
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.
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.
When organisations look to rebuilt their intranets, the obvious tactic - or 'strategic leap' - is to revolutionise design and structure and develop a brand new and improved experience for users. While this is clearly the most impressive approach in terms of demonstrating improvement and change, it is probably the worst way of effecting real improvement and productivity gains for users and the organisation at large.
I have recently switched development environment from Mac to Ubuntu. By and large this has proved a really positive experience as I can so closely match my development machine to the production servers we run. I ran into one sticking point during set up - configuring Netbeans to compile SASS. This ought to be straightforward and it is, although I couldn't find any clear documentation. So to save anyone else similar pain, here are the steps I went through to get my set up working.