Migration › Knowledge Base › Plugin cookbook
Plugin cookbook
The old doPlugins was your "last call", the function that ran in the split second before every hit, your final chance to set or tweak variables. The Web SDK has no equivalent function, so that logic moves to two homes[16][17]: the onBeforeEventSend callback (a global last-call that mutates the payload before it sends)[15] and the Common Web SDK Plugins extension, which ports the most-used plugins as native data elements[18].
| getQueryParam | Clean, URL Parameter data element |
| getValOnce | Clean, Common Web SDK Plugins data element |
| getPreviousValue | Clean, plugins data element (on SPAs, verify it reads previous, not current) |
| getTimeParting | Clean, plugins data element, or use Workspace time dimensions |
| apl (append-to-list) | Manual, no native element; rebuild in onBeforeEventSend |
| getPercentPageViewed | Awkward, scroll/unload timing; reimplement and validate carefully |
| crossVisitParticipation | Reconsider, often better served by Attribution IQ than re-porting |
For your migration: the Common Web SDK Plugins are Adobe-Consulting courtesy code, not Customer Care–supported, and several aren't available for raw-library use. For the awkward ones, first ask whether a Workspace feature makes the plugin unnecessary at all.
doPlugins had no successor function; it has two
doPlugins was your "last call": the function that ran in the split second before every hit, your final chance to set or tweak variables. The Web SDK has no single equivalent, so that logic moves to two homes used together. The first is onBeforeEventSend, a callback registered on the extension (Configure → Data Collection → "on before event send callback code")[15] that runs before every event and receives the payload to mutate; return false aborts the send. The second is the Common Web SDK Plugins extension[18], which ports the most-used plugins as native data elements.
Worked: campaign tracking with de-duplication
Old doPlugins grabbed a campaign code, de-duped it for the session, and counted it once:
s.campaign = s.Util.getQueryParam("cid");
s.campaign = s.getValOnce(s.campaign, "s_camp", 0);
if (s.campaign) { s.events = s.apl(s.events, "event1", ",", 2); }The Web SDK rebuild is three named pieces, no doPlugins: a URL Parameter data element for cid; a getValOnce data element (from the plugins extension) wrapping it[19]; mapped into xdm.marketing.trackingCode. The apl step has no native element, so it goes in onBeforeEventSend:
function (content) {
var tc = content.xdm && content.xdm.marketing && content.xdm.marketing.trackingCode;
if (tc) {
content.xdm._experience = content.xdm._experience || {};
content.xdm._experience.analytics = content.xdm._experience.analytics || {};
(content.xdm._experience.analytics.event1to100 =
content.xdm._experience.analytics.event1to100 || {}).event1 = { value: 1 };
}
}The honest cookbook
| getQueryParam | Clean, URL Parameter data element |
| getValOnce | Clean, plugins data element |
| getPreviousValue | Clean, but on SPAs verify it reads previous, not current |
| getTimeParting | Clean, or use Workspace time dimensions instead |
| apl | Manual, rebuild in onBeforeEventSend (no native element) |
| getPercentPageViewed | Awkward, scroll/unload timing; reimplement and validate carefully |
| crossVisitParticipation | Reconsider, often better served by Attribution IQ |
The Common Web SDK Plugins are Adobe-Consulting courtesy code, not Customer Care–supported, and several aren't available for raw-library use. For the awkward ones, first ask whether a Workspace feature removes the need entirely.