Your PHP version should be fine, version 8 of concrete5 is designed to work with version 7 of PHP (and it's recommended you use PHP 7.1 or 7.2 for speed)

What this sounds like is that the install is running out of memory, and at that point the server is throwing up a custom error message.

If the installer is flagging memory as an issue, I'd be taking note of that. What does it show on screen as your memory limit before you try to install?

You'll should have at least 64M, but I'd be aiming for more than that if it's something you can configure on the host.

I'd be wondering about php's max_execution_time, or whatever it's called.

This doesn't solve the problem but it might point someone in the right direction to do so.

I had the identical problem trying to install 8.4 on a shared Hostgator account.

I was aware that I had had no problems with the same configuration when I installed another site a few weeks ago.

I checked and that site was running 8.2.1.

So, I tried an install with a copy of 8.3.2 and that didn't work.

When I tried with 8.2.1...success!

I then manually updated to 8.4 without problems.

It would appear that there is something different with installation after 8.2.1.

Thanks crldev,

I had a similar idea and tried installing 8.3.2 (because like you, I have another site running with it) and it didn't work. So I'll try 8.2.1 and see if it does.

And thanks mesuva,

In the meantime, I'm also on hold with tech support of the webhost to see if I can increase the RAM on the site.

Will post again if I have any positive results! Fingers crossed.

As already mentioned, php memory or execution time.

Try a CLI install from SSH. That is outside of the execution time limits. Beware that the version of php available from the CLI may be old - a month or two ago I ran into a CLI that defaulted to php4, so completely unable to install c5.

https://documentation.concrete5.org/developers/appendix/cli-commands...

Thanks Johnthefish, this might do it, but I'm afraid a bit out of my capabilities to implement.... :-(

So I simply can't install any version 8.

I was able to successfully install v5.7.5.13, but when trying to upgrade to v8.2.1 from there get the following message: Allowed memory size of 33554432 bytes exhausted (tried to allocate 14696448 bytes) Is this referring to RAM or something else?

If it's the RAM, I have talked to the webhost and unfortunately for me the only way to increase RAM (as previously discussed) is to go to a VPS which is complete overkill and too much $$ for this small client project. Looking for another way around. I know changing webhosts could solve it, but is tricky to due client situation, so only want to do that as a last resort, and looking for possible alternatives.

Here is my environment information. Can anyone decipher what I might need to fix on the server (other than more RAM) to get v8.2.1 to install?

THANKS

# concrete5 Version
Core Version - 5.7.5.13
Version Installed - 5.7.5.13
Database Version - 20160615000000

# concrete5 Packages
None

# concrete5 Overrides
languages/cs_CZ/LC_MESSAGES/messages.mo, languages/cs_CZ/LC_MESSAGES, languages/cs_CZ, languages/da_DK/LC_MESSAGES/messages.mo, languages/da_DK/LC_MESSAGES, languages/da_DK, languages/de_DE/LC_MESSAGES/messages.mo, languages/de_DE/LC_MESSAGES, languages/de_DE, languages/el_GR/LC_MESSAGES/messages.mo, languages/el_GR/LC_MESSAGES, languages/el_GR, languages/en_GB/LC_MESSAGES/messages.mo, languages/en_GB/LC_MESSAGES, languages/en_GB, languages/es_ES/LC_MESSAGES/messages.mo, languages/es_ES/LC_MESSAGES, languages/es_ES, languages/es_PE/LC_MESSAGES/messages.mo, languages/es_PE/LC_MESSAGES, languages/es_PE, languages/es_PY/LC_MESSAGES/messages.mo, languages/es_PY/LC_MESSAGES, languages/es_PY, languages/fi_FI/LC_MESSAGES/messages.mo, languages/fi_FI/LC_MESSAGES, languages/fi_FI, languages/fr_FR/LC_MESSAGES/messages.mo, languages/fr_FR/LC_MESSAGES, languages/fr_FR, languages/it_IT/LC_MESSAGES/messages.mo, languages/it_IT/LC_MESSAGES, languages/it_IT, languages/ja_JP/LC_MESSAGES/messages.mo, languages/ja_JP/LC_MESSAGES, languages/ja_JP, languages/nb_NO/LC_MESSAGES/messages.mo, languages/nb_NO/LC_MESSAGES, languages/nb_NO, languages/nl_NL/LC_MESSAGES/messages.mo, languages/nl_NL/LC_MESSAGES, languages/nl_NL, languages/pl_PL/LC_MESSAGES/messages.mo, languages/pl_PL/LC_MESSAGES, languages/pl_PL, languages/pt_BR/LC_MESSAGES/messages.mo, languages/pt_BR/LC_MESSAGES, languages/pt_BR, languages/ru_RU/LC_MESSAGES/messages.mo, languages/ru_RU/LC_MESSAGES, languages/ru_RU, languages/sv_SE/LC_MESSAGES/messages.mo, languages/sv_SE/LC_MESSAGES, languages/sv_SE, languages/tr_TR/LC_MESSAGES/messages.mo, languages/tr_TR/LC_MESSAGES, languages/tr_TR, languages/cs_CZ/LC_MESSAGES/messages.mo, languages/cs_CZ/LC_MESSAGES, languages/cs_CZ, languages/da_DK/LC_MESSAGES/messages.mo, languages/da_DK/LC_MESSAGES, languages/da_DK, languages/de_DE/LC_MESSAGES/messages.mo, languages/de_DE/LC_MESSAGES, languages/de_DE, languages/el_GR/LC_MESSAGES/messages.mo, languages/el_GR/LC_MESSAGES, languages/el_GR, languages/en_GB/LC_MESSAGES/messages.mo, languages/en_GB/LC_MESSAGES, languages/en_GB, languages/es_ES/LC_MESSAGES/messages.mo, languages/es_ES/LC_MESSAGES, languages/es_ES, languages/es_PE/LC_MESSAGES/messages.mo, languages/es_PE/LC_MESSAGES, languages/es_PE, languages/es_PY/LC_MESSAGES/messages.mo, languages/es_PY/LC_MESSAGES, languages/es_PY, languages/fi_FI/LC_MESSAGES/messages.mo, languages/fi_FI/LC_MESSAGES, languages/fi_FI, languages/fr_FR/LC_MESSAGES/messages.mo, languages/fr_FR/LC_MESSAGES, languages/fr_FR, languages/it_IT/LC_MESSAGES/messages.mo, languages/it_IT/LC_MESSAGES, languages/it_IT, languages/ja_JP/LC_MESSAGES/messages.mo, languages/ja_JP/LC_MESSAGES, languages/ja_JP, languages/nb_NO/LC_MESSAGES/messages.mo, languages/nb_NO/LC_MESSAGES, languages/nb_NO, languages/nl_NL/LC_MESSAGES/messages.mo, languages/nl_NL/LC_MESSAGES, languages/nl_NL, languages/pl_PL/LC_MESSAGES/messages.mo, languages/pl_PL/LC_MESSAGES, languages/pl_PL, languages/pt_BR/LC_MESSAGES/messages.mo, languages/pt_BR/LC_MESSAGES, languages/pt_BR, languages/ru_RU/LC_MESSAGES/messages.mo, languages/ru_RU/LC_MESSAGES, languages/ru_RU, languages/sv_SE/LC_MESSAGES/messages.mo, languages/sv_SE/LC_MESSAGES, languages/sv_SE, languages/tr_TR/LC_MESSAGES/messages.mo, languages/tr_TR/LC_MESSAGES, languages/tr_TR

# concrete5 Cache Settings
Block Cache - On
Overrides Cache - On
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).

