Above: The current header for the www.rochesterastronomy.org website. Subject to change (when the template finally breaks).
From the shameless self-promotion department (isn't that the whole site?) – I was honored to have been selected as the Outstanding Astronomer of 2025 by my current home astronomy club, the Astronomy Section of the Rochester Academy of Science ("ASRAS").
Two points to this.
One – I had barely observed all year with more than my trust Nikon Action 12x50s (but don't tell Ryan Goodson) and, with a six- and four-year-old in the house making things occasionally difficult in the 7 to 9 p.m. range, have barely been present at a monthly ASRAS meeting since before COVID. Anyone on the email list who sees the quality of member astrophotography knows that there are plenty of people doing serious, widely acknowledged (featured images in Sky & Telescope and BBC Sky at Night Magazine, which covers a lot of territory), generally stellar (sorry) work that might better fall into the "outstanding" category. My contribution to the club the past two years was the migration of the old website into a new and improved WordPress database and template, getting the online membership forms installed and working with the rather complicated assemblage of membership dependencies within RAS, and attempting to do both sensitive to the inner workings of the club and in the interest of future-proofing its online presence for the next webmaster to come along.
Two – having presided over one club (for a while) and been director of another (and still holding the keys to the website), I know well how much effort it takes to keep the lights on for a group of amateur astronomers with many varied (and not always overlapping) interests. Most of the clubs I've interacted with have been very good at being non-profits – maintaining officer positions, holding meetings, keeping the membership engaged, keeping the observatories clean and ready for public viewings, and being out-and-about in the community when libraries, scouts, state parks, and senior living facilities come calling for public astronomy outreach. All of that volunteering matters a lot, and stepping up in a club to take over even a small thing (that you might even be good at) is not insignificant to those members taking on other additional responsibilities within a club to keep that club running.
Amateur astronomy clubs survive on volunteerism, and sometimes the most useful contributions happen behind the scenes rather than under the stars. That said, clear nights with clean optics and friendly banter are magic, and I hope to get back to it in full force soon (maybe with a kid or two in tow to ruin their sleep hygiene as well).
Above: if only he'd waited, Σωκράτης (that's "Socrates" to the rest of us) could have seen his name rendered correctly on my site. From "Death of Socrates," by Jacques-Louis David, 1787.
Logging into phpMyAdmin for this site, I was greeted with (the key part of this being the latin1_general_ci)
And, from all reports, the latin1 character set does not support special characters. The character set of choice seems to be utf8mb4, for which a completely usable collation is utf8mb4_unicode_ci. So, to begin, change that.
Next step in this process was the replacement of all instances of latin1 to utf8mb4 in my database, which I performed as per the recommendations found at brianli.com/how-to-fix-wordpress-character-encoding/ but with the SQL query box.
And yes, for f's sake, back up your database first or download a copy and then do this.
Below is the process I went through to clean up a WordPress site injection into www.cnyo.org – an old astronomy club I directed and a site (now unused) that I still maintain/keep active because there's lots of (a) good information and (b) CNY-based astronomy history to be read. There are many, many files in a WordPress install that can suffer an attack of some kind, many, many ways for a hacker/bot to make such an attack happen, but only a few things everyone seems to recommend doing to try to make the problem go away. In my case, the problem with the website went away after simply renaming two folders, uploading new versions of those folders, and then using the success of that replacement step to find the exact files in the site that were causing me issues. Consider this post a "First Step" if you find yourself similarly inconvenienced.
Some Light Reading (Background)
The CNYO website had, up until quite recently, a bug in the main menu that I initially chalked up to a very old (and free) theme (Vortex) running up against recent updates to WordPress. The romantic perspective on the maintaining of the site mentioned above aside, the site is really only still up because it (a) costs me nothing and (b) is now hosted in a subfolder of this website, and the site only gets a few visits each day (even with the upcoming solar eclipse in Western New York, cnyo.org is crickets). I hadn't much bothered exploring the menu issue further. The specific issue is shown below for the front page of the website, with the "About" menu much larger vertically than all the other menu items and the sub-menu items inside of "About" equally expanded.
A bane of my existence for a while. If you visited the cnyo.org site in the last few years, you know.
Interestingly, this oddity started appearing in Firefox and then, after a year or more, began appearing in Chrome and Safari. Clicking on the About link produced the image at the link below, which was a full-blown insertion of unwanted content and a de-columning of the website (and, even worse, it shows two fewer people subscribed to the site!).
While making tweaks to the rochesterastronomy.org website and un-doing a menu expansion that shouldn't have been, I decided to check back on the CNYO site to see if I could play the same trick. And I couldn't. But, in exploring how to tailor the css in browser Developer Tools, I noticed a slew of embedded links and class="r67298bc6" calls that I had not previously for Klonopin/Clonazepam.
Enlightenment by way of Developer Tools in Chrome (Firefox, Safari, etc.)
Klonopin is "used to treat panic disorder (including agoraphobia) in adults." I am 100% for adults overcoming anxiety about being outdoors (because I do astronomy) or with groups (because being outside in the middle of nowhere while observing by yourself can get old when the first howls are heard). That said, advertise by injecting something into someone else's WordPress, please.
Files And Tools To Have On Hand
It's a short list, things you probably have on hand or quick access to anyway if you're maintaining your own website (self-hosting or, at least, self-sufficient on your hosting service), and things you should probably always have at-the-ready for when (not if) the situation calls for them.
A local copy (on your computer) of the WordPress version your site is currently using. To be even more exhaustive, have copies of EVERYTHING installed on your site. Themes, plug-ins, custom css, media, etc.
All the needed credentials to get into your site by (s)ftp
A browser's Developer Tools to do that cursory inspection of whatever looks off (all modern browsers have this option, snoop around the Tools menu)
Access to your site's database (likely phpmyadmin if you're running a WordPress site on a major hosting service)
A tool for comparing the contents of folder A and folder B – this is how you'll find the difference in the content of the before/after files to see which file or files has/have been modified
stackoverflow open. This link, this link, and this link were early first reads on my path (the third link was insightful, but it turns out my problem was in a WordPress core folder itself).
Step 1 – Replace WordPress Files (Carefully!)
A quick check that might save you several hours. This assumes you've done nothing to the contents of wp-admin and wp-includes, which is a pretty good assumption unless you dabble in .php files. All of your themes, plugins, and uploads are in wp-content.
My working FileZilla window, with renamed folders on the right (hosting company) and local folders (with fresh WordPress folders) on the left.
Uncompress your local copy of WordPress to have all of the core files/folders accessible for uploading
Log out of your WordPress site if you're logged in (you probably don't have to do this)
Get into your site account's directory with your (s)ftp client
Rename wp-admin to wp-admin-old and wp-includes to wp-includes-old
Upload the local WordPress copy's wp-admin and wp-includes
When done, hit RELOAD on your problematic site.
For www.cnyo.org, my problem went away completely.
Step 2 – If Needed, Replace More WordPress Files (Very Carefully!)
My next step would have been to VERY CAREFULLY inspect and/or replace the .php files in the main directory (in the image above, index.php and downward, not touching .htaccess or .user.ini until a "Step 2b" when I found past versions to compare these to).
My next-next step would have been to go into wp-content with backup copies of my themes and plugins, but I would have done this VERY, VERY CAREFULLY.
Usual reminder from other sites – make sure you have a copy of wp-config.php somewhere, else you're in for a very long evening if you do something unwanted.
Step 3 – Inspect The Database
I started here, as it seemed the most likely culprit based on lots of searching for similar issues. Consensus among several discussions was that searching for the keywords:
eval, gzinflate, shell_exec, base64_decode
in your database would produce the maximum bang-for-buck. As it happens, only "eval" existed in the CNYO database and, sadly, "eval" is a common combination of four letters on a science-based website (so 100 hits, many of "evaluation").
I was fortunate to do this first-pass, find little that looked problematic, and move on to Step 1 above instead.
Step 4 – Transfers Worked? Now Find The Problem (Locally)
For the academically curious… the wp-admin and wp-includes replacement solved my problem. Doing the next logical step of renaming the new wp-admin to wp-admin-new and renaming the old wp-admin-old to wp-admin (alphabetically, of course), I found the site remained in its original, untouched state – placing the problem file(s) squarely in wp-includes.
To find the official location, one needs a tool that will compare the contents of files and directories. In OSX, this is FileMerge in Xcode (search for the app or Command-Space Bar and type filemerge.app (see this link on stackexchange for a how-to). If you don't have Xcode, similar comparison tools exist on all OSs.
To start this, I moved wp-includes-old to my local machine so as to perform this comparison in filemerge. I renamed it to wp-includes in the pic below.
Once open, select the wp-includes in your clean, unzipped WordPress folder as the Left folder, then select the wp-includes(-old) as the Right folder. And run Compare.
Left folder is the clean WordPress folder, Right is the hacked folder.
FileMerge with the wp-includes folders loaded for comparison, showing only folders containing files with differences (click on Identical to exclude those files).
temdfgp.php, containing a call to a hidden file .quota
.quota, not in the official WordPress release, but very present (and problematic) in the old cnyo.org wp-includes.
Clicking on "Identical" on filemerge's righthand side to exclude all identical files, the list of changed files from old-to-new is small, with the offending .php file identified as temdfpg.php, which calls a .quota file that looks something like below:
php $IBmtKwVMuXQGpgbUH='ur'.'ld'.'ec'.'od'.'e'; … lots of and lots of scribble ... %22%2F%3E%3C%2F%73%62%65%7A%3E'));exit;
Problem identified, problem solved. All in all, I suspect I got lucky in doing a few very simple things to narrow down the location of the problem. I will hope for similar luck next time.
