We’ve all had a love/hate rela­tion­ship with our Site­Cat­a­lyst plu­g­ins. I mean, where would we be today with­out good ol’ s.getQueryParam or s.getTimeParting? And when you have a new track­ing para­me­ter from your mar­keters, who doesn’t love to get your devel­op­ers and imple­men­ta­tion con­sul­tants to change and test those fate­ful lines in the doplu­g­ins sec­tion? But it’s time to move on. Tech­nol­o­gy has final­ly caught up to our needs. Plu­g­ins you pre­vi­ous­ly couldn’t have lived with­out are now obso­lete, since their func­tion­al­i­ty is built right into the Satel­lite inter­face.

I’ll admit, when Rudi Shumpert post­ed about how to get a Site­Cat­a­lyst Base Code (scode) into Satel­lite before I start­ed work­ing here, I thought “well, it will be nice to be able to manage/make changes to the scode right with­in the satel­lite inter­face, but Rudi left off a pret­ty crit­i­cal piece- plu­g­ins! That’s where all the hard work is, any­ways.” That plain lit­tle scode you get from the admin con­sole doesn’t include any plu­g­ins- yet some­how pret­ty much every scode on the web includes lines and lines of plu­g­in code. You can’t live with­out them! Or at least, you couldn’t in the past. But Rudi and Satel­lite were already a few steps ahead of me.

Where did all those scodes get their plu­g­in code? Some can be found in the Site­Cat­a­lyst knowl­edge base doc­u­men­ta­tion, some can be found smat­tered across the web on var­i­ous blogs (I can’t tell you how often I’ve referred clients to Kevin Rogers and Jason Thomp­son‘s blogs). Either way, you need some­one famil­iar with the plu­g­ins, their use-cas­es, and their gotchas, to imple­ment them for you: the Imple­men­ta­tion Con­sul­tants. As some­one who has made a liv­ing for 6 years as an scode jock­ey, I can tell you that while there is always plen­ty of s_code work to keep an IC busy, we’d much rather focus our efforts on stream­lin­ing process­es, cre­ate bet­ter gov­er­nance and stan­dards, and help­ing bring in data that  can real­ly change the way an orga­ni­za­tion does dig­i­tal busi­ness.

Now that I’ve had more of a chance to work with Satel­lite, I see Rudi wasn’t wrong to omit plu­g­ins in his post: he just knows that with Satel­lite, you may sim­ply just not need them! Take get­Query­Param for exam­ple.

Query Param Tracking – The Old Way

In the past, if I used a query string para­me­ter, such as “cid”, “cmpid”, or “source”, in my mar­ket­ing URLs to track cam­paigns, I’d need to include this in my scode in the sdoPlu­g­ins func­tion:


Then in my plu­g­ins sec­tion, I’d need to include the whole get­Query­Param plu­g­in (hope­ful­ly the most recent ver­sion, which is cur­rent­ly 2.3).

/* * Plu­g­in: get­Query­Param 2.3 */ s.getQueryParam=new Function(“p”,“d”,“u”,”” +“var s=this,v=”,i,t;d=d?d:”;u=u?u:(s.pageURL?s.pageURL:s.wd.locati” +“on);if(u’f’)u=s.gtfs().location;while℗{i=p.indexOf(‘,’);i=i<0?p” +”.length:i;t=s.pgpv(p.substring(0,i),u+”);if(t){t=t.indexOf(‘#’)>-” +“1?t.substring(0,t.indexOf(‘#’)):t;}if(t)v+=v?d+t:t;p=p.substring(i=” +”=p.length?i:i+1)}return v”); s.pgpv=new Function(“k”,“u”,”” +“var s=this,v=”,i=u.indexOf(‘?’),q;if(k&&i>-1){q=u.substring(i+1);v” +”,’&’,‘pgvf’,k)}return v”); s.pgvf=new Function(“t”,“k”,”” +“if(t){var s=this,i=t.indexOf(‘=’),p=i<0?t:t.substring(0,i),v=i<0?‘T” +“rue’:t.substring(i+1);if(p.toLowerCase()k.toLowerCase())return s.” +“epa(v)}return ””);

Now you’d wait for devel­op­ers to test it, and/or for the next code release cycle. Not exact­ly the most clear-cut solu­tion for some­thing so sim­ple, is it? In truth, this is prob­a­bly the eas­i­est, most sim­ple plu­g­in you can imple­ment in your scode. And if you want­ed to keep it in your scode, you still could, and man­age it with­in Satel­lite to keep it easy to man­age and con­trol.

Query Param Tracking -The New Way

Now, you can accom­plish the exact same pur­pose with a few key­strokes and a mouse click. In either your page rules (to apply to only a sub­set of pages) or your over­all tool set­tings (to apply site-wide), you’ll find the cam­paign vari­able :

set up campaign tracking in one click

Done! Yep, that’s it.

Additional Uses

If you need to cap­ture dif­fer­ent query string para­me­ters into dif­fer­ent vari­ables – for exam­ple, an inter­nal pro­mo­tion into ?icid – this is done with one addi­tion­al step: the cre­ation of a sim­ple data ele­ment (under “rules” then “data ele­ments”). Give it a friend­ly name for the satel­lite inter­face, select “URL Para­me­ter” under type, enter the para­me­ter, and save.

Creating a data element from a query string parameter

All that’s left to be done is to call that data ele­ment in the eVar itself. This can be done site wide (in your tool set­tings) or for a spe­cif­ic page or sub­set of pages- either way, the set up is the same and very sim­ple. I set the eVar num­ber, type “%” to let Satel­lite know I am call­ing a data ele­ment, choose my already-cre­at­ed ele­ment from the list, and hit save:

Adding the data element to an eVar.

I save my rule or my set­tings, test it, and pub­lish it- a process that could be com­plet­ed in as few as 5 min­utes. Done. No code touched. The scode file is still that basic, plain scode straight from the admin con­sole.

Conclusion and Next Steps

Obvi­ous­ly this is a very sim­ple (if very com­mon) use case. I imple­ment­ed both cam­paign and inter­nal pro­mo­tions on my own site in under 15 min­utes. I’ll be fol­low­ing this post by look­ing at oth­er plu­g­ins that Satel­lite can free you from, includ­ing the linkhan­dler plu­g­ins, get­Pre­vi­ous­Pa­ge­Name, getAnd­Per­sist­Val­ue, append­ToList, Form Analy­sis, and forceLow­er­case plu­g­ins.

Are you ready to move on? Which plu­g­ins are you ready to leave behind?