The list below is comprised of the projects for which I did heavy feature development or ground-up implementations. I filled the support role for nearly all of the projects listed in Switchback’s portfolio.

Midwest Eye-Bank

Midwest Eye-Bank (MEB) needed a way of organizing their internal documents – a replacement for a simple ftp server that had been used previously. Drupal offered the opportunity to allow for advanced searches and metadata, more comprehensive group management and a better overall user experience.

We used Drupal 7 for MEB. We contributed testing notes and bug-fixing patches for a number of Drupal core/Organic groups issues during development. File security was an important issue, so we wrote some custom code to handle securing file downloads from private groups.

Wunderground Module

Weather Underground offers a comprehensive weather reporting web service that draws from thousands of personal weather stations around the country (you can think of them as “open-source” weather). Their Drupal module was in need of an upgrade. We created several new blocks that let users better leverage the power and detail of the Weather Underground data.

Under-the-hood improvements included multiblock support and locations integration. We aimed to provide the most comprehensive weather information module for Drupal. These enhancements are currently found in the dev version of the Weather Underground module, pending the maintainer’s merge into the main branch.

Bgreen Today

Bgreentoday.com sells sustainable building and restaurant materials. Their site is an attribute-heavy ubercart implementation, the main catalog being views embedded on template-overridden taxonomy pages.

This project involved fairly complex data migration of products with attributes and overlapping taxonomy terms. Special url handling was added so that products would automatically generate multiple aliases if they appeared in more than one root taxonomy section.

Traverse City Chamber of Commerce

Switchback’s Civicrm-Drupal package powers tcchamber.org. We added enhancements to the membership process, administrative interface, search functionality, event discounts and mass email. Many of these features were contributed back to the Civicrm project.

A few years ago, I joined the Scrapwalls team as a PHP and front-end developer. One of my first tasks was designing and implementing the checkout user interface, which has since helped to provide a steadily increasing conversion rate. Scrapwalls has grown from a simple collage-making tool into a successful business, integrating seamlessly with PayPal, various printing API’s and Facebook.

Scrapwalls is a handbuilt PHP application that uses the Smarty templating engine, jQuery and cross-browser compatible XHTML to deliver its user interface. During much of my time, I focused on creating the three-step collage creation process. The challenge here was to provide an interface that allowed users to complete a relatively lengthy and complicated task with a minimal amount of confusion. We decided to break the process down into smaller steps, with concise yet descriptive titles, icons and instructions.

Later, I turned my efforts to the design of the shopping cart and checkout sections of the site. We did a survey of successful e-commerce sites in order to find at set of established and trusted design patterns to use, while rethinking certain features that seemed unique to Scrapwalls, such as collage previews on the shopping cart page which weren’t always ready to view by the time a user reached that page.

Soon we realized that we could add significant value to Scrapwalls by allowing people to import photos from Facebook. After learning a bit about the Facebook graph API and FQL, I was able to put this feature together so that users do not have to go through the lengthy process of uploading photos if they already have them in Facebook.

A good introduction to dynamic views is the function views_embed_view(). Using this, one can render the finished display of a view stored in the database or in code. It returns rendered HTML:

Often this function is a good alternative to using views blocks, for situations where the view display should be more tightly integrated in a certain area. By using func_get_args(), views_embed_view lets you pass arguments into the view that would normally have to be in the URL.

However, there are situations where views_embed_view just won’t cut it. Here are some examples:

1) The user needs be able to choose what filters/fields exist in the view.
2) Groupings need to be dynamically generated based on user input

The functionality listed above cannot be achieved merely by passing arguments into the view. Rather, one must employ methods of the View object ([views module]/includes/view.inc) in order to build up elements of the view from the foundation.

This approach starts with the function views_get_view(). This function loads a view from any storage, but does not execute or render it.

Now comes the most important function to master, View::add_item(). The code is in views/includes/view.inc. The following snippet demonstrates how to add a node id filter to a view named “example.”

Here is a breakdown of arguments found in View::add_item:

1) display id
2) type – can be filter, relationship, field, sort
3) table – can also be table alias
4) options – see below
5) identifier – an internal reference to this filter, useful for establishing predictable dynamic keys for fields/filters/relationships that may get added twice. If you don’t pass anything for this argument, Views will create a unique id using an incremental variable if necessary.

