Add New Premium Plugin

Why these changes are being introduced:
A third premium plugin was purchased from InnoCraft. At the same time,
one of the other premium plugins had a pending update. Per the
documentation in the HOWTO-premium-plugins.md, this pass through the
repository just installs the plugin directory and files but does not
activate the plugin.

Additionally, we revert the copying of the config.ini.php file back to
the /var/www/html folder instead into the source folder. Now that we
have established the persistent storage for the config.ini file, we
don't need to worry about forcing it into the source.

How this addresses that need:
* Add the source code for the SearchEngineKeywordsPerformance plugin to
the files/ directory
* Add the new version for the HeatmapSessionRecording plugin to the
files/ directory
* Update the Dockerfile to copy the new plugin sources to the plugins/
directory
* Update the Dockerfile to copy the config.ini.php to /var/www/html
instead of to /usr/src/matomo
* Update the backup-data.sh script to make it a little cleaner
* Update the HOWTO-premium-plugins.md documentation
* Update the HOWTO-miscellaneous.md documentation to address a TooManyRedirectsException

Relevant ticket(s):
* https://mitlibraries.atlassian.net/browse/INFRA-558

Author: cabutlermit

Dockerfile

@@ -9,16 +9,16 @@ COPY ./files/plugin-EnvironmentVariables-5.0.3/ /var/www/html/plugins/Environmen
 COPY ./files/plugin-CustomVariables-5.0.4/ /var/www/html/plugins/CustomVariables
 
 # Add the HeatmapSessionRecording plugin
-COPY ./files/plugin-HeatmapSessionRecording-5.2.3/ /var/www/html/plugins/HeatmapSessionRecording
+COPY ./files/plugin-HeatmapSessionRecording-5.2.4/ /var/www/html/plugins/HeatmapSessionRecording
 
 # Add the UsersFlow plugin
 COPY ./files/plugin-UsersFlow-5.0.5/ /var/www/html/plugins/UsersFlow
 
-# Our custom configuration settings. We put it in /usr/src because the 
-# entrypoint.sh builds the /var/www/html folder from the /usr/src/matomo 
-# folder. This ensures that the config file from our updated container is the 
-# one that is pushed to the persistent EFS storage.
-COPY ./files/config.ini.php /usr/src/matomo/config/config.ini.php
+# Add the SearchEngineKeywordsPerformance plugin
+COPY ./files/plugin-SearchEngineKeywordsPerformance-5.0.22/ /var/www/html/plugins/SearchEngineKeywordsPerformance
+
+# Our custom configuration settings.
+COPY ./files/config.ini.php /var/www/html/config/config.ini.php
 
 # The HeatmapSessionRecording and UsersFlow update the matomo.js and piwik.js
 # files when they are activated. Those updates have been captured and we

docs/HowTos/HOWTO-miscellaneous.md

@@ -34,8 +34,13 @@ To retrieve the **task number** value for the command:
 OR
 
 ```bash
-aws ecs list-clusters --output text | grep matomo | cut -d'/' -f2
-aws ecs list-tasks --cluster $(aws ecs list-clusters --output text | grep matomo | cut -d'/' -f2) --query "taskArns[*]" --output text | cut -d'/' -f3
+aws ecs execute-command --region us-east-1 --cluster $(aws ecs list-clusters --output text | grep matomo | cut -d'/' -f2) --task $(aws ecs list-tasks --cluster $(aws ecs list-clusters --output text | grep matomo | cut -d'/' -f2) --query "taskArns[*]" --output text | cut -d'/' -f3) --command "/bin/bash" --interactive
+```
+
+If you need to force a redeployment of the task for the service, this one-liner will work:
+
+```bash
+aws ecs update-service --cluster $(aws ecs list-clusters --output text | grep matomo | cut -d'/' -f2) --service $(aws ecs list-services --cluster $(aws ecs list-clusters --output text | grep matomo | cut -d'/' -f2) --output text | grep matomo | cut -d'/' -f3) --force-new-deployment
 ```
 
 ## Reset 2-Factor auth

docs/HowTos/HOWTO-premium-plugins.md

@@ -8,7 +8,7 @@ After some initial testing in Dev1, it's not as simple as just dumping the new p
 1. Some plugins require changes to the database tables or just new tables. This requires that the plugin installation process is triggered to kick off the script that updates the tables.
 1. The *Marketplace* plugin must be active for license keys to work.
 
-## The config.ini.php file
+## A note about the config.ini.php file
 
 The `config.ini.php` file has two lists of plugins under two different headings.
 
@@ -22,28 +22,30 @@ In the end, the premium plugin installation is a two-pass process.
 
 ### High level overview
 
