Piwik

Les articles publiés sur le site

• Piwik PRO is hiring a Technical Support Specialist (Remote)

  13 mars 2015, par Piwik Core Team — Jobs

  At Piwik and Piwik PRO we develop the leading open source web analytics platform, used by more than one million websites worldwide. Our vision is to build the best open alternative to Google Universal Analytics. We are growing and now looking for a Technical Support Specialist!

  What will you be doing?

  • Supporting Piwik PRO clients on a daily basis – providing rapid responses via phone and email.
  • Participating in calls with Piwik PRO clients analyzing requirements for enterprise customers.
  • Onboarding clients – planning and coordinating the implementation with the dedicated technical team.
  • Communicating complex problems to the dedicated technical team.

  We can promise you:

  • A competitive salary.
  • The opportunity to develop your skills and gain more experience by working on exceptional projects.
  • Access to a regularly updated resource library and the opportunity to contribute to it.
  • Flexible working hours.

  Desired Skills and Experience

  You won’t make it without:

  • A solid technical background and a familiarity with the IT sector.
  • A receptive mind.
  • Great English communication skills (speaking, reading, writing, and listening).
  • Previous experience of working with corporate clients and a sixth sense for striking up relationships.
  • Appropriately mixed abilities: solid communication skills, inquisitiveness and an analytical mind (have the ability to draw conclusions based on gathered data).
  • Great self-organization skills.

  About Piwik PRO

  At Piwik and Piwik PRO we develop the leading open source web analytics platform, used by over 1.1M websites worldwide and is currently ranked the 7th most used web analytics tool in the world. Our vision is to build the best open alternative to Google Universal Analytics.

  The Piwik platform collects, stores and processes a lot of information: hundreds of millions of data points each month. We create intuitive, simple and beautiful reports that delight our users.

  Piwik PRO provides cloud hosting solutions and enterprise-level support and consultancy services. We’re in the process of expanding our US team and are currently seeking to hire a Technical Support Specialist who will focus on assisting our US clients.

  Location

  Ideally you will be located in the USA or Canada (Remote work).

  Apply online

  To apply for this position, please Apply online here. We look forward to receiving your applications!

