websta

I want to add one other mistake I made, in case anyone else runs into this problem. At a certain point, the underlying pages worked fine, but the homepage would have redirect errors. The problem turned out to be a capital letter in the subdomain in the WordPress settings: R6.utah.gov instead r6.utah.gov.

Thank you very much for your help, Threadi! Your comments led me to a remedy.

It seemed like the problem was with Litespeed server/caching thing/whatever it is.

Here’s my solution: I activated the Litespeed Cache plugin. I flushed the cache using the plugin, leaving it activated. Then, I changed the permalinks to from “Plain” to “Post name.”

On my PC, the pages appeared still broken, and since I was thinking about caching — this time in my browser — I double-checked the site, remotely, via Browserling.com.

Viewing the site remotely, the pretty permalinks worked, using “Post name.”

Apparently, while I was thinking things over, the caching had apparently been updated for the site and although my browser is still showing a broken (home) page from the browser’s cache, the rest of the site’s pages are appearing properly, as they had before (using Post names) — but now, with the new domain name.

All’s well. Thank you again, Threadi! I appreciate your insights and help.

With the site set to “plain permalinks,” I added “aaaa” in line one of .htaccess (via editing using file manager in cPanel), saved that, reloaded the public pages, and they loaded just the same — loading correctly, but using plain permalinks.

Is that what I was supposed to do? What does that mean?

Server Name premium230
cPanel Version 110.0 (build 24)
Apache Version 2.4.59
MySQL Version 10.6.17-MariaDB-cll-lve
Architecture x86_64
Operating System linux
Shared IP Address…
Path to Sendmail /usr/sbin/sendmail
Path to Perl /usr/bin/perl
Perl Version 5.26.3
Kernel Version 4.18.0-513.11.1.lve.el8.x86_64

Sorry, here is the actual .htaccess file, currently, minus the hashtags which aren’t copying over:

BEGIN LSCACHE LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block!


RewriteEngine on
CacheLookup on
RewriteRule .* - [E=Cache-Control:no-autoflush]
RewriteRule .litespeed_conf.dat - [F,L] marker ASYNC start

RewriteCond %{REQUEST_URI} /wp-admin/admin-ajax.php
RewriteCond %{QUERY_STRING} action=async_litespeed
RewriteRule .* - [E=noabort:1] marker ASYNC end marker CACHE RESOURCE start

RewriteRule wp-content/./[^/](responsive|css|js|dynamic|loader|fonts).php - [E=cache-control:max-age=3600] marker CACHE RESOURCE end marker FAVICON start

RewriteRule favicon.ico$ - [E=cache-control:max-age=86400] marker FAVICON end marker DROPQS start

CacheKeyModify -qs:fbclid
CacheKeyModify -qs:gclid
CacheKeyModify -qs:utm*
CacheKeyModify -qs:_ga marker DROPQS end LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! END LSCACHE BEGIN NON_LSCACHE LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! END NON_LSCACHE BEGIN WordPress The directives (lines) between "BEGIN WordPress" and "END WordPress" are dynamically generated, and should only be modified via WordPress filters. Any changes to the directives between these markers will be overwritten.

RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase / RewriteRule ^index.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] END WordPress BEGIN Security Block Block the include-only files.

RewriteEngine On RewriteBase / RewriteRule ^wp-admin/includes/ - [F,L] RewriteRule !^wp-includes/ - [S=3] RewriteRule ^wp-includes/[^/]+.php$ - [F,L] RewriteRule ^wp-includes/js/tinymce/langs/.+.php - [F,L] RewriteRule ^wp-includes/theme-compat/ - [F,L] Disable directory listing

Options All -Indexes Remove header with PHP version

Header always unset X-Powered-By
Header unset X-Powered-By END Security Block BEGIN LiteSpeed The directives (lines) between "BEGIN LiteSpeed" and "END LiteSpeed" are dynamically generated, and should only be modified via WordPress filters. Any changes to the directives between these markers will be overwritten.

SetEnv noabort 1 END LiteSpeed

order allow,deny allow from all

deny from 157.245.201.74
deny from 94.156.64.75
deny from 91.92.241.245
deny from 91.92.246.225
deny from 173.249.52.101
deny from 173.249.52.122

Here is the .htaccess file, which looks incorrect to me:

# BEGIN WordPress
# The directives (lines) between “BEGIN WordPress” and “END WordPress” are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
# END WordPress


If you need the Site Health info (and it’s not a security concern), please let me know.

• This reply was modified 11 months ago by websta.

Yes, of course. However, when switched to another permalinks setting, there are redirect errors–no pages display properly/at all.

Thank you for the response and info. I removed that block of text from the .htaccess file as well as the new login file. Logged in and still got blocked moments later.

So it appears there is something else wrong at my host.

My apologies!

To be clear, this is a seemingly standard WHM/cPanel hosting setup which most webhosting companies use. So, if this is something new to WHM/cPanel, then could it affect everyone using the plugin?

Thanks for the code, Mitchell.

I guess I am mistaken, then. FWIW, we had cron jobs taking our shared hosting account (Midphase, a higher end business plan) down about 900 times per 24 hour period. Unacceptable. Tech support just said there were tons of cron jobs running, not completing, and stacking up, causing faults. The issues started when we’d installed the AMP plugin on our (only) 8 websites in that account.

So, realizing that, we removed AMP from all our sites, and it still gets faults but far less. I figured that the plugin was checking on whether the sites were updated, and those cron jobs were stacking up, unfinished.

Maybe Midphase isn’t keeping up with the times but the demands of WordPress on shared hosting seems to be getting to be too much. The “wordpress hosting” sites seem like a warning that thing have gotten out of hand, especially since they’re really too expensive for offering what seems to be just plain ole hosting, particularly when Adsense, etc., offer far lower returns than what they used to (we’re down ~80% in revenues from what they were, say, 5-10 years ago).

Said it before, and I’m saying it again: WordPress needs to cut its hosting demands profoundly — which ought to be the team’s main focus now. In terms of its interface, it needs to simplify, simplify, simplify, instead of offering unrequested flexibility to power users (they can just buy Divi).

Once a site is developed, I need it to barely run so it can serve up the (mostly static) pages super fast — and that’s it. We’ve tried using caching plugins but their recurring checks for updates and resulting performance loss ended up being a net loss for us.

Back in the day, I’d be in the Apache settings all the time trying to fix things; now, I don’t give it a thought. WordPress **needs** to head in that direction.

FWIW, in the meantime, you might want to try to limit your feeds to those which are httpS.

Thank you for your help! I added an “!important” to the width and it worked very well.

Thanks again for your awesome work!

You can alter the template page and add it to your child theme.

Add the modified file place the page here:
themes/YOURTHEME-child/deal-of-the-day/deal_of_day_view.php

If that doesn’t work, add it to:
themes/YOURTHEME-child/deal-of-the-day/includes/shortcodes/views/deal_of_day_view.php

The Page template I’ve made accesses only part of the Page’s files, which are split up in so many ways that, honestly, it is beyond me.

I’ll research the page you listed and see if I can integrate that into what I have.