You Can Change the PHP Version of Websites Hosted With Hostgator to Version That Are Not Selectable

We were recently working on doing an upgrade of some very out-of-date software. As part of dealing with that, there was a need to change the PHP version being used on the website. We needed to change to a version that the web host of the website, HostGator, doesn’t appear to provide the ability to change to. The client thought that you had to go through HostGator’s support to change it to that version. It certainly looks like that, as they have a selector for customers that only allowed you to change to version to 8.1, 8.2, or 8.3:

Going through hosting support to address something that would be inconvenient at best. There is a simpler way to handle this. In root directory of the files for the website we were dealing with, was a .htaccess file. In that, there were the following lines:

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php56” package as the default “PHP” programming language.

  AddHandler application/x-httpd-ea-php56___lsphp .php .php5 .phtml

# php -- END cPanel-generated handler, do not edit

That code specifies what version of PHP is used on the website. The version of PHP being used on the website was 5.6. If you look closely at that, you can see at one point it says “php56”. Changing that changes the PHP version. So, for example, changing it “php74” would change the version of PHP being used on the website to 7.4.

While the first line says to not edit this, you can safely change the version there.

Another useful feature of changing the PHP version that way is that you can set the PHP version to a different version for different directories on the website. So we could in this change the version of a directory containing a test of the upgrade without impacting the running website.

Disabling Pop Up Images on Zen Cart Website’s Product Pages

Recently, we were brought in to disable the pop up to show larger images on the product page of a Zen Cart website. Looking around, we didn’t see information on doing this with more recent versions of Zen Cart. With the default template files of Zen Cart, there isn’t an option in the admin area to do that. Instead, you need to modify a template file.

If a template hasn’t been overridden, the file handling this is at /includes/templates/template_default/templates/tpl_modules_main_product_image.php

The relevant code is this:

    <a href="javascript:void(0);" onclick="openModal('imageModalPrimary')">
        <?php echo zen_image($products_image_medium, $products_name, MEDIUM_IMAGE_WIDTH, MEDIUM_IMAGE_HEIGHT); ?>
        <br>
<!--        <div class="imgLink center">--><?php //echo TEXT_CLICK_TO_ENLARGE; ?><!--</div>-->
    </a>

What that code does is to create a link that runs JavaScript code that surrounds the image. That would be this part of the code, “<a href=”javascript:void(0);” onclick=”openModal(‘imageModalPrimary’)”>” and “</a>”. When the image is clicked, the JavaScript code runs and the pop up appears.

The simplest way to change that is to comment out the lines like one line in the code already was. So it would look like this:

<!--    <a href="javascript:void(0);" onclick="openModal('imageModalPrimary')">-->
        <?php echo zen_image($products_image_medium, $products_name, MEDIUM_IMAGE_WIDTH, MEDIUM_IMAGE_HEIGHT); ?>
        <br>
<!--        <div class="imgLink center">--><?php //echo TEXT_CLICK_TO_ENLARGE; ?><!--</div>-->
<!--    </a>-->

You could also remove the code. There also is code above that in the file that loads the larger image, which you could also comment or remove.

Any changes you make to the default template files need to be reapplied when you do an upgrade of Zen Cart, if the template files is changed. Or you can use template overrides to handle the changes instead modifying default files.

If you need help handling something like this with your Zen Cart website, we are available to help.

Switching From WordPress to ClassicPress

With what is going on with WordPress, there has been a lot of discussion of there being a fork of WordPress. It’s a bit odd as there has already been a fork of WordPress that has been around for years. It’s ClassicPress. It does have a big difference as it doesn’t support the block (Gutenberg) editor. But for anyone that doesn’t need that, it is available and isn’t a flash in the pan.

ClassicPress refers to switching from WordPress to ClassicPress as a migration in their documentation. For those that have dealt with migration between versions of some CMSs that might sound scary, as the migration involves largely starting over. That isn’t the case with ClassicPress.

The basics of the migration process are really simple, though depending on your setup, it might require more extensive work.

The first step is to install the Switch to ClassicPress plugin in the existing WordPress website.

Once that is activated, the Tools menu in the backend of WordPress will now have a Switch to ClassicPress item.

