But encrypting after compression leaks information about the length of the compressed data (down to the block granularity). Which in turn leaks information about the general structure of the file (with an LZ compression that means number of repeated strings). If the attacker is in control of even a small part of the message then he can find out more about the rest of the message.
It's things like this that make security and encryption a hard problem.
Yup, no disagreement from me there. None of my above advice was intended as a way to implement good encryption, just a few points to get someone started and read up more from there.
Implementing encryption that can withstand attack isn't all about the maths either. You have to implement it in such a way that the math isn't subtly altered. That's just so that data at rest is safe. On top of that you'll want to write the code so that it can withstand timing and other side channel attacks. If that isn't done, then even the data at rest isn't safe potentially if a side channel attack could've retrieved all or part of the key material or internal state during encryption.
Take away lesson: If you don't know what you're doing, don't implement your own encryption when you rely on it for something important. Learn about it by all means. If all you're after is obfuscation for unimportant data, sure, have a crack at it.
Encryption and security are hard. Half the battle is knowing what is and is not potentially insecure. Even if you use pre-made encryption, make sure you know what you're doing. Using the wrong mode or the wrong number of rounds, or any number of things, can make an ostensibly secure solution insecure.
Good times, huh? :)
But don't let that discourage you. It's a fascinating field of study.