How to "guess" php version by looking at code?
Suppose you're handed a zip file containing php code for an application.
Are there any telltale signs about which version (5.x, 7.1, 7.3,etc )
the original author was working with?
My issue is, I suspect I'm running an incorrect php version for my (phalcon) application, my users can't log in. I see in logs
"PHP Warning: Use of undefined constant success - assumed 'success' (this will throw an Error in a future version of PHP)"
and
Uncaught Error: Class 'View' not found in ....
In general, this is not possible. You can inspect the set of features the original author used and try to identify a minimal version. When you find removed features you can also find a maximum version.
According to your warning message I assume you are using PHP 7.2 right now?!
The author probably developed this with a lower version (5.x) or has disabled warnings.
Maybe have a look here for more info about your warning message.
However, the warnings and errors you get are not really version related but seem to result from missing files and / or bad programming.
You should try to make it work with Version 7.2+ instead of choosing the version matching the developers version. Have a look at PHP versions here.
I inherited a Typo3 site to maintain and have had no trouble until now. When I try login I get this error message:
Oops, an error occured!
PHP Runtime Notice: Declaration of t3lib_userAuthGroup::checkLogFailures() should be compatible with t3lib_userAuth::checkLogFailures() in /home3/onefoug3/public_html/t3lib/class.t3lib_userauthgroup.php line 113
I checked with my hosting service and they say it is an error with the script. I am not a programmer so I do not know how to fix that...not even sure where to start. How do I fix this?
To give you an overview about the situation with your TYPO3 installation I list a few points, some of them where you've to verify more:
TYPO3 in your installation is very old and outdated. You'll get perhaps many hints to update due to security-reasons. This is not wrong but I'd concentrate first on getting it running, perhaps better on a local server.
The Version of your TYPO3 installation is in any case very useful, you should try to provide it.
It's possible that you need an old PHP version to run that site and that the error is just thrown because of a wrong PHP Version. You could try with PHP 5.2.
It's not improbable that something in the TYPO3 core was changed manually. It might be patches or individual but in many versions I never found the mentioned methods in the line 113 like shown in the error-message.
Rarely I changed in the core somethings too, to circumvent some temporary problems, usually that's neither required nor advisable. Nevertheless if it helps you to get the installation locally running - why not.
The more advised step is to download the current version new and replace the existing core with that. Often you can chose the most recent minor version: assume you've Version 4.7.18, then you can download Version 4.7.20 or newer if available.
The link to get the newest Version of that old branch would be https://get.typo3.org/4.7
Better keep the old core till the problem is solved, even if you replace it.
If you follow my hint to get a higher minor version you should have a look in the install-tool, specifically in the update-wizard there.
I'd advise to update the question to include the Versions of TYPO3, PHP and MySQL, then perhaps it will be easier to help more.
As target I see to get the installation locally running and performing an update instead of serving the old site with insecure core. Based on that I answered in point 5 too, on a live-system it's not advisable especially with your limited knowledge.
libsodium WAS working fine but now I managed to break it and can't find how to unbreak it.
Amazon AWS Ubuntu Xenial, libsodium18 installed, php-sodium from Ondrej Sury PPA installed but instead of working I now get:
Undefined constant 'Sodium\CRYPTO_SECRETBOX_NONCEBYTES'
The annoying thing is it's fine in Zesty but there's no stable AWS Zesty image still. I'm sure I've just forgotten some simple thing but it's just ceased working.
Found it.
PHP sodium function names have changed so instead of calling \Sodium\crypto_secretbox_open() you now have to call sodium_crypto_secretbox_open()
I seriously hope this post helps someone avoid the grief I've had in the last 24 hours wondering what I'd *^&%'d up - it might well be the only thing on the internet actually pointing this change out that Google finds...
The revised function names and constants are all listed at https://paragonie.com/book/pecl-libsodium/read/01-quick-start.md
The project description explains the reason behind these changes: https://github.com/jedisct1/libsodium-php
There is also a polyfill that provides the old interface: https://github.com/mollie/polyfill-libsodium
However, new libsodium APIs are not available using this polyfill.
I can't maintain both versions, sorry. I wish we could have kept using the original, namespaced version.
This is the error every time I start up php:
Unable to load dynamic library '/usr/lib/php/extensions/no-debug-non-zts-20100525/proxyauth.so' - dlopen(/usr/lib/php/extensions/no-debug-non-zts-20100525/proxyauth.so, 9)
I have two older versions of the proxyauth.so in no-debug-non-zts-20060613 and no-debug-non-zts-20090626, but neither is compatible with a module API compatible with 20100525, so symlinking doesn't solve the problem.
I've Googled my best and have no idea where proxyauth comes from, and therefore can't make a new one with the compatible API. There doesn't appear to be an extension in the php ext directory, so I have no idea what to do next.
Thoughts?
Thanks,
Bill
If the warning is the only problem - meaning your code itself runs fine - then the extension isn't required anymore by your application. Why not out-commenting the extension=proxyauth.so?
I have an inconsistency, and I could not align their versions properly, so I just wanted to remove the library version. Can I do this? Is the header version for PHP while the library is from my distro? Can I upgrade PHP's library version? If so, how? I am using PHP 5.4.4
For example,
Is the header version for PHP while the library is from my distro?
It means it was compiled against the 1.0.1 headers, but is now dynamically linking against 0.9.8. So you are using an older version than what was used when PHP was compiled.
Many libraries store the version in the header files. So when a program uses the library, it can do something like int HEADER_FOO_VERSION = LIBRARY_VERSION, which embeds that version number into the program (e.g., php). Now when that program runs, it links dynamically against the library, which may be a different one than was on the host system.
That library may have a function call, say int get_library_version(). So the program (PHP) can check if HEADER_FOO_VERSION == get_library_version(). If it's different, then there could be a compatibility issue. (Of course, it doesn't have to be assign to a local variable... I'm just trying to drive home the point that the header version number can be compiled into php, and remains constant no matter which version of the library is being used at run time.)
Whether or not it is a problem depends on if the two versions are compatible.
Usually if the library is > than the header, you are okay. It's definitely more likely to be a problem if the library is older than the version it was linked against. Of course, this is because it's impossible to know what changes future versions may have.
So in your case, I would try to update your system's SSL libraries via apt-get, yum, etc, to match the version PHP is expecting.
To check which version php is using on Linux:
$ ldd `which php` | grep ssl
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0
Note that which php is just a short-cut to find the full path. You can hard code any executable you'd like to check: ldd /usr/sbin/httpd.
I dont know the answer myself, but when searched on google some nice resources explaining the same.....
What's the difference between a header file and a library?
The version of the files are the one mentioned in the phpinfo used to create a library.
Hope it helps, there are lot of resource available if searched on google.
Still will like to hear from someone in great details about the question
The header version is the functionality version, whereas the library version is the code version.
The header defines the interface - it tells you what functions are within the library. If a header gets updated, then you need to check to make sure all the functions are the same, and see if any are added or subtracted.
But if a library gets updated, and not the header, it means all the function calls are the same, but some of the code may be changed (eg, bug fixes).
In your example, PHP is seeing functionality for OpenSSL 1.0.1, but the actual version of the source code that OpenSSL is loading is 0.9.8o
This is commonly seen on updated versions of openssl. What happens is the newer versions for the libraries are stored in different folder. The original folder located at /usr/bin/openssl would need a symbolic link to the new folder /usr/local/bin/openssl. That would get both to be the same version or just show OpenSSL Version _(Whatever)
Normally there is no concern for this, since it still works the way it is intended. This is seen a lot on shared servers.
EDIT:
The information in this post is generic and can be different if you are running
CentOS, RedHat, Ubuntu, or another Linux/BSD version. Check documentation or man
pages for the best information
If you do update your OpenSSL, some versions of *nix Require for you to rebuild PHP and Apache for it to update
If you are rebuilding PHP from source, I have found another possible reason for a mismatch. It's so simple yet if you are not familiar with building from source on Linux, not knowing it can cost you a lot of time.
The answer is here: https://serverfault.com/a/567705/305059 - unfortunately I cannot up-vote it over the not-so-useful answer, so if you have the reputation there, please do.
You need to run "make clean" before "make" in order for it to rebuild all binaries. Strangely, without this step I was getting an updated library version, but the old header version - so I think it must have rebuilt something, but not everything. My rebuild involved linking to a version of curl in another location (built with ssl), which might be the reason behind it.
Anyway, I hope this helps someone. Thank you to #velcrow on serverfault.