Giter Site home page Giter Site logo

developer-documentation's Introduction

Matomo Developer Documentation

Documentations

License

Copyright Matomo team. Do not republish, or copy, or distribute this code or content. Thank you!

Run locally

$ cd app/
$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
$ php -r "if (hash_file('sha384', 'composer-setup.php') === '906a84df04cea2aa72f40b5f787e49f22d4c2f19492ac310e8cba5b96ac8b64115ac402c8cd292b8a03482574915d1a8') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
$ php composer-setup.php
$ php -r "unlink('composer-setup.php');"
$ composer install
$ mkdir tmp/cache
$ mkdir tmp/templates
$ cd public/
$ php -S 0.0.0.0:8000

To disable caching and enable debugging, create a app/config/local.php file with the following:

<?php
define('CACHING_ENABLED', false);
define('DEBUG', true);

Without cache, the website might be slow because of the inclusion of remote files (through HTTP). You can disable that locally by adding this to your local.php:

define('DISABLE_INCLUDE', true);

Automatic documentation generation (API-Reference)

The first time

# Clone Matomo repository the first time
git clone [email protected]:matomo-org/piwik.git piwik
# Download the dependencies for our generator 
cd generator/
composer install
cd ../piwik/
# Now set up composer according to https://getcomposer.org/download/

Generate the API reference docs

  • Execute ./generate.sh
  • Commit
  • Push

or just execute ./generateAndPush.sh.

The documents will be generated into the docs/generated directory. It will always generate the documentation for the latest stable version.

How to add docs for a new Matomo version

  • Increase version number for LATEST_PIWIK_DOCS_VERSION in config/app.php
  • Copy the previous documentation folder to the new one eg cp docs/4.x docs/5.x -R
  • Add a new line to generate.sh eg generateDocs "4.x-dev" "4.x" similar to the other ones. You might also want to copy the generation success detection.
  • Copy pictures from the previous version into latest version eg from public/img/3.x to public/img/4.x and update all needed pictures.
  • In app/routes/page.php we might need to update the branch for the latest CHANGELOG version in the /changelog route see eg https://github.com/matomo-org/developer-documentation/blob/0.1.0/app/routes/page.php#L156 . It will be important that we merge all changes to the changelog for different Matomo versions into the changelog of the latest Matomo version as we currently want to show one changelog across all versions.

How to manage docs for different Matomo versions

So far, docs can be put into docs/2.x, docs/3.x and directly under docs/. If eg a guide is requested for Piwik 2, we first look for docs in docs/2.x and if not found for docs in docs/. This allows us to have some pages always the same, eg "Support" page, "Matomo Core Development", etc. So far I have left all guides under docs/ as not many docs will actually change for Matomo 3. This way, when changing a document under docs/ it will be updated for Piwik 2 and Matomo 3.

As soon as something on a guide changes for Matomo 3, we should copy that article into docs/2.x and afterwards make adjustments on the content for Matomo 3.

If a guide will be removed for a newer Matomo version and does not exist in the latest Matomo version anymore we should setup a redirect in app/helpers/Redirects.php eg to redirect /guides/pages to /2.x/guides/pages. This can be optional as the 404 Error page would suggest to open that page.

When does an article need to be copied into a versioned docs folder?

  • When an article references a resource / URL that is not available for another Matomo version. For example an article links to the API reference guide to a class that is not available in another Matomo version
  • When links for some reason are not the same for 2 different Matomo versions in general
  • When an article references eg menu items or something else but it is not the same across Matomo versions. For example there is no user menu in Matomo 3 anymore, or Plugin Settings are now split into "Personal Settings" and "General Settings". In such a case we need to make a copy of that article as the guide would be wrong otherwise.
  • When a submenu is different across Matomo versions. Submenus are usually defined in markdown files, for example under "Develop => Plugin Basics" submenu items are defined in develop-plugin-basics.md. If we eg add a new Import API into Matomo X we would need to create that new guide under /docs so it will be also available for Matomo 4 etc and then copy /docs/develop-plugin-basics.md into /docs/2.x/develop-plugin-basics.md and next add the menu item to /docs/develop-plugin-basics.md.
  • There can be many more reasons. In general if articles are different between 2 versions for various reasons because they mention eg outdated classes, outdated configs etc or when links break between 2 Matomo versions etc we need to created a copy of that guide, put it into eg docs/2.x and then update the existing article under /docs.

