Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Archiving custom range is not triggered correctly. #3833

Closed
anonymous-piwik-user opened this Issue · 4 comments

4 participants

@anonymous-piwik-user

Seems that custom period should is only metric that should be processed independently (regardless browser triggering is on/off)

In global.ini.php we can disable browser archiving for everything except custom period, what seems to be expected behavior (as custom period needs to be archived somehow)

The only time that the browser will still trigger archiving is when requesting a custom date range that is not pre-processed yet

In current version (1.10 and 1.11 - not sure how it worked earlier) after disabling browser archiving (high traffic page - we're using archive scripts to compute data) i had problems with getting correct results for periods

[2013-03-15 15:29:38] [35d4e34d] [13.66 Mb] * ARCHIVING DISABLED, for Preparing archive: range(From 2013-03-12 to 2013-03-13), plugin VisitsSummary , Visits = <br/>

what shouldn't happen for period range.

In attachment patch that should solved this issue.

Keywords: range, custom period, browser trigger

@anonymous-piwik-user

Attachment: Piwik_ArchiveProcessing range fix
archivingPatch.diff

@zawadzinski
Collaborator

We shall use $this->periodId to check which period we are dealing with (the request var may not be set)

@mattab
Owner

In 03a6e97: Fixes #3833 adding check upstream. Thx for the report & patch, very nice bug to fix!

@peterbo
Collaborator

In 5700b37: Refs #3833 - Piwik_Period's toString method does not return the type of the Period and a "Array to String conversion" notice is triggered. So we use the getLabel accessor.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.