This as the install completes:
You do not appear to have a version of PHP installed on your webserver that meets ElkArte's minimum installations requirements.
phpinfo reports:
PHP Version 5.4.45-1~dotdeb+7.1
command line reports:
php -v
PHP 5.4.45-1~dotdeb+7.1 (cli) (built: Sep 4 2015 23:38:46)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
Minimum requirements state > 5.2
So what's the deal guys? Can I run this please...
I've spent hours trying to find a self-hosted, responsive (yay - Bootstrap!), PHP/MySQL discussion forum that looks good, can can be easily skinned, only to hit the buffers. Where's this test carried out - can I obliterate it please???
I guess the dot deb build might be confusing your checks?
thanks
TSG
The test is done comparing the required version with the native constant PHP_VERSION that is defined by PHP itself.
Out of curiosity, would you mind reporting the value of this constant?
For example:
php -r "echo PHP_VERSION;"
~# php -r "echo PHP_VERSION;"
5.4.45-1~dotdeb+7.1<redacted as irrelevant>
;-)
Incidentally, the host VM was due an upgrade so I cloned the container, and then while I was about it I removed the dot deb package, and the pinning etc. and did a dist-upgrade (to Jessie) on my new cloned container. I now have 5.6.36... (official Debian pkg) and it's producing exactly the same error on trying to load the forum... ???
Can you 'echo PHP_VERSION' in an web page? I have it installed on debian using jessie and stretch along with sid, with no issues.
& 5.4.45-1~dotdeb+7.1 comes right back at you...
I've checked php.ini to make sure none of the other dependencies are wrong - tons of headroom on all the size limits, the appropriate extensions (bcmath and gd) are there and running...
???
If you can email me, I'll send you the URL so you can see for yourself... ;-)
Are you installing from the Github Master or the the package available: https://github.com/elkarte/Elkarte/releases/download/v1.1.4/ElkArte_v1-1-4_install.zip
I was using Github master, but I'm now downloading this version 1.1.4 and will let you know what happens...
OK, so now it doesn't complain about the PHP version, but instead tells me that my db user doesn't have ALTER, CREATE & DROP privileges.
The db user has database wide permissions for everything except GRANT. No global permissions of course, as is standard.
So what does this error message mean. Again, not what it says I think? Any ideas what is really going on here - this is a dead simple nginx / php5-fpm server that's running a load of PHP websites without issue... ???
I'm stumped.
PS - the self-same db user accessed the empty db ( I dropped all the tables from previous attempts before starting this 1.1.4 install) without any complaint, and I can see all the tables etc. created by the installer, so I think CREATE works !!!
It only throws this error if the ALTER command fails. Can you check the user privileges?
What database tables do you have in your database, if any, primarily this one is used to test the ALTER command against "log_digest"
I'm afraid I'm giving up at this point. Needless to say, the privileges are all set correctly and have been throughout and yes, the log_digest table was correctly created on install, and so the worry for me is that the logic is clearly there but all these errors leave me with no confidence that we can use this live.
I asked earlier if you could tell me where these checks are being performed, because I'm perfectly prepared to get into the PHP and sort this out for myself if needs be... but without that info I've really not got time to go hunting through to find it.
Simply turning them off might even just result in a working solution - perhaps you're setting timeouts to short or something? I don't know, all I know is that a system that announces that the user cannot CREATE when they have just done so has to be a bit lame!!! Can I not get this running and then test it myself?
OK, we're at line 1883 etc. in /install/upgrade.php - now to figure this out... stay tuned...
OK, so all this is doing is upgrading the db from a previous schema to the required one for 1.1.4. So you can send me a clean, empty db at 1.1.4 which doesn't need upgrading and then we can bypass this completely?
Why are you running upgrade.php? It should be install.php if you're installing a new forum.
I am only going on GitHub and looking at the code btw, I didn't write this software just trying to assist.
As far as I can see the installer runs and then goes straight on to upgrade.php - it does seem odd that the latest version requires an immediate upgrade and I suspect this is root of the problem, and nothing to do with db privileges or even php versions! I'm playing with setting up a clean install on a D8 droplet at digital ocean. If that hits the same issues we're in trouble. But if I get a clean install there then I'll use that to try and figure out what's different about our container environment! Very many thanks for your help - you've got me on the right track I hope...
Ok, I was curious and tries a fresh install, I can confirm I get the same error as you do.
I'll get back to you with the fix!
It's the ALTER command itself which is failing.
Can you replace your upgrade.php with the attached please?
You go to the upgrade because you did not delete the install directory when the installer told you so.
So, just get rid of the directory and live happy! :D
Then you were probably downloading development that has minimum version 7.something, do note the "default branch" at github is development and not master.
I removed that first time and it complained upgrade.php wasn’t there due to your policy dB changes
The bug I raised on GitHub is still valid I believe.
The bug open at github if I understand it correctly is about upgrade.php, but if you delete the install directory you delete every thing including upgrade.php.
Unless I misunderstood the report.
If I do that I get what is in the attached image, everytime I try to access the forum.
I change the url to http://192.168.0.65/elkarte2/index.php and it redirects to http://192.168.0.65/elkarte2/install/upgrade.php
Ok so it removes the contents of the install directory but not the directory itself, this is what causes the issue.
Although I think the db query call should be changed also. So I would say there are two bugs.
The test is on the directory, so it is not a bug per se, but the intended behaviour. We can discuss is there is a more appropriate.
The query is indeed a bug.
The issue with this is that on my install ticking the button to remove the install files ( in the final step ) does not remove the install directory, this means it tries to load upgrade.php, which is no longer there as I removed it.
If I manually remove the install directory all is well. I don't think this is user friendly.