shawnkhall

When you delete the plugin and refresh the page it recognizes that it is missing and disables it, so the script that triggers the “preparing theme styles” issue doesn’t load.

I refreshed it a couple times to make sure everything was operating normally then installed the plugin manually.

Fixed it.

Deleted the plugin.
Visited the Plugins page to ensure it was properly disabled.
Reinstall the plugin manually through the Plugins page.
Activate the plugin manually.

This resolved the “Preparing theme styles” forever issue.

the more important question for you is: were they able to actually *hack* your wp-admin, or did they just throw a bunch of traffic its way?

this plugin is not intended to prevent every form of attack, but minimize the risk of fake interaction (such as comments and logins) *succeeding* on your site. brute force attacks should be handled by htaccess rules, content request filtering and similar server-side controls. this will prevent brute force attacks from succeeding to login, but it won’t prevent their bandwidth and resource consumption.

This plugin did it for me on a multisite network:
https://www.ads-software.com/extend/plugins/control-xml-rpc-publishing/

And the reason you cloaked it instead of simply providing non-obfuscated code?

Thank you!!

What users should understand is that this is only a security risk *if* none of the existing options to prevent unauthorized content are used. You should be using a unique email address for the target address, and a specific authorized sender email address, or allowed SMTP servers or any of the other methods to ensure validity of the content before posting. If you’re already doing that, then this “feature” will only introduce problems for legitimate messages – such as blacklisting common terms in the content or attachments.

The new anti-xss code will also prevent messages with any of the following words within them from being processed:
description
subscription
scripture
metabolism
metallic
metadata
as well as over 700 more.

So forget about telling someone to “manage their subscription” or mention biblical scripture in a message you want Postie to publish to your website.

I’m reverting to 1.4.3.

@robfelty – if you want to implement this type of functionality, it *really* needs to have a front-end option for us to disable it.

The post-edit hook being used isn’t properly validating that a value is being passed before trying to read it as an array. Here’s a fix. Open the file “/wp-content/socialize/admin/socialize-admin.php” and find lines 88 to 95, which should be:

foreach($_POST['socialize_buttons'] as $button){
			if(($button > 0)){
				array_push($socializemetaarray, $button);
			} else{
				//$hs_settings['socialize_buttons'][$formid] = htmlentities(stripslashes($form));
			}
			$formid++;
		}

We’re going to add a check to it to ensure that the variable is being passed first, so replace it with this:

if(isset($_POST['socialize_buttons'])) {
			foreach($_POST['socialize_buttons'] as $button){
				if(($button > 0)){
					array_push($socializemetaarray, $button);
				} else{
					//$hs_settings['socialize_buttons'][$formid] = htmlentities(stripslashes($form));
				}
				$formid++;
			}
		}

You could probably use this to deactivate the default styles:
remove_action('admin_print_styles', 'print_admin_styles', 20);