On my latest project, I was faced with a challenge: build Flash widgets that displayed dynamic data and could be embedded on any web page. Phase two of the widgets called for user interaction with the widget, as opposed to simply displaying content. It seemed that Flex would be the most logical technology to use for this project.

I used the Services and AMFPHP modules for Drupal to expose content via web services for my Flex widget to consume. However, I ran into a problem with the critical piece that Flex needs in order to get remote data. As a workaround to the browser security settings that prevent cross-site scripting, Adobe chose to implement an opt-in solution in the form of a file called crossdomain.xml. With crossdomain.xml, a site owner may allow a list of domains to read its data and the client, Flash in this case, is responsible for enforcement. As the business case for the project called for the widget to be embedded on any domain, I needed to use a promiscuous crossdomain policy, allowing access from all domains:

Because of this policy, the widget was allowed to read all data on the site that the user has access to, including any (authenticated) content and (session) cookies. This could easily lead to privacy violations, account takeovers, theft of sensitive data, and bypassing of CSRF protections.

Other domains in a similar predicament have simply hosted their APIs on a different domain, thus preventing access to user data on the root domain. Unfortunately, the nature of Drupal doesn't allow for splitting the Services functionality out from the rest of the platform.

My solution was to write a forwarder, which is just a really simple PHP script, that is hosted on a subdomain. This subdomain hosts the promiscuous crossdomain policy, and the policy file on the root domain is configured to only accept requests from the subdomain. The forwarder does two things: it first makes sure that only requests to /services/amfphp are allowed; if allowed, the $HTTP_RAW_POST_DATA is sent to the root domain via cURL.

Because the subdomain doesn't host any data at all, the security risk has been removed. If you are working with Drupal and Flash remoting, you'll need to consider the risks associated with promiscuous crossdomain policy files. While my solution certainly isn't the only solution, it is pretty effective and simple.

My niece, Brynn Doughty, played a wonderful piano piece for a recital on June 12, 2008.

Drupal is incredibly flexible, but in current versions, lacks the ability to export content easily in the form of widgets. However, the Services module gives you that flexibility in a very easy to use manner.

Services allows you to expose pieces of your Drupal site, such as user, node, and views methods. Combine this with the integration of AMFPHP, you can build some extremely fast Flash and Flex widgets that display dynamic data and can be embedded on any website.

However, there is a catch.

I was working with another developer on a Facebook application that displayed my Flex widget, and it seems that in Facebook, you have to provide a static image for the user to click on in order to active the flash. This is clunky, and not the ideal solution for me.

Another option was to attempt to create cross-domain javascript widgets. I looked at JSON Server, which is a Services wrapper that returns data in JSON. This module worked great on the same domain, but failed on cross-domain calls. The reason why is that the module only accepts POST requests.

I ended up patching the module to accept GET requests structured in the following manner:

You'll note that I am doing script tag inserts into the head of the calling website. The script source is set to the path of my JSON server, with the services method as a parameter. The services method takes arguments, which differ depending on the service you are calling. In the case of the Views.getView service, you have to supply the name of the view to call.

The last parameter specifies the name of your output function. My patch takes this callback and wraps the JSON-formatted data returned by the service with the name of the callback. The callback is extremely important, as the JSON sent back by the server acts as a call to your defined callback function. From there, your callback function can display the data however it chooses.

Implementation of this method on a remote site is very easy:

For my widget, I created a custom service that returned the output of a theme() function to render the widget template. This html output was then displayed by my JSON callback function.

Using the Services and (patched) JSON Server modules for Drupal, you can quite easily set up cross-domain javascript/html widgets that can be embedded anywhere.

I have found PHP nirvana in a box.

I was trying to debug the lastest dev version of the userpoints module for Drupal, and was getting nowhere. The process of debugging PHP is tedious to begin with, but the practice of putting print statements into your code in places you think are likely the problem is a nightmare, and a huge black hole for productivity. Understanding what hooks are getting called and when they execute via print statements is a good way to waste an entire afternoon.

