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.

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.

All it really needs to do is hand off the form_state back into storage, rebuild the same form, and use part of the storage array as the default value of the editor field.

This one is really going to send shockwaves through the Drupal community

As far as I can tell, the only way to do this is to write the R output to a temporary file. So to start off, I create a new temp file with:

This function, in case you’ve never seen it, creates a file with a random name in the directory specified by the first argument, with the extension specified by the second argument.

Next, I loaded up some R. Here’s what I did:

First, you connect to your database in R. This is a lot easier than trying to pass in a result set – you could use JSON to do this if you really needed to. But R runs MySQL queries just fine, and puts them into neatly accessible vectors. Don’t forget to load the RMySQL library before doing your queries. I believe this comes with the standard package of R.

One word of warning – be careful of using the $ sign in your R code string. There may be a way to escape it, but I couldn’t (quickly) find a way to use this character without PHP trying to parse it as a variable. Fortunately, R has substitute ways to access vectors of a dataset.

Here I’d like to point out that R has a unique functionality that makes it better than PHP for manipulating and traversing raw data. Without having to write a loop, R has functions that can create new vectors out of the matching values of existing vectors, like this:

This command means “assign the second vector of dataset ‘data’ where the ‘x’ vector equals $a, to variable x.”

After loading the rjson library, you can turn your output, in this case a T-test, into JSON notation. JSON is a special format that makes data readable by PHP and Javascript as an object or array. Finally,

writes the JSON output to the temp file we created. But none of this has been executed yet. So let’s say:

First, this runs the R code as a UNIX command on your server. Then, it reads the contents of the temp file and JSON decodes them. The second “true” argument of json_decode returns the data as an array rather than an object. This is important because R will often name its properties with spaces and other illegal characters for object properties in PHP. There is probably a way to escape or change these characters, but I couldn’t find it. The array will work just as well as the object though.

I thought this was pretty cool. Using this method, you could run statistics on anything in your database and display it on a web page. This seems like a clever way to display usage statistics to site admins, and actually give them an idea of whether the results are statistically significant.

Drupal’s user interface has a steeper learning curve than that of WordPress. Users of WordPress are mostly bloggers, so the interface emphasizes a small set of the things bloggers need to do most frequently, like writing new posts, editing/deleting old posts and viewing statistics. The dashboard aggregates these high-use panels as a default landing page after authentication.

Users:

Drupal users have more diverse needs than just blogging support. Drupal provides more flexible layouts (panels) and information displays (views) than anything in the WordPress framework currently has to offer. An inexperienced, non-technical user would probably give up long before they got Drupal to do anything like what they wanted, whereas the default post-management behavior of WordPress caters to the goals of users who want to spend more time creating content than managing it.
I believe the fundamental difference between Drupal and WordPress is that Drupal fulfills the needs of developers while WordPress fulfills the needs of end-users. This means if you are developing WordPress plugins, you’re developing software for normal people, and if you’re building Drupal modules, you’re developing software to help people build websites for normal people. Not to say that people don’t hire WordPress developers to build custom sites, but if you want a site that features a non-blog-like information architecture or layout, a Drupal developer will be able to build your site cheaper by spending less time.

Extendability:

Drupal’s information architecture is more abstracted and more extendable than that of WordPress. In WordPress the post is analogous to a node, but no one has gone as far as to create a data-structure in WordPress that is as infinitely extendable as Drupal CCK. The closest WordPress has is a post metadata table, which really doesn’t come very close.