Here is a breakdown of the $options argument, at least that of it which I have used:

1) value – meaningful only to filters. Specifies the conditions that will pass the filter. This can be an array in order to imply the IN operator
2) operator – may assume any of the standard db operators. It is not necessary to specify IN if you provide an array as value.
3) relationship – specifies a relationship for this item to use. Remember that doing this will require that you change the table alias to reflect the relationship table alias.
4) group – filters only. Specifies a group for this filter to be a part of. Numeric or string values will work.

The majority of the work can be done with the add_item function. If I were to choose one more important method to learn within this subject it would be set_option(). Suppose you have defined several filters as being part of groups 0 and 1. Here is how you would use set_option to tell Views what to do with those groupings:

This snippet would create two conditional groups, 0 conjoined by OR and 1 conjoined by AND.

Set_option is a method of the views handler, not the view. It can be used to set any of the other characteristics defined the in the options element of the handler. It can do the same things as add_item but add_item performs additional procedures that help things come out the way you want (in most cases) and is definitely more useful for adding filters, relationships, fields and sorts.

Once you have your view prepared the way you want it, you need to execute and probably render it. The following code will do just that:

There is a lot more you can do with dynamic views than I have outlined here. Generally, the best way to learn more about this is to first use the UI to build a view that contains the elements and characteristics that you want to dynamically add in your function. Then look at the export of that view. You will gain a good understanding of what the $view object and its display handler need to look like in code. Having a PHP debugger is also immensely helpful, but short of that, just use dpm liberally.

The bottom line is that at this time, Drupal 7 development takes a lot longer than Drupal 6 development. There are benefits of course. To me, Drupal 6 is already starting to seem cumbersome and antiquated at the architectural and UI levels. Many of the Drupal 7 features and modules are way ahead of their Drupal 6 counterparts: Commerce versus Ubercart, Field api versus CCK, Entity API versus, well, nothing … and et cetera. Soon Drupal 7 will be better supported than Drupal 6, but right now, it is not.

Module update lag now overshadows the benefits of using Drupal 7. I would recommend that the novice PHP/Drupal API developer not use Drupal 7 at this point in time, because the likelihood of having to debug/patch complex modules or implement functionality with little or no documentation, is high. Also, module interactions are fluid and brittle. In order to get a D7 site working that uses Views, Entity API and Date, you have to install and maintain a changing cocktail of dev, beta and RC versions. Using the wrong combination will earn you a site full of undefined function errors. Suffice it to say you had better know how to disable modules in the database before attempting to use these modules.

These issues should not daunt skilled developers doing work for clients with large budgets. Drupal 7 development is fun and challenging. A little bit of code goes a long way, especially when working with the entity and field API. Also, at this stage in the game, you may get a chance to write some code for the big modules or for Drupal core, because it is likely that a bug in one of these large codebases will block your way at some point and you will have to either fix it or wait for someone else to do so. One word of warning, if you are a Drupal developer who has hitherto avoided learning about Object Oriented programming (I mean beyond insofar as objects are the same as arrays in PHP), now is the time to put aside your trepidation and learn at least a little bit about class inheritance, interfaces, abstract classes, protected properties and other structural conventions for OO. Many of the big modules (Views, Rules, Entity API and others) make heavy use of OO now.

On the user interface side, there are two modules that are important to learn for Drupal 7: Rules and Features. Spearheaded mainly by Drupal Commerce, there seems to be an initiative for making rules events where there were once hooks, with rules action instances taking the place of hook implementations. Indeed, Commerce appears somewhat inert until you realize that most of its more advanced features are configurable as rules. If you want to write a module that adds functionality to cart events for example, you will find rules event invocations rather than module hook invocations. Fortunately, rules and hooks function similarly; the difference being that while rules are are more complex to configure in code, they, unlike hook implementations, can be customized and created in the UI and exported as Features.

As Rules becomes more central to the average Drupal consumer, the Features module gains significance too. Rules are beginning to describe increasingly complex procedures and business logic previously defined in module hooks, and only through Features can this functionality be packaged and reused abstractly. Features documentation is abundant and mostly good due to the fact that Features hasn’t changed much since Drupal 6. My only advice is to get to know the drush Features commands: drush fr (feature revert), drush fu (feature update), et cetera.

