This is my first real post in this series. My first steps were focused on just getting the project installed and running. Through this process, I learned some details about the application that will be important in the future modernization tasks.

It has been a while since any real development work has been done on my home PC, which is a Windows 10 laptop. There was some set up I needed to do in order to get the environment ready for this project. Here’s a list:

  • Upgrade MySQL to 5.6.31
  • Install the latest PHP version (7.0.9 at this time)
  • Upgrade Apache 2.4

The MySQL upgrade was straight forward using the installer.

I downloaded the VC14 Thread Safe zip file for PHP 7.0.9, copied the standard php.ini-development file to php.ini, and set the error_log property to my log directory.

error_log = "X:/path/to/logs/php709_errors.log"

I then downloaded the XDebug extension for PHP7 and configured it in the php.ini file.

zend_extension="X:/path/to/xdebug/xdebug_dll_file"

I did not change any other settings or enable any extensions in the php.ini file. I want to be conscious of the requirements for the application. I’ll enable extensions or change settings as the need is identified.

Lastly, I added the PHP install directory to the PATH environment variable.

Apache gave me the most trouble. I already had Apache 2.4 installed, so I just tried to configure the new version of PHP. It took me a while to figure out I had the VC11 version of Apache 2.4 and the new version of PHP was VC14. I downloaded the new version of Apache 2.4 VC14, but when I tried to run it, it would not start. It turns out that Windows 10 has built in services that use port 80. In this case, it was the World Wide Web Publishing Service. After stopping and disabling this service, Apache was running fine. After that, the standard PHP configuration for Apache worked without issue.

LoadModule php7_module "X:/path/to/php/php7apache2_4.dll"
PHPIniDir "X:/path/to/php"

AddType application/x-httpd-php .php

DirectoryIndex index.php index.html

I also went ahead and set up an alias in the Apache configuration to access my project directory.

Alias /weberp "X:/path/to/project/webERP"
<Directory "X:/path/to/project/webERP">
    AllowOverride all
    Require all granted
</Directory>

One last set up task I did was create a phpinfo.php script in the project directory so that I can easily review the PHP configuration when needed. I created a .gitignore file and added phpinfo.php to be ignored so that it is not committed to the project.

With the environment setup, it was time to get the git repository structured to be able to track my progress. I had already forked the subject repository and downloaded a clone from GitHub. I then created 2 branches. I want to keep the original source intact throughout the project, so I don’t want to make any changes to master (or any other branches that came from the upstream repository). I created a branch called mondernize off of master and pushed this branch to GitHub. As I go through the modernization process, I will create new topic branches off of modernize for each step I take. I will be creating Pull Requests and merging changes into the modernize branch as I complete each phase of the process. The first topic branch is called ‘installation’.

Now with all the prerequisite installations and setup out of the way, it was time to take a peek at the application. From the documentation in the project, it looked like there is a guided installation script initiated by default when you navigate to a new install in the browser. When I visited the site, I found the first problem and a valuable piece of information.

The install script is performing some environment validation. I saw that the script is checking for a version of php that is greater than 5.1.0. This gives me information that will be helpful in setting the scope of what I need to look for in terms of PHP Upgrade issues since I am working with version 7.0.9.

Also, the first error encountered was Call to undefined function mb_substr(). The fix for this was simple. I modified the php.ini file to enable the mbstring extension extension=php_mbstring.dll and then restarted Apache. Now I know that this extension is required for the project.

With the mbstring extension enabled, the install page loaded correctly. I did see an Undefined Index Notice at the top of the screen. I’ll leave that alone for now. It doesn’t necessarily indicate a problem in execution yet.

Using the information on the installation screen, I started a Readme.md file in the project to document the requirements and some thoughts on potential issues.

After filling out all the installation parameters and submitting the form, I saw the next error Call to undefined function mysqli_connect(). I enabled the mysqli extension and submitted the form again.

There were some ‘Deprecated’ warnings on the screen warning about deprecated constructor names (e.g. PHP4 style constructors). I just made a note of those in the Readme file for now. That issue should be taken care of during the actual code modernization steps. There were also some Notices on the screen, but I’m choosing to ignore those for now.

Along with the PHP warnings, there was an application error on the screen. It seemed to be related to application permissions. It’s like the system tried to keep me logged in as a user after the installation script completed, but it didn’t know what user I was. I navigated back to the home screen and saw a login form. When I logged in with the admin account, I saw what looked like an appropriate screen with menu options. To test it out, I created a Sales Order in the application. During the Sales Order creation, I found that LOCK TABLES permissions is required for the MySQL user on the database. Once I set that, I was able to successfully create a Sales Order.

Also, after the installation script completed, I checked the project directory with git status to see what changes were made by the script. The only change was that a config.php file was created and contained the parameters set on the install screen. I also noticed that config.php is explicitly turning off NOTICES in the error_reporting PHP parameter. So, I shouldn’t see those notices mentioned above any more. This might be something I’ll want to change much later in the modernization process. I added the config.php script to the .gitignore file. Configuration files should not be committed to the repository.

That’s it for this post. I now have the system in what seems to be a functioning state. I have created and merged a Pull Request for this step in the GitHub repository. There is not much to it; just some notes in the Readme file and the .gitignore file. My next post will focus on evaluating the current code related to the PHP version upgrade from 5.1.x to 7.0.9. Suggestions, questions, and insights are welcome in the comments section.

Share this on: