I recently encountered an issue where dollar amounts such as "$300" in a text field were not showing up correctly when the field contents were rendered as HTML. In this specific case, they were all being rendered as "0".

Debugging Steps I took

The first step was to start in the middle and look at the database. This allows me to mimic the process of a binary search and begin narrowing down the location of the bug. Due to the nature of bugs in general, at some point of the process the desired data was being lost. The entire process of debugging and fixing the issue starts with identifying the point where the source code and execution state doesn't match the intended model. This could happen at data collection, insertion, output, or rendering.

After looking in the database, I discovered that the database contents were storing the string properly. This meant that the data was being affected either during the output, or the rendering phase, so the next step to identify the issue was to look at the HTML source code being generated by PHP.

The source code did not contain the right string, so the issue existed in the generation of the HTML. I visited this part of the code next. The highest level logic existing for the display of the text area is called "formatArticle". I added some temporary debug code to check the value here, to determine if it was a problem getting the data to here, or if the problem was after this point in execution. The debug code revealed that at this point in the execution, the variables contained the correct data.

Following the program flow to the parts of the code that call this method that would be executed chronologically after this point was the next step. Doing this revealed that the issue was not in the article organization. When the page-specific code was done executing, the page contents looked great. This meant that the issue was located in the part of the code responsible for formatting the page and adding standard page elements.

Once again the next step was to follow the program flow to this point, and moving the debug code there to check the true value of the variables. Once again the contents were correct, which meant the problem was specific to the templating code. The templating code I use performs a find a replace on all of the key and value pairs it is passed. The debugging step here was to output the value of the page after each step in the replacement. Doing this showed an unexpected value. Only one replacement was being performed. Because this didn't match my expectation I looked into this next.

After much reflection on the inputs and outputs of the replacements, I believed I had come up with a plausible explanation of the behavior. The instances of $300 in the replacement using preg_replace were actually backreferences to nonexistant capture groups, meaning that the $30 was dropped after replacement.

Towards a Solution

Reading the documentation for preg_replace as well as ereg_replace, and finding that there was no easy flag to disable replacement, I decided to simply add another rule before replacement. This rule converted any $'s it found into \$. After implementing this and testing, it appeared that all was finally well, and that numbers and dollar signs could be stored and used as intuitively expected, with the exception being the string "\$".