Got it, thanks @p44 and @jdaviescoates.

This is a follow-up to the conversation at https://forum.cloudron.io/topic/2688/disaster-recovery-restoring-a-backup/2?_=1611914904153.

Currently, the only way to install a version of an app other than the current/latest version is to manually manipulate the version property in the query string during the installation process. This is basically an undocumented feature, and even when one knows about it, one doesn't have any simple way of knowing which versions are available.

Ideally, the app installation dialog would present the user with a dropdown of available app versions, defaulting to the latest/current version. This is an important use case when recovering from a backup of an app older than the latest version. The user is instructed to make sure that the new app and the app being recovered have the same version, but there is no way to actually do that unless the user knows about this semi-hidden feature.

@girish wrote:

Are you able to open a request [for this]?

Done, thanks: https://forum.cloudron.io/topic/4306/provide-ui-support-for-choosing-app-package-version-during-installation

I'm also a bit frustrated with Commento, primarily due to the fact that migrating between domains is unsupported / undocumented, and in researching that, I've noticed a number of people complaining about support (on the paid product). I've noticed that the existing requests about domain migrations haven't been taken seriously by the app author. I'm just getting started migrating to Commento, and I've held off because of these concerns. For example, see https://gitlab.com/commento/commento/-/issues/225.

In the search for alternatives, I too found Remark42, and I've just added an issue to their tracker asking if they'd be interested in packaging it up for inclusion in the Cloudron app store. See/watch https://github.com/umputun/remark42/issues/865 for details.

I have imported several years of data from Google Analytics into my Matomo instance, and upon attempting to view a multi-year range of Visits Over Time, I am getting the following error:

Oops… there was a problem during the request. Maybe the server had a temporary issue, or maybe you requested a report with too much data. Please try again. If this error occurs repeatedly please contact your Matomo administrator for assistance.

Looking at the logs, I see out of memory errors like the following:

Feb 08 06:39:17 [Mon Feb 08 05:39:17.396474 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16384 bytes) in /app/code/libs/Zend/Db/Statement/Pdo.php on line 233, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1
Feb 08 06:39:17 [Mon Feb 08 05:39:17.399492 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 163840 bytes) in /app/code/vendor/composer/ClassLoader.php on line 444, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1
Feb 08 06:39:17 [Mon Feb 08 05:39:17.400723 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Uncaught Error: Class 'Zend_Db_Statement_Exception' not found in /app/code/libs/Zend/Db/Statement/Pdo.php:236\nStack trace:\n#0 /app/code/libs/Zend/Db/Statement.php(300): Zend_Db_Statement_Pdo->_execute(Array)\n#1 /app/code/libs/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)\n#2 /app/code/libs/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('INSERT INTO ses...', Array)\n#3 /app/code/core/Db/Adapter/Pdo/Mysql.php(309): Zend_Db_Adapter_Pdo_Abstract->query('INSERT INTO ses...', Array)\n#4 /app/code/core/Session/SaveHandler/DbTable.php(122): Piwik\\Db\\Adapter\\Pdo\\Mysql->query('INSERT INTO ses...', Array)\n#5 /app/code/core/Session/SaveHandler/DbTable.php(156): Piwik\\Session\\SaveHandler\\DbTable->query('INSERT INTO ses...', Array)\n#6 [internal function]: Piwik\\Session\\SaveHandler\\DbTable->write('6543b55875760dd...', 'a:17:{s:12:"not...')\n#7 {main}\n thrown in /app/code/libs/Zend/Db/Statement/Pdo.php on line 236, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1
Feb 08 06:39:17 [Mon Feb 08 05:39:17.402563 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 163840 bytes) in /app/code/vendor/composer/ClassLoader.php on line 444, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1

The operative line there is:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 450560 bytes)

Searching for this error, I came upon this page: https://matomo.org/docs/setup-auto-archiving/#increase-php-memory-limit

Which instructs me to add the following to my php.ini file:

memory_limit = 512M

Note that based on the error message above, "Allowed memory size of 134217728 bytes exhausted", I assume I currently have 134217728/(1024*1024) = 128M allocated, so bumping to 512M should be more than enough.

Note also that I have allocated 768M RAM to the Matomo container in Config > Resources, so there should be enough to give 512M to PHP as directed in the php.ini file.

After adding this param to the php.ini file, I restarted Matomo. Everything comes back up fine, and I am able to view pages and queries that are less resource intensive, but when I attempt to load the same multi-year Views Over Time query, I end up with the same PHP Fatal Error, indicating that 134217728 of allocated memory has been exhausted.

This suggests to me that the settings in data/php.ini are not in fact being respected as advertised in its comments:

; Settings here are merged with the package's built-in php.ini

Any ideas what could be the problem here? Thanks.

