
Recherche avancée
Médias (91)
-
Géodiversité
9 septembre 2011, par ,
Mis à jour : Août 2018
Langue : français
Type : Texte
-
USGS Real-time Earthquakes
8 septembre 2011, par
Mis à jour : Septembre 2011
Langue : français
Type : Texte
-
SWFUpload Process
6 septembre 2011, par
Mis à jour : Septembre 2011
Langue : français
Type : Texte
-
La conservation du net art au musée. Les stratégies à l’œuvre
26 mai 2011
Mis à jour : Juillet 2013
Langue : français
Type : Texte
-
Podcasting Legal guide
16 mai 2011, par
Mis à jour : Mai 2011
Langue : English
Type : Texte
-
Creativecommons informational flyer
16 mai 2011, par
Mis à jour : Juillet 2013
Langue : English
Type : Texte
Autres articles (112)
-
Personnaliser en ajoutant son logo, sa bannière ou son image de fond
5 septembre 2013, parCertains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;
-
Ecrire une actualité
21 juin 2013, parPrésentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
Vous pouvez personnaliser le formulaire de création d’une actualité.
Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...) -
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir
Sur d’autres sites (6955)
-
How to write UI tests for your plugin – Introducing the Piwik Platform
18 février 2015, par Thomas Steur — DevelopmentThis 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 methodit(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 definedscreenshotName
. 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 ofcapture
: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 theHTML
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 theexpected-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 folderexpected-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 — DevelopmentThis 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 methodit(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 definedscreenshotName
. 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 ofcapture
: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 theHTML
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 theexpected-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 folderexpected-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.
-
11 ways Piwik Analytics helps you to protect your visitors privacy
11 janvier 2017, par InnoCraft — CommunityAt Piwik and at InnoCraft, we think Privacy matters. From the beginning, Piwik has had a strong focus on privacy and ensures the privacy of your visitors and analytics data. As a result, Piwik has been recommended as a privacy-compliant analytics tool for example by the Independent Center for Privacy Protection in Germany (ULD) and by the Center for Data Privacy Protection in France (CNIL). In France, Piwik is the only web analytics tool that does not require Cookie Consent.
Here are some ways how you can ensure your users and visitors privacy by using Piwik.
1. You own the data
Whether you host Piwik on premise yourself, managed on premise by InnoCraft, or whether you use our Piwik cloud, when you use Piwik, YOU keep control of your data and nobody else. This also means you can decide where your data should be located physically.
2. Anonymized IP addresses
For better privacy by default, Piwik will not record the full IP address of your visitors because otherwise the browsing history could be easily tracked across several days and even across websites within the same Piwik server. Some countries even require to anonymize the IP address, considered Personally Identifiable Information (PII).
To change the IP anonymization settings go to “Administration > Privacy”. Optionally, you can use the full IP to still get for example accurate location data.
3. Delete old visitor logs
The visitor logs contain information all the collected raw data about every visitor and every action. You can configure Piwik to automatically delete logs from the database. When you delete old logs, only the real time and visitor log reports will no longer work for this old time period, all other aggregated reports will still work.
For privacy reasons, we highly recommend that you keep the detailed Piwik logs for only 3 to 6 months and delete older log data. This has one other nice side effect : it will free significant database space, which will, in turn, slightly increase performance !
4. Support Do Not Track preference
Do Not Track enables users to opt out of any tracking by websites they do not visit, including analytics services, advertising networks, and social platforms. By default, Piwik respects users preference and will not track visitors which have specified “I do not want to be tracked” in their web browsers. Get more information about DoNotTrack.
To make sure Do Not Track is respected, go to “Administration => Privacy”.
5. Include an Opt-Out Feature on your website or app
By embedding the Opt-Out feature in your website, you give your visitors the possibility to opt-out of the tracking. When you go to “Administration > Privacy”, you will be able to copy and paste an HTML Iframe code to embed the opt-out feature for example into your privacy policy page or in your ‘Legal’ page. Your users can then click on a link to opt-out.
On the Piwik Marketplace there are also some plugins available to customize the Opt-Out experience. For example AjaxOptOut and CustomOptOut.
6. Disable Live features
The Real-Time, Visitor Log and Visitor Profile features give you insights into the tracked raw data by showing you details about every visitor and every action they performed. To protect the privacy of your visitors you may decide to prevent access to such features by disabling the “Live” plugin in “Administration => Plugins”. This way only aggregated reports will be shown in your Piwik.
7. Disable fingerprinting across websites
By default, when one of your visitors visits several of your websites, Piwik will create a fingerprint for this user that will be different across the websites to increase the visitors’ privacy. You can make sure that this feature is disabled by going to “Administration => Config file” and verifying that the value of “enable_fingerprinting_across_websites” is set to zero.
8. Disable tracking cookies
Piwik uses cookies to store some information about visitors between visits. In some countries, the legislation requires websites to provide a way for users to opt-out of all tracking, in particular tracking cookies. You can disable cookies by adding one line in the Piwik Javascript code.
9. Custom development
Piwik is an open platform that lets you extend and customize the tracking, the reporting and the Piwik user interface to your needs and to protect your visitors’ privacy the way you want or need it. Learn more in the Piwik Developer Zone. You may also have a look at our Piwik Marketplace where you can find several free and premium features to extend your Piwik.
10. Transparency
By default, all information and all collected data in your Piwik server are protected and nobody can access it. However, Piwik allows you to optionally make your collected data public and you can export any Piwik report including the whole dashboard to embed it into your website. This way you can show your users exactly which information you track. When you decide to make reports public, we do our best to protect privacy and automatically hide any Personally Identifiable Information such as the Visitor Profile and we make sure to not show any Visitor IP address and the Visitor ID.
11. Privacy policy
When you use Piwik to track your visitors, we recommend to update your Privacy Policy to explain how Piwik is used and what data it gathers. We provide a Privacy Policy template for Piwik users that you can copy on your site.
Continuous privacy improvements
We are always interested in improving the privacy. If you miss any feature or have an idea on how to improve the privacy, please let us know.
More information about all the Piwik features
If you want to learn more about all the features in Piwik, have a look at our User Guides and FAQ entries.