If there is nothing the plugin detects that would stop the migration, you will see a screen like this:

It has a couple of warnings about possible incompatibilities, but nothing blocking the migration.

If you are unlucky, there may be a blocking issue that stops the migration from being possible until it is addressed:

Going back to what is shown in the first image, the only remaining step is click to the button to do the migration.

If everything goes right, as it did with the website shown in the screenshots. After clicking the button, the website was seamlessly switched to ClassicPress.

Before making any change like this, it would be a very good idea to make a full backup. You already should be making backups for the website.

Even better would be to do a test run of the migration first on a copy of the website. That way you can make sure that your theme and plugins are fully compatile with ClassicPress. If there are issues, it is easier to address them when not having to address on your production website. Or worst case scenario, you realize that your set up isn’t compatible with ClassicPress in the way that can reasonably be fixed, before you switch the production website.

For those looking to have someone else handle the migration for them, and address any problems that crop up, we can do a WordPress to ClassicPress migration for you.

Magento Carding Request Coming Through Magento’s GraphQL API

When it comes to dealing with security issues with Magento websites or other types of websites, we can’t emphasize enough the value of bringing in someone with more security expertise to help deal with it. We recently were brought in to help upgrading a Magento website, where there also was an ongoing issue with a form of carding. The carding here involved someone testing if stolen credit cards were valid by making zero dollar authorizations through the website to PayPal. We were asked if we could help with that as well.

The carding had been going on for weeks when we were contacted. A lot of things had been attempted to address this. What hadn’t been done is where we always start when brought in with something like this. Figuring out what was the attacker was actually doing. That allowed us to quickly implement a solution instead of doing more things that didn’t actually have an impact.

There had been a lot of focus on trying to make changes to the normal checkout process to stop the carding, but the attacker wasn’t using that. Instead, once we were provided with the IP addresses of recent authorization, we found that in the logging all of them corresponded with a single request to the website. An example of that was this:

