Continuing on from last week, I managed to finish up what I have left to do, i.e putting the participant’s contact email in the TSV output as well as testing out the POP3 implementation. Fortunately, everything went as expected. However, there were a few more additions that needed to be done for CRS. One of it includes having to place quotes around each participant’s NRIC number. This is because when the TSV file gets imported into a spreadsheet program such as LibreOffice or Google Sheets, the NRIC number is interpreted as an integer instead of a string. As a result, any leading zero would be truncated, e.g: 0123456 becomes 123456.
This was apparently a common problem during the registration period last year. Since most of the participants are children or teenagers born in the 21st century, their NRIC number would have the leading zero. By wrapping the NRIC number with quotes, the spreadsheet program would interpreted it as a string rather than an integer, hence that is the solution.
Moving on, there is a new competition category for this year. CRS distinguishes the categories based on some identifier, that is specified as a slug in a WooCommerce attribute. When outputting the registration slip or the TSV file, CRS needs to map the category identifier to its human readable form. Therefore, I just need to make CRS handle the identifier for the new category and map it to its human readable form when needed.
Last, but not least, instead of having two duration selections, for the categories that require two repertoire pieces to perform, in the WooCommerce store, the registrants are now required to select only a single duration, which should be the combined total for both repertoire pieces. The purpose for doing so is to minimize the error rate of the selected duration from the actual duration amount.
The database in CRS have a separate table to store information regarding the repertoire pieces. Only the name of the repertoire piece and its duration are stored in that table. If there are two repertoire pieces for a competition entry, then they would be two separate rows in that database table. Since there is only a single duration now, CRS stores the same duration amount for both repertoire pieces and thus can read the duration amount from either. Although it looks wrong semantically, this is the best I could do for now without having to do more unnecessary changes in the codebase and potentially introduce unintentional bugs. Like I mentioned before, the code structure for CRS is really not the best, but having a working application is top priority for now. Some major refactoring of CRS code structure would be needed to benefit its future development.
Once all of that is in place, CRS is ready to be deployed on the production server and the entire could be tested along with the actual store. This time, we tried out a different deployment procedure. Instead of running it as a standalone HTTP server process, we deploy it as a FastCGI process. You could think of a FastCGI process as if it’s like a plugin to an existing web server process. Thus, we do not need to run two separate web server process. It worked like a charm. At least we now know there is another deployment option for any of our future applications.
0 Comments