johndball

Geeze, this always happens. Troubleshoot for an hour, no results, post in the forum, BAM! find the problem.

Looks like “BBP STYLE PACK” plugin version 5.1.3 is causing a conflict with the AIOWPS plugin.

FYI the error message is not correct. Looks like the forum post is interpreting the /access as .&#8221.

• This reply was modified 2 years, 3 months ago by johndball.
• This reply was modified 2 years, 3 months ago by johndball.

Working now on version 4.3.8.3.
Tried logging in with u/p and no CAPTCHA = error
Tried logging in with u/p and wrong CAPTCHA = error
Tried logging in with u/p and correct CAPTCHA = success

Thanks wpsolutions!

I’m in the pro version right now.
I think the area that needs to be edited for global change is going to be on line 33.

Where

function setHeight() {
				var windowHeight = $(window).innerHeight();
				$('.site-header, .site-brand-main').css('height', windowHeight);

Change to

function setHeight() {
				var windowHeight = $(window).innerHeight();
				$('.site-header, .site-brand-main').css('height', '600px');

Replacing windowHeight with a numeric size.

I was testing this today and failing to update properly but was able to resolve the problem.

Back end:
Server 2012 R2
VMware ESXi 5.5
Guest VM running IIS 8.5.9600 with MySQL local DB
Host running actual WP site behind reverse IIS proxy (not important for this exercise but noted nonetheless)

I attempted to update plugins and core site files but failed. IIS_USRS were given full control.
I examined the permissions of the .maintenance file while the update was in progress and the owner was IUSR.

I reverted back to my snapshot after the failed upgrade. IIS_USRS had default permissions again. This time I added IUSR to the root of the site with full permissions and the upgrades took successfully.

I am going to tweak the permissions and remove “take ownership” from the IUSR account moving forward.

It seems like IUSR needs full (or near full) NTFS perms for updates and upgrades. This was all on the back end IIS server with the WP site, not the proxy server.

I was testing this today and failing to update properly but was able to resolve the problem.

Back end:
Server 2012 R2
VMware ESXi 5.5
Guest VM running IIS 8.5.9600 with MySQL local DB
Host running actual WP site behind reverse IIS proxy (not important for this exercise but noted nonetheless)

I attempted to update plugins and core site files but failed. IIS_USRS were given full control.
I examined the permissions of the .maintenance file while the update was in progress and the owner was IUSR.

I reverted back to my snapshot after the failed upgrade. IIS_USRS had default permissions again. This time I added IUSR to the root of the site with full permissions and the upgrades took successfully.

I am going to tweak the permissions and remove “take ownership” from the IUSR account moving forward.

It seems like IUSR needs full (or near full) NTFS perms for updates and upgrades. This was all on the back end IIS server with the WP site, not the proxy server.

Yeah, it was a long night indeed. Had to manually remove the plug, which was easy since I run the server, but also had to remove all traces of references to Akismet in the PHP files with a text editor. THAT was the hard part!

Once I cleaned everything out referencing Akismet I was able to manually install and manually activate version 3.0.3 of Akismet. Looks like two attempts to auto upgrade (the first failed attempt, cleanup, backup, second failed attempt) was the culprit.

* Akismet 3.0.3, not 4.0.

If you’re using Untangle Firewall, under Intrusion Prevention, you have to bypass (or temporarily allow) rule 3827. The filter is xmlrpc.php post attempt.