@nebulon Thanks, I've successfully submitted a merge request at https://git.cloudron.io/cloudron/dashboard/-/merge_requests/2.

@girish thanks for the response, makes sense. By the way, it looks like you pasted a screenshot from Bookstack's settings screen, as opposed to wiki.js. So far as I can tell, Wiki.js does not have equivalent "make this instance private to logged in users" functionality.

Also note that it looks like CloudFlare's "Access" feature could be a way to lock down whole subdomains/apps to logged in Cloudron users, regardless of whether the app explicitly supports doing so. https://www.cloudflare.com/teams/access/

@nebulon Agreed, making, restoring an app from scratch would make things more intuitive and even easier. I did have to read and re-read and try things out manually to really figure out what I needed to do.

I think the dropdown would be good in any case though. It could be that a user simply wants to install an older version of an app, perhaps not for recovery, but for testing e.g. to reproduce a version-specific bug.

I too am unable to fork either the box or dashboard projects. The fork button is available on both repositories, but unclickable. When I attempt to directly edit a file within the dashboard project, I am taken into the fork workflow, but then see the following error when actually trying to fork the project:

When clicking "Try to fork again", I see:

It appears that as a new user, I am unable to create any projects at all, and this is why I cannot fork. Indeed, if I return to the main GitLab dashboard and try to click "Create project", it is also unclickable:

Could you see about tweaking the quotas for new users to make this possible? Note that I've just signed the CLA as well.

The changes I'm going to propose are very minor, just some typo fixes. Thanks.

@girish There appears to be a bug when installing older, non-current versions by modifying the query string as mentioned above.

This is what it looks like when I try to install an older version of Ghost (v3.139.4) when the current version is 3.40.5:

Notice how the dialog tells me I'm going to be installing the current version versus the one I specified. I thought that this meant that the query string technique didn't (any longer) work, so I tried a bogus version number (v42.0.0) and got the following error message:

Then I figured it's just a display bug, and went ahead with the installation. The desired older version (v3.139.4) was indeed installed correctly, but the process was pretty confusing.

Perhaps more importantly, I would have had no way of knowing how to install an older version of an app if I hadn't seen this forum post and the tip above about changing the query string. I would have expected there to be a drop down, or at least text field available in the installation workflow to allow me to specify a version other than the most current.

I've since searched the docs as well, and I couldn't find anything on this feature. In any case, I'm glad it's there, and the process of testing out my remote backups against this older app version was incredibly smooth!

@cbeams Everything works as expected now against v1.24.0, thanks!

@girish Will do now, and will let you know, thanks!

I have imported several years of data from Google Analytics into my Matomo instance, and upon attempting to view a multi-year range of Visits Over Time, I am getting the following error:

Oops… there was a problem during the request. Maybe the server had a temporary issue, or maybe you requested a report with too much data. Please try again. If this error occurs repeatedly please contact your Matomo administrator for assistance.

Looking at the logs, I see out of memory errors like the following:

Feb 08 06:39:17 [Mon Feb 08 05:39:17.396474 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16384 bytes) in /app/code/libs/Zend/Db/Statement/Pdo.php on line 233, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1
Feb 08 06:39:17 [Mon Feb 08 05:39:17.399492 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 163840 bytes) in /app/code/vendor/composer/ClassLoader.php on line 444, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1
Feb 08 06:39:17 [Mon Feb 08 05:39:17.400723 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Uncaught Error: Class 'Zend_Db_Statement_Exception' not found in /app/code/libs/Zend/Db/Statement/Pdo.php:236\nStack trace:\n#0 /app/code/libs/Zend/Db/Statement.php(300): Zend_Db_Statement_Pdo->_execute(Array)\n#1 /app/code/libs/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)\n#2 /app/code/libs/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('INSERT INTO ses...', Array)\n#3 /app/code/core/Db/Adapter/Pdo/Mysql.php(309): Zend_Db_Adapter_Pdo_Abstract->query('INSERT INTO ses...', Array)\n#4 /app/code/core/Session/SaveHandler/DbTable.php(122): Piwik\\Db\\Adapter\\Pdo\\Mysql->query('INSERT INTO ses...', Array)\n#5 /app/code/core/Session/SaveHandler/DbTable.php(156): Piwik\\Session\\SaveHandler\\DbTable->query('INSERT INTO ses...', Array)\n#6 [internal function]: Piwik\\Session\\SaveHandler\\DbTable->write('6543b55875760dd...', 'a:17:{s:12:"not...')\n#7 {main}\n thrown in /app/code/libs/Zend/Db/Statement/Pdo.php on line 236, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1
Feb 08 06:39:17 [Mon Feb 08 05:39:17.402563 2021] [php7:error] [pid 241] [client 172.18.0.1:53456] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 163840 bytes) in /app/code/vendor/composer/ClassLoader.php on line 444, referer: https://matomo.beams.io/index.php?module=CoreHome&action=index&date=today&period=day&idSite=4&updated=1