73.231.56.2 [redacted[ – [18/Oct/2024:16:59:54 +0000] “POST /graphql HTTP/1.1” 200 196 “https://[redacted]/checkout/” “Mozilla/5.0 (Windows NT 6.0; Trident/5.0; EIE60;ENUSMSN; rv:40.0) like Gecko” | TLSv1.2 | 0.834 0.834 0.835 – 0 NC:000000 UP:SKIP_CACHE_SET_COOKIEDT

The important detail in that a POST request was being the URL /graphql on the website. A POST request involves additional data being sent with the request. The data wasn’t logged, so what we had to go on was that the URL. That is the URL for requests being sent to Magento’s GraphQL API. That is an API to allow data to be sent to and from the website.

Because the website isn’t using the GraphQL API, the quick solution without having to make any changes to Magento was to block access to the URL used for that. That instantly stopped the carding.

We haven’t yet gotten access to more data on the requests being sent, which would likely explain better why the attacker could use the GraphQL API, but the quick solution has dealt with the issue for now.

Your WordPress Web Host Might Not Really Your Web Host

The current situation with WordPress has exposed a lot of things about WordPress that have largely been hidden away. The lawsuit filed by WP Engine against the company closely associated with WordPress and its CEO focused a lot on that. Seemingly unrelated to that, it also quoted someone that made quite an admission. They claim to host websites, but as they then admit just a sentence later, they are not really hosting websites:

We are in the same boat. We host websites for schools, nonprofits and mostly rural police and fire departments. We have been working with WP engine for seven years and our margins are not big enough to afford to hire in all of the technical services that WP engine provides as part of its hosting package.

Another way to put that is that they are charging their customers a premium for web hosting that they could otherwise buy themselves for less. That could be worth it, if they are providing some value beyond what you could get with going with the same web host directly. But it also could just mean higher costs. Unnecessary higher costs for schools, nonprofits and mostly rural police and fire departments isn’t a good thing.

If you are looking to get away from someone who is up charging you for web hosting, we can handle moving your WordPress website to a new web host.

WP Engine Isn’t Hacking WordPress, It Is Using Functionality That WordPress Provides as Intended

Right now the head of WordPress, Matt Mullenweg, is doing a lot of damage to everyone else that is involved in WordPress. The direct cause of this is that he is trying to extort a competitor of his for-profit company Automattic. One of his tactics that has been successful in tricking some people that are not familiar with how WordPress works, is claiming the competitor is hacking WordPress to do things it shouldn’t do.

In one post on WordPress’ website, he described that hacking this way:

What WP Engine gives you is not WordPress, it’s something that they’ve chopped up, hacked, butchered to look like WordPress, but actually they’re giving you a cheap knock-off and charging you more for it.

In a follow up post, he put it this way:

WP Engine is free to offer their hacked up, bastardized simulacra of WordPress’s GPL code to their customers, and they can experience WordPress as WP Engine envisions it, with them getting all of the profits and providing all of the services.

But if you look the two supposed hacks, it turns out that WordPress is actually intended to do be able to do those things. So WP Engine isn’t hacking anything at all.

Revisions

The first “hack” involves limiting or disabling post revisions. Here is how he described that:

WordPress is a content management system, and the content is sacred. Every change you make to every page, every post, is tracked in a revision system, just like the Wikipedia. This means if you make a mistake, you can always undo it. It also means if you’re trying to figure out why something is on a page, you can see precisely the history and edits that led to it. These revisions are stored in our database.

This is very important, it’s at the core of the user promise of protecting your data, and it’s why WordPress is architected and designed to never lose anything.

WP Engine turns this off.

If you were to do a search to see how to disable revisions yourself, one page you might then go to is a page on the website’s for one Automattic’s businesses, which provides this explanation on how to do this, which starts this way:

Although revisions are enabled by default in WordPress, you can easily disable them by taking similar steps to the ones discussed above. To disable WordPress post revisions, you’ll need to modify the wp-config.php file.

You can find instructions on accessing the file in the previous section, where we cover how to limit WordPress revisions. Once you find the file, you’ll need to edit the WP_POST_REVISIONS code to disable them entirely. This is the new line you’ll use:

define( 'WP_POST_REVISIONS', false );

So adding a single line of code to a file allows this, despite his claim that WordPress is “architected and designed to never lose anything.”

It goes on to link to a plugin that is available in WordPress’ own plugin directory to do the same.

Information on disabling revisions can also be found in WordPress’ own documentation.

News Feed

The second “hack” was described this way by him:

I won’t bore you with the story of how WP Engine broke thousands of customer sites yesterday in their haphazard attempt to block our attempts to inform the wider WordPress community regarding their disabling and locking down a WordPress core feature in order to extract profit.

The story he didn’t want to bore people with is that he heard a rumor that a news feed was being removed by WP Engine:

Heard a rumor @wpengine is trying to remove the news feed from wp-admin dashboards so people don’t see my post about them, can anyone confirm or deny?

If you are confused about how that relates to what he claimed about WP Engine, you are not alone. What he said doesn’t make sense.

What actually happened is that WP Engine stopped showing links to pages being used by Matt Mullenweg as part of his extortion campaign. This doesn’t break websites and is something that, again, WordPress allows.

One way to do that is to use a WordPress plugin. That is available plugin that is available in WordPress’ own plugin directory and, if you pay for a higher tier of Matt Mullenweg’s competing hosting service to WP Engine, available as well. The plugin uses WordPress hooks, which are there to do things just like this.

What You Can Do About This

The concern that a lot of people have about the whole situation is very real. Just the fact that the head of WordPress is making those unhinged claims about a “hack” that are easily checked to be false is alarming. This situation is likely to be headed to civil legal action and possibly criminal legal action, which won’t involve those using WordPress. But what can you do?

In the short term, making sure that Matt Mullenweg’s misinformation about WP Engine is countered is important. We have no connection to WP Engine, but they are clearly a victim, even if they have their own problems.

In the longer term, unless things change, you can consider moving away from solutions from Automattic and maybe even WordPress. We don’t like saying that, but what is happening is really bad.

If you use WordPress and don’t use its the Gutenberg (block) editor, you can switch over to an existing fork of WordPress, ClassicPress. Which has been available since 2019 and, unlike, WordPress has governance. We can help with that.

What Hacker Does When They Try to Regain Access to a Hacked WordPress Website Through a Backdoor

A couple of months ago, we talked about the difference between a website that is repeatedly hacked due to an unaddressed vulnerability and a backdoor. How you handle those situations is also different and you need to figure out which has occurred to handle it right. One way to help figure out which is occurring is to review the log files of requests to the website, after the website has been cleaned up, to see what the hacker then does. We did just that with a hacked WordPress website we were cleaning up that had an issue with backdoors.

The first requests the hacker made were to try to access malicious code that the hacker added that runs when accessing the website:

  • 157.90.177.207 – – [03/Apr/2024:18:34:46 -0700] “POST /index.php?AyGb=Bcsmp HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.183”
  • 164.92.131.172 – – [03/Apr/2024:18:34:47 -0700] “POST /index.php?AyGb=Bcsmp HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36”

After that failed because the website had been cleaned, they then made requests to many backdoor files they had previously placed on the website to try to regain access and add malicious code back on the website:

  • 162.241.253.213 – – [03/Apr/2024:18:34:49 -0700] “POST /profile.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5.2 Safari/605.1.15”
  • 198.57.247.231 – – [03/Apr/2024:18:34:50 -0700] “POST /[redacted]/wp-includes/PHPMailer/admin.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1”
  • 103.93.160.210 – – [03/Apr/2024:18:34:51 -0700] “POST /[redacted]/wp-includes/block-supports/quxgekpc.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 15_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/110.0.5481.83 Mobile/15E148 Safari/604.1”
  • 64.202.190.47 – – [03/Apr/2024:18:34:54 -0700] “POST /.wp-cli/wp-login.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Mobile/15E148 Safari/604.1”
  • 192.185.4.62 – – [03/Apr/2024:18:34:56 -0700] “POST /[redacted]/wp-includes/js/imgareaselect/options.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; RMX2103) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Mobile Safari/537.36”
  • 185.26.106.164 – – [03/Apr/2024:18:34:57 -0700] “POST /[redacted]/wp-includes/block-supports/mptrluah.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 13; SM-A715F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Mobile Safari/537.36”
  • 162.241.230.71 – – [03/Apr/2024:18:34:57 -0700] “POST /[redacted]/wp-content/uploads/2022/profile.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6,2 Safari/605.1.15”
  • 161.35.61.218 – – [03/Apr/2024:18:34:58 -0700] “POST /[redacted]/wp-admin/css/fkeyshcu.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; vivo 1915) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Mobile Safari/537.36”
  • 217.117.128.10 – – [03/Apr/2024:18:35:00 -0700] “POST /[redacted]/wp-includes/theme-compat/ldgjoguq.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_0_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Mobile/15E148 Safari/604.1”
  • 50.62.150.220 – – [03/Apr/2024:18:35:02 -0700] “POST /cgi-bin/wp-login.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1”
  • 132.148.120.153 – – [03/Apr/2024:18:35:03 -0700] “POST /[redacted]/wp-includes/images/admin-ajax.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36”
  • 198.57.247.226 – – [03/Apr/2024:18:35:04 -0700] “POST /wp-content/plugins/olympus-google-fonts/includes/customizer/controls/js.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1”
  • 182.50.132.94 – – [03/Apr/2024:18:35:05 -0700] “POST /[redacted]/wp-content/uploads/2022/profile.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; M2010J19SG) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Mobile Safari/537.36”
  • 69.163.178.127 – – [03/Apr/2024:18:35:07 -0700] “POST /[redacted]/wp-includes/block-supports/quxgekpc.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 10; M2004J19C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.101 Mobile Safari/537.36”
  • 69.49.241.41 – – [03/Apr/2024:18:35:08 -0700] “POST /[redacted]/wp-includes/block-supports/mptrluah.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; arm_64; Android 11; 21091116UG) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 YaBrowser/23.1.4.84.00 SA/3 Mobile Safari/537.36”
  • 157.230.240.43 – – [03/Apr/2024:18:35:10 -0700] “POST /.wp-cli/wp-login.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/273.0.547966426 Mobile/15E148 Safari/604.1”
  • 95.216.8.84 – – [03/Apr/2024:18:35:11 -0700] “POST /[redacted]/wp-includes/PHPMailer/admin.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 6.0; ALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.74 Mobile Safari/537.36”
  • 63.228.175.170 – – [03/Apr/2024:18:35:12 -0700] “POST /profile.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1”
  • 50.87.144.121 – – [03/Apr/2024:18:35:13 -0700] “POST /[redacted]/wp-includes/images/admin-ajax.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1”
  • 92.222.10.62 – – [03/Apr/2024:18:35:15 -0700] “POST /[redacted]/wp-includes/theme-compat/ldgjoguq.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15”
  • 103.74.116.113 – – [03/Apr/2024:18:35:21 -0700] “POST /[redacted]/wp-admin/css/fkeyshcu.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; CMA-LX2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.98 Mobile Safari/537.36”
  • 202.28.78.37 – – [03/Apr/2024:18:35:23 -0700] “POST /[redacted]/wp-includes/js/imgareaselect/options.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1”
  • 169.45.200.230 – – [03/Apr/2024:18:35:25 -0700] “POST /wp-content/plugins/olympus-google-fonts/includes/customizer/controls/js.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1”
  • 50.62.176.231 – – [03/Apr/2024:18:35:26 -0700] “POST /cgi-bin/wp-login.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/273.0.547966426 Mobile/15E148 Safari/604.1”
  • 109.105.49.240 – – [03/Apr/2024:18:35:27 -0700] “POST /index.php?vfb=Klkw HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1”
  • 157.90.145.251 – – [03/Apr/2024:18:35:28 -0700] “POST /index.php?vfb=Klkw HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36”
  • 81.169.250.132 – – [03/Apr/2024:18:35:30 -0700] “POST /index.php?TgAD=utRBi HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1”
  • 203.245.28.189 – – [03/Apr/2024:18:35:33 -0700] “POST /index.php?TgAD=utRBi HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/115.0.5790.130 Mobile/15E148 Safari/604.1”
  • 148.113.173.205 – – [03/Apr/2024:18:35:39 -0700] “POST /?Zzw=AUFBo HTTP/1.1” 301 244 “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Mobile/15E148 Safari/604.1”
  • 51.91.44.167 – – [03/Apr/2024:18:35:43 -0700] “POST /index.php?WeXQ=yuej HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36”
  • 208.113.205.120 – – [03/Apr/2024:18:35:44 -0700] “POST /index.php?WeXQ=yuej HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36”
  • 184.168.118.22 – – [04/Apr/2024:00:07:17 -0700] “POST /[redacted]/wp-content/themes/qop043n9/cbgyjuye.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; SM-A202F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.62 Mobile Safari/537.36”
  • 142.93.14.237 – – [04/Apr/2024:00:07:25 -0700] “POST /[redacted]/wp-includes/rest-api/themes.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 10; SM-A405FN) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Mobile Safari/537.36”
  • 198.57.247.188 – – [04/Apr/2024:00:07:26 -0700] “POST /[redacted]/wp-includes/rest-api/themes.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1”
  • 185.162.31.173 – – [04/Apr/2024:00:07:30 -0700] “POST /[redacted]/wp-includes/Requests/bsqukfha.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1”

