I've been building them for a while now, and fell into many a pitfall, so learned from my mistakes. Firstly, I saw the need to store information about every page, along with information about all the form fields and how they should be dealt with. In a system like CakePHP, a lot of that is taken care of for you, but from experience, its still best to make your own page data system.
The first major pitfall I fell into was storing everything in arrays. Its alright for simple web page systems but it can get complicated fast, and you can end up with a monstrous multidimensional array which is a bastard to debug. XML files are probably a better approach, but since I'm most comfortable with dbs, I'm going that route. First I make a crud database, this will have tables with info on all the pages, subpages. For non static pages (i.e. ones where you display DB data and let users edit it), there'll be tables that controls all that (i.e. how many form fields need to be displayed, how they should be display and validated [for frameworks obviously, I'll just extract that from the models]. This kind of system is actually more useful for frameworks, because you can add rules for how differently routed pages should be processed and avoid all the ass pains I've had from working with CakePHP in an unconvetional way (I hack and tweat the crap out of everything and do a lot of unusual routiing). Another benefit is it will give you much easier control over complicated database relations. Rather than being limited by the models built in rules, you can make a table of relations which will provide the code necessary for the connection to be made and processed properly. I'm kind of rambling on here, I have the idea in my head, I'll post more about it when I set up the system.
If anyone wants to help me out with this i'd greatly appreciate it. Any constructive criticism and suggestions are more than welcome.