Equality was written to fill what I believed to be a gap in the logic of Equal Heights. Like Equal Heights, the purpose of Equality is to set height of multiple elements equal to one another, however, unlike Equal Heights, these elements do not necessarily have to be in the same container. This is a very minimalistic approach to the matter, however it serves its purpose for my projects.

The need arised to display a single content type — which included a conditional field that separated the content into two categories depending on that condition — in a block depending on which category’s landing page a user arrived on. Following? No? Alright….

Assume you have two factions of one website, for example’s sake, lets say you’re building a summer camp website that has a girls side and a boys side. A cookie is set when a user arrives at domain.org/boyscamp or /girlscamp that simply states which page they landed on. Both sides have campfire nights that they would like to publish on the website using the same form, with a condition boys or girls, but only one of the sides is going to display in a single block. The website is the same for both sides with the exception of the landing page — both sides access the same nodes, so how do we display this side specific block on all nodes?

There’s several ways to go about this actually. You could use Context, with Context PHP and pull the cookie value and create 2 Contexts, one with each cookie evaluating true. But perhaps you don’t want to install Context just for a single purpose — it is a lot of module for one block.

A second method is to create a PHP block and use views_embed_view with an elseif based on the cookie value:

if ($_COOKIE["cookiename"] == "site1") {
print views_embed_view('Campfire','block_1');
} elseif ($_COOKIE["cookiename"] == "site2")  {
print views_embed_view('Campfire','block_2');
}

Either way, you’ll now have both Views in a single block.

In using Views 3 recently, I found, as I'm sure most everyone else has, that it has had some significant changes in the new release. The one that got me recently was triggering the display of a Content field with the argument based on the current node ID...

Development for the module seems to be mostly at a standstill, presumably due to the developer jumping into Drupal Commerce, yet for the Drupal 6.x users still working with Ubercart, Better Cart Links is pretty much unusable.

Attempting to create a link with Better Cart Links drops the error “Product ID not valid” even when using a valid Node ID.

Anyway, here’s the patch. The issue was product IDs being called incorrectly in the mysql query. The fix is working well for me, but if you have any issues let me know.

In using a few select templates from GoGoThemes, I’ve developed quite the headache fixing the code that controls the Theme Options menus in the backend of WordPress. If you’re using a GoGoTheme and you’re having issues with Theme Options, then this is for you.

The first thing you may notice is that your pretty tabs in Theme Options just don’t function — aside from the HTML throwing around 90 validation errors, the main issue is the way that pages are being selected from the database — the current method used either returns –1 for the ID or returns nothing and breaks entirely. To solve this issue, follow the steps below:
Find:

foreach(get_pages() as $id) { $page = get_page($id)

Replace With:

foreach(get_pages() as $id) { $page = get_page($id->ID)

Just below that, you’ll see a line looking something like this:

echo $id; ?>">selected="selected">post_title; ?>

Your objective here is going to be to replace

$id

With:

$id->ID

And fortunately, you’ll have to follow these steps for each tab, replacing, of course, ‘team_page’, with the appropriate title.

Good stuff.