Bear in mind that as the timestamp on this post slips further into the past, Drupal 7 will have gotten better and the things written here will be less true. Until then, heed this advice: 1) introduce a healthy time/budget buffer in your Drupal 7 estimates, 2) be prepared for programming challenges, 3) do not expect everything to “just work” like it did in Drupal 6 and 4) use forums, issue queues and IRC to your advantage. The good thing is once you get into developing with Drupal 7, you will realize how much better it is as a framework compared to Drupal 6. My guess is we have about a year to wait before the old, important Drupal 6 modules are fully upgraded, and the community can return to relying on a large canon of feature-rich and largely bug-free modules.

Quickbooks is the event horizon – you have know idea what it does with your SOAP responses once it takes over. It is poorly documented and the Intuit developer forums are essentially derelict. Before we could even tackle the problem of getting the response data structures right, we had to make sure our SOAP server was working right. Packet sniffing was not an option for investigating our server’s responses because QWC needs to use SSL. Instead we wrote the output of the SOAP server instance to the output buffer, and logged it:

Output buffers direct the http response away from its destination and into a “buffer” where it can be retrieved later with ob_get_contents(). Using this method we were able to verify that our SOAP server was sending proper (looking) SOAP requests.

The random Javascript in example.php is important

It took me a while to realize this, but you will have problems detecting a browser’s Facebook login status if you don’t have something like the following in your page:

This is from example.php in the PHP SDK. Basically this detects if the login status has changed, and reloads the page if it has. Your site’s server can’t see Facebook’s login cookies, so this snippet ensures that when the browser session changes, the pages gets reloaded. This process isn’t asynchronous (that would be cool) but simply adds an extra refresh to a page load where it detects a changed FB session. It is a bit weird, but as far as I could tell this is the only way to get it to work.

FQL is faster than the Graph API

Facebook’s graph API reflects their current “no-sql” storage and retrieval approach. Through the graph API you see Facebook information as objects connected non-hierarchically through common id references. It is great for jumping from node to node but not so great for getting sets of nodes of one type attached to a user – e.g. “get name and url of all photos belonging to user” or “get all friends of user with IDs in a set.” For these “old school” queries, a SQL-like language is best, and that is why Facebook still supports FQL.

If you understand the basics of SQL, you understand FQL. FQL uses the simplest faculties of SQL (no joins) to query for specific field values within Facebook’s data store. The big advantage is it returns only as much info as you need. Responses from graph API calls are often huge and can cause slowdowns when requests are fired in a long loop, which is often necessary due to the nature of the graph API.

Don’t forget to install the cert

This is probably in the directions somewhere, but I wasted some time not realizing you have to put fb_ca_chain_bundle.crt in the same dir with facebook.php.

Overall impressions

The most annoying thing I ran into was right at the beginning of the project. Over the span of a few days, I tried to register the app five or six times and was unsuccessful. At the time there was a lot of buzz about this. I don’t know how long it took for them to fix, because fortunately I realized one of the other developers had registered an app for us a year ago. Old apps seemed to still work fine, but the registration bug kept new ones from working for at least two or three days.

But hey, you have to take the bad with the good. The SDK is a well written class and provides everything you need to make API requests efficiently. I couldn’t imagine using the REST API without the SDK. On the browser side, the Javascript SDK has what it needs, and most importantly work well with jQuery.

Mostly I was just struck by the richness of the information that these APIs expose. I can see clever people writing apps that gather tons of information and analyze users’ lives on Facebook, which today reflect quite accurately the ways in which people perceive themselves and are perceived. The security/privacy situation is attrocious, and it made making the app a lot easier. I worry about the potential for powerful corporate and political entities to gather information about individuals and groups – if the governments of Libya or Egypt had been effectively monitoring the revolutionary mentality as it developed on Facebook, they could have probably mounted a preemptive crackdown.

But insofar as code is apolitical, I say the Facebook APIs are a hit. Check out Facebook import on scrapwalls.com.

Fortunately, I came upon https://github.com/douglascrockford/JSON-js/blob/master/json2.js, a handy library that gives you variable.stringify(). This will output a string of JSON representing your variable. I simply used this method to create a JSON string for the data I wanted, and used jQuery to set this as the value of a hidden input. Adding a json_decode() on the server allowed me to read this data directly as a variable.