The operative line there is:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 450560 bytes)

Searching for this error, I came upon this page: https://matomo.org/docs/setup-auto-archiving/#increase-php-memory-limit

Which instructs me to add the following to my php.ini file:

memory_limit = 512M

Note that based on the error message above, "Allowed memory size of 134217728 bytes exhausted", I assume I currently have 134217728/(1024*1024) = 128M allocated, so bumping to 512M should be more than enough.

Note also that I have allocated 768M RAM to the Matomo container in Config > Resources, so there should be enough to give 512M to PHP as directed in the php.ini file.

After adding this param to the php.ini file, I restarted Matomo. Everything comes back up fine, and I am able to view pages and queries that are less resource intensive, but when I attempt to load the same multi-year Views Over Time query, I end up with the same PHP Fatal Error, indicating that 134217728 of allocated memory has been exhausted.

This suggests to me that the settings in data/php.ini are not in fact being respected as advertised in its comments:

; Settings here are merged with the package's built-in php.ini

Any ideas what could be the problem here? Thanks.

@nebulon Thanks for looking into it further. It certainly is an annoying problem!

That's interesting regarding the session table, especially in light of this comment from https://github.com/matomo-org/matomo/issues/15625#issuecomment-770846839

Maybe session file on your server gets removed for some reason. Don't know what could be the problem.

Perhaps he is confused about this too, but I assumed he was someone knowledgeable about Matomo.

@nebulon sigh... I take it back. I thought I had this sorted, but I've been getting logged out again as I was before.

A quick look at the session store reveals, that no sessions are saved to /run/matomo/session this is odd, but maybe matomo is actually using some other storage somewhere else...have to investigate

Indeed my /run/matomo/session dir is empty as well, but I do notice that /run/matomo/tmp/sessions is not:

root@dc23980a-557c-4199-ad52-8d1139a19467:/app/code# ls -l /run/matomo/tmp/sessions/
total 16
-rw-r--r-- 1 www-data www-data  20 Feb  1 15:42 index.htm
-rw-r--r-- 1 www-data www-data  20 Feb  1 15:42 index.php
-rw------- 1 www-data www-data 278 Jan 16 16:58 sess_58ac4nlca9d8na9tb4selvf1mu
-rw------- 1 www-data www-data 278 Jan 16 16:58 sess_b6ah1mt6739rjka699reutrf54

Both of the session files there are rather old, though, and neither match the active session ID I see in my browser's dev tools:

Perhaps this provides a clue.

P.S.: If you notice the longer-than-usual expiry period for my cookie, it's because I set login_cookie_expire = 315360000 in config.ini per the instructions here as part of my previous attempts to solve this problem. The config parameter does in fact extend the expiry beyond the default, but does not have any effect on getting remember me functionality to actually work.

@nebulon Thanks. As I mentioned in a follow-up to my comment above, I've actually now gotten everything working as expected, or at least it seems that way. I think it had something to do with one of or a combination of:

• clearing my cookies for the site
• logging out of matomo
• quitting my browser process
• restarting matomo itself

At some point in the process of doing all these things, I started getting the expected remember me' / persistent login behavior.

I'm still seeing this behavior (remember me not working) on the latest Matomo Package v1.23.1 / App v4.1.1. I see the fix for it happened quite a while ago at https://github.com/matomo-org/matomo/issues/15625#issuecomment-592580628, so I don't understand why it's still happening. See my comment about it at https://github.com/matomo-org/matomo/issues/15625#issuecomment-770823919.

I’ve gotten Möbius set up in the meantime and it’s quite promising so far. My core use case works, which is syncing a few markdown files between my Mac and iPhone, so I can edit with Vim in the Mac and iaWriter on the phone, keeping them in sync as I do. This has so far been impossible for me to set up in any usable way (without resorting to Dropbox or iCloud), so syncthing and Möbius are really looking good.

Here are a couple issues and questions I’ve run into along the way:

https://github.com/MobiusSync/MobiusSync/issues/7#issuecomment-770217846

https://github.com/MobiusSync/MobiusSync/issues/26#issuecomment-770235377

Just catching up on this thread, thanks, @necrevistonnezr for the writeup. Has anyone tried the Möbius Sync iOS client? I'm not sure how new it is, perhaps it wasn't around when this thread was active. In any case, I'd be interested to hear pros and cons between these two approaches.

https://www.mobiussync.com/

@nebulon Agreed, making, restoring an app from scratch would make things more intuitive and even easier. I did have to read and re-read and try things out manually to really figure out what I needed to do.

I think the dropdown would be good in any case though. It could be that a user simply wants to install an older version of an app, perhaps not for recovery, but for testing e.g. to reproduce a version-specific bug.