Salient Soft

I hit an issue with the Salient Soft website whereby the PHP error log file used up all my available zen hosting disk space, and my email started to fail. It turned out that there were a number of php define statements in the code, where the actual define name was not quoted. in PHP 7.3, which I was using, this added a warning to the log, stating that this would not be supported in future versions and would fail.

I was surprised that the log had grown suddenly – whilst it did have entries going back a number of years, I suspected that the real culprit was likely a fairly recent server side change e.g. in the php version.

The original incorrect code and the corrected version are shown here for reference:

define (SSW_PHPTHUMB_DIR, “wp-content/phpThumb”);

define (‘SSW_PHPTHUMB_DIR’, “wp-content/phpThumb”);

I must say that it felt strange to have to quote the definition name in addition to the replacement string, but this was correct. In common with others who posted about this online, I elected to use a policy single quotes for the static definition names, and double quotes for other replacement and dynamic strings in the code. I fixed all of these, plus an additional string which should have been quoted in another expression, and everything was fine – all the errors disappeared.

I uploaded a zip of the fixed theme (with a new point version) and unzipped it manually. Whilst initially it appeared that WordPress did not recognise the uploaded theme, this was incorrect – it was actually in the list of themes when uploaded manually and unzipped into the themes directory along with all the others. I did briefly try the wordpress feature whereby you can upload a zip of a new theme and install it using wordpress, but wordpress complained about the writeability of its temporary chosen upload directory so I didn’t pursue this further and just did it all manually, which was fine.

I also hit a number of issues with eclipse for PHP 2022-03, as I had done previously here. My workspace got corrupted somehow causing eclipse errors that would not disappear even with a restart. It also refused to rename a subfolder (which I had renamed with the new theme version) for a while and I could not resolve this and so I had to delete and recreate it and then re-import the theme code from bitbucket. After this, and importing it as a general PHP project as before, it all resolved ok, and as before, I had no trouble importing from git directly into a subfolder of the workspace.

I have been having mouse/mouse driver issues whereby windows keeps interpreting a click as a double click or two successive single clicks which causes numerous issues all over the place, so this may have been partly to blame for php messing up and spitting at me in various ways. However, I do not believe this was the only problem, and am still of the opinion that this version of php has issues – I will keep an eye out for a new version to try, or may even wind back to an older one. I must say that the PHP integration with git/bitbucket did generally work well. Importing from bitbucket with the remote URI was easy, as was all the usual features like creating a new local branch from a newly created remote feature branch in bitbucket, and commiting all the code back, and pulling changes from develop for the final merge (which was done in bitbucket) etc.

After all this everything was fine with the website and theme.

Comments Off on PHP Compilation issues with existing Salient wordpress theme

I was in the process of upgrading all aspects of the Microapps functionality to the latest versions, and in particular, was upgrading the Yoti SDK versions used as part of the Age Verification Microapp Identity API. I’ve already posted about the Java/Spring Boot issues I hit when upgrading the Java/Spring Boot Identity API. I also hit a couple of issues when upgrading the PHP version of the Identity API, which are detailed here as follows.

1/ To manage the PHP versions of the Yoti SDK, I was using PHP composer as detailed here. Rather than complicate matters for such a simple demo API, as per the linked post, I elected to use a simple PHP project which was not integrated to Composer within PHP. Composer functions such as install or upate were performed separately on the command line.

When doing this upgrade, I was using a new PC and so had to check out the code from scratch from Bitbucket. As a policy I do not check in IDE related files (in this case, the PHP version of eclipse), as I wish to keep checked in source IDE agnostic. I therefore cloned the repository on the command line, in a folder under the eclipse workspace, and then tried to create this as an eclipse project from existing files. Whenever I attempted this initially, I got the error ‘Cannot create project content in workspace’. After investigation I found this stack overflow post here on the subject, which says in the comments that this is in fact a long standing eclipse issue. I was able to create a project from existing files in a folder outside the workspace, but eclipse refused to do this inside the workspace, which is strange. It was possible to create the project outside the workspace, then copy the folder into the workspace, and then import it as an existing project, i.e. with all the eclipse project files already present. This all seemed unnecessarily hard though and certainly appeared to be a bug as per the post.

2/ When creating/importing the new project into eclipse, on several occasions I hit an issue where the resulting code had compilation errors in eclipse relating to the composer include files. After investigating, it appeared that due to the way I was importing/creating, eclipse was trying to interpret the type of project (possibly as a composer one) and set some complex invalid entries for the build path and include path which tripped everything up. In the end, I noted that importing just as a simple PHP project was fine and all the errors disappeared. Whilst this may not integrate eclipse fully with the underlying Composer structure, as before, I was not interested in doing this. The project was just a simple interface calling Yoti’s php api, with no other composer dependencies of mine. I therefore stuck with a simple project import and ensured that, however I went about the import/create, I told eclipse effectively ‘stop trying to be clever, just treat it all as a simple php project’. This worked fine.

