Version 3.6.5 Breaks 404 logging

Same problem here.
I went back to version 3.6.3 again at localhost on my test site but the problem with logging persists. Apparently, the problem is now in the database? The question is what?
I imported and replaced the table bwps-log with one from a backup that has not yet been upgraded to 3.6.5 and then it worked as it should again.
It seems that the problem is provided in table bwps-log somewhere
“”Edit: My mistake, it does not work””

The problem is not in the DB.
I compared the DB tables for a working (3.6.4) and non-working (3.6.5) version and they were the same. Also – bad login logging was still working and they use the same logevent function.
I did a compare of all files in the installations for broken and working versions. There were only three files with differences.
Readme (who cares)
better-wp-security.php (just the version number)
and

/inc/secure.php (thousands of differences).

Replacing just secure.php with the 3.6.4 version seems to have fixed the issue for me.

Besides the InfiniteWP check (what is that anyway? Who cares?) there were THOUSANDS of changes in spacing and formatting. My guess is that whomever took this over has run the code through some sort of code formatting tool and it jacked something up by adding or removing a space or tab here or there. So now, where you had

array(“a”,”b”)
we now have
array ( “a”, “b”)
and somewhere in the code, some of those spaces mattered.

Apparently, they don’t do any regression testing at iThemes…
Be very wary of any future upgrades.

@thefitrv In PHP spaces like that do NOT matter. You say “they don’t do any regression testing” which is just gossip. Don’t make up things about what you don’t understand.

Your “Replacing just secure.php with the 3.6.4 version seems to have fixed the issue for me.” might be useful; however, I have to recommend you do a complete version change not just that one file.

Dude,

I agree that whitespace is not supposed to affect code execution in PHP. Apart from the InfiniteWP block, the only changes in the file were spacing and formatting. I didn’t feel like debugging it further, so I left it at that. As it turns out though, it was the new InfiniteWP block that broke things.

That’s actually a lot worse, because the InfiniteWP check looks like it’s used to disable a whole bunch of other functions. Lack of 404 logging is just the one we notice first. The following functions are disabled by this new version:

execute 404 check
remove wp-generator meta tag
remove login error messages if turned on
remove wlmanifest link if turned on
remove rsd link from header if turned on
ban extra-long urls if turned on
require strong passwords if turned on
display random number for wordpress version if turned on
remove theme update notifications if turned on
remove plugin update notifications if turned on
remove core update notifications if turned on
load filecheck and backup if needed (if this isn’t a 404 page)

Replacing this new block of code:

$HTTP_RAW_POST_DATA = @file_get_contents( 'php://input' );

			if ( $HTTP_RAW_POST_DATA !== false && strlen( $HTTP_RAW_POST_DATA ) > 0 ) {

				$data = base64_decode( $HTTP_RAW_POST_DATA );

				if ( strpos( $data, 's:10:"iwp_action";' ) !== false ) {
					$isIWP = true;
				} else {
					$isIWP = false;
				}

			}

with this single line from 3.6.4

$isIWP = false;

restores the above functions.

With regard to the files changed – the only files with modifications are the three I pointed out. And the only one with material changes was secure.php. If you’ve already had to modify the Better WP installation to fix other bugs (LinkedIn Bot causing a 500 error if you use the HackRepair list), then replacing the entire install just makes more work for yourself. However, if a user is not comfortable changing just one file, they can obviously replace the entire version and get the same effect. Apart from breaking the 12 items above, there is no functional difference between 3.6.4 and 3.6.5.

Version 3.6.5 should really be removed. It only breaks things.

As far as regression testing goes – I’m not part of iThemes, so obviously I can’s say exactly what their policy is. But consider:

1: “Regression testing is a type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes such as enhancements, patches or configuration changes, have been made to them.”

2: After this latest enhancement (3.6.5), an existing function (404 logging) and 11 OTHER FUNCTIONS no longer work.

If they are regression testing, it obviously wasn’t enough to catch 12 major pieces of broken functionality that were directly caused by the only change made to the code. Even the most basic regression testing would have caught this. In fact, it really should have been caught in unit testing when they should have checked for execution of the elseblock as well as the thenblock.

Everyone can draw their own conclusions on the regression testing.
I know what mine are.