Here’s a function I use to load mysql data into a hash for quick lookups in my code:

function select_sql_hash ($link,$sql,&$all_hash,$key) {
  $r = mysqli_query($link,$sql);
  if (!$r) {
   $message  = 'Invalid query: ' . mysqli_error() . "\n";
   $message .= 'Whole query: ' . $sql;
   print "$message\n";
        exit;
  }
  while ($results = mysqli_fetch_array($r, MYSQLI_ASSOC)) {
        $all_hash[$results[$key]] = $results;
  }
  mysqli_free_result($r);
}

This can be called something like this:

$topics = array();
select_sql_hash($db,"select topicid,name,created_date from topic",$topics,"topicid");

The results is a hashed array where $topic[5][‘name’] is the “name” field for that topic, and $topic[5][‘created_date’] is the date created, etc. This is handy if the code is doing some mapping to print out topic names and you’d like to avoid joining the tables. Or it may save additional queries to the database when displaying data.

One way to tell a website that hasn’t been updated in a long time, or is defunct, is by whether or not it has a “responsive design”. Responsive designed sites are made to display nicely on any size screen – smartphones, tablets, laptops, etc. The essentially “redraw the layout” or respond to the available screen size. You can easily see this in action by loading up a site on your computer, then “shrinking” the screen (width wise). As it shrinks, the content should re-position itself (if it’s responsive) to fit on the current window size. There are many frameworks out there to facilitate responsive design. For the test site below, I used bootstrap:

https://quickthreads.com/

The site pulls in article summaries from several news sites daily for quick reading on any device. Below are screenshots of full screen and mobile views:

Full Size View

Mobile View

Recently, a new security issue with Linux came to light (https://nvd.nist.gov/vuln/detail/CVE-2021-3156), which could allow a user to gain root access of a server. This is using the “sudoedit” command, which is used to give users elevated privileges (but not root access) in some cases.

The first question a website / server owner should ask here is “Is my server vulnerable to this?” – if so, the next question is “who needs to fix it and how?”. In this particular case, only servers which allow normal “user” access need to be immediately concerned.

If you run / own a dedicated server with only trusted user accounts, the urgency to get patched is not as high. For sure, you should get it done, but it’s unlikely someone could exploit this bug.

If, however, you run a multi-user system with many untrusted users logging in, you probably need to act quickly. Once these bugs are revealed publicly, hackers will look to exploit them. Many hosting companies run jailed-shells, or otherwise restricted shells, so they may not be vulnerable. If you have a more vanilla Linux installation with multiple user accounts, you should get this patched.

On websites with tight budgets, and no development staff, it’s fairly common to make code updates directly on the live code. The thought of this gives many coders the chills, but I’ve been doing this for 20 years. When a client can’t afford a development environment, doesn’t have a code repository, and there’s no time / budget for a lengthly QA process, this is what you do.

There are a few relatively easy ways to handle live changes:

• Be careful and test immediately. For small changes, this works well. If something doesn’t work, you can quickly revert with little to no downtime. If it does, then you are finished and the code is live.
• Save old code / edits – make sure you have a quick “restore” plan in case something really gets messed up.
• Work with parallel code – for larger changes, make a copy of the affected code, and use that for testing until you are confident it’s working. Then swap it in place.

Obviously, these tips only work for relatively minor updates to the code – changes that require structural database or code changes will most likely require some kind of development environment to be set up. However, many day-to-day changes can be accomplished without the overhead of a full blown development cycle.

This week a long-time client called with an issue – people were trying to buy items from his website, but the transactions were not being processed correctly. Credit cards were being charged, but the site was not seeing the successful purchase.

After some investigation, it turned out the payment processor had ever so slightly modified the return value for transactions, adding in a newline to the beginning of the value. This broke the code that was looking for the success code, thus causing the problems.

The key to identifying this issue was good logging, and reviewing the code carefully. Once fixed, new transactions worked as normal. It’s not clear to me that the payment processor communicated this change at all, and perhaps it was an unintended side-effect of another change they made.

When troubleshooting new issues to code that has been working for a long time, my first question is “what changed?” – if I can figure out where the change occurred, it’s then easier to rectify the problem.