Enter Zend Studio. Their newest version is based on Eclipse, the open-source IDE that ties development in many languages into a single common UI. Zend Studio supports interactive debugging sessions with the server version of its debugger, and the client-server communication allows you to step into, over, and return from bits of code. It tells you what variables are currently in the stack, what the chain of functions is that is being called, and many other useful things.

I have to admit, I didn't come to this point of nirvana without trial. In trying to configure the Eclipse PDT to communicate effectively with the server debugger running on a remote server, I failed spectacularly. I tried a few other IDEs, and found them all to be unacceptable. I even tried Zend Studio 5.5. I was at the end of my patience when I found the newest version of Zend Studio, which. just. worked. Yes, I said it. It just worked, with the exception of changing the default port setting for the remote debugger.

My frustration is gone, I am at one with the code, and I can finally explain exactly what is going on in Drupal - how things get called, where and when they get called, and what the results of each call are.

And that bug with the userpoints module? The problem existed between keyboard and chair.

I have the distinct pleasure of attending DrupalCon 2008, which is being held in Boston, MA this year. This year's attendance has blown out the attendance levels of previous DrupalCons, and it is a testament to the growing popularity of Drupal as a content management system.

The sessions I attended today were:

Design on the Edge of Drupal
This session was principally for designers, and talked about taking inspiration from architecture to build Drupal websites that are anything but standard. The point of the presentation was that a Drupal site does not have to look like a Drupal site, as long as users of the site have an expectation of how to navigate and get around.

Enterprise Theming in Drupal
As the engineering manager for Greenopolis, an environmentally-themed social networking site built 100% in Drupal, this session was very informative. We have thousands of nodes and users, and the purpose of this session was how to take a very large site and segment it thematically for the purposes of monetizing your audience.

Mapping Business Requirements to Drupal Modules
This session covered the basic problem of taking what the customer has asked you to build, and applying a development planning process for meeting those business goals.

Drupal Multimedia
As I continue to work on Greenopolis, one of the challenges I face is how to implement multimedia, especially in user-generated content. Performance and security are always major concerns, and this session provided a wealth of information regarding the options available to Drupal developers, as well as techniques for accomplishing some of this kind of functionality.

I will be attending DrupalCon on Tuesday and Wednesday, and post more information as the conference progresses.

I finally broke down and bought a cellphone.

Nothing fancy, just a Sanyo SCP-3200 with Sprint as the carrier. There is nothing spectacular about this phone; it's got basic functionality, it's small and lightweight, and is a good solution for someone who doesn't like to talk on the phone in the first place.

Sadly, this phone had an unfortunate interaction with the inside of a toilet bowl, resulting in the white screen of death. Despite having been submerged in water for less than two seconds, the screen was completely shot, a victim of "massive water damage."

Fortunately, the screen was the only part of the phone that was damaged, but it could not be repaired, so I purchased a new phone of the same model. My new problem was how to get my contacts and other data off the old phone. Stupidly, I went to Radio Shack to purchase a data cable for $9.99. The data cable came with the HandsetManager software, which the manager at RadioShack said would help me retrieve my data from the broken cell phone.

Much to my dismay, the manager did not know the product he sold me, or else he would have known that the software does not support my phone. After searching the internet for a few hours, it became clear that a lot of people did not know how to connect their computer to the SCP-3200.

One tip led me to DataPilot, which is not free. Despite paying for a data cable and software, I had to shell out another $39.95 for the DataPilot software, which was risky considering the fact that I had no idea if it would work or not. Out of the box, this software did not support my phone. I had to update the software several times and from several different places before I could finally connect to my phone. Once I was able to do that, the software did a good job of reading the data from the phone, allowing me to edit the data and save it to my computer, and then send the data to the new cell phone.

The user interface is not the best, being neither intuitive nor visually appealing. However, it is very functional software, except it does not support ringtone editing on my phone, or photo editing. These pieces of missing functionality don't bother me though, as I use neither function on my phone.