• How to expose new API methods in the HTTP Reporting API – Introducing the Piwik Platform

  26 février 2015, par Thomas Steur — Development

  This is the next post of our blog series where we introduce the capabilities of the Piwik platform (our previous post was How to write UI tests for your plugin). This time you’ll learn how to extend our Reporting API. For this tutorial you will need to have basic knowledge of PHP.

  What is Piwik’s Reporting API?

  It allows third party applications to access analytics data and manipulate miscellaneous data (such as users or websites) through HTTP requests.

  What is it good for?

  The Reporting API is used by the Piwik UI to render reports, to manage users, and more. If you want to add a feature to the Piwik UI, you might have to expose a method in the API to access this data. As the API is called via HTTP it allows you to fetch or manipulate any Piwik related data from anywhere. In these exposed API methods you can do pretty much anything you want, for example:

  • Enhance existing reports with additional data
  • Filter existing reports based on custom rules
  • Access the database and generate custom reports
  • Persist and read any data
  • Request server information

  Getting started

  In this series of posts, we assume that you have already set up your development environment. If not, visit the Piwik Developer Zone where you’ll find the tutorial Setting up Piwik.

  To summarize the things you have to do to get setup:

  • Install Piwik (for instance via git).
  • Activate the developer mode: ./console development:enable.
  • Generate a plugin: ./console generate:plugin --name="MyApiPlugin". There should now be a folder plugins/MyApiPlugin.
  • And activate the created plugin: ./console plugin:activate "MyApiPlugin"

  Let’s start creating an API

  We start by using the Piwik Console to create a new API:

  ./console generate:api

  The command will ask you to enter the name of the plugin the created API should belong to. I will simply use the above chosen plugin name “MyApiPlugin”. There should now be a file plugins/MyApiPlugin/API.php which contains already an example to get you started easily:

  class API extends \Piwik\Plugin\API
  {
      public function getAnswerToLife($truth = true)
      {
          if ($truth) {
              return 42;
          }
  
          return 24;
      }
  
      public function getExampleReport($idSite, $period, $date, $wonderful = false)
      {
          $table = DataTable::makeFromSimpleArray(array(
              array('label' => 'My Label 1', 'nb_visits' => '1'),
              array('label' => 'My Label 2', 'nb_visits' => '5'),
          ));
  
          return $table;
      }
  }
  

  Any public method in that file will be available via the Reporting API. For example the method getAnswerToLife can be called via this URL: index.php?module=API&method=MyApiPlugin.getAnswerToLife. The URL parameter method is a combination of your plugin name and the method name within this class.

  Passing parameters to your method

  Both example methods define some parameters. To pass any value to a parameter of your method simply specify them by name in the URL. For example ...&method=MyApiPlugin.getExampleReport&idSite=1&period=week&date=today&wonderful=1 to pass values to the parameters of the method getExampleReport.

  Returning a value

  In an API method you can return any boolean, number, string or array value. A resource or an object cannot be returned unless it implements the DataTableInterface such as DataTable (the primary data structure used to store analytics data in Piwik), DataTable\Map (stores a set of DataTables) and DataTable\Simple (a DataTable where every row has two columns: label and value).

  Did you know? You can choose the response format of your API request by appending a parameter &format=JSON|XML|CSV|... to the URL. Check out the Reporting API Reference for more information.

  Best practices

  Check user permissions

  Do not forget to check whether a user actually has permissions to access data or to perform an action. If you’re not familiar with Piwik’s permissions and how to check them read our User Permission guide.

  Keep API methods small

  At Piwik we aim to write clean code. Therefore, we recommend to keep API methods small (separation of concerns). An API pretty much acts like a Controller:

  public function createLdapUser($idSite, $login, $password)
  {
      Piwik::checkUserHasAdminAccess($idSite);
      $this->checkLogin($login);
      $this->checkPassword($password);
      
      $myModel = new LdapModel();
      $success = $myModel->createUser($idSite, $login, $password);
      
      return $success;
  }
  

  This is not only easy to read, it will also allow you to create simple tests for LdapModel (without having to bootstrap the whole Piwik layer) and you will be able to reuse it in other places if needed.

  Calling APIs of other plugins

  For example if you want to fetch an existing report from another plugin, say a list of all Page URLs, do not request this report by calling that method directly: \Piwik\Plugins\Actions\API::getInstance()->getPageUrls($idSite, $period, $date);. Instead, issue a new API request:

  
  $report = \Piwik\API\Request::processRequest('Actions.getPageUrls', array(
      'idSite' => $idSite,
      'period' => $period,
      'date'   => $date,
  ));
  

  This has several advantages:

  • It avoids a fatal error if the requested plugin is not available on a Piwik installation
  • Other plugins can extend the called API method via events (adding additional report data to a report, doing additional permission checks) but those events will be only triggered when requesting the report as suggested
  • If the method parameters change, your request will most likely still work

  Publishing your Plugin on the Marketplace

  In case you want to share your API with other Piwik users you can do this by pushing your plugin to a public GitHub repository and creating a tag. Easy as that. Read more about how to distribute a plugin and best practices when publishing a plugin.

  Isn’t it easy to create a API? We never even created a file! If you have any feedback regarding our APIs or our guides in the Developer Zone feel free to send it to us.