How do we handle images for different Matomo versions?

Images are always stored in a versioned directory. Eg public/img/2.x/* and public/img/3.x/*. When there is a new Matomo version we need to copy all the images from the previous version and put them into a new Matomo directory. In guides you would still reference an image via /img/myimage.jpg and the Markdown parser will add the path for the currently selected Matomo version and turn it into either eg /img/2.x/myimage.jpg or /img/3.x/myimage.jpg. With a new Matomo version often the UI changes and this way it keeps things simple by having always different images and by not using the same image across different Matomo versions.

Writing guides

Just edit the docs/*.md files. Any change you make there should be available on the developer website within a minute.

Guides are written using Markdown. CommonMark and Markdown Extra are supported.

In addition:

  • headers have an autogenerated HTML ID (so that they can be linked to). You can also use Markdown Extra to explicitly define it: ## Some title {#some-title-id}
  • you can include remote files as-is using:
    • {@include http://example.com/file.xml}: the content is not escaped
    • {@include escape http://example.com/file.xml}: the content will be escaped

Adding a new guide

Create a new Markdown file in docs/ and use YAML Front Matter to configure it:

---
category: Develop
---
# The title

Lorem ipsum…

YAML Front Matter is YAML embedded at the top of Markdown files. It is commonly used to define metadata, and we use it to define several items:

  • category: the name of the category (Develop, Integrate, Design, API Reference)
  • subGuides: allows you to define a list of sub-guides (will appear in the left sidebar)
  • previous: allows you to define the previous guide (a link will be added at the end of the guide, it does not affect the sidebar)
  • next: allows you to define the next guide (a link will be added at the end of the guide, it does not affect the sidebar)

A guide must be either added to a category menu or set as a "sub-guide" of another guide. It cannot be both (else it will appear twice in the left sidebar).

To add a guide to a category (i.e. it will appear in the left sidebar) edit the PHP class for the category (in app/helpers/Content/Category).

Adding the new guide to a menu item

Some menu items need to be added by adding the markdown filename without the .md in one of these category classes.

Some submenu items need to be added as a subguide see for example this example.

It really depends submenu item which one you need to edit. If the parent menu item defines it's submenu items in a category class, then you need a new entry there. Otherwise you need to edit the markdown file for the parent menu item and add a new entry to subGuides.

Please note that also the category: in the beginning of your guide needs to match the name of the category this page should be in. The category name can be for example Develop, DevelopInDepth, Integrate or API Reference.

Supported inline tags in PHP comments

The following tags can be used in PHP docblocks so that they can be turned to links in the API reference.

{@hook Request.dispatch}                    // link to Request.dispatch hook
{@hook Request.dispatch description text}   // link to Request.dispatch hook with different link text
{@hook # description}                       // link to hooks page

Note: In contrast to @link we do not check whether a hook with the given name exists.

{@link Map}                  // class within this namespace
{@link Piwik\DataTable\Map}  // full classname
{@link \Exception}           // php internal class
{@link serialize()}          // php internal function
{@link getKeyName()}         // method within this class
{@link $myproperty}          // property within this class
{@link INDEX_NB_UNIQ_VISITORS}  // constant within this class, note: a link will be only generated if the constant has a long description
{@link Map::getKeyName()}    // method from any class
{@link Map::$myproperty}     // property from any class
{@link Piwik\Metrics::INDEX_NB_UNIQ_VISITORS}  // constant from any class, note: a link will be only generated if the constant has a long description
{@link http://matomo.org}    // http link
{@link https://matomo.org}   // https link
{@link mailto:test}          // mailto link


{@link Map Description Text}                  // class within this namespace
{@link Piwik\DataTable\Map Description Text}  // full classname
{@link \Exception Description Text}           // php internal class
{@link getKeyName() Description Text}         // method within this class
{@link $myproperty Description Text}          // property within this class
{@link Map::getKeyName() Description Text}    // method from any class
{@link Map::$myproperty Description Text}     // property from any class
{@link http://matomo.org Description Text}    // http link
{@link https://matomo.org Description Text}   // https link
{@link mailto:test Description Text}          // mailto link

developer-documentation's People

Contributors

altamashshaikh avatar bx80 avatar cheweyz avatar dependabot[bot] avatar dheid avatar diosmosis avatar findus23 avatar flamisz avatar gausam avatar geekdenz avatar justinvelluppillai avatar kesselb avatar kwadronaut avatar lance-matomo avatar larsnystrom avatar lecoyote avatar lipis avatar mattab avatar mattmary avatar michalkleiner avatar mnapoli avatar pgrimaud avatar sgiehl avatar snake14 avatar spacenate avatar starker3 avatar tassoman avatar tsteur avatar ulcuber avatar vanilla-thunder avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

developer-documentation's Issues

Split Javascript Tracking reference into guide + API reference

Current problems:

  • the Javascript Tracking client API reference is very long and is a mix of "API reference" and "User guide"
  • the "Track your application" section in Integrate Piwik doesn't have much content, all the content is in user guides

Solution:

Split the current API reference into:

  • a user guide that will be in "Integrate Piwik"
  • an API reference that will stay where it is

Given this article is linked to a lot, we need to add a visible link at the beginning of the API reference to make users aware that a detailed user guide exist.

Add more information to the Pages guide

  • How to test a page (with UI tests). We only have to mention it in a section and can link to the guide
  • We need to link to the Check permission guide and mention they have to take care of it if needed
  • Explain what they can do with pages (pretty much anything) (refs #80)
  • Explain how to place a page under the User section (extend user.twig in template)
  • Explain how to create a blank page (no extends *.twig) at the beginning of the template
  • Explain how to access $_GET and $_POST parameters via Common::getRequestVar
  • Not sure if it is needed how to call API methods via Request::processRequest. Probably rather not, this would be a separate guide maybe under Utils named "API Requests"? Shall we create an issue for this?

Parts of it can be maybe used from http://developer.piwik/guides/controllers

Add Piwik tag on 404 page

In order to detect the 404 pages, we can add the following tag on 404 pages:

<!-- Piwik -->
<script type="text/javascript">
  var _paq = _paq || [];
  _paq.push(["setCustomVariable", 1, "error404", "1", "page"]);
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="//demo.piwik.org/";
    _paq.push(['setTrackerUrl', u+'piwik.php']);
    _paq.push(['setSiteId', 36]);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
  })();
</script>
<noscript><p><img src="//demo.piwik.org/piwik.php?idsite=36" style="border:0;" alt="" /></p></noscript>
<!-- End Piwik Code -->

Call the Piwik API in PHP

See http://developer.piwik.org/guides/querying-the-reporting-api#call-the-piwik-api-in-php

We need to explain that doing this actually bootstraps most of the Piwik, eg it loads the config, it loads the plugins, it checks the database etc. We need to warn people about this. Also we need to make sure there is no exit in the code etc eg as in handleMaintenanceMode. If people include this in their application we might kill their app etc. Also we should in general not recommend this way of calling API requests from any other application.

Guides renaming

  • "Piwik data" to "Piwik database schema"
  • "Plugin data" to "Extending the database"

Hide @deprecated events from the Events reference page?

Currently deprecated events such as the Menu events or Widgets, Tasks are displayed in the documentation.

Maybe these events could be removed from documentation? I guess I like the idea of having a smaller list of events, slowly removing some that are useless (Convention over Configuration ftw) and refactoring code to need less events.

Make overview pages more "clearly"

I mean the pages when clicking on a top menu item eg "Integrate Piwik", "Develop plugins"...

There is first the big banner on every overview page saying eg "Develop plugin" which just duplicates the highlighted menu item again. I think I added this initially but it is only disturbing. Give it a try in dev tools and see how it looks without it. I think it's much better :) We should not remove it on the home page though.

Then below this header the sections and links are quite "large". Maybe we can reduce the size a bit so that one can easier get an overview? I'm personally a huge fun of the Redis website where you can get a nice overview of the available guides etc http://redis.io/documentation . It looks a bit more friendly.

Provide a Reporting API guide

So far we have 3 reports related to the Reporting API:

None of those guides explains on one page what the Reporting API is, what it can be used for, and how to query it step by step. I'm currently writing a blog post about "How to expose new methods in the Reporting API" but noticed I can actually not link to any of those pages for people who don't know much about it. The In Depth Guide seems to be the only one who explains in a sentence what it is but then it follows be unrelated DataTable Filters etc. The Querying the Reporting API contains only 2 bigger examples but not much explanations etc. Also the second part of this guide should be rather in a separate guide and we need to discuss whether it is actually a good idea to recommend to load index.php to do that. I will create a separate issue on piwik/piwik for this. The Tutorial is a good start but doesn't explain what it is, what it can be used for, doesn't mention authentication etc.

The API-Reference is purely a list of parameters and methods but doesn't explain anything (which is good).

Maybe we can write a single page that explains what it is, what it can be used for, and how to make a successful call with authentication if needed and maybe explain a few more basics like period and date. Then we can link to the API-Reference. We could also write a small section about Segmentation and Metadata API and link to their pages on developer.piwik.org. A while ago I wrote an article for a German PHP Magazine maybe we could reuse some parts or the structure of it in some way.

Track site search keywords

Today I was wondering whether our blog post series already has a positive effect on developer.piwik.org and was analyzing the traffic a bit. During this I noticed we do not track the keywords used in our search.

Goal of this ticket would be to see what people are searching for. This can be useful to know to be able to decide about which topics we should write more and which topics should be covered in a blog post next etc

Improve documentation for Theming

It was reported in the forums:

I've gone through both guides to theming, and unfortunately they seemed to be a little lacking of covering some basic content. I did some digging and reverse engineering of the code and have some notes I wanted to post in hopes it may help others in the future.

The goal of this issue is to review the Theming guide with the feedback from this user in mind, and try to create a simple and useful Theming guide.

Add Changelog to menu again

I think there used to be a Changelog link in the top menu of developer.piwik.org. Is it possible to add this there again as it is very important. Maybe we could remove "Home" and / or "Develop Piwik" (which doesn't contain so much useful anyway) instead? Also "Community & Support" could be renamed to "Support"

Remove duplicate Tracking API user guide

Dupes between http://piwik.org/docs/tracking-api/ and http://developer.piwik.org/guides/tracking-api-clients

I'm removing this content:


## iOS SDK 

If you are building iOS apps, you can use the Objective-C PiwikTracker client to send tracking data to your Piwik server.

Learn more and download Piwik iOS SDK on Github at [github.com/piwik/piwik-sdk-ios][6]

## Android SDK

If you are building Android apps, you can use the Android Java client to send tracking data to your Piwik server.

Learn more and download Piwik Android SDK on Github at [github.com/piwik/piwik-sdk-android][14]

## PHP client

The default client is the PHP PiwikTracker, learn more at: [developer.piwik.org/api-reference/PHP-Piwik-Tracker][2]

## Java client

A Java client for the Piwik Tracking API is available on Github: [github.com/piwik/piwik-java-tracking ][3]

## Python client

A complete Python client implementation of the Tracking API is available on Github at [github.com/piwik/piwik-python-api][4]

## C# client 

A C# client implementation of the Tracking API is available on Github at [github.com/piwik/piwik-dotnet-tracker][5]

## Appcelerator Titanium Module 

If you are building Mobile apps using Appcelerator Titanium, use the Piwik Analytics Module for Titanium to measure how users are navigating and consuming your apps. Learn more and download the Piwik Module for Titanium at [github.com/manumaticx/ti.piwik][15]

@mnapoli can you check this is added and synced in http://developer.piwik.org/guides/tracking-api-clients

we cannot use google fonts from http://fonts.googleapis.com/

For privacy reasons we prefer not to load any fonts from google domains. Let's move the font from http://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,400,300,600&subset=latin,cyrillic-ext,greek-ext,greek,vietnamese,latin-ext,cyrillic to locally on developer.piwik.org

cc @mnapoli

Change Markdown parser

Problems with the current parser:

  • doesn't support fenced code blocks (à la GitHub):
    • indented code blocks are a pain to write with some editors
    • syntax highlighting is random because autodetected, which leads to very weird highlighting (fenced code blocks allow to set a language explicitly)
  • hacked all over the place

Parsedown is probably the best choice. The main difficulty now is try to understand what all those hacks do and see if they can be ported to Parsedown.

Developer.piwk.org API reference is currently broken

Parse Error: The root container has not been created yet.
#0 /home/piwik-docs/plugins-api-doc-generator/piwik/core/Container/StaticContainer.php(75): Piwik\Container\StaticContainer::getContainer()
#1 /home/piwik-docs/plugins-api-doc-generator/piwik/plugins/ScheduledReports/config/tcpdf_config.php(18): Piwik\Container\StaticContainer::get('path.tmp')
#2 /home/piwik-docs/plugins-api-doc-generator/piwik/core/ReportRenderer/Pdf.php(21): require_once('/home/piwik-doc...')
#3 /home/piwik-docs/plugins-api-doc-generator/piwik/vendor/composer/ClassLoader.php(386): include('/home/piwik-doc...')
#4 /home/piwik-docs/plugins-api-doc-generator/piwik/vendor/composer/ClassLoader.php(278): Composer\Autoload\includeFile('/home/piwik-doc...')
#5 [internal function]: Composer\Autoload\ClassLoader->loadClass('Piwik\\ReportRen...')
#6 [internal function]: spl_autoload_call('Piwik\\ReportRen...')
#7 /home/piwik-docs/plugins-api-doc-generator/generator/ApiClasses/Filter.php(23): class_exists('Piwik\\ReportRen...')
#8 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/tsteur/sami/Sami/Parser/NodeVisitor.php(118): ApiClasses\Filter->acceptClass(Object(Sami\Reflection\ClassReflection))
#9 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/tsteur/sami/Sami/Parser/NodeVisitor.php(79): Sami\Parser\NodeVisitor->addClassOrInterface(Object(PHPParser_Node_Stmt_Class))
#10 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/tsteur/sami/Sami/Parser/NodeVisitor.php(39): Sami\Parser\NodeVisitor->addClass(Object(PHPParser_Node_Stmt_Class))
#11 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/nikic/php-parser/lib/PHPParser/NodeTraverser.php(87): Sami\Parser\NodeVisitor->enterNode(Object(PHPParser_Node_Stmt_Class))
#12 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/nikic/php-parser/lib/PHPParser/NodeTraverser.php(58): PHPParser_NodeTraverser->traverseArray(Array)
#13 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/nikic/php-parser/lib/PHPParser/NodeTraverser.php(92): PHPParser_NodeTraverser->traverseNode(Object(PHPParser_Node_Stmt_Namespace))
#14 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/nikic/php-parser/lib/PHPParser/NodeTraverser.php(40): PHPParser_NodeTraverser->traverseArray(Array)
#15 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/tsteur/sami/Sami/Parser/CodeParser.php(43): PHPParser_NodeTraverser->traverse(Array)
#16 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/tsteur/sami/Sami/Parser/Parser.php(53): Sami\Parser\CodeParser->parse('<?php\n/**\n * Pi...')
#17 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/tsteur/sami/Sami/Project.php(431): Sami\Parser\Parser->parse(Object(Sami\Project), NULL)
#18 /home/piwik-docs/plugins-api-doc-generator/generator/vendor/tsteur/sami/Sami/Project.php(104): Sami\Project->parseVersion(Object(Sami\Version\Version), NULL, NULL, false)
#19 /home/piwik-docs/plugins-api-doc-generator/generator/generate.php(71): Sami\Project->update()
#20 /home/piwik-docs/plugins-api-doc-generator/generator/generate.php(119): generateApiClassesReference('/home/piwik-doc...', 'master')

Provide a guide how to use the HTTP Tracking API

When going to the Integrate page we see a couple of Tracking guides. The first two links "JS Tracking Client" and "Tracking API Clients" list clients that access the HTTP Tracking API. The third link is a guide how to use Content-Tracking via the HTTP Tracking API but there is actually no guide how to use the HTTP Tracking API which would be helpful if people want to write a client or if they want to track data in their application without using any of those clients.

I don't think we need a huge guide here but we need to explain some basics and the link to the Tracking API Reference.

At the end of the API Reference there is for example one part "Debugging the Tracker" which could be part of the guide. How to construct an example request could be moved there as well and explained in steps. We also need to explain when authentication is needed and how they can test it etc.

In many guides mention what it can be used for

In some guides we already write what they will learn but not for what the components can be used for. For all guides under Develop => Plugin Basics it would be nice to give developers ideas what they can do with the API's. This could be always like a simple list of 3-5 items.

Also useful for the guides Integrate/Tracking API (refs #78), Integrate/Reporting API (refs #76), Develop/Plugin Settings and Develop/Extending the Database

Add a selection to see docs for Piwik 3.0.0

We will change many API's for Piwik 3.0.0 and it would be nice to be able to select between the versions "Latest 2.X" and "Latest 3.0". At least till 3.0.0 is released but it might be even useful afterwards.

Without having the possibility to see the docs for 3.0.0 developers won't be able to migrate their plugin to 3.0.0 upfront.

The automated docs are already automatically created for master and the latest stable see https://github.com/piwik/developer-documentation/tree/master/docs/generated but there's no selection for it. Ideally we would also show the related guides when selecting "2.x" so we could maybe at some point just copy everything in docs into a "2.X" folder and leave them there until maybe 6 months after the 3.0 release.

Remove some metadata / yaml from docs

I was wondering if we actually need the metadata defined in the beginning of docs/*.md files?

category: Develop
previous: tests-ui
next: tests-travis
subGuides:
  - plugin-settings
  - piwiks-ini-configuration

In theory this information is already present in the category classes, isn't it? For example here: https://github.com/piwik/developer-documentation/blob/master/app/helpers/Content/Category/DevelopCategory.php

Depending on the path or filename of the markdown file we know the category. Currently, when moving a page to another category I do have to update the PHP category classes and update the related markdown file.

Also previous and next could be maybe automatically generated for all pages and not needed to be defined in the markdown files since we have that information already in the category class? Meaning we can find out whether there is a previous or next sibling.

With subGuides I was confused why it is sometimes defined in the markdown file and sometimes in a category class. I think we could just remove it and for simplicity always define it in the category class so one can immediately see the whole structure there and change things in one place.

Of course we'd have to create all category classes to know all this information but that should be fast. Especially since we cache pages.

Split guide "Commands" into two guides

I'm not 100% sure whether it is a good idea but think so.

We currently have one guide for Commands which handles how to use the console and one tiny section how to generate a command. This section is tiny as we have not merged the blog post yet which will be done in refs #44

The console is a crucial tool for developers as they will use it to generate all sort of things, to activate plugins, to clear caches, to enable the developer mode etc. Maybe we can move the current guide to Getting started between Setting up and Distributing your plugin? The title could be "Piwik on the command line". We do link to this from many blog posts already. Then add a new guide named "Commands" under Plugin Basics where it is currently positioned as well. This guide will only explain how to generate and develop new commands.

Write a guide how to provide Updates

This is kinda crucial for "Extending the database" as at some point there will be updates needed.

For a beginning we could just add a section about Updates to the "Extending the database" guide explaining they can create an update via ./console generate:update. We could close this ticket after this is done.

In the next step we maybe need a separate guide for this. We will probably write a blog post about this anyway, afterwards we can merge the blog post to a guide.

Add more information to the Menu guide

  • Mention how to check for permissions and that they need to check for permissions in Menu and for example in the Controller as well as it would be otherwise still possible to execute the controller via URL
  • Menus are often needed in combination with Pages therefore we should mention Pages (Controllers) and link to them
  • How to rename Menu items
  • How to delete Menu items (I think for both delete & rename there is a configure method in the Menu class otherwise we need to explain the events)
  • Explain that they need to find the translation key to rename/delete menu items and how they can find it (switch language to Development or under Admin => Translation search)
  • Update Admin and User menu screen
  • Explain at the beginning what Menus are good for (restrict items to certain users / user-groups etc, remove unneeded items etc) refs #80

Developer website is slow

Just opened the website and noticed the website is pretty slow. It takes over 4s to load and the JS and font files are never cached. The site used to load in under 500ms. It's also a bit annoying since sometimes some content is there but it takes 2 or 3 more seconds until the titles are rendered (because they use a custom font now). My internet connection is 2Mbit/s, testing with Chrome.

JS and fonts should be loaded from cache, ideally they would be loaded async.

developer website

Write a guide for tracking single page applications

A user asked for this via the feedback link. I remember we talked about this in the past already but didn't create an issue. We should definitely provide a guide for this.

This will also help us to identify whether there are problems with the current JS tracker when using it in single page applications. I'm sure there are things that can be improved or that are problematic currently.

Move blog articles into developer documentation

Write a guide how to implement an API Report method

It would be good to extend the current guide about Exposing API Methods with an example how to implement an API Report method.

Maybe one example that creates a DataTable from a simple array and runs a filter on it? The filter is maybe not needed but we should explain why not simply return the plain array: Because the dataTable allows to use all our query parameters like limit, showColumns, filter_*, ...

Then maybe another simple example that fetches an existing report, runs a filter on it to customize the report and returns it.

Enable plugins using CLI commands

To create a new plugin, the doc say to use CLI (./console generate:plugin) then enable the plugin in the web interface. Using the CLI would be more consistent and easier.

Review each guide and improve the content and structure

The goal of this project is a medium term goal that you review each page of the Developer website. The goal is to make the documentation from OK quality to good or even very good (!) when possible.

Project description:

See also the related issue in piwik/piwik

Assigned to at least @mnapoli and @mattab who will review content of each page

  • Integrate
    • #61 The Javascript Tracking Client
    • #41 Tracking API Clients
    • 60b521d All About Tracking
    • #65 Content Tracking
    • #66 Reporting API Tutorial: Get your top 10 keywords
    • #66 Querying the Reporting API
  • Develop
    • #25 Getting Started Part I
    • #26 Getting Started Part II
    • 97ad26c Getting Started Part III
    • #49 Distributing Your Plugin
    • #32 How Piwik Works
    • #64 All About Analytics Data
    • #60 Piwik's Extensibility Points
    • b94d9c6 MVC in Piwik
    • #48 Pages
    • #48 Menus
    • #48 Widgets
    • #69 JavaScript and CSS
    • #59 Visualizing Report Data
    • #43 Piwik INI Configuration (moved as sub-article of Piwik Configuration)
    • #43 Piwik Configuration (extracted "Plugin Settings" into sub-article)
    • #43 Plugin Settings
    • #56 Persistence & the MySQL Backend
    • #36 Security best practices
    • #48 Permissions
    • #37 Internationalization
    • #38 Tests
    • #63 Piwik's Reporting API
    • #50 Scheduled tasks
    • #52 Piwik on the Command Line
    • #53 Contributing to Piwik Core
    • #30 Core Team Workflow
    • #70 Theming

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.