The hacker tried to access over 30 different backdoor files that they placed on the website. It isn’t uncommon for many of those files to have been added and for them to be placed widely across the website’s file structure, as was the case here. Because we had already cleaned out all of those files, the hacker was unsuccessful in regaining access.

Also notably there, the hacker was making the requests from many IP addresses, which is a good example of why trying to stop hackers by blocking access to certain IP addresses is not an effective security measure. (The requests also made it look like the request were coming from a variety of web browsers.)

If you need help with a hacked WordPress website, we can help you.

Transferring phpBB to a New Web Hosting Account

If you need to transfer a phpBB website to a new hosting account, either at a new web host or another account at the same web host, the process usually isn’t too hard. But there are things that can go wrong, so below we go through the important things to do as you are working to accomplish that in way that leads to a smooth transfer.

Test Before You Switch

When doing a transfer like this, the best advice is to do a test of the transfer before you make the final switch over. That way, if any problems come up, you can work on resolving them without having to rush the process.

Transfer the Files

You will need to transfer the files from the old hosting account to the new one. That is usually most easily done using FTP or SFTP to copy the files from the old hosting account to a computer and then copying them from there to the new hosting. That also provides you with a backup of the files.

Transfer the Database

You will need to copy the database from the old hosting account to the new hosting. That is usually done through phpMyAdmin, to export a copy of the database from the old hosting account, and using it to import that copy of the database to a database on the new hosting. Though there may be other options depending on the hosting setup. You will need to create a database on the new server to import the existing database.