• How to expose new API methods in the HTTP Reporting API – Introducing the Piwik Platform

  26 février 2015, par Thomas Steur — Development

  This is the next post of our blog series where we introduce the capabilities of the Piwik platform (our previous post was How to write UI tests for your plugin). This time you’ll learn how to extend our Reporting API. For this tutorial you will need to have basic knowledge of PHP.

  What is Piwik’s Reporting API?

  It allows third party applications to access analytics data and manipulate miscellaneous data (such as users or websites) through HTTP requests.

  What is it good for?

  The Reporting API is used by the Piwik UI to render reports, to manage users, and more. If you want to add a feature to the Piwik UI, you might have to expose a method in the API to access this data. As the API is called via HTTP it allows you to fetch or manipulate any Piwik related data from anywhere. In these exposed API methods you can do pretty much anything you want, for example:

  • Enhance existing reports with additional data
  • Filter existing reports based on custom rules
  • Access the database and generate custom reports
  • Persist and read any data
  • Request server information

  Getting started

  In this series of posts, we assume that you have already set up your development environment. If not, visit the Piwik Developer Zone where you’ll find the tutorial Setting up Piwik.

  To summarize the things you have to do to get setup:

  • Install Piwik (for instance via git).
  • Activate the developer mode: ./console development:enable.
  • Generate a plugin: ./console generate:plugin --name="MyApiPlugin". There should now be a folder plugins/MyApiPlugin.
  • And activate the created plugin: ./console plugin:activate "MyApiPlugin"

  Let’s start creating an API

  We start by using the Piwik Console to create a new API:

  ./console generate:api

  The command will ask you to enter the name of the plugin the created API should belong to. I will simply use the above chosen plugin name “MyApiPlugin”. There should now be a file plugins/MyApiPlugin/API.php which contains already an example to get you started easily:

  class API extends \Piwik\Plugin\API
  {
      public function getAnswerToLife($truth = true)
      {
          if ($truth) {
              return 42;
          }
  
          return 24;
      }
  
      public function getExampleReport($idSite, $period, $date, $wonderful = false)
      {
          $table = DataTable::makeFromSimpleArray(array(
              array('label' => 'My Label 1', 'nb_visits' => '1'),
              array('label' => 'My Label 2', 'nb_visits' => '5'),
          ));
  
          return $table;
      }
  }
  

  Any public method in that file will be available via the Reporting API. For example the method getAnswerToLife can be called via this URL: index.php?module=API&method=MyApiPlugin.getAnswerToLife. The URL parameter method is a combination of your plugin name and the method name within this class.

  Passing parameters to your method

  Both example methods define some parameters. To pass any value to a parameter of your method simply specify them by name in the URL. For example ...&method=MyApiPlugin.getExampleReport&idSite=1&period=week&date=today&wonderful=1 to pass values to the parameters of the method getExampleReport.

  Returning a value

  In an API method you can return any boolean, number, string or array value. A resource or an object cannot be returned unless it implements the DataTableInterface such as DataTable (the primary data structure used to store analytics data in Piwik), DataTable\Map (stores a set of DataTables) and DataTable\Simple (a DataTable where every row has two columns: label and value).

  Did you know? You can choose the response format of your API request by appending a parameter &format=JSON|XML|CSV|... to the URL. Check out the Reporting API Reference for more information.

  Best practices

  Check user permissions

  Do not forget to check whether a user actually has permissions to access data or to perform an action. If you’re not familiar with Piwik’s permissions and how to check them read our User Permission guide.

  Keep API methods small

  At Piwik we aim to write clean code. Therefore, we recommend to keep API methods small (separation of concerns). An API pretty much acts like a Controller:

  public function createLdapUser($idSite, $login, $password)
  {
      Piwik::checkUserHasAdminAccess($idSite);
      $this->checkLogin($login);
      $this->checkPassword($password);
      
      $myModel = new LdapModel();
      $success = $myModel->createUser($idSite, $login, $password);
      
      return $success;
  }
  

  This is not only easy to read, it will also allow you to create simple tests for LdapModel (without having to bootstrap the whole Piwik layer) and you will be able to reuse it in other places if needed.

  Calling APIs of other plugins

  For example if you want to fetch an existing report from another plugin, say a list of all Page URLs, do not request this report by calling that method directly: \Piwik\Plugins\Actions\API::getInstance()->getPageUrls($idSite, $period, $date);. Instead, issue a new API request:

  
  $report = \Piwik\API\Request::processRequest('Actions.getPageUrls', array(
      'idSite' => $idSite,
      'period' => $period,
      'date'   => $date,
  ));
  

  This has several advantages:

  • It avoids a fatal error if the requested plugin is not available on a Piwik installation
  • Other plugins can extend the called API method via events (adding additional report data to a report, doing additional permission checks) but those events will be only triggered when requesting the report as suggested
  • If the method parameters change, your request will most likely still work

  Publishing your Plugin on the Marketplace

  In case you want to share your API with other Piwik users you can do this by pushing your plugin to a public GitHub repository and creating a tag. Easy as that. Read more about how to distribute a plugin and best practices when publishing a plugin.

  Isn’t it easy to create a API? We never even created a file! If you have any feedback regarding our APIs or our guides in the Developer Zone feel free to send it to us.

