Matomo offers the possibility to manage multiple websites in just one installation and I would like to merge two separate Matomo installations into just one Matomo installation. How can I handle this? - Is there a best practice way?
Now: Two existing Matomo Installations:
www.domain1.com/statistics
www.domain2.com/statistics
Plan: just one Matomo Installation:
statistics.domain3.com
How can export / import the data from the two existing installations and import it into just one installation? - Is there a export / import functionality?
There is a new Plugin for Matomo that allows to to move single sites to another existing Matomo instance:
https://plugins.matomo.org/Migration
Related
I was wondering if it is possible to export and import my nexus-repositories without using the task which sonartype provides to its pro-users. This way it would be possible to backup and restore one specific repository.
I used this script (had to work out some kinks) to download the artifacts from Nexus3.
The author also describes Nexus import scripts that can be used to upload the artifacts to another repository.
I want to some changes in jitsi and install from my own repository.
Actually after some changes, i want to install it in many servers with each servers have unique domain.
You can change the front-end with two options :
Option 1 (recommended)
Follow the manual installation documentation and replace «jitsi-meet» component which is in /srv/jitsi-meet
This directory must contain your version of jitsi-meet (you must build the project, follow this step but clone your repository instead official repository)
Option 2 (not recommended)
Follow the quick installation then replace the /usr/share/jitsi-meet
This is the same step but in another directory
Be careful, this option is faster but each update on jisti-meet package (apt) can break your installation and override the /usr/share/jitsi-meet directory
I created a small vue.js library that is using scss for styling and published that as npm package. It works well with a default theme included into the package. But what if I would like to provide a custom theme from the application that consumes that npm package, how would you do that?
The source for a very basic version of the library is here: https://github.com/gwildu/gwi-vue-components
The idea is, that you would copy paste the styling folder somewhere (e.g., into your application directory or into another npm package) and configure the library package to import from that copyied directory.
I did some investigation myself and found that there is a big discussion about having dynamic imports in sass since years. This issue (open since 2013) claims to add such a feature (they call it load). Not sure, how actively sass is still developed and when this feature will be supported. For now I see 3 possible solutions:
move to LESS as it supports dynamic imports. Semantic UI gives you a hint about how theming could be done in LESS
It is possible to import from relative paths in SASS. That way you are also able to import from a parent directory of your package root directory (your application directory) like, e.g., #import '../../theme/index';. You would support somewhere in your package an example of a theme that the consumer then would have to copy to, e.g., the root directory of his application and adjust it to his needs. In your package you would then import the theme from that directory in the consumers application folder. The downside is, that the package would not work out of the box
You have a default theme in your package and you add some instructions into the readme how the user can override that theme in a build script. The consumer would have to copy the default theme to his application directory, adjust it to his needs and in the build script he would replace the theme in, e.g., node_modules/your-library-package-folder/theme/ by the theme in your application folder.
To be complete here is the approach with a dynamic import (that is not yet supported by SASS):
In your main theme file in the library package (that would be imported by the components) you would do a relative import of kind of a config file from the consumers application folder like in approach 2 (see above) but that config file yould not contain the theme but only the import path of the theme in a variable. that variable then would be used by the package main theme file to import the theme. For making the library work out of the box, I guess there would be a way to have a default theme as backup if the config file in the consumers directory would not exist (not tested)
Update:
I tried approach 3 but failed to get something useful. The issue with that approach is that you would have to somehow sync your custome theme with the default theme when you update the library to a higher version which might get too complex to handle in a reasonable way. Then I tried to use the overwrite feature of SASS as described here: How to overwrite SCSS variables when compiling to CSS which led me to approach
In your library component you first import a file with possible custom variables and you declare your variables in the library as default.
The issue with that approach is that SASS does not support optional imports. The file with the custom variables have to exist somewhere. So if the library updates you again have to sync your custom theme files for each component / file that was changed in the library. Apparently SASS also don't want to support such a feature in the future: https://github.com/sass/sass/issues/779 which is sad, as it seems to me an essential feature for being able to do theming without a highly complex build step.
Overall, it seems SASS itself is making every effort to prevent a simple theming approach which makes me think of moving back to LESS again. Not having a simple way for static theming in SASS in my opinion outweight the cons of not having an easy way to define custom functions in LESS.
I need to add my own behat tests to a sylius based application. I plan to do this from my own bundle.
Reading doc at http://docs.sylius.org/en/latest/behat/how-to-add-new-context.html is not clear to me how could i add context from my own bundle.
Is this possible? Doc says you need to do this in one of the files at src/Sylius/Behat/Resources/config/services/contexts/
So, do i need to add them there or can i add new ones from my own bundle?
Thank you.
You can do that, by configuring a MultiContainerExtension in your behat.yml file.
Sylius\Behat\Extension\MultiContainerExtension:
imports:
- "src/AppBundle/Resources/config/services.xml"
With this config you can place all of your services in this file or import them. Just like regular symfony services. It is defined similar way here.
It seems to have moved to FriendsOfBehat\ContextServiceExtension in the first beta (1.0.0-beta.1) release.
I guess it's working the same way:
FriendsOfBehat\ContextServiceExtension:
imports:
- "/www/vvc/vendor/sylius/sylius/src/Sylius/Behat/Resources/config/services.xml"
- "/www/vvc/src/AppBundle/Resources/config/behat_services.xml"
And don't forget to rename your contexts_as_services to contexts_services if your are upgrading
I'm using WiX, and would like to know the .wxs necessary to take a file and install it to every available sub-directory of a particular location. This could mean 0 or more final installation locations, determined at install time based on the currently existing directory structure. For example, if I started the install with:
\target
\subdir-1
\subdir-2
Then at the end of the installation my file would be in \subdir-1 and \subdir-2. If on the other hand these directories did not exist on the system when the install was started, my file would not be installed at all and no sub directories would be created.
Afaik this is not possible with WiX (because it is basically against the nature of MSI to install a component into several locations).
You could either
create a different component for each subfolder, or
use a custom action to copy the component to all subfolders.
In the latter case you should also provide a corresponding CA for uninstallation which removes all the files from the subfolders again.
EDIT: Seems my above answer is not totally correct. MSI supports duplicating files using the DuplicateFile tables and WiX 3.0 also provides a mechanism called "smart cabbing". Both are mentioned in a blog post by Aaron Stebner.
Not without a custom action, you need to write a custom action that will do that.
The latest and greatest in custom actions is the DTF (and here) framework that comes with Wix3.
If you are targeting Vista (or Win2k8, not sure about Win2k3), you can use mklink.