If I understand your question right ...
you are searching for the "correct" place to put you getActiveEntries() method. Cause from a OO-Design "point-of-view" you want to adhere to the principles of:
- Separation of Concerns
- Single Responsibility Principle
(FYI: I never heard avoid statics, so I skipped that one)
The cause of your "problem":
Every single entry should only be concerned about itself, and only responsible for itself. Therefore it can not be responsible for a "collection" of entries.
The principles you mentioned above are Object Oriented principles. Solutions for problems involving OO principles demand that you create many objects and many classes so that together they work as a solution.
Now if the method "getEntries" can not go into the DAO class (Data Access Object) it
... could go into a factory type of class. A Factory is responsible for "creating" objects. You could argue that a Factory for GuestBookEntries has 2 methods: createEntryFromId(int $entryId) and createActiveEntries().
... could go into a controller type of class. Same as factory above, just named differently. The controller type of class could do anything, even more than a factory. If you ever need something like "verify()" or "isDirty" for your GuestBookEntry, the factory would again not be the place to put those methods. Cause factories are only concerned about creation (they kind of have the duty to guarantee creation or fail quick) where as controller type of classes can carry verify() or isXYZ() methods without hurting their "purpose".
... in the end it doesn't matter what you call "it". But you will need another "class/object" to take the responsibility of restoring a collection of active GuestBookEntries. Most likely this class will make use of the single GuestBookEntry class that you already have.
When it get's down to implementing the methods that interact with each other (the new class and the GuestBookEntry) you are welcome to use array() as a container to transport GuestBookEntry objects.
You could create a special "typed" container that guarantees to only carry GuestBookEntry objects, but that's again up to you. (Plus it yet another oo-design decision, hehe)
To sum it up:
Create another class with the responsibility to retrieve "collections of GuestBookEntries based on their status (active|inactive)" that uses (composition) your existing GuestBookEntry class.