• How to write UI tests for your plugin – Introducing the Piwik Platform

  18 février 2015, par Thomas Steur — Development

  This is the next post of our blog series where we introduce the capabilities of the Piwik platform (our previous post was How to write unit tests for your plugin). This time you’ll learn how to write UI tests in Piwik. For this tutorial you will need to have basic knowledge of JavaScript and the Piwik platform.

  What is a UI test?

  Some might know a UI test under the term ‘CSS test’ or ‘screenshot test’. When we speak of UI tests we mean automated tests that capture a screenshot of a URL and then compare the result with an expected image. If the images are not exactly the same the test will fail. For more information read our blog post about UI Testing.

  What is a UI test good for?

  We use them to test our PHP Controllers, Twig templates, CSS, and indirectly test our JavaScript. We do usually not write Unit or Integration tests for our controllers. For example we use UI tests to ensure that the installation, the login and the update process works as expected. We also have tests for most pages, reports, settings, etc. This increases the quality of our product and saves us a lot of time as it is easy to write and maintain such tests. All UI tests are executed on Travis after each commit and compared with our expected screenshots.

  Getting started

  In this post, we assume that you have already installed Piwik 2.11.0 or later via git, set up your development environment and created a plugin. If not, visit the Piwik Developer Zone where you’ll find the tutorial Setting up Piwik and other Guides that help you to develop a plugin.

  Next you need to install the needed packages to execute UI tests.

  Let’s create a UI test

  We start by using the Piwik Console to create a new UI test:

  ./console generate:test --testtype ui

  The command will ask you to enter the name of the plugin the created test should belong to. I will use the plugin name “Widgetize”. Next it will ask you for the name of the test. Here you usually enter the name of the page or report you want to test. I will use the name “WidgetizePage” in this example. There should now be a file plugins/Widgetize/tests/UI/WidgetizePage_spec.js which contains already an example to get you started easily:

  describe("WidgetizePage", function () {
      var generalParams = 'idSite=1&period=day&date=2010-01-03';
  
      it('should load a simple page by its module and action', function (done) {
          var screenshotName = 'simplePage';
          // will save image in "processed-ui-screenshots/WidgetizePageTest_simplePage.png"
  
          expect.screenshot(screenshotName).to.be.capture(function (page) {
              var urlToTest = "?" + generalParams + "&module=Widgetize&action=index";
              page.load(urlToTest);
          }, done);
      });
  });

  What is happening here?

  This example declares a new set of specs by calling the method describe(name, callback) and within that a new spec by calling the method it(description, func). Within the spec we load a URL and once loaded capture a screenshot of the whole page. The captured screenshot will be saved under the defined screenshotName. You might have noticed we write our UI tests in BDD style.

  Capturing only a part of the page

  It is good practice to not always capture the full page. For example many pages contain a menu and if you change that menu, all your screenshot tests would fail. To avoid this you would instead have a separate test for your menu. To capture only a part of the page simply specify a jQuery selector and call the method captureSelector instead of capture:

  var contentSelector = '#selector1, .selector2 .selector3';
  // Only the content of both selectors will be in visible in the captured screenshot
  expect.screenshot('page_partial').to.be.captureSelector(contentSelector, function (page) {
      page.load(urlToTest);
  }, done);

  Hiding content

  There is a known issue with sparklines that can fail tests randomly. Also version numbers or a date that changes from time to time can fail tests without actually having an error. To avoid this you can prevent elements from being visible in the captured screenshot via CSS as we add a CSS class called uiTest to the HTML element while tests are running.

  .uiTest .version { visibility:hidden }

  Running a test

  To run the previously generated tests we will use the command tests:run-ui:

  ./console tests:run-ui WidgetizePage

  After running the tests for the first time you will notice a new folder plugins/PLUGINNAME/tests/UI/processed-ui-screenshots in your plugin. If everything worked, there will be an image for every captured screenshot. If you’re happy with the result it is time to copy the file over to the expected-ui-screenshots folder, otherwise you have to adjust your test until you get the result you want. From now on, the newly captured screenshots will be compared with the expected images whenever you execute the tests.

  Fixing a test

  At some point your UI test will fail, for example due to expected CSS changes. To fix a test all you have to do is to copy the captured screenshot from the folder processed-ui-screenshots to the folder expected-ui-screenshots.

  Executing the UI tests on Travis

  In case you have not generated a .travis.yml file for your plugin yet you can do this by executing the following command:

  ./console generate:travis-yml --plugin PLUGINNAME

  Next you have to activate Travis for your repository.

  Advanced features

  Isn’t it easy to create a UI test? We never even created a file! Of course you can accomplish even more if you want. For example you can specify a fixture to be inserted before running the tests which is useful when your plugin requires custom data. You can also control the browser as it was a human by clicking, moving the mouse, typing text, etc. If you want to discover more features have a look at our existing test cases.

  If you have any feedback regarding our APIs or our guides in the Developer Zone feel free to send it to us.