This method can be pretty useful if you are collecting object oriented data asynchronously and hoping to send that data back to the server. It seems like it ought to be built into jQuery at some point.

Cogito ergo sum essentially represents a logical rule. It is steeped in the proposition that if an object has a property, then it exists. Usually this proposition is meaningless: it is impossible to know if an object actually has a certain property because our perceptions are subject to error. Also the distinction between properties and objects becomes obsolete in the context of perception because we only perceive objects by their properties. If we did not perceive the color, shape or texture of a red chair, we would not perceive it at all. However, Descartes argued that the process of thinking, or the possession of the property of being a “thinking thing,” was something that we could squarely define as belonging to our consciousness.

Although I have wrestled with this proposition for many years, I have never been able to refute its truth. The presence of experience is the one thing that human beings know empirically. This is our one bit of knowledge, a kind of disembodied truth that we know is more than nothing but that we cannot even begin to define within a larger framework. Human experience possesses myriad internal states and possibilities, but all we can say about it from an outside perspective is that it represents something and not nothing – a 1, not a 0.

Descartes succeeds in bringing human experience beyond the subjective in most possible worlds except the most sollipsistic, where one’s own experience is everything and thus nothing is beyond the subjective. But in such a world there is no need to justify one’s own existence because it is assumed to be all-encompassing. In one of his central arguments, Descartes states that the irrefutability of the Cogito made it possible to rationalize our faith in our experience as being “real.”

I disagree with this proposal of Descartes, that the truth of the Cogito lends truth to propositions that exist within the closed system of our experience. I believe that cogito ergo sum is valid, but I also believe that it is a sophism – a statement whose truth is an illusion made possible by a logical trick. For the cogito to have meaning, the I that thinks must be the same I that exists. So what is the I that thinks? Truly, we know nothing about the I that thinks except that it thinks. If we knew anything else for certain, for example that we were walking, we could say ambo ergo sum (I walk therefore I am). But walking is a property knowable only through our error-prone impressions.

Moving across the word ergo, we find that the existence of our consciousness is steeped solely in its being a “thinking thing.” We are ignorant of all properties of our existence but this one. We do not know if our consciousness is connected to a body, or if its perceptions point to a reality that exists independent of our observation. The ontology of human existence is limited to one proposition: we possess thought; cogito. After refining our definitions of its terms, the Cogito provides us with a tautology: I think therefore I think, or I am therefore I am.

Really my struggle should have been less epic. Quite simply, if you have MAMP, don’t try to install xDebug in your MAMP Apache instance. Why? It’s already there! Just put this in your php.ini (the one in the MAMP instance, probably something like /Applications/MAMP/conf/php5.x/php.ini):

If you are trying to install xDebug on a linux machine, or Windows, there are tons of instructions accessible via easy googling, or on the Xdebug site.

If you are special like me, and managed to overwrite your original MAMP copy of xdebug.so, don’t try to re-compile it. Instead, if you find yourself down this path, simply find your original MAMP download, grab its xDebug.so and throw it where it needs to be (somewhere relatively close to the url after “zend_extension” up above). I tried to compile my own xDebug.so, but the MAMP instance of phpize would not run correctly on the Xdebug files.

Xdebug is great. I have no complaints, but bear in mind I am ecstatic about simply getting any PHP debugger to work. So far, Netbeans is my favorite text-editor/IDE. It has better usability than Eclipse and is faster and more reliable than Aptana. The only annoying thing is that it opens too many browser tabs while debugging. It makes a new tab for every session, as well as a whole tab for a “session ending” message. Integration with Growl or some other ambient notifier would have been better.

Scrapwalls is a web application that lets you make a shape collage out of your pictures. It is written in PHP using the Smarty templating engine, and uses VIPS C++ library to manipulate the images. Scrapwalls has been around for a few years, but only in the latest release can you purchase high-resolution posters of your collages. The test orders have gone through correctly, and we’ve started promoting the site on Google and Facebook.

Please give us feedback if you end up using the site, by emailing me or commenting on this post.

Anyway, we are excited to present scrapwalls.com to the world!