failedprocess

When network activated, the settings page is under the Sites menu on the network admin screen.

Yeah, echoing @neschalk, this thing is definitely bad. In the first posted example, you can see where the file itself is changing the permissions on wp-config to global r/w/x (chmod 777) and inserting the require_once line as well as the preceding comment leading you to believe that it is necessary for outputting the site header. This is actually in the second example as well along with a list of pharmaceuticals that I’m sure the WordPress foundation doesn’t endorse. Best advice? Take off and nuke it all from orbit; only way to be sure. Definitely have a security deficiency somewhere. It’s highly likely that deleting that file (wp-head) and removing the require_once statement will prevent this particular hack from working but it’s likely the attack vector still exists.

If you have the Jetpack Protect module activated, this is the back-up method of authentication if it can’t reach their servers. This is the same functionality that Bruteprotect used before it was rolled into Jetpack as Protect. If you are still having issues, I would recommend reaching out on the Jetpack or Bruteprotect forums. IIRC, there were some threads on the Bruteprotect forum regarding this issue but the fixes are likely different since the JP roll-up.

Since this question is in regards to a specific plugin, it might be more prudent to post this question in the respective plugin support forums. It would appear that your issue isn’t necessarily a defect with WordPress core but with the interaction between the plugins and version 4.2.

Excellent! Thanks for your input Frankie!

OK, so it looks like this is a specific configuration issue rather than a ZenCache issue as additional testing confirmed that the post cache is being refreshed properly. I’ll do some additional testing and open up a new thread if I can’t figure it out.

Looking at the source code for the plugin, would it be as simple as hooking into publish_post and calling auto_clear_post_cache similar to the other actions listed in the main php file? Something like:

add_action('publish_post', array($this, 'auto_clear_post_cache'));

Sounds good! Thanks alanft. Didn’t think it was anything to worry about but wanted to be sure I covered my bases.

This is something that I am also interested in.

Hi ninjago,

Were you able to fix your problem? If not could you describe in more detail what is not functioning correctly with the latest update; and if you were able to fix it, let us know what you did and mark your post as resolved.

Thanks!

failedprocess

Hi kometak,

This sounds similar to the majority of issues people are experiencing using this plugin. Take a look at the fix described here and see if that solves your problem.

Let us know and if this fixes it, be sure to mark your post as resolved.

Thanks!

failedprocess

I was also able to confirm correct operation in FF 18, Chrome 24.0.1312.52 m, IE 8.0, Safari 5.1, and Opera 12.12. Glad to see that it’s working in the majority of use cases!

So upon further investigation, I believe that this is related to this plugin calling its own version of javascript which according to this forum post (Troubleshooting WordPress 3.5 Master List) is a major no-no in WordPress 3.5. I was able to get this plugin to work by going into the super-rss-reader.php and commenting out the javascript call that is specific to this plugin. The lines that need commented out are 24-26 and it should look like this when you are done:

function srr_public_scripts(){
	// jQuery
	//wp_deregister_script('jquery');
    //wp_register_script('jquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js');
    //wp_enqueue_script('jquery');

	// Super RSS Reader JS and CSS
	wp_register_script('super-rss-reader-js', SRR_URL . 'public/srr-js.js');
	wp_enqueue_script(array('jquery', 'super-rss-reader-js'));
}

Your mileage may vary with this fix but Chrome is showing no javascript errors once this was implemented.

I have noticed a conflict with superfish.js in Elegant Themes themes as well as a conflict with top_up.js. Both of these are related to intrinsic theme files, not other plugins. So far, deactivating this plugin has been the only solution I have been able to find. (WordPress 3.5 and Super RSS Reader 2.2)

Hi Caris,

In need of similar functionality, I looked for a solution to this problem. This fix is a little involved but here it goes.

You will need to open up the approval-workflow.php file in a code or plain text editor (i.e. Notepad but not Word). The line you are looking for is 218 in the current version of the plugin. You should see a <input> opening tag followed by a string of variables. After the type="checkbox" variable, add checked="yes". This should force the checkbox to be checked by default.

I ended up going further by hiding the checkbox from view so that the user could not uncheck it. This was accomplished by adding the style="display: none;" variable to that same <input> tag.

I am not having issues with edits to previously published pages going live without approval but I do seem to remember that I had problems with that when I was trying out this plugin a while back. Are you still experiencing that issue?

Best of luck!