Update The Configuration File

Once you have copied the files and the database, you will need to update the phpBB configuration file, /config.php, in the new hosting to have the credentials for the new database.

Plan for a Switch Over

After you have tested out everything and confirmed that it works, plan for a time to switch over to the new hosting. You will need to allocate time for recopying the database and if the files have changed, the files as well. You also need to allocate for the time it will take for the website’s domain name to point to the new web hosting.

You will also want to make sure that access at the old hosting is blocked, so no more changes are being made once you start the final transfer process.

Redo The Transfer and Point The Website’s Domain to New Hosting

Once you have made a final transfer of the database and possibly the files, you need to update the records for the website’s domain name to point to the new server.

Getting Help

If you need help with phpBB, we offer support and we offer a service specifically to handle transfers like this.

Resetting the WordPress Password When WordPress Can’t Send Emails

We were recently contacted by someone who needed support for their WordPress website, where they were locked out of the website and needed to change their WordPress password. We suggested they use the “Lost your password?” link on the login page to reset the password. They said that didn’t work. It turned out that when you tried that, you got shown this message:

Error: The email could not be sent. Your site may not be correctly configured to send emails. Get support for resetting the password.

That message is saying that WordPress isn’t able to send emails. Without that ability, the password reset feature doesn’t work.

So how do you address that? To fix the email issue, you are likely going to need to be able to log in to WordPress as an Administrator. If there is only one account, then you won’t be able to do that because you are locked out. Even if you are not, fixing that can take some time, so it is easier to reset the password another way before addressing the email issue.

