@AbcSxyZ opened this Pull Request on March 12th 2020 First_time_contributor

Diagnostic are runned at the beginning of the installation, and could be a better way to use specific function used for this purpose.

@AbcSxyZ commented on March 13th 2020

I made a mistake, it was only for commit 8f4fb4a initially. But not so bad, things are related.
I didn't thought pushing to my repo would also add new commit to the PR...

I worked on a feature : https://github.com/matomo-org/matomo/issues/10257 , about Matomo installation in a automated way.

It's for me the beginning of a feature who must be review and adjusted, I wasn't able to manage all. I tried to create it as a depedent block, I juste add it to Matomo in a temporary way (5bb4565) for testing.

Please check issue, I added some comments (way to use). I know it's not finished, I think it can be a good point to start with, I tried to do as most as possible for me for the moment (I never used Matomo, don't know some cases). It can be for a new branch.

@tsteur commented on May 13th 2020 Member

@AbcSxyZ how would someone trigger the headless installation?

@AbcSxyZ commented on May 13th 2020

@AbcSxyZ how would someone trigger the headless installation?

See https://github.com/matomo-org/matomo/issues/10257#issuecomment-598262173 for some explaination. It's using a MatomoInstall section in the config file.

seems there is something to do?

Like I said, I'm not a user of matomo, so there is multiple point that I don't know how to do. I commented out those point and it's necessary to dive into the code again with someone who know matomo.

btw ideally we would put these things maybe in a command so someone can specifically trigger the headless installation?

Think only about MatomoInstaller.php file, other files of the PR is for testing, to correct some small stuff incompatible with the installer etc.
I was more thinking about it as a core feature, who can be used for any installation (and could be an helper for the actual one).

You can see the difference because between MatomoInstaller::headlessInstall and Matomo::installFromConfig have their own purpose. headlessInstall function just get all parameters, and perform the installation. installFromConfig retrieve the settings inside the MatomoInstaller section of the config file, and give them to the headlessInstall.

So what I had in mind is to allow the user to perform the installation in any way he want. He just have to define his own way to retrieve data, and give them to the MatomoInstaller::headlessInstall. In this way you [Matomo devs] could create some default way to perform the installation (through config file for exemple) and allow the user to create custom method.

@AbcSxyZ commented on May 15th 2020

Because there is a lot of edited files (7 files), I will add explaination about all of them, to detail what are purpose of the modification, hope it will be usefull.

  1. commit 8f4fb4afb1232d588d0615a794e6c313b86ed0ff, files plugins/Diagnostics/Diagnostic/{DbReaderCheck, ForceSSLCheck, NfsDiskCheck}.php (3/7)
    --> To launch diagnostic, it actually verify if matomo is installed by checking the local config file. Change it by using function SettingsPiwik::isMatomoInstalled designed for it, otherwise it create some conflict with a config file containing an installation section.

  2. commit a391f00436c8147bed254d0397438efa8dd2b164

    • file core/Db/Adapter.php (4/7)
      --> Create a function to get the default adapter instead of hardcoding it in the installer.
    • file core/MatomoInstaller.php (5/7) [THE MAIN FEATURE]
      --> Class to perform an entire installation. Actually divided by step like it is with the actual GUI (system check, databases installation, site creation ...). Mainly 2 extra function MatomoInstaller::headlessInstall and MatomoInstaller::installFromConfig, respectively used to perform all step from given settings and to retrieve settings within the config file.
  3. commit 5bb4565136fa3b06d18386b94d9ccf3be67a6f54
    • file core/SettingsPiwik.php (6/7)
      --> For SettingsPiwik::isMatomoInstalled, check if an headless install have to be performed.
    • file core/Application/Kernel/EnvironmentValidator.php (7/7)
      --> Perform the MatomoInstaller::installFromConfig. Probably not the best place to perform this call, but this allowed me to test the installer. From my memory, I was a bit lost because the environnement is called from multiple place, and it was working when called from here. It's like glue.

I hope all comments and this will help to understand my work. Remember, I'm nor a php dev, nor a matomo user so there is multiple unknow stuff to me who could (should ?) be improve. Also in multiple place, I didn't know how to deal with some errors (it should be commented within the code). Finally, to avoid duplicating code, the actual GUI installation could call function from the installer because each installation step is a function of the MatomoInstaller. Because it's important feature, I didn't add those modification to the PR, to let the headless installation being a standalone feature, but those modification should be performed at short or long term.

@AbcSxyZ commented on May 15th 2020

As an important extra, inside the MatomoInstaller, or the installer himself, it have to be rethink to allow inheritance of a couple of functions, at least MatomoInstall::isHeadlessInstall, to let the user adding custom installation methods.

Powered by GitHub Issue Mirror