Using wget to Download a Matomo Widget

(Roddy A. Stegemann) #1

Recently I have sought to access Matomo widget using wget. Although some progress has been made, Matomo is rejecting me with the following error message:

The requested website idSite is not found in the request, or is invalid. Please check that you are logged in Matomo and have permission to access the specified website.

The wget string that I am using is the following:

wget    --http-user=[...]
        -P /tmp/ -p -k

Now, I am sure that the following are correct:

QUESTION:  What is missing, or improperly coded?


(Louis) #2

Hey @Kiusau, I don’t think you can widgetize or call iframe from corehome - I could be wrong.

For the Goals overview you could use, as an example:

(Roddy A. Stegemann) #3

Hi, Louis!

Thank you for the suggestion, but my goal is to obtain a graphical image over time. Fabian Delwing, I believe it was in the German forum, is the one who suggested wget.

If I have understood you correctly, one cannot obtain anything directly from the CoreHome that does not go through the Dashboard – widget or otherwise. Surely there is a different avenue. I just have to discover the right module and method.

At least you have dissuaded me from the wrong route.

Many thanks!


(Louis) #4

Do you require an interactive element or simply the trend of something as an image? Matomo can create that for you:

(Roddy A. Stegemann) #5

Yes, Lousi! That just might work.
I can create my own interaction by allow my visitors to modify the parameters.

The question remains, of course, whether I can obtain it using wget.
I will try it, and let you know the outcome. It will likely be a day or two. So please be patient.

Thank you, for sticking with on this.


(Louis) #6

You’re welcome. Although I have to confess as I do not know what you are trying to do, my suggestion is only based on your original issue and not what you are looking to develop.

(Roddy A. Stegemann) #7

Originally, the idea was to download a completed widget into a PHP file and then display it in an iframe as the value of the source attribute. Loading the widget into the PHP file would keep hidden the authorization token necessary to call the widget.

A graphic image will suffice, however, for I can make the graph pseudo interactive by allowing the visitor to select the parameter values for the PHP request via AJAX.


(Louis) #8

Are you just looking for a way to completely hide the token by a server side (back end) facility?

So then any GET requests from the client (front end) side do not show the token of a Matomo user account?

If so, then you are approaching this in the right way, that you can’t do what you are looking to do via the front end.

I think you will need to build your own php widget/app and then pass dynamic parameters from the front to back end when a User selects them via a form post method or Ajax.

That sounds like what you said you wanted to do.

(Roddy A. Stegemann) #9

Yes. That is my goal. In addition, I want to make what I display available to everyone.

Matomo’s strategy is to provide everything to a selected few or everything to all. My strategy is to provide a selected something to everyone.


(Louis) #10

Yeah, the governance is pretty basic really. You need to build that. Any server side languages would work tho, unless you are comfortable with php and that would probably be the best choice here.

(Roddy A. Stegemann) #11

Yes, I am most familiar with PHP, but I am knew to wget and the PHP exec() and system() commands.

I will let you know the outcome, I promise.


(Louis) #12

Just a thought, have you considered creating a simple server side include file that runs the http get request (AP) with the variables coming from the front as query strings set by the user?

This would be the most basic and simple approach for you, then you could make more intelligent and efficient if the results are as expected.

(Roddy A. Stegemann) #13

I have never used the include() method in the suggested manner.

The problem, as I have experienced it, is that Matomo widgets are dependent on browser functionality for their rendering, and in order to create a browser rendering you must create an HTML document. As soon as you do this, however, you become exposed. The idea of wget is to create the widget without the document, and then move the result into the document.

Are you suggesting that a simple include statement could achieve the same?


(Louis) #14

I’m not quite sure of your need to have a Matomo widget to surface Matomo recorded analytics.

Maybe I am missing something.

You could use an SSI to send a GET request to Matomo, either local or external and then send the response back to the browser. Your token would only be passed from server to server and the client should not be able to see that request, only the response. You could easily test this with a html format API request.

This is theory, if you are interested in this approach I can run a test on my own environments.

(Roddy A. Stegemann) #15

Hi, Louis!

I am relatively confident that I can obtain the historical data that I need to create the graphs that I would like to produce. Simply, Matomo has already done the work to build the graphs, and I thought it silly to duplicate it.

Philosophical Note: Now, it might just be that I have to create my own graphs, and why not? I have done nearly everything else on my website from scratch. Simply, some day I have to start earning money, and I do not want to end up painting the same picture for my whole life and die in poverty.


(Louis) #16

Let me know how it goes :slight_smile:

(Roddy A. Stegemann) #17

Well, I did not exactly reinvent the wheel, but the first of my many graphs to come has been successfully generated. I am currently using Chart.js and the data from the Live.getLastVisitsDetails method.

You can see the result at
Look under the heading Visitor Profile in the navigation bar. Please be patient as Matomo struggles to perform … :slight_smile:


(Roddy A. Stegemann) #18

Although the Live.getLastVisitsDetails() still appears to have been the properly selected method, the serverDate parameter leads to data inconsistency with other visit-related parameters. Use the serverDatePretty parameter and strip away its “pretty” formatting, instead.