• How to write UI tests for your plugin – Introducing the Piwik Platform

  18 février 2015, par Thomas Steur — Development

  This is the next post of our blog series where we introduce the capabilities of the Piwik platform (our previous post was How to write unit tests for your plugin). This time you’ll learn how to write UI tests in Piwik. For this tutorial you will need to have basic knowledge of JavaScript and the Piwik platform.

  What is a UI test?

  Some might know a UI test under the term ‘CSS test’ or ‘screenshot test’. When we speak of UI tests we mean automated tests that capture a screenshot of a URL and then compare the result with an expected image. If the images are not exactly the same the test will fail. For more information read our blog post about UI Testing.

  What is a UI test good for?

  We use them to test our PHP Controllers, Twig templates, CSS, and indirectly test our JavaScript. We do usually not write Unit or Integration tests for our controllers. For example we use UI tests to ensure that the installation, the login and the update process works as expected. We also have tests for most pages, reports, settings, etc. This increases the quality of our product and saves us a lot of time as it is easy to write and maintain such tests. All UI tests are executed on Travis after each commit and compared with our expected screenshots.

  Getting started

  In this post, we assume that you have already installed Piwik 2.11.0 or later via git, set up your development environment and created a plugin. If not, visit the Piwik Developer Zone where you’ll find the tutorial Setting up Piwik and other Guides that help you to develop a plugin.

  Next you need to install the needed packages to execute UI tests.

  Let’s create a UI test

  We start by using the Piwik Console to create a new UI test:

  ./console generate:test --testtype ui

  The command will ask you to enter the name of the plugin the created test should belong to. I will use the plugin name “Widgetize”. Next it will ask you for the name of the test. Here you usually enter the name of the page or report you want to test. I will use the name “WidgetizePage” in this example. There should now be a file plugins/Widgetize/tests/UI/WidgetizePage_spec.js which contains already an example to get you started easily:

  describe("WidgetizePage", function () {
      var generalParams = 'idSite=1&period=day&date=2010-01-03';
  
      it('should load a simple page by its module and action', function (done) {
          var screenshotName = 'simplePage';
          // will save image in "processed-ui-screenshots/WidgetizePageTest_simplePage.png"
  
          expect.screenshot(screenshotName).to.be.capture(function (page) {
              var urlToTest = "?" + generalParams + "&module=Widgetize&action=index";
              page.load(urlToTest);
          }, done);
      });
  });

  What is happening here?

  This example declares a new set of specs by calling the method describe(name, callback) and within that a new spec by calling the method it(description, func). Within the spec we load a URL and once loaded capture a screenshot of the whole page. The captured screenshot will be saved under the defined screenshotName. You might have noticed we write our UI tests in BDD style.

  Capturing only a part of the page

  It is good practice to not always capture the full page. For example many pages contain a menu and if you change that menu, all your screenshot tests would fail. To avoid this you would instead have a separate test for your menu. To capture only a part of the page simply specify a jQuery selector and call the method captureSelector instead of capture:

  var contentSelector = '#selector1, .selector2 .selector3';
  // Only the content of both selectors will be in visible in the captured screenshot
  expect.screenshot('page_partial').to.be.captureSelector(contentSelector, function (page) {
      page.load(urlToTest);
  }, done);

  Hiding content

  There is a known issue with sparklines that can fail tests randomly. Also version numbers or a date that changes from time to time can fail tests without actually having an error. To avoid this you can prevent elements from being visible in the captured screenshot via CSS as we add a CSS class called uiTest to the HTML element while tests are running.

  .uiTest .version { visibility:hidden }

  Running a test

  To run the previously generated tests we will use the command tests:run-ui:

  ./console tests:run-ui WidgetizePage

  After running the tests for the first time you will notice a new folder plugins/PLUGINNAME/tests/UI/processed-ui-screenshots in your plugin. If everything worked, there will be an image for every captured screenshot. If you’re happy with the result it is time to copy the file over to the expected-ui-screenshots folder, otherwise you have to adjust your test until you get the result you want. From now on, the newly captured screenshots will be compared with the expected images whenever you execute the tests.

  Fixing a test

  At some point your UI test will fail, for example due to expected CSS changes. To fix a test all you have to do is to copy the captured screenshot from the folder processed-ui-screenshots to the folder expected-ui-screenshots.

  Executing the UI tests on Travis

  In case you have not generated a .travis.yml file for your plugin yet you can do this by executing the following command:

  ./console generate:travis-yml --plugin PLUGINNAME

  Next you have to activate Travis for your repository.

  Advanced features

  Isn’t it easy to create a UI test? We never even created a file! Of course you can accomplish even more if you want. For example you can specify a fixture to be inserted before running the tests which is useful when your plugin requires custom data. You can also control the browser as it was a human by clicking, moving the mouse, typing text, etc. If you want to discover more features have a look at our existing test cases.

  If you have any feedback regarding our APIs or our guides in the Developer Zone feel free to send it to us.