No, there is no way to enforce that with the compiler, you'd have to use run-time checks (say, in the constructor) for the $tablename variable, e.g.:

class Foo_Abstract {
  public final function __construct(/*whatever*/) {
    if(!isset($this->tablename))
      throw new LogicException(get_class($this) . ' must have a $tablename');
  }
}

To enforce this for all derived classes of Foo_Abstract you would have to make Foo_Abstract's constructor final, preventing overriding.

You could declare an abstract getter instead:

abstract class Foo_Abstract {
  abstract public function get_tablename();
}

class Foo extends Foo_Abstract {
  protected $tablename = 'tablename';
  public function get_tablename() {
    return $this->tablename;
  }
}

To answer your question, yes. If the abstract class is the logical place for the property then put it there. Use the tools that classes and OOP gives you.

"overtime the original structure/layout of these abstract properties is forgotten and could be left at there default static values or even forgotten(not used) completely."

This implies to me that developers using/creating the abstract class or child classes are required to do something with these properties. If that is true, try to come up with a class design that forces a developer to deal with this. That's better then to trust everyone to always do it correctly.

You mention changing static values. Static properties are shared between all class instances, so by changing their value in one object you change it for all. Multiple objects changing global state is something you want to avoid, because it is difficult to keep all changes in the correct order.