-1. Install license key (via UI or CLI) so that it is in the database.
-2. Go through a dev -> stage -> prod deployment cycle of the container to install the plugin folder(s) into the container.
+1. Install license key (via UI or CLI) so that it is in the database (this apparently only needs to be done once as all future premium plugins get linked to the same license key).
+2. Go through a dev -> stage -> prod deployment cycle of the container to install the plugin folder(s) into the container
 3. Activate the new plugin(s) (via UI or CLI) so that any database changes are properly executed.
 4. Go through a dev -> stage -> prod deployment cycle of the container to match the updated `config.ini.php` file on the server.
 
 ### Details for each step
 
 #### 1. Install the license key
 
-Before installing the license key, the *Marketplace* plugin must be activated. This is a one-time update to the `config.ini.php` file to add the *Marketplace* pluging to the `[Plugins]` section.
+Before installing the license key, the *Marketplace* plugin must be activated. This is a one-time update to the `config.ini.php` file to add the *Marketplace* pluging to the `[Plugins]` section - all new premium plugin purchases are linked to the same license key.
 
 According to the support team at Matomo, the premium license key can be installed in two instances of Matomo, "stage" and "prod." So, we can do some initial validation of a license key in Dev1, but the key cannot remain installed in the Dev1 instance. The license key installation can either be done by a user with "superuser" privileges in the Matomo web UI or it can be done by a member of InfraEng who has ssh access to the running container task/service. The CLI command is
 
 ```bash
 ./console marketplace:set-license-key --license-key=LICENSE-KEY "<key>"
 ```
 
-This needs to be done on each of the stage & prod instances of Matomo.
+This needs to be done once on each of the stage & prod instances of Matomo.
 
 #### 2. Install the plugin files
 
-In this phase, the files are installed in the container *but no changes are made to the `config.ini.php` file. This will **not** activate the plugins, it will just make them visible in the UI.
+In this phase, the files are installed in the container **but** no changes are made to the `config.ini.php` file. This will **not** activate the plugins, it will just make them visible in the UI.
+
+**Note**: It is possible to do this with the `/var/www/html/console` utility when logged in to the cli of the running conatiner. However, that method introduces potential file permission errors since the command is run as `root` and the content in the `/var/www/html` folder needs to be owned by `www-data`.
 
 #### 3. Activate the plugin
 
@@ -53,7 +55,9 @@ Once the plugin files are installed in the container, it's time to activate the
 ./console plugin:activate [<plugin>...]
 ```
 
-This will change the `config.ini.php` file on the container. It is **very** important to capture these changes and put them back in the `config.ini.php` in the container (see step 4).
+This will change the `config/config.ini.php` file -- which is actually persisted on the EFS filesystem linked to the container. It is important to capture any changes that happen in this file so that we can back-fill this repository in case we need to redeploy in a DR scenario.
+
+It's also important to note that this `plugin:activate` command very likely makes changes to the database (adding/removing tables/columns or other changes).
 
 #### 4. Backfill this repo
 

files/backup-data.sh

@@ -1,15 +1,31 @@
 #!/bin/bash
 
-target_dir="/mnt/efs"
+# Define source directories
+source_dirs=(
+    "/var/www/html/config"
+    "/var/www/html/misc"
+    "/var/www/html/js"
+)
 
-mkdir -p "$target_dir/config"
-tar -cf - -C "/var/www/html/config" . | tar -xf - -C "$target_dir/config"
+# Define target directory
+target_dir="/mnt/efs/backups"
 
-mkdir -p "$target_dir/misc"
-tar -cf - -C "/var/www/html/misc" . | tar -xf - -C "$target_dir/misc"
+# Loop through each source directory and duplicate it to the target directory
+for src in "${source_dirs[@]}"; do
+    # Extract the directory name from the source path
+    dir_name=$(basename "$src")
+    
+    # Create the target directory if it doesn't exist
+    mkdir -p "$target_dir/$dir_name"
+    
+    # Use tar to duplicate the directory
+    tar -cf - -C "$src" . | tar -xf - -C "$target_dir/$dir_name"
+done
 
-mkdir -p "$target_dir/js"
-tar -cf - -C "/var/www/html/js" . | tar -xf - -C "$target_dir/js"
+echo "Directories have been successfully duplicated to $target_dir."
 
 cp -a "/var/www/html/matomo.js" "$target_dir/matomo.js"
 cp -a "/var/www/html/piwik.js" "$target_dir/piwik.js"
+
+# finally, make sure everything is www-data:www-data
+chown -R www-data:www-data "$target_dir"