# Server Software
Apache

# Server API
cgi-fcgi

# PHP Version
7.0.2-pl0-gentoo

# PHP Extensions
bcmath, bz2, calendar, cgi-fcgi, Core, ctype, curl, date, dba, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imagick, imap, ionCube Loader, json, libxml, mbstring, mcrypt, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, pspell, readline, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend OPcache, zip, zlib

# PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - -1
max_input_vars - 1000
memory_limit - 32M
post_max_size - 100M
sql.safe_mode - Off
upload_max_filesize - 100M
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 3600
soap.wsdl_cache_limit - 5
opcache.max_accelerated_files - 2000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5

It wouldn't surprise me if this is something to do with image resizing (eg, thumbnailing). One way to test this would be to delete images (especially large ones) from the site before attempting the upgrade, but that's a fairly painful thing to do.

...especially since I'm just guessing wildly.

I think regardless of whether you can get it installed or not, a memory limit of 32M is going to be problematic long term. Other tasks in concrete5 might end up hitting that limit, future upgrades, etc, etc. The system requirements lists 64M as a minimum.

What I'd be wondering is whether you actually have more memory available on your host, it's just that it has to be configured by an htaccess or php.ini line.

Your host might be talking about maximum amount of _total_ memory you are allowed, by all of your requests all at once. But in this case it's the memory_limit value that is too low and that's the per request maximum. I'd be specifically asking if they can help you adjust that (or you could try yourself).

32M is very low these days, I actually think that's too low for even Wordpress installs (which is either something like 40 or 64, and many recommend 256M for stuff like WooCommerce).
So this host really wouldn't be able to run any decent CMS with this restriction.

I'd go back to them and ask specifically for the memory_limit limit to be lifted to at least 64, and avoid the use of RAM in the conversation, as that's more about server resources.

Completely agree. 32M is way too low for many modern applications.

Another possible solution in the meantime is to install on another host, backup the database and directories and transfer them to the weak one.

Won't help with possible future problems, but could get things going...

Thanks again Mesuva and jasteele12!

I agree that the memory limit on this host is dumb, especially since it's not that much to begin with. I'm going to try and see if I can get it increased by asking a different way, and talking to a different department.

jasteele12 your idea is interesting, could work and I might try just for the fun of it, but I'm concerned I'll have problems long term because of the memory issue -- although this isn't going to be a very big site, and probably not get THAT much traffic...