Why does 0x00 make bcrypt weaker?
In many cases, 0x00 is treated as end of string. That is where the problem comes into play. So if I passed password\x00defgreallylongpassword into bcrypt, the password would be terminated after password due to the null byte. That is a very insecure password and can easily be found with a dictionary attack.

No one types null bytes into a password field, however. Where the blog post says this can occur in practice is if you first hash the password, then run it through bcrypt. There is a chance that the hash digest will have a null byte in it, which will cause the bcrypt code to truncate it.

The poster gets around this by suggesting that you base64 encode the hash of the password before feeding that to bcrypt. The base64 encoding will not have null bytes.

This hash then bcrypt construction has been proposed as a way around the 72 character limit of bcrypt. That said, I agree with this answer on our sister site. If you are using bcrypt for values that you expect might be larger than 72 characters, you are probably not using bcrypt for its intended purposes and should rethink what you are doing.