PHP Versions

[gcarrizo]

I would need help regarding Appgini compatibility information with the different versions of PHP
For example :
version 22.14 is compatible with php versions 7 or higher
version 5.95 is compatible with php versions 5


Where find that's info ?

Best Regards

[AhmedBR]

I do not think there is topic or link mentioning exactly what you need, BUT there is Change Log, and usually PHP version is mentioned when a specific version is required:

https://bigprof.com/appgini/release-log

[gcarrizo]

Really I look before in that link expand all and ... not found about that ...

Thanks

Best Regards

----------------------------------------------

I do not think there is topic or link mentioning exactly what you need, BUT there is Change Log, and usually PHP version is mentioned when a specific version is required:

https://bigprof.com/appgini/release-log

[jsetzer]

I'm wondering if all of us could contribute by posting our environments and perhaps problems in a central place:

• Xampp/wamp/IIS/others
• PHP version
• MySQL/MariaDB version
• AppGini version
• language settings
• Problems, if any

I am thinking of some kind of compatibility matrix. Would be great if someone could setup a file or spreadsheet or database. It would be even better if many of us would contribute to that database. Especially on new versions many of us could benefit, even BigProf would see problems in certain constellations early. One should be able to vote when facing same problems.

Any volunteers? Any better ideas?

[D Oliveira]

I support Jan's idea

running mac os xampp 8.1.6
PHP version: 8.1.6
Server version: 10.4.21-MariaDB - Source distribution
AppGini 22.14
no language settings

no problems, running smoothly ( was running well with PHP 7.3 and 7.4 as well)


(only problem when executing sql() method without second error parameter)

[baudwalker]

LOCAL Server
running Windows 10 64bit
Wamp 3.2.6 64bit
PHP version: 8.1.6 ( I change sometime when developing for different servers)
Server version: MYSQL 5.7.36
AppGini 22.14

[AhmedBR]

Appgini 22.14
Xampp 3.3.0 64bits PHP 7.4.29
(Xampp 8.1.6 I get a lot of errors, not from the app but from the plugins)

after development app is running live on PHP 8.1.4 no problem
(with the plugins already installed, if I need to change something in the plugins I have to do it on 7.4.29)

[dkano]

Yesterday bluehost upgraded my php to 8.2 on my new domain name and it broke appgini. But to be fair, the following code stopped working:

Code: Select all

session_name("test_session");
session_start();

echo "<pre>\n";

echo "Session super global before saving now:\n";
print_r($_SESSION);

$_SESSION['now'] = date("Y-m-d H:i:s");

echo "Session super global after saving now:\n";
print_r($_SESSION);


echo "<\pre>\n";

I called customer support and they rolled me all the way back to php 7.4.33 and it worked again.

It would be great if every version of appgini stated explicitly what the highest version of PHP that it had been tested on, to avoid these problems.

I just upgraded to appgini 24.10 (after the problem) but I didn't think I needed to upgrade right away! Maybe that would have helped? I wish I knew.

Thanks!

[D Oliveira]

My app also got busted in blue host a few days ago, they will auto update it and it wil break again...

The session path got changed and I'd strongly reccommend migrating your app away from bluehost to another provider or a VPS.

[onoehring]

Hi,

local:
I had problems with local ( I am using https://www.uniformserver.com (similar xampp) ) and php 8.2, but switching to php 8.1 was working fine. I did need to adjust some code - as AG code itself produced errors in php 8.x - as posted here in the forum.

online:
a) no problem. hosted with ionos (1and1). PHP Version 7.3.33, mariadb-10.5.17
b) no problem. hosted with webgo.de. PHP Version 8.1.26, 10.11.4-MariaDB

Olaf

[dkano]

Another one of my appgini sites got reported down today. It was the same problem: the code (pasted above) does not work on php 8.2.16, at least on my bluehost server! I've now used their web multi-php version interface to set all my appgini sites to 8.1, including the one they rolled all the way back to 7.x for me when I was on the phone! 8.1 works fine.

Does anyone know why the basic session code above might not work on 8.2.16?

[maryann-weekes]

Hi,
I am new to the forum. Our Appgini application stopped working last week when Hostgator upgraded our server to PHP 8.2. We get a 500 error before the login screen appears. I contacted Hostgator, and they set our PHP version back to 8.0, which works ok. They auto-update to 8.2 almost daily, so I need to keep changing it back to 8.0.

