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

I decided to go from Java 8 to the most recent LTS release of Java, JDK 17, and to the current latest Spring Boot, 2.6.7, for my Spring Boot Identity API which is a java back end interface to Yoti.

Initially I used Oracle JDK 17, and I hit an issue when running live with Yoti, but using the Java IdentityAPI locally. Curiously (and annoyingly) everything worked fine when running in debug under the latest eclipse, 2022-03, but I failed to get a Yoti profile back when running the compiled Spring Boot version directly.

This Spring Boot issue details the problem, which is exactly what I was getting – an error returned when getting the Yoti profile, due to an interaction between Spring Boot, Oracle jdk 17, and Bouncy Castle encryption, causing an IllegalStateException citing ‘zip file closed’ when the jar is being unpacked. The issue does not occur when running an exploded deployment (i.e. not in a fat jar), such as is done when running in debug in eclipse as I was.

There is no resolution at present, but as the problem does not occur under openJDK, I elected to switch to openJDK 17 rather than revert to Oracle JDK 11, which would have been another option.

Switching to openJDK 17 fixed the problem, and I was able to successfully perform age verification using a local Spring Boot IdentityAPI of mine, built with openJDK 17, and using the production Yoti to retrieve a live profile.

Whilst doing this, I improved the logging and elected to use Lombok’s @slf4j annotation to create loggers, for convenience, as this also allows logging to be tweaked via the Spring Boot application.properties as normal for Spring Boot. This is detailed here for reference.

In addition I upgraded the Yoti Java SDK I was using to the latest one (yoti-sdk-api version 3.4.0) rather than the old one I was using (yoti-sdk-impl version 2.6.0). This involved a small change to my YotiService as the interface to Yoti has changed, and some small pom changes for the new version. This all worked fine.

Comments Off on Issues upgrading my Yoti Java IdentityAPI to JDK 17