I did note that unlike intellij (and indeed eclipse for java), control/clicking on a method did not appear to go to the method, or offer the choice of visiting either the declaration or the implementation. After checking online, this appears to be the norm – I could not see any posts indicating that ctrl/click or some variant of this would work in this way. There were however keyboard shortcuts to do this kind of thing, but I did not investigate further.

3/ In the end, my solution to both these issues was to use the import menu in eclipse and import directly from bitbucket into eclipse, creating a new project in the process. The double advantage of this was that the integration with the remote bitbucket was immediate as a result of the import, and creating the project in the workspace during the import did not give the error above under 1/. 

To do this, I used the clone URI that bitbucket provided for cloning, but without the git command prefix. Whilst the initial import form has a ‘local directory’ next to the remote git uri field, this was not the target local folder – it would try to do a local import instead from this folder, and suppress the git uri. I therefore left this folder blank and proceeded with the next button. A subsequent screen had a local folder location field for where to place the imported/cloned project, and when placing this under the workspace, crucially, eclipse did not complain, and everything proceeded fine. An important point during this process was that I took great pains to ensure that any fields relating to the type of import were set to basic/simple eclipse project only, i.e. I told eclipse not to try to second guess the project type, and risk getting the errors I received above in 2/ again.

After doing this, the project looked fine in eclipse, with no compilation errors. I then updated the composer.json file as required, and manually ran ‘composer update –no-dev’ to update the vendor files, then did a refresh/revalidate in eclipse. This all worked fine.

4/ Another issue I hit was when accidentally missing out the pem file when deploying under zen hosting with the new version. When this happened, Yoti correctly returned an exception re the missing pem file, but the error code was set to 0, rather than to a specific http status as is done for the success case which gives a code of 200. Unfortunately, whilst this code of 0 was returned in the response body, the actual http status was set to 200 ok, as for success. This resulted in the age verification application assuming a successfully returned age of -1. In the java/Spring Boot version of the same api, I had elected to return all error conditions as a 404 for simplicity. This would be sensible i.e. if a broken or invalid token was sent to Yoti – Yoti would return an error stating that it could not decrypt the token, which should map to a 404. I did not want to get into mapping individual statuses to http responses as the mapping would not be easy/good anyway, and it did not feel right to map all errors to a 500 say, as in many typical cases this would not be appropriate, as in the incorrect or duplicate token usage as above.

I therefore did exactly the same for the PHP version as for the java one, for consistency. All 200 error codes were sent as an http response of 200 as expected, but anything else in the code field, which would not be a success, was sent as a 404. This solved the problem and all worked fine.

Comments Off on Issues when upgrading Yoti PHP Identity API to use v3 of the Yoti PHP api

Although I was deploying an Angular app for this, it is a Yoti requirement that some interaction with Yoti is done via a backend.

As I wanted to deploy under cPanel with Zen for demo purposes, my only backend option was php.

I therefore planned a simple php backend web service that could be called from the Angular app to do the required Yoti backend functionality.

To develop and test this locally I installed a local WAMP server – details of this may be found on this post here.

Having installed Wamp64 and got working ok, I was able to run microapp demos locally with Angular deployments, and to run a simple ‘hello world’ php backend, by renaming index.html to .php and inserting the php code.

Next I needed to install composer and set up a composer.json to handle dependency loading as Yoti needs this.

Composer is a commonly used dependency management tool for PHP and full details and the download for it may be found here.

I had some issues getting Composer to co-operate with Wamp64, regarding the PHP version. In particular it gave errors on the PHP version when loading the Yoti SDK, which I initially assumed were due to not having a recent enough version of php for the latest Yoti SDK. However, in the end, this was not the case – it was purely a local Composer/Wamp64 integration issue.

This post here offers help on this. I ended up adding the correct PHP version to the system path, which kept Composer happy and in my case, unlike other posters in the previous post, did not upset Wamp64.

I was ultimately able to use php 5.6.40 with the latest 2.4 Yoti SDK with no problems – this was helpful as this was the version currently in use on the target Zen cPanel hosting.

I then installed the latest eclipse for PHP, as I did not want to upgrade my webstorm to PHPStorm just for a simple PHP requirement.

It was however useful having the eclipse ability to provide a decent PHP editor in its IDE.

When creating a workspace and project, I was offered Composer integration by eclipse, which initially seemed attractive.

However, this proved somewhat complex to get into, given I had no intention of building my own Composer packages. The only reason I wanted it was to allow loading of the Yoti SDK via Composer, as this would be called from my simple php backend.

I therefore dumped this and used a basic PHP project in eclipse. I manually created the composer.json file per Yoti’s instructions, and a simple manual “composer install” command from the command line in the project directory caused the SDK to be downloaded and correctly placed under the vendor subfolder, which also needed deploying along with the api code.

Having fixed all the issues along the way which are documented in my wamp server installation post above, I was able to fully integrate with Yoti both locally and from Zen cPanel hosting. My simple initial test PHP backend was taken from the Yoti samples, and successfully displayed the user’s date of birth, obtained from the live Yoti integration, after its Yoti button was clicked and the QR code scanned via the mobile Yoti app.

Comments Off on Integrating the Yoti backend via PHP under cPanel