Foggy Perspective

Throughout a development life-cycle code may move between various environments (e.g. Development -> Integration -> Staging -> Production), however we may not want every environment to have the exact same setup. An example of this might be that on Staging and Production we have CSS / JS aggregation enabled along with caching. On a Development environment we may want both of those disabled. The database connection is also going to be different on each environment.

It's been a while since I've had time to share my Drupal experiences with the community. New additions to the family, moving, and a large / length Drupal project have taken up my time. Hopefully things are easing up a bit and I'll be back to sharing.

Have you ever noticed that not all elements rendered on the user account page are visible on the user account -> manage display configuration page?

This past weekend I had the pleasure of attending DrupalCamp Asheville.  It was a great time to see some old faces and meet some new ones.  For me these events are less about the sessions and more about the other Drupaleers I get to meet in person.  

Entities are a new and exciting concept in Drupal 7 and a few modules are starting to make use of them. A co-worker (Scott) of mine has recently jumped on the Drupal bandwagon. He's been reading up on the Drupal development books and creating custom modules. A new module that he was working on created a new entity type. Great! Not a problem, the Drupal books and online docs provided pretty detailed steps. We ran into a wall however when we attempted to theme it. The documentation was lacking at this point and looking over contrib modules that created entities didn't provide any entity theming examples.

Scott started digging through the code and eventually figured out how to accomplish custom entity theming.  Even better, he contributed his findings to the Drupal online documentation.  Win Win!

You can learn more about the solution he found on his blog post.  Just don't give him too hard of a time about his blog running on Wordpress.  :-)

I work quite often with Drupal doing various tasks like setting up temporary sites to test out new modules, develop custom modules, and demo Drupal's capabilities to clients and co-workers.  For years I've done this on Windows-based machines.  I've found over time that I spend quite a bit of time doing tasks that I have very little interest in, just to get to a point where I can enjoy working with Drupal.  Some of these tasks include:

With the recent transition for foggy perspective from posterous to drupal 7 one of the features I lost was the ability for readers to subscribe to comments.  The comment notify module has recently released a D7 version so I've installed and enabled that.

Now all I need are readers and commenters.  :-)

I'm fairly comfortable with installing Drupal having done so many times with D6. When the D7 release candidates came around I wanted to get my feet wet so I threw up some test sites and eventually moved this blog to D7.  Everything had gone fairly smooth and I've been monitoring the logs to catch redirects, etc. that I needed to setup.  One log entry that I noticed was there was an issue with my cron running.  Ok, no problem.  I headed to my host and checked on my cron job.

Wow... I've been busy the past few months and haven't had a chance to post any drupal goodness.  I've been wanting to get back into that habit and drupal 7 provided the perfect opportunity. Up until today I had been running my drupal blog on posterous.  Posterous has served well this past year.  And while I'm all for choosing the right tool for the job, it probably makes more sense for me to use drupal for a drupal blog.  :-)  

On a project that I'm working on, a situation has arose where the client wants to display content that is both generated directly on their site and sourced from external sites (i.e. feeds).  To the end user this should be a fairly seamless experience and there are a couple of solutions that should satisfy this requirement.

Concepts to keep in mind.

• Integration of home grown content and content from external sources.
• Provide as seamless a user experience as possible.
• Some sourced content (via feeds) may only contain titles and / or teasers.
  

In an earlier article I described how we can create a drupal block to display a twitter profile widget.  This earlier method would use PHP in the block to evaluate the node each time and check if a twitter account existed.  It works great but there are other alternatives I wanted to explore.

Yesterday I started using the computed field module.  This is a CCK add-on module that executes PHP code during a node insert/update and (optionally) stores that value in the database.  I say optionally because I believe you can also set it to evaluate PHP on the fly, however for something like a twitter widget we don't need to do this dynamically.  Once the widget information is stored in the database we only need to display it.

So the objective here is to use the computed field to check if the node contains a twitter account.  If it does then we simply compute the widget code and save it.  If not, we leave it blank.  So let's get started.