We are running Appgini 5.94. I can buy the new version and upgrade, but I would like to know if the new version of Appgini works with PHP 8.2 before I do that. I have searched the forum and found issues with 8.2 but have not found any confirmation that it will work. Is anyone running 24.10 with PHP 8.2? If so, I'll give the update a try. I created this application for a non-profit in 2008 and have only updated a few times, so I am not very proficient at updating.

Thanks in advance for any help.
Mary Ann

[a.gneady]

Hmm .. we test AppGini apps on PHP 8.0 up to 8.3 and they work fine. But to help me investigate this issue, is there a specific error message reported in the server error log? (you can usually access the error log from the hosting control panel)

[jsetzer]

Don't know if this is related and hope this helps at least some of you:

I just want to note that certain PHP functions, especially function sqlValue, require a second, mandatory parameter now, which, when missing, did not break the application in the past but breaks it since PHP 8.WHATEVER. At least that is what I have seen.

Most of the times a migrated, broken project works fine for me after updating all sqlValue function calls.

In generated AppGini code all sqlValue function calls already have that 2nd parameter. But in my own older code I've missed it several times.

May break:

Code: Select all

$result = sqlValue('YOUR QUERY');

Should work:

Code: Select all

$o = [];
$result = sqlValue('YOUR QUERY', $o);

Additionally, I have seen that for SELECT statements sqlValue-function works fine but not for INSERT, UPDATE, DELETE. For those I'm using sql('COMMMAND', $o);

[maryann-weekes]

This is from the server error log:
[20-Feb-2024 17:04:30 America/New_York] PHP Fatal error: Uncaught mysqli_sql_exception: Duplicate key name 'name' in /home3/sharpei/public_html/admin/db.php:109
Stack trace:
#0 /home3/sharpei/public_html/admin/db.php(109): mysqli_query(Object(mysqli), 'ALTER TABLE `me...')
#1 /home3/sharpei/public_html/admin/admin/incFunctions.php(422): db_query('ALTER TABLE `me...', Object(mysqli))
#2 /home3/sharpei/public_html/admin/admin/incFunctions.php(1177): sql('ALTER TABLE `me...', Array)
#3 /home3/sharpei/public_html/admin/admin/incFunctions.php(839): update_membership_groups()
#4 /home3/sharpei/public_html/admin/lib.php(66): setupMembership()
#5 /home3/sharpei/public_html/admin/index.php(4): include_once('/home3/sharpei/...')
#6 {main}
thrown in /home3/sharpei/public_html/admin/db.php on line 109

[maryann-weekes]

I do see some sqlvalue function calls without the second parameter in our 5.94 generated application. I will try the Appgini upgrade and hope that helps since it sounds like the newer Appgini generated code will have that second parameter.

Thank you for the help.
Mary Ann

[D Oliveira]

I do see some sqlvalue function calls without the second parameter in our 5.94 generated application. I will try the Appgini upgrade and hope that helps since it sounds like the newer Appgini generated code will have that second parameter.

Thank you for the help.
Mary Ann

You're correct in the sense of the appgini auto generated code, but if there are any custom php files in your system you may need to adjust those as well, the workaround is to use an IDE like VScode to carefully search and inspect each occurrence, but that would require a lot of focus and functionality testing along the way.

[maryann-weekes]

Hi,
I upgraded from Appgini 5.94 to 24.10 today, regenerated our application, uploaded to our server and added our hooks, etc. It is now working with PHP 8.2. I still have a lot of testing to do, but it is 95% complete and way past the error we were getting with 5.94. Thank you to all for your help!
Mary Ann

[pfrumkin]

So grateful to this forum post. HostGator upgraded us to PHP 8.2 this week and broke our site. We got them to rollback.

PHP version: 7.4
MySQL version: 5.7.23-23
AppGini 5.97

We are dev testing with AG 24.10 now. Appreciate the heads up about the sqlValue. We'll look for anymore gotchas.

Paul

[a.gneady]

I just want to note that certain PHP functions, especially function sqlValue, require a second, mandatory parameter now, which, when missing, did not break the application in the past but breaks it since PHP 8.WHATEVER. At least that is what I have seen.

Most of the times a migrated, broken project works fine for me after updating all sqlValue function calls.

In generated AppGini code all sqlValue function calls already have that 2nd parameter. But in my own older code I've missed it several times.

May break:

Code: Select all

$result = sqlValue('YOUR QUERY');

Should work:

Code: Select all

$o = [];
$result = sqlValue('YOUR QUERY', $o);

