We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.

Phalcon\Version::get() returning "3.4.2" for Phalcon 3.4.3 installation

I am running Ubuntu 18.04.1 with PHP 7.3.6-1 and have installed Phalcon 3.4.3. When I run phpinfo() it says that Phalcon version 3.4.3 is loaded. I have searched and confirmed that there only exists one phalcon.so file and it is the one being loaded.

I have a dashboard in my web app that that calls Phalcon\Version::get() to display the Phalcon version number. It is returning "3.4.2" as the version number.

I also can run the following from the command line and it also return 3.4.2:

php -r "echo Phalcon\Version::get();"

I tried searching and could not find a previous post on this issue.

Any thoughts?



8.4k
edited Jun '19

Php CLI could use another php.ini/php version than what is used for http

Phalcon\Version::get() will show the actual version used in current php.ini

i never used Ubuntu but can you explain what is paginfo()

Apologies... that should have said "phpinfo()". I corrected it above.

Both the CLI and web app (Apache) return version "3.4.2" but phpinfo() shows "3.4.3" as the installed version. Apache has been restarted. And there is only one version of phalcon.so on the machine, which is the one loaded by Apache.

Very confusing.

More info... output from phpinfo for phalcon:

Web framework delivered as a C-extension for PHP phalcon => enabled Author => Phalcon Team and contributors Version => 3.4.3 Build Date => May 31 2019 23:05:22 Powered by Zephir => Version 0.10.14-975ad02db4

Directive => Local Value => Master Value phalcon.db.escape_identifiers => On => On phalcon.db.force_casting => Off => Off phalcon.orm.cast_on_hydrate => Off => Off phalcon.orm.column_renaming => On => On phalcon.orm.disable_assign_setters => Off => Off phalcon.orm.enable_implicit_joins => On => On phalcon.orm.enable_literals => On => On phalcon.orm.events => On => On phalcon.orm.exception_on_failed_save => Off => Off phalcon.orm.ignore_unknown_columns => Off => Off phalcon.orm.late_state_binding => Off => Off phalcon.orm.not_null_validations => On => On phalcon.orm.update_snapshot_on_save => On => On phalcon.orm.virtual_foreign_keys => On => On

I restarted Apache again just to be certain and still both the CLI and the web application show 3.4.2 as the version.



8.4k
edited Jun '19

that is strange i checked for bugs nothing popped but i recommend compiling a new one with different file name

and since your current compiled file is very recent i would check the source version.zep

https://github.com/phalcon/cphalcon/blob/v3.4.3/phalcon/version.zep

I checked and version.zep is:

    protected static function _getVersion() -> array
    {
            return [3, 4, 3, 4, 0];
    }

And I ran a find and there is only one version.zep file on the server as expected.

Yeah, this is a strange one. Nothing makes any sense.



8.4k
edited Jun '19

did you compile it or download it ? did you try fresh compile ?

Fresh compile...



8.4k

find php.ini and check each one of them

im pretty sure you already done that but it wouldnt hurt to double check

It's been a few days since I updated this issue. OK, so I am having this same behavior on seven separate server installations. We've just completed an upgrade from Ubuntu 16.04 to 18.03 and clean install of php 7.3. Phalcon was built from scratch using these commands:

 cd /usr/local/lib/php7.3
git clone --branch v3.4.3 --depth=1 "git://github.com/phalcon/cphalcon.git" 
cd cphalcon/build
./install --phpize /usr/bin/phpize7.3 --php-config /usr/bin/php-config7.3
phpenmod phalcon

I did a find / -type f -iname "phalcon.so" and there were three copies of phalcon.so found:

-rwxr-xr-x 1 root root 5312960 Jul  4 00:48 /usr/lib/php/20180731/phalcon.so
-rwxr-xr-x 1 root root 5312960 Jul  4 00:48 /usr/local/lib/php7.3/cphalcon/build/php7/64bits/modules/phalcon.so
-rwxr-xr-x 1 root root 5312960 Jul  4 00:48 /usr/local/lib/php7.3/cphalcon/build/php7/64bits/.libs/phalcon.so

When I built Phalcon, this was the version/date info provided:

PHP Api Version:         20180731
Zend Module Api No:      20180731
Zend Extension Api No:   320180731

And then at the end of the build:

Installing shared extensions:     /usr/lib/php/20180731/
Installing header files:          /usr/include/php/20180731/

So I'm at a loss to explain what's going on. I've replicated the problem across 7 servers running four different applications with the same results.

It's not the end of the world, but it is confusing and I know that it caused me to doubt that the original update had worked correctly, causing me to spend a few extra hours scratching my head.

OK, after making the post above I was searching on a separate issue, and I stumbled across a thread on github that pointed out that 3.4.4 had been released to fix a segfault issue. So I upgraded to 3.4.4 and now the version is properly displayed to 3.4.4.

So this issue appears to have been resolved with the 3.4.4. release though there was no mention of it in the change log.