The error message links to a documentation page for WordPress on resetting the password. That explains multiple alternative methods to reset the password. All of those require at least minimal technical expertise, so you may want someone to help you with that. That is something we can do for you, alongside getting the email for the website working.

Transferring MediaWiki to a New Web Hosting Account

If you need to transfer a MediaWiki website to a new hosting account, either at a new web host or another account at the same web host, the process usually isn’t too hard. But there are things that can go wrong, so below we go through the important things to do as you are working to accomplish that in way that leads to a smooth transfer.

Test Before You Switch

When doing a transfer like this, the best advice is to do a test of the transfer before you make the final switch over. That way, if any problems come up, you can work on resolving them without having to rush the process.

Transfer the Files

You will need to transfer the files from the old hosting account to the new one. That is usually most easily done using FTP or SFTP to copy the files from the old hosting account to a computer and then copying them from there to the new hosting. That also provides you with a backup of the files.

Transfer the Database

You will need to copy the database from the old hosting account to the new hosting. That is usually done through phpMyAdmin, to export a copy of the database from the old hosting account, and using it to import that copy of the database to a database on the new hosting. Though there may be other options depending on the hosting setup. You will need to create a database on the new server to import the existing database.

Update The Configuration File

Once you have copied the files and the database, you will need to update the MediaWiki configuration file, /LocalSettings.php , in the new hosting to have the credentials for the new database.

Plan for a Switch Over

After you have tested out everything and confirmed that it works, plan for a time to switch over to the new hosting. You will need to allocate time for recopying the database and if the files have changed, the files as well. You also need to allocate for the time it will take for the website’s domain name to point to the new web hosting.

You will also want to make sure that access at the old hosting is blocked, so no more changes are being made once you start the final transfer process.

Redo The Transfer and Point The Website’s Domain to New Hosting

Once you have made a final transfer of the database and possibly the files, you need to update the records for the website’s domain name to point to the new server.

Getting Help

If you need help with MediaWiki, we offer support and we offer a service specifically to handle transfers like this.