The purpose of this issue is to refactor the tracker so code relevant to plugins (eg, goal/conversion tracking, action tracking, etc.) are put into their respective plugins (eg, Goals, Actions).

To accomplish this, we can refactor Visit::handle() and introduce a new concept of a RequestProcessor which plugins implement to handle tracker request parameters. Unlike dimensions, these parameters do not have to be stored in the DB, and unlike Handlers, these parameters do not require an entirely different tracking mechanism (ie, QueuedTracking).

TODO:

• introduce a new RequestProcessor interface which plugins implement (and add to DI). has the following methods:

  • processRequestParams(VisitProperties properties, Request request): implementations get information from request and store in visit properties (things like Actions detected, is manual goal conversion, is ecommerce, etc.). VisitProperties is a new class to be introduced, stores variables currently local vars in Visit::handle() or stored as properties in GoalManager.
  • handleRequest(VisitProperties properties): deduce other visit properties based on detected request information (eg, is new visit, goals converted due to action in request, etc.).
  • afterVisitHandled(VisitProperties properties): do non visit related things (like record conversions).

• use the RequestProcessors in Visit::handle() as follows:

  • call processRequestParams() on all request processors to get info from request
  • recognize visitor, turn list of actions into single action (this is done in Action::factory)
  • call handleRequest() on all request processors to determine if visit is new, + other stuff needed
  • handle visit (either existing or new)
  • handle action
  • call afterVisitHandled()

• move goal tracking code to Goals plugin & move action tracking code to Actions plugin

• Move ping=1 tracker handling to a new plugin. When doing so, make sure ping=1 will ignore all goal related logic to be faster.

• Move Action class & related code to Actions plugin. Move GoalManager to Goals plugin. Move other plugin related code to plugins from core.

• Move current code to insert/update visit data in core to CoreHome. To do this correctly, would need a new service (eg, VisitRecorder), so VisitRequestProcessor does not get bloated (or more bloated).

• Remove lots of tracking events, I think many (if not most) are no longer needed.

• Create a new method in RequestProcessor specifically for manipulating request metadata. Right now, afterRequestProcessed() is used for both defining metadata that depends on other plugins' metadata and for manipulating other plugins' metadata. This means metadata that uses other plugins' metadata, can't be manipulated. Order of plugins will be come a problem eventually if many plugins get involved together...

• Refactor the system again for clarity and ease of use. This makes it possible to split up the code and correctly scope classes, but the code is still verbose and the tracking logic is still not obvious. Before the system is made @api it should be made as easy to use as possible.

• After it is possible to inject "component" types, RequestProcessors should use the "component" scheme.

• Decouple VisitorRecognizer from Tracker classes and add integration test for it.

• Do not use multi-dimensional array of properties for request metadata, instead use array of classes defined by plugins, so:

  /** @var $data MyPluginRequestMetadata */
  $data = $request->getMetadata('MyPlugin');