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.

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.

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.

Fortunately it is quite easy to change the way activity items are stored in the database. I’m going to use blog post activity items as an example, but this process is the same for just about every kind of activity item.

The first objective is to find the filter function that you want to hook into. For blog posts, look to line 385 of bp-blogs.php, inside function bp_blogs_record_post(). In general, to find these record functions, search the component core file for the string ‘record.’ This will point you to both the utility function that hands the array off to bp_activity_add(), and to the function that a specific user task initiates to record an activity.

The filter we are interested in is bp_blogs_activity_new_post, in the segment:

Now, in our plugin, or in custom.php, add the following:

Skip to the next heading if you understand filters, or don’t care!

I will take a minute to explain filters, because they are a useful but somewhat obscure concept in WordPress. Filters are like actions, in that they provide an access point into code running in the WordPress framework. Filters are different from actions in that they return a value. It helps to think of apply_filters() as being analogous to do_action(). The first argument of apply_filters() is the tag that an add_filter() action hooks into with its first argument. This is not unlike the relationship between add_action() and do_action().

The second to nth arguments in apply_filters() allow variables to be passed into your custom filter. Try and understand this diagram:

Information flow between apply_filters, add_filter, and custom filter function

Back to the task!

It would be nice if we could edit the individual components of $activity_content, but alas, it doesn’t have its own filter. That’s why some copying is necessary from the core file – but usually this code is pretty short, as you can see. It’s necessary to pass $post, $post_permalink into your filter function so that you can use these values in your activity content variable.

After returning the variable with your formatted feed, guess what, you’re done! apply_filters() will return the value of your function’s return.

Its not too hard, but a big barrier to getting it to work is keeping all of the connections straight. When you have something of this nature wrong it is hard to debug.

Lets make a button that loads a hello world via ajax. Start with whatever input fields you need, and put a wp_nonce_field() underneath. Its a good idea to put all of this inside a form with an action, because you want people to be able to use your plugin even if they can’t run Javascript for some silly reason!

Enqueue a javacript file that has something like this:

We’re doing jQuery here. Basically this hi-jacks the submit button and causes javascript to run instead of the usual post to the action page. Read up on jQuery if this code doesn’t make any sense.

But let me explain a few things about the jQuery.post(). action, _wpnonce and cookie are $_REQUEST variables that Buddypress understands – you must name these properties exactly as you see here. Additionally, their values must correspond to other values set in different places of the Ajax process. I’m going to communicate these necessary equalities in a series of rules. The first one is:

_wpnonce” in the javascript file = id of your nonce_field (the second parameter of wp_nonce_field)

Now its time to write our target php function.

Here’s the second rule:

Bind your target function to an action named after the “action” property in your Ajax Javascript, and remember to add “wp_ajax_” to the beginning

. . . And the third:

Use the first argument (the action) of your wp_nonce_field() on the Ajax initiating template/screen function as the argument for check_admin_referer()

check_ajax_referer is a security thing – you need to do this. At the end of all of this, the message should appear dynamically at the end of your form when you press the button. Keeping the equalities straight is key.

What exactly does this mean? It means that after we’re done, you will have something on the right of your appearance->widgets screen like:

"Groups Sidebar" is not a default widget

There’s nothing special about code that runs inside a widget.

A widget is similar to any other piece of template code, except that widget output is defined by the return value of a special function and class. When you put your custom code into the specified parts of this function, WordPress will treat that code as something that can be run and displayed in a specific widget area, depending on where you drag your widget in /wp-admin/widgets.php.

Usually you want to define a widget area in your theme file. Lets say we want to add a widget area to the groups directory page (/directories/groups/index.php) in Buddypress. First find a place where you want to put your widget area div. For my example, I’m going to make a new div in /directories/groups/index.php. You can make a new one like I’m doing, or use an existing element in the template. I’ll put my new element right about here:

This will make the area below the group search box widget friendly. Add the following lines of code underneath, like this:

see http://codex.wordpress.org/WordPress_Widgets_Api/dynamic_sidebar

Basically this is saying “if nothing has called dynamic sidebar on the element with id ‘groups-sidebar,’ execute the code that comes after this. This is how you add default sidebar content to display when users have not added any widgets

There is one more step to defining a widget area. You might want to do this in a simple plugin:

source: http://codex.wordpress.org/Function_Reference/register_sidebar

You can modify these tags, but WordPress suggests that you leave the sprintf stuff alone for the sake of consistency.

Your widget area should now show up in wp-admin/widgets.php

It should display a properly formatted widget where ever you have it located. I found this process especially useful while editing Buddypress, because it seems like the groups and members pages should really be made widget friendly.

I suggest you read the documentation in http://codex.wordpress.org/WordPress_Widgets_Api for more information – this is basically how I learned to do this.

You can do this without writing any SQL. Buddypress uses a class called BP_Groups_Group to handle its group creation. BP_Groups_Group is defined in /groups/bp-groups-classes if you want to see it. I highly recommend taking a look at this, as you will discover other class methods that do other group-related things.

Say you want a plugin that upon activation creates a certain group. First add an action to the activation hook:

register_activation_hook(__file__, 'create_a_group');

Next, we need to call a function that instantiates the class BP_Groups_Group. Lets do this:

The whole point of doing it this way is so you that can use the save() method. Check this function out on line 90 of bp-groups-classes.php. It does all the SQL for you, and to reproduce this would be very tedious.

create_a_group() will dump a row into wp_bp_groups. But if you go to your site and look at the groups directory, it won’t show up. Why? Because Buddypress checks for certain kinds of metadata before it displays a group in the main directory. So add this:

This is how Buddypress updates group metadata. Your new group should show up.

It is worth mentioning that the other database operations in Buddypress work exactly the same way: first you instantiate a database class, populate the object with data, then you call save(). But look at the code, there are tons of other methods for these kinds of classes that will help you do things without writing redundant SQL.

Basically, what you are doing here mirrors what Buddypress does in step one (case 1) of groups_create_group() on line 1451 of bp-groups.php. The reason you can’t just use this function is that you need your own data, not the canned query that comes with the plain old populate().