Easy! Reader

If you've built anything remotely challenging in ExpressionEngine, you've no doubt discovered things that are easier done in native PHP than in EE tags. A lot of it has to do with how ExpressionEngine parses templates and what gets parsed first.

One recent bugbear I ran into was trying to use the {count} "magic" variable from a call to {exp:query} that resided inside a loop. I needed the {entry_id} from the entry in the SQL statement, but {count} (despite being used inside {exp:query}) was evaluating as the count and not the {exp:query} count. To solve the issue, I came up with the following:

{exp:weblog:entries weblog="services"
                    disable="categories|category_fields|member_data|pagination|trackbacks"}
  {exp:query sql="SELECT @row := 0"}{/exp:query}
  {exp:query sql="SELECT @row := @row + 1 AS `query_count`
                         `project`.`title` AS `project_name`
                  FROM   `exp_weblog_titles` AS `project`
                    INNER JOIN `exp_relationships` AS `service_projects` ON `project`.`entry_id` = `service_projects`.`rel_parent_id`
                  WHERE `project`.`weblog_id` = 13
                    AND `service_projects`.`rel_child_id` = {entry_id}
                  LIMIT 10"}
    {if query_count=="1"}
<ul>
    {/if}
    {if query_count!="10"}
  <li>{project_name}</li>
    {/if}
    {if query_count=="9"}
  <li>&#8230;and many more</li>
</ul>
    {/if}
  {/exp:query}
{/exp:weblog:entries}

You'll notice I'm using {exp:query} twice. The first time is to establish a variable in the SQL connection. Then I am free to use the variable in the second query and the count (returned as {query_count}) will be a count of the inner loop instead of the outer one.

It is important to note, however, that MySQL will evaluate the variable's incrementation before paying attention to any ORDER BY clauses, so your mileage may vary. Regardless, it's a handy technique.

A few projects back, I decided to rethink our JavaScript organization strategy and came up with a new technique that, I think, helps us better manage behaviors from page to page.

For years, when I needed page-specific interactions, I would either embed the JS (unobtrusively, of course) at the bottom of the page or externalize it to a separate page-specific file. In some sites, that became a difficult setup to manage because we were juggling so many files and we were also forcing our users to download each of those files individually.

Looking for a better way to manage all of the code, I built FunctionHandler. This script takes lets you declare blocks of JavaScript and then target them at pages based on the id attribute on the body element. When the targeted id is encountered, the code block is executed on DOM ready. Here's a quick example:

FunctionHandler.register(
  ['home'],
  function(){
    alert("I'm gonna run some code here.");
  });

As you can see, using it is pretty simple: you make a call to FunctionHandler's register method and pass it two arguments. The first is an array of the id values you want this code block to execute on and the second is an anonymous function that wraps your code block.

What we've found really nice about this setup is that it encourages you to create discrete JavaScript components while, at the same time, easily allowing you to adjust the pages that those components run on by simply adding to or subtracting from the id stack. You can even blanket every page with a given script by supplying a string value of "*" as the initial argument:

FunctionHandler.register(
  '*',
  function(){
    // Typekit
    // Google Analytics
    // etc.
  });

Anyway, I just wanted to take a brief moment to share this script because we've found it pretty handy. Perhaps you will too.

PS - FunctionHandler is available in 3 flavors: native JS, jQuery, and Prototype.

This one took a little futzing around and digging through the TinyMCE forum to figure out, but it's been nagging at me for a while. By default (or at least in the default configuration provided under the LG TinyMCE extension for ExpressionEngine), TinyMCE will remove the alt attribute if it is empty. Obviously, for accessibility and validation reasons, this is highly undesirable and needs correcting. Thankfully, the fix is pretty simple: add the following to your TinyMCE configuration options:

// fix empty alt attributes
extended_valid_elements : 'img[src|alt=|title|class|id|style|height|width]',
verify_html : true,

I choose to add these options right after declaring my cleanup/output options but before the remainder of the configuration. If you choose to tack these options on at the end, just remember to remove the trailing comma.