Drupal
An Awesome Drupal Search Experience with ApacheSolr
December 14, 2009 - Katherine Bailey
We recently implemented a complex search solution for a client that wanted content from all of their various web properties (built on a multitude of different technologies) to show up in the search results on their main Drupal site. We chose to use Apache Solr for the search functionality for reasons relating to the Solr search engine technology itself, such as its speed, faceting and spelling suggestion capabilities, but also because of the excellent integration with Drupal, in the form of the ApacheSolr Integration module.
FEED09 Finds That Digital Experiences Create Customers
December 09, 2009 - Jordan Willms
"How do consumers engage with brands in an increasingly digital world?" is the question, that the FEED09 report published by Razorfish, is hoping to answer. If you have the time, the report is well worth a read and is an experience in itself (the art direction on the report is quite comical at times). However, the assumption of this post is that you don't have the time to read it all, and as such we'll boil down what we believe the key takeaways are.
JavaScript in Drupal 7: What developers need to know
November 03, 2009 - Katherine Bailey
An overview of the most important changes affecting the use of JavaScript in Drupal 7.
How to Convince Your Boss that Drupal is Better than Proprietary CMS?
September 24, 2009 - Jordan Willms
In large organizations, convincing your boss or department or project to use Drupal can sometimes be met with resistance. This following table has been instrumental in convincing decision makers regarding why Drupal (and by extension open source) is leaps and bounds better than proprietary content management systems (CMSs).
How The Drupal Services Module Should Be Used
July 15, 2009 - James Andres
I'm embarrassed to say I haven't fully understood the services module, until now. I just found this great example of how the services module SHOULD be used. http://gregbosen.org/blog/drupal-services-php-xml-rpc-example and http://drupal.org/node/394364 Here's a summary in my own words:
- Web services should ALWAYS be accessed with a logged in user
- Create a special Drupal account just for web services, eg: a "services" or "amfphp" user.
- Create a special Drupal role called "Services" that your "services" user is a part of.
- Assign as little permissions as you can get away with to the Services role. This account should not be a "super-user" in case it becomes compromised.
- Now, for the fun part .... here's the CORRECT way to connect to your web services. It is a 2 step process:
- Call the system.connect service. This services exists ONLY to give you a session token. It will return a "sessid" parameter.
- Call the user.login service. Pass the "sessid" parameter you received from system.connect, in addition to the user name and password of your "services" user. user.login will return the UID of your "services" user, if successful.
- Finally, you are logged into Drupal as the services user! Call whatever services you want, don't forget to pass the "sessid" parameter each time.
Nonce's, and keys still apply. Learn more about those here: http://drupal.org/handbook/modules/services
Konigi : Tools and content curator for UX designers
July 09, 2009 - Jesse Korzan
Konigi is a great website for UX professionals and those involved in the design of websites.
We love the Konigi OmniGraffle tools at our office; they are an indispensable tool in my bag of tricks.
Not your ordinary design gallery
I am a big fan of the showcase and blog. They find unique and compelling aspects that deal with all sorts of design problems. It's fast become a daily stop and a resource I'll flag for almost any new project.
Since we use Drupal a lot (like this blog), we noticed it's a fine Drupal install. I appreciate the subtle details, especially enjoying how the tagging is done, nice big images in the postings, and the home page design.
And it's very encouraging to see our own work in the showcase.
What You Should Know About Drupal Contrib Modules
June 19, 2009 - Ronn Abueg
You should know....
Views, Panels, and CCK are the foundation of all modern Drupal sites -- They do all most of the work for you
- tip: Reality check -- build as much of a site as you can using JUST contrib and core. Make sure your first question is "How can I implement this with existing modules like views, CCK and panels? Then, and only then, once you establish a gap, produce custom code. Custom code should only be used if you can prove that you were not able to use Views and CCK to create the equivalent functionality.
- tip: Learn how views export module works. It's bundled with views and allows you to literally turn your views into "versionable code".
- tip: Panels and blocks are a powerful combination. Learn it.
- see: Listing of "Essential Drupal Modules"
- see: Panels Video Tutorial from Oregon state Univ.
- see: Views + CCK Tutorial
Static nodes can be exported using the node_export module
- see: Install Profile API for importing node exports
CCK types can be exported and imported with content_copy module, ships with CCK
- tip: Again, the Install Profile API module makes importing CCK types easy.
i18n + views is the easiest way to build a multilingual site
- tip: Use the views language filters to build language aware views
Image module is one of the longest running, and best supported modules ever
- tip: If you're not using image module to handle your uploaded images, think again.
imagecache module is the long-run simplest way to handle multiple image sizes
- tip: Sure, there's a little configuration pain up front but your site will be extremely flexible
That pathauto is almost always the easiest SEO win
- see: Pathauto tutorial, a fairly good one
logintoboggan module solves 80% of the registration related requests from the client
- see: LoginToboggan Project on Drupal.org
admin_menu module makes administering and building Drupal sites easier and faster It is more attractive that simplemenu (and more logical and Acquia supported!)
- see: Admin Menu on Drupal.org
Managing Taxonomy Exports with Drupal
June 18, 2009 - James Andres
Hi Drupalites, A recurring pain point in my Drupal development has been managing the vocabularies and terms in Drupal. I tried using the Taxonomy XML module, but found it much too complicated for everyday tasks. Without further hesitation I am proud to unveil Taxonomy Export!
What You Should Know About Drupal File Management
June 01, 2009 - James Andres
You should know...
How to manage javascript
- tip: jQuery plugins can be downloaded to sites/all/js for easier management
- tip: Custom plugins should be either attached to a custom module or custom theme. The choice is based on whether the plugin helps a module, or purely acts at the design layer.
- eg: A plugin that adds DHTML UI elements for a block should live in the module that creates the block.
- eg: A plugin that adds DHTML navigation for the site would reside in the theme
What You Should Know About Drupal's Development Only Modules
May 28, 2009 - James Andres
Development modules are great when you are building a Drupal deployment. But, there are a few things you should know. You should know ...
How to use devel to its full potential
- see: Devel Project on Drupal.org
- tip: Enable the devel block for quick access to developer features
- tip: Instead of writing code like var_export($node); use the dev render and dev load pages generated by devel. Just log in as admin visit a node and click the tab.
- tip: Unless you really need it ... don't bother with the query logging features of devel. You should turn on the Slow Query Log in MySQL to automatically discover queries that are slowing down your code.
- tip: Learn how to generate users and nodes using devel. It's REALLY handy and you can quickly create data that mimicks a production environment (Instead of nodes that just say 'test this' and 'test that')
How to use coder module
- tip: Validate your custom modules and themes often to ensure your syntax is Drupal standard.
Converting modules from 5.x to 6.x is not that hard with the deadwood module
How to ensure development modules NEVER make it to live
- tip: Use subversion hooks to delete, yes literally delete, the sites/all/modules/development directory every time you do a live release. This ensures that there is no way these modules can be enabled.
Anything to add?