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.

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.

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

Change line 80 (line 3 in this excerpt) to:

That should make it work. As far as I know, the .htaccess solutions to this problem don’t work in Magento, because Magento encrypts the filename and extension, and the path does not represent a real location.

Note: I usually don’t go around hacking the core files of a CMS, but sometimes I make an exception with deep extensions within Magento because it just takes so darn long to follow the variables through to their various sources in the code. Not that I don’t know how to do it …

By the way, if you’re not using Magento and just have regular paths to your files, put this in your .htaccess:

This is one of the best .htaccess resources I’ve seen and it explains by example.

You can of course change the list of extension if you want. Hope this helps.

Simply provide a seed argument that is an integer that varies based on user input, or some state of your application. This function will output a number between 0 and the ‘maximum’ argument.

I used this to create a simple Javascript game. It could be applied to any situation where you want to present the user with outcomes that feel random but are consistent based on what they do. Of course there are limits to how random these outcomes actually are. But in general it works well enough to give the experience of randomness.

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.

WordPress loads plugins in alphabetical order. So the simplest (and most janky) solution is to name your plugin something that comes after “buddypress” in the alphabet. But there are better methods that you should use instead.

For versions before BP 1.2

The goal here is to check whether Buddypress has been loaded at the point when your plugin loads, and if it has not, load it manually. The manual load will prevent the normal load from happening later, so you won’t get double what you need.

If you are using BP 1.2+

Fortunately, they made this much easier to do in BP 1.2. For my plugin, all I needed to do was:

… in order to load my classes only once Buddypress has finished loading. Probably the safest way to ensure that your plugin completely loads after Buddypress is to create a loader.php file that contains this action and loads all of your other files.

I’ve seen this question come up on a lot of forums – people want to use email addresses as usernames in Buddypress. It makes sense – emails are easy to remember. But Buddypress has made this difficult to do. Andy Peatling added the following constant to the core:

in order to deal with part of this problem. But this did not solve the problem completely. See this article for how to use this. This changed allowed users to navigate to an @-containing username’s profile, but that user could not do things like create groups or edit his profile.

It turns out there’s another step to getting this to work. You have to override wp_sanitize_redirect in wp-includes/pluggable.php and add ‘@’ to the list of OK characters, like this:

Now it should work.