Helpful Coder

A long-time client contacted me with a question about their SSL certificate, and said they thought the site "might be hacked." Well, boy was it hacked. Shell scripts everywhere, and core Wordpress files as well as plugins heavily modified. I think it's all cleaned up now, so I thought put up a quick post about the process while it's still fresh in my mind. How to know it's hacked? In this case, it was easy. The site looked fine in the browser, but when I logged in and looked at the files on the server there were quite a few shell scripts which are little php files (in this case) that give the attacked a 'back door' to continue to upload files/etc even if their WordPress access was closed off. Additionally, there were many core files (wp-config.php for example) that had huge chunks of encoded text inserted at the top of the file. Additionally, looking at the transfer logs revealed traffic to weird looking URLs that were definitely not legitimate pages/post...

This one caused some confusion today! I have an AWS lightsail server set up. It handles multiple different domains - essentially the same codebase, but does different things depending on the hostname (domain) being used to access it. I needed to add a new letsencrypt certificate to the system. This would be the second one I've added. After generating the certificate, I found that the new site (called it domain2) was trying to use the certificat of the first site (domain1) ... I thought I'd generated a certificate that supported both domains, but apparently not. After some poking around (lightsail has its own way of setting up the apache configuration files) I finally figured it out. To fix it, I needed to have two different virtual host (port 443) directives. They were essentially alike, except that that I had to add ServerName and ServerAlias settings appropriate for domain1 and domain2, and set the SSLCertificateFile and SSLCertificateKeyFile settings appropriately. Now I j...

 I'm working on a largish project, converting it to work from early PHP 5 to PHP 7.3 and I found myself spending a lot of time converting all those various mysql_* to their equivalent procedural mysqli_* function calls. Mostly pretty tedious. Anytime you encounter something tedious that you'll have to do on a ton of files, it's a chance for automation. In this case, I decided come up with a vim macro that would automagically convert the most commonly occurring function calls. Here's the macro, which uses 4 regular expressions to search and replace the four most common ones - then followed by a search for "mysql_" to catch any outliers. :% s/mysql_query(\(.\{-}\),\(.\{-}\))/mysqli_query(\1 , \2)/eg :% s/mysql_fetch/mysqli_fetch/eg :% s/mysql_num/mysqli_num/eg :% s/mysql_close/mysqli_close/ge :/mysql_ The easiest way to use this is to paste into a new document, then select it all and yank it into a buffer. Then just run the buffer as macro. So, I used 'm...