So the bottom line is, if you need to connect to a Sanyo SCP-3200 cell phone, one solution is to purchase a data cable and DataPilot, and make sure you update the software after purchasing it.

tags: datapilot, handsetmanager, radioshack, scp-3200, sanyo, sprint, cell+phone, water+damage

I've been working on a Drupal module that generates a search form and presents the results below the form. However, I ran into a strange issue where the database query returned 3 records, and yet, the pager was displaying 9 pagination links.

The code that builds and handles the query looks like this:

After banging my head against the wall for a few hours, I came across a post by Kris Buytaert which explained why I was seeing this problem.

To summarize, the code that produces the pagination links is in pager.inc. Within this code is this bit:

You'll note that the pattern matching is case insensitive. As my query was written all in lowercase, the pagination code was not matching anything. All I had to do was rewrite the query such that the MySQL keywords were in uppercase.

A bug, to be sure, considering that the SQL Standard does not call for specific case. As pager.inc is part of the Drupal core, hopefully it will get patched and fixed soon.

I recently built my first module for Drupal, which exposes data from the Userpoints module to Views. There was some talk with the CEO of my company about releasing the module to the community as a contributed module, and some hedging about whether to release it or not.

Releasing modules shouldn't even be a topic of discussion within a company. The work I did on this module was built off the many, many, many hours others have spent on Userpoints and Views. In addition, thousands of developers contributed to, and continue to contribute to Drupal. For a company to even consider taking an Open Source project, developing a feature on top of it and then not releasing it, is rude and insulting to all the developers that have work on this OSS project.

Companies who use Drupal and other open source software have directly benefited from the work of thousands. These companies have saved gobs and gobs of cash by stating with Drupal as a base and then building on top. That base was built by ordinary people, and that base depends upon people contributing their code.

Credit should be given where it is due and if your company has sponsored the development of Drupal modules by paying your salary, that should be mentioned. At the very least, your company's name can be in the module itself with the README file and within the code.

Again, this should not even be a topic of discussion. If you work with Drupal and extend its functionality, release the code to the community.

I have found that the core Drupal profile module provides very limited customization possibilities. However, the Usernode and Nodeprofile modules help out immensely with this.

If you want access to custom user profile fields, such as CCK fields, you simply load the profile:

Drupal is a fairly flexible system as far as CMS applications go, and is even more flexible as a development platform. The Views module gives developers ways to dynamically build queries of data, and display that data in many different ways. Sometimes, however, you want to display views in ways not supported through the admin interface. Fortunately, there are other ways to get the job done.

For example, I have a block in my sidebar where I want to display a list of the latest blog post, latest forum topic, and latest user poll. Each of these lists can be created as separate views. However, there doesn't seem to be any functionality, either in the Views module or another third-party module, that allows you to display multiple unrelated views in a single block. So, we turn to the code. The Views API provides a mechanism for building and displaying your views anywhere in your templates:

and

Clearly, the views_get_view() function retrieves the view definition from the database, while the views_build_view() function renders it.

Back to my example - I simply created a new block, and set the input format to PHP. Then, I used the following code to populate the block with the views:

The above code shows the rendered view. However, there are times where you want or need to do some additional processing on the values returned by the view. Fortunately, the Views module is incredibly powerful, and has a ton of options for retrieving the views.

In the above example, the first argument to the views_build_view() function is 'embed'. There are several other options:

• page - Produces output as a page, sent through the theme. The only real difference between this and block is that a page uses drupal_set_title to change the page title.
• block - Produces output as a block, sent through the theme
• embed - Use this if you want to embed a view onto another page, and don't want any block or page specific things to happen to it.
• result - Returns an array of information, including a database object that you can use db_fetch_object() on
• items - Returns an array like resul, however, it contains an array of objects found by the queries, so you don't have to fetch the objects yourself.
• queries - returns an array, summarizing the queries, but does not run them

This information comes directly from the code, and hopefully, it will be of some assistance to people who are looking for this kind of functionality.