Mika Epstein

It means the plugin is detecting 2 gigs of data, so either your hosting provider’s quota check is wrong, or the OS you’re running is giving the wrong results.

Check that the wp-content/upgrades folder is empty and you’ll need to manually determine the size of your folders.

A good command for that is du -sh ./wp-content/

The issue is that it’s (kinda properly) treating .html files as… well … .html. Those are MEANT to be static files and so they’re caught by the static file check. We do have a couple possible changes to fix it, but with only two people impacted, it’s not really a huge priority.

We don’t want to use the extant check for is WP logged in around ALL static caches, because js and css are included there and you should have those cached :/ So we would have to move out the .html check, which we don’t want to do since you really do want .html pages cached.

I know the wholesale URL change is annoying, but at the same time it’s 2015 and .html URLs have been rather unpopular for a few years. I’ll bring it up again at our meeting tomorrow morning, but since there’s no SEO benefit to using it AND it’s a very simple .htaccess rule to change it without losing your SEO ranking or links (people would redirect properly), the safest fix is removing .html :/

They’re separate sites, the espresso.dreamhosters.com and battleandbrew.com ones. When I look on your panel, I see them both as fully separate hosting.

Looking at your site, I see you have a lot of cached content pointing back to espresso.dreamhosters.com, but that should get cleaned up if you flush your cache.

How did you move the site over? There is (sadly) a lot of DB stuff that has to be updated, and that requires plugins (or some command line savvy – wp search-replace espresso.dreamhosters.com battleandbrew.com works on DreamHost).

You’re going to have a problem with your URLs ?? and I suspect that’s why Jetpack’s being weird.

https://www.thezenofmaking.com/2014/12/tutorial-resin-thread-spool-bracelet.html

Notice how they end in .html? We’ve been working through some issues where Varnish decides those are legit HTML pages and caches them as static content, versus the dynamic that WP should be.

We strongly recommend not using .html in your URLs, and just change your permalinks to /%year%/%month%/%postname%/

Then you can use this to redirect all the posts without loosing SEO:

RedirectMatch 301 ^/([0-9]{4})/([0-9]{2})/([^/]+).html$ https://www.thezenofmaking.com/$1/$2/$3/

It would go at the top of your .htaccess. If you open a ticket, we can help you with that.

It’s related to this bug actually

https://core.trac.www.ads-software.com/ticket/27669

It’s not JUST DreamHost having the issue if that helps. If you have Memcached (which DreamPress does), Redis, or APC, you may have this issue. Just flush the DB cache. On DreamPress we run wp cache flush via the command line ??

You can put in an IP block in your .htaccess, but we’ll only block spammers and hackers like that for you here at DreamHost.

You’re on BlueHost, not DreamHost.

https://www.whoishostingthis.com/?q=frontporchcville.com

I can’t detect your PHP version from here either ??

It’s possible he has an older version (you can be on Ubuntu or Debian after all, depending on when the server was built).

beneppard, what’s your domain?

If the plugin’s running on JS, it’s going to be fine with DreamPress, but again, Varnish, the thing you’re clashing with, isn’t working on your account. I’m 100% certain the Varnish cache isn’t the issue just yet.

Ethan, can you try disabling the cache that comes with WordFence?

ethanoltom – You’re on DreamPress, which comes with Varnish (doesn’t cache wp-admin) and Memcached (object caching, kinda caches wp-admin).

datafeedr – How are the ads injected? if impressions are tracked by a JS script, they should be fine, but if it’s plain old PHP, then it may be stuck on cached data.

That said, Varnish isn’t currently caching properly on ethanolnetworks.com for a couple reasons. WordFence is primarily why. BuddyPress is the other main reason.

But did you know that WORDFENCE has a cache? Try turning that off.

Fatal error: Cannot redeclare class Contact_Info_Widget in /home/fgmb/fgmb.dreamhosters.com/wp-content/themes/nimva/functions/widget-contac t.php on line 118

What that means is that ‘something’ is declaring the class Contact_Info_Widget besides your theme nimva.

Here’s some weird code search info:

# grep -r "Contact_Info_Widget" .
./nimva/builder/js_composer/composer/shortcodes_templates/vc_wp_contact_us.php:$type = 'Contact_Info_Widget';
./nimva/functions/widget-contact.php:	register_widget('Contact_Info_Widget');
./nimva/functions/widget-contact.php:class Contact_Info_Widget extends WP_Widget {
./nimva/functions/widget-contact.php:	function Contact_Info_Widget()

and

# grep -r "Contact_Info_Widget" .
./jetpack.old/modules/widgets/contact-info.php:if ( ! class_exists( 'Contact_Info_Widget' ) ) {
./jetpack.old/modules/widgets/contact-info.php:	//register Contact_Info_Widget widget
./jetpack.old/modules/widgets/contact-info.php:		register_widget( 'Contact_Info_Widget' );
./jetpack.old/modules/widgets/contact-info.php:	class Contact_Info_Widget extends WP_Widget {

So yes, they both use the code, but JETPACK properly only calls if it doesn’t exists (that’s the if ( ! class_exists( 'Contact_Info_Widget' ) ) {... bit)

I would contact the theme dev and tell them they have a conflict with Jetpack. That’s a pretty big plugin to clash with, and one they can fix with a simple check to see if the class exists before declaring it: https://www.rockythemes.com/nimva/

418 Unused is us, 100% no doubt, and yes, it’s mod_security saying your string arguments are too long.

Is all that info being put into the URL?

Just skimming it, it looks like Ghostscript doesn’t need ROOT access, so technically you can install it. But we at DH won’t do it for you. Not even with a VPS (and not at all on DreamPress).

What is it you need it for?

Our PHP is a little more forgiving about blank lines outside of PHP calls than others. Which is probably the issue.

kmiskulin – Can you please open a support ticket with DreamHost and tell us that your user ID is invalid?

That’s the issue here, it’s absolutely nothing that you did wrong! One of our robots was clearly drunk when it did setup and broke the user ID for your site ??