heytricia

As it turns out, there was a command in the config file disallowing file edits. How or why it got there, I don’t know. This has happened twice within the last two weeks with fresh installs. Editing wp-config did the trick.

I’ve noticed the same issue in new installs. These are dev environments without security plugins activated. I even tried switching to a default theme, in case my parent theme was the culprit. No luck.

I’m so sorry for the false alarm. The issue wasn’t with your plugins or the CSV – it was with the database. I realized this after not being able to upload images to the media library and getting an error that pointed us in the right direction.

@specialk – I’m seeing the same or a similar issue. I set the plugin to disable only on a legacy template – using template-name.php.

This worked to prevent g-blocks from showing in the edit view, but… it breaks layouts on the front end. Specifically, text and images set to center show the applicable classes in the DOM, but it looks like the styles to make that happen aren’t being served.

That does seem to have addressed the problem. Now that learning mode time has expired, I am still able to work with SG Optimizer in the sub-site.

So does this mean we’ll have to go through these steps every time we add a new subsite?

Agreed. I’m glad you posted, because it gave me something to point to with server support. It did take a few tries and a bit of pushing to find the real issue.

So thanks for sharing – and rocking on! ??

As it turns out, this was a case of migration – I just didn’t know it. Siteground migrated the site to a new server. I’m sure they notified my client, but that’s easily overlooked, and we devs are typically the last to know…

So the original dns settings were still in place. The old IP still forwarded users to the new one, but this made it look like all users were coming from the original IP. After updating A records, the issue was resolved.

My case is not a result of migration or propagation.

When I recheck the logs, all traffic is still being logged with the hosting server IP. All is fine until someone breaks a rule – and then the site is shut down for all.

At some point I ran across support documentation that said if one IP is being logged for all traffic, to check the settings for how Wordfence gets IPs. I am using the recommended “Let Wordfence use the most secure method to get visitor IP addresses.” Still…. when I log out and back in, Wordfence shows the activity coming from the server’s IP. I’m just hoping that plugin support monitors and responds to these threads regularly.

I’m having a similar issue. I also use Wordfence on multiple client accounts and have just one on Siteground that is logging all live traffic with the site’s IP address – and shutting down the site. I just tried restoring default settings with no luck. I don’t want to whitelist the IP if all traffic – including bad – is being logged with that IP.

I did reach out to Siteground support last night, and got this feedback:

The issue here is related to the Wordfence’s “Live Traffic View” feature, the requests it makes to itself, just use one of the server’s IP addresses.

Since this feature “reviews” all requests before they reach the website, they all appear to be coming from the server IP address, while maintaining their user agent.

So this seems to be a plugin issue?

Thanks for the update!

I had some luck with creating a custom post template, i.e. single-eventbrite_events.php.

@xylus

I’m using v1.5.6 and need to add a sidebar to the single-event-post views. I see part of the path you noted above: wp-content/plugins/import-eventbrite/templates/ – but it does not have a layout folder.

I tried adding to my theme anyway by using the file structure in place – with no luck. So I removed the folders and file. As it turns out, the post view isn’t even using templates from the plugin! When I use “What the File”, it looks like the event view is using single.php and several include files – none of them driven by the plugin. It’s relying on theme files instead.

Am I missing something?

Here’s the status for the site I had issues with:

Status

WP-Optimize 2.1.1 – running on: PHP 5.5.24, MySQL 5.6.24 – Darwin
There was no automatic optimization
Scheduled cleaning disabled
Not keeping recent data

Current database size: 5.5 MB
You can save around: 2.4 KB

I’ve used your plugin many times, and this is the first time I’ve seen something like this. It could very well be an issue with the site’s database. I started with a site built years ago… so it was pretty antiquated and used methods that need to be redone. I’m building a new theme now and wanted to clean out data-trash. It’s worth mentioning that I also tried optimizing from phpmyadmin and ran into the same error.

I don’t think disabling the plugin would have fixed anything… the database had been affected, so the damage was done.

I just ran the updated plugin on a local site and have the same issue – The frontend of the site isn’t able to connect to the database.. I was prompted by the plugin in dashboard view to add a line to wp-config and run a repair, which I did. Feedback: wp_options: Table is marked as crashed and last repair failed.

I tried this, but it didn’t work. Were there additional changes?