Additionally, I have seen that for SELECT statements sqlValue-function works fine but not for INSERT, UPDATE, DELETE. For those I'm using sql('COMMMAND', $o);

Hmm ... interesting point. The second parameter to sqlValue() is an optional parameter that is populated by any error message resulting from the query. But it's optional, so if you don't pass that parameter, the function should work fine. The function is defined as follows in admin/incFunctions.php:

Code: Select all

function sqlValue($statement, &$error = NULL) {

The main purpose of this function is to run a SELECT query that should return a single row with a single column, and it returns the value from that single row/single column result. If you'd like to execute a non-SELECT query, the sql() function is more suited for this purpose.

[dkano]

Hmm ... interesting point. The second parameter to sqlValue() is an optional parameter that is populated by any error message resulting from the query. But it's optional, so if you don't pass that parameter, the function should work fine. The function is defined as follows in admin/incFunctions.php:

Code: Select all

function sqlValue($statement, &$error = NULL) {

The main purpose of this function is to run a SELECT query that should return a single row with a single column, and it returns the value from that single row/single column result. If you'd like to execute a non-SELECT query, the sql() function is more suited for this purpose.

I've never seen or used a default value for a function argument that is passed by reference before. What would actually happen when that variable is assigned a new value? Is this defined by PHP explicitly?

Maybe some versions of PHP 8.x don't handle the way you use the second parameter, when it isn't supplied? It looks like you assign to it without first checking if the optional parameter was supplied or not. Maybe it would be better to do something like:

if ($error != NULL) {
$error = whatever;
}

in an error condition, and drop the error return on the floor if the second parameter wasn't supplied.

In the PHP manual, it states:

"Note: Arguments that are passed by reference may have a default value."

But I don't see anywhere a definition of what happens if you assign to one. Before the above quote, they say they must be contants. But they can be non-scalar:

"Default parameter values may be scalar values, arrays, the special type null, and as of PHP 8.1.0, objects using the new ClassName() syntax."

Anyway, I'm going to add the second parameter to my calls, to be safe. I appreciate the heads up on that change jsetzer!

[jsetzer]

There can be more problems. I can only say that this helped when migrating to PHP 8. And VSCODE showed those sqlValue('...') lines as syntax errors.

[a.gneady]

I've never seen or used a default value for a function argument that is passed by reference before. What would actually happen when that variable is assigned a new value? Is this defined by PHP explicitly?

Maybe some versions of PHP 8.x don't handle the way you use the second parameter, when it isn't supplied? It looks like you assign to it without first checking if the optional parameter was supplied or not. Maybe it would be better to do something like:

if ($error != NULL) {
$error = whatever;
}

in an error condition, and drop the error return on the floor if the second parameter wasn't supplied.

In the PHP manual, it states:

"Note: Arguments that are passed by reference may have a default value."

But I don't see anywhere a definition of what happens if you assign to one. Before the above quote, they say they must be contants. But they can be non-scalar:

"Default parameter values may be scalar values, arrays, the special type null, and as of PHP 8.1.0, objects using the new ClassName() syntax."

Anyway, I'm going to add the second parameter to my calls, to be safe. I appreciate the heads up on that change jsetzer!

I tested the function under various versions of PHP and it worked without issues, but I'll re-investigate the case when the provided query causes an error. Thanks for the detailed feedback!

UPDATE OK, I retested sqlValue() under PHP 8.0, 8.1, 8.2 and 8.3 with the following scenarios and all of them passed without errors:

• sqlValue('select 1') == 1 => works
• sqlValue('select 1 from non_existent_table') === false => works
• $error = ''; sqlValue('select 1 from non_existent_table', $error); !empty($error) => works
• sqlValue('select 1 from non_existent_table', $error); !empty($error) => works

So, whether $error (2nd param) is defined or not, and whether the query causes an error or not, it's working fine. If I'm missing a use case not covered in above tests, please let me know.

[D Oliveira]

Just adding to the discussion, declare(strict_types=1); is the kind of thing that can also "break" applications in regards to how this function and others are treated as far as matching returned data types and handling errors/warnings.

[maryann-weekes]

When I upgraded from Appgini 5.94 to 24.10 due to PHP 8.2 issues, I checked our hooks for sqlvalue functions without the second parameter. I do have some of them but decided to test without changing anything since I saw some newly generated Appgini code without the second parameter. We have tested and gone live without adding that second parameter to our sqlvalue functions and have had no issues. We do not have a lot of custom code, but I wanted to update that we had no further issues after upgrading from 5.94 to 24.10 on PHP 8.2.