Cloudron Forum

What is the process for submitting a packaged app for inclusion in the app store? I see the "app wishlist" category here in the forum, but these seem to be user requests. If an app's project team goes through the process of properly packaging their app per the instructions above, what's the best way for them to request inclusion?

I am thinking in particular about BTCPay Server, which has been requested at https://forum.cloudron.io/topic/3956/btcpayserver. I'm asking the BTCPay team now if they'd be interested in doing the work, but want to make sure they'd have a reasonable chance of getting it added if they do so.

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.

Got it, thanks @p44 and @jdaviescoates.

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.

@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 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.

FYI, I just pinged the Commento team about merging the blocking merge request: https://gitlab.com/commento/commento/-/merge_requests/88#note_495324294

@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!

@girish said in Disaster recovery - Restoring a backup:

If you have any suggestions on how to reduce this confusion, we are open to ideas.

Thanks for the explanation. Indeed, the visually similar version numbers did throw me off here. Perhaps one way to make things clearer would be to explicitly mention both app version and package version in the installation dialog. Then the reader can't miss the distinction.

@cbeams wrote:

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.

Just re-iterating this here, as I think it's actually the more important improvement request. Shouldn't there be a more first-class way to discover and install older app/package versions? This is an important use case for anyone doing disaster recovery for an app older than the latest version.

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.

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