I would like to illustrate this in a potentially unusual way.
Years and years ago, in the Soviet Union, there was a shoe
manufacturing plant. This plant made shoes out of leather. The plant
had a quota, make so many shoes. After awhile, the workers discovered
that no rule existed that said they had to make so many of any size
shoe, so they began churning out the same size shoe, so they could go
After awhile, the authorities caught on and began making
rules. A rule said they had to create so many of a particular size;
the plant then put a different size stamp on the same size shoe. Then a
rule was enacted that so many shoes had to be made with so much
leather. So the plant produced shoes that had 3" soles, of the same
size regardless. Eventually, the plant was shutdown.
Moral of the story? If your developers don't understand it is in their best interest to follow your carefully crafted rules, that are in place for a reason, you might have a problem. If your rules are not guided by prudence and necessity, you might have a problem (in PHP). If you hate PHP and can't stand how it does some things, there are other languages that you would probably be better using.
As my comment said, the most prudent and least-expensive (in terms of time spent) would be to establish prudent rules, but NOT to create a number of faulty constructs (like magic getters/setters and other cruft), since your wily programmers can and probably will (at times even without realizing it, for instance the public property created in a function) get around them.
Establish rules that make sense and everyone understands and buys into. This is my suggestion, which is inherently more opinion than anything. But I hope it helps. :)