3Lancer

There’s one issue I’ve found when using it’s Addons, however it probably only affects me.

Awesome Support: E-Mail Support version 0.2.1 when activated with the new plugin, will display “You do not have sufficient permissions to access this page.” on it’s setting page.

I noticed you have a version 0.2.2, but my support has just expired back on May 21, 2016, so probably will need to renew and update to use it again?

I also use Canned Responses and Private Notes, those however work fine.

Hi Julien,

I ran a quick test run on a development server. It appears to be resolved the issue now, thanks a lot!

Found it under the debug log dump now, with those extra outputing:
PHP Warning: Invalid argument supplied for foreach() in /wp-content/plugins/awesome-support/includes/functions-addons.php on line 23

Don’t know if this is related and the root cause?

Notice: is_category was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see Debugging in WordPress for more information. (This message was added in version 3.1.) in /wp-includes/functions.php on line 3897

Notice: is_tag was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see Debugging in WordPress for more information. (This message was added in version 3.1.) in /wp-includes/functions.php on line 3897

Appear just before that PHP Fatal Error, when using debug dump under wp-config:

define('WP_DEBUG', true);
 define('SCRIPT_DEBUG', true);
 define('SAVEQUERIES', true);
 ini_set ("display_errors", "On");
 error_reporting(E_ALL);

Same here. The error only occurs on the backend (Admin area).

PHP Fatal error: Call to a member function get() on a non-object in /wp-includes/query.php on line 28

Repeats each time the admin area is attempted to be accessed. Shows nothing else and error log shows the same.

Hi,

If this is of help for you:

After updating to version 5.4, Database Backups was set to “Enabled”. I don’t believe this was enabled prior, however I might of tried the “Create a database backup” option once when exploring the option changes.

Setting where: Backup Full Database (unticked), Backup Method (email only), Retain (0), Compress Backup Files (zip ticked), Schedule Database Backups (unticked).

Even though it wasn’t set as scheduled, it would email around 10:46am daily providing zip backups.

Resaving these setting wouldn’t prevent it from occurring the next day.

The memory exhausted error messages just occur on any webpage (admin back-end or the front-end pages) at random times. Refreshing the page and it would work fine again.

I was attempting to disable other plugins, but those didn’t affect it at all by the looks. I had to click the “Disable” button on “Database Backups”, then it ran fine from then on.

The security leak is not actually mentioned. It could be they gain access via FTP or an uploader exploit, etc.

It appears the hacker had just spread his exploited PHP files to try avoid being fully cleaned up and secured.

The plugin folders affected where:
/plugins/cybersyn/
/plugins/bullet-proof-security/

However:
/uploads/ithemes-security/

That isn’t actually the plugin, but rather it’s backup and log folders under uploads.

Under it check for (these help protect it from public access):

index.php

<?php
// Silence is golden.

.htaccess

Deny from all

Try unticking the ‘zip’ option for your backups, if your server host doesn’t support it?

Great, I believe I will need the same thing! Over 246,000 customers ??

Thanks for your feedback, I will check into that as a possibility.

I haven’t personally done that, but could be one of the plugins. Originally, I was assuming it’s an optional parameters (PHP allows you to leave it off), but if it’s a requirement, then you would be correct and it should be fixed the other way around (avoiding this patch).

Use FTP Client to access your server root and copy/backup the ‘.HTACCESS’ file.

Under it find these tags and (if found) remove them along with everything inside:

# BEGIN W3TC Browser Cache
(remove all this)
# END W3TC Browser Cache

# BEGIN W3TC Page Cache core
(remove all this)
# END W3TC Page Cache core

This will ensure W3 Cache isn’t being used anymore.

WordPress will still have it’s default normal Cache under the WP-Content folder, leave that there. W3 Cache as well as other cache plugins simply share that folder.

If you are talking about CHMOD permissions on your server. Then it’s default settings…

Folders = 755
Files = 644

Make sure both FTP and Apache (www-data) users have group access.

So if you have minified enabled on W3 Cache, for it to access under the “Cache” folder of WordPress, that folder should be set to “755”.

Seems a bit overkill. I would remove that and suggest telling it to protect your upload folder(s) from PHP files/execution. As this is where hackers will attempt to inject and execute them from. Then it won’t be affecting your plugins execution, etc.

For example:

<LocationMatch "/uploads/.*(?i)\.(php3?|phtml)$">
     Order Deny,Allow
     Deny from All
</LocationMatch>

Well normally it’s done the other way around, people don’t want the homepage cache, rather just the rest. There’s an option available for that. However, in your case…

Depending on how large your website is, you could simply tell it what pages or URL folder structures not to cache?

Under the Page Cache options, there’s a ‘Never cache the following pages’ in which you could throw all the pages you don’t want cached.

For example (you can use the .* for all), normally it would be just selected areas:

/checkout/.*
/cart/.*
/order/.*
/members/.*

By reading that, it seems the root cause would be filename length is too long for your server hosting and being blocked (this is normally done for security reasons on some hosts).

You could try disabling ‘Rewrite URL structure’ under the Minify options and checking if that helps? As that would give you a shorten folder structure to call from.