MichaelPaulmeno

Just to give an update it looks like our WordPress site may be too big for our shared hosting plan. According to the company our website is hitting the limit of the resources they allocate shared hosting accounts, which they say is probably causing some of the errors we’re seeing.

Our hosting provider said they couldn’t find anything out of the ordinary. They did send us the Litespeed and MySQL logs. I’m not an expert with either, but saw a bunch of messages like these around when we had trouble:

Litespeed:

/var/log/apache2/error_log:2022-02-07 02:24:08.409493 [INFO] [22056] [xxx.xxx.xxx.xxx:57760-1#APVH_lib.skidmore.edu:lsapi] Abort request processing by PID:20622, kill: 1, begin time: 0, sent time: 0, req processed: 0
/var/log/apache2/error_log:2022-02-07 04:17:14.611139 [INFO] [24620] [xxx.xxx.xxx.xxx:60971-1#APVH_lib.skidmore.edu:lsapi] Abort request processing by PID:9318, kill: 1, begin time: 1, sent time: 1, req processed: 0
/var/log/apache2/error_log:2022-02-07 04:17:49.026266 [INFO] [24620] [xxx.xxx.xxx.xxx:60971-1#APVH_lib.skidmore.edu:lsapi] Abort request processing by PID:9763, kill: 1, begin time: 0, sent time: 0, req processed: 0
/var/log/apache2/error_log:2022-02-07 04:25:56.115219 [INFO] [24623] [xxx.xxx.xxx.xxx:38974-1#APVH_lib.skidmore.edu:lsapi] Abort request processing by PID:17784, kill: 1, begin time: 1, sent time: 1, req processed: 0

MySQL:

2022-02-03T15:11:23.005493Z 48190 [Note] Aborted connection 48190 to db: '<name redacted>' user: '<name redacted>' host: 'localhost' (Got an error reading communication packets)

I opened a ticket with our hosting company on Friday to have them look at those logs and will report back what they find. In the past they haven’t found much, but it’s not clear they searched all the logs mentioned in the other post. Would it help to send you our logs?

I figured it out. One of the mod_security rules was preventing the admin dashboard from loading properly. The key was to check the SSL error log. Once I did so, and disabled the offending rule for a few files, everything was fine.

I decided to bite the bullet and simply rewrite all of the image links in my blog. As it turns out, not all of them transferred over from Blogger. Now I’ve installed the plugin and everything seems to be working fine.

I thought manually deleting images from the server would still leave the (now broken) image links in my blog posts. Therefore once an item was re-uploaded it could simply reappear without me having to touch each page. Of course if said image is now hosted on S3 the link would still be wrong, hence my question.

However I may have misunderstood how the plugin is designed to work. I thought by “automatically replaces the URL to each media file” you meant, the URLs in the blog posts themselves. It seems that will be reserved for the pro version. Do you know when it will come out?

Fixed *dances around the room* ! The key was to put test.michaelpaulmeno.com/blogs as both the site address and the WordPress address URL. Now if you go to the first link, the problem appears. However since that is not one I plan on giving out, it is of little concern. I still have to fiddle with Apache so that one can access the blog by simply typing test.michaelpaulmeno.com without needing the /blogs (and get rid of the default Apache test page in the process), but that can wait for another time.

Thank you for your help Martin. I am very new to WordPress administration and am still learning the ropes.

Yeah that didn’t help me either. Restarting did not do much good.

I feel like this must be a theme issue. Some script is not pulling images from the right spot. Perhaps the FQDN is buried somewhere in the theme file where the images are called up? Problem is I can’t seem to find any suspicious looking code in the php files so far.

I did not notice the font. Thank you for pointing it out.

Additionally modifying the Virtual Host in Apache did not make a difference. My thought had been that with the document root being /var/www/html and the content being in /var/www/html/blogs the wrong URL was being served up causing the browser to look in the wrong spot for the images. Such does not the case.

The alias was created in AWS Route 53. Admittedly it was only set up around 6 PM Central US time. For testing purposes the blog is hosted on EC2 with the OS being Amazon Linux (haven’t decided on a production host). But since the user arrives at the correct page, I don’t see how the DNS could be an issue.