Structuring your MODx website the CORRECT way - advice needed how to structure

Hi guys, been running with MODx a while now, it is time to make a new version of the site, all the drafts have been made and its time to start the implementation. Of course i started with Revo this time round, and am just wandering how best to do it.

Quick Explanation/Question:

How would you structure the destinations & Properties section in revo for a site laid out below? Would you create the destinations in the resource tree, or would you build an external dbase to handle the destinations/properties part and then use custom snippets to pull data in? Keep in mind that there is a possibility this will scale to thousands of destinations and tens/hundreds of thousands of properties:

Home
Destinations
Spain
Portugal
Italy
UK
Midlands
London
Scotland
Inverness
Property 1
Property 2
Etc
About us
Contact Us
Blogs
Etc



Long and Boring Explanation:
We are looking to gain various functionalities with Revo, in particular better caching, better categorisation and hopefully better efficiency.

The issues I ran into when setting this up with Evo was the steep learning curve before I managed to get everything running the way i wanted it and some speed issues along the way due to haphazard style of implementation. The biggest gripe was modifying existing templates, adding new chunks and TVs which did specific tasks like pull in appropriate metatags, extra content we thought up and new parts of the site we developed.

At present time the existing Evo site in question contains loads of old/unused chunks and snippets, there is about 10 different templates used for different landing pages, and the whole site tree in manager is also full of pages which are not used any more, mixed in with live pages. Speed issues were slightly corrected due to partial caching I put in place (snippets remain running uncached due to nature of site - ie when a user modifies info we need uncached info to show right away). Partial means modx part is cached, part dealing with destinations/properties runs uncached.

It is a bit of a problem finding your way around due to this mess, ie a bug is discovered on a particular page - the process to correct it is:
1. Lookup htaccess to find out what the real page name is due to friendly URLs
2. Try and find the page name in the site tree, and see which snippet is responsible for processing of main code
3. Go to snippets and find the snippet in question, which contains a reference to a physical file
4. Go back to the filesystem and open the physical php file in order to correct the bug
5. Upload file & test

The site is a property website, containing lists of properties, geographical locations for each property (creating 2-3 levels of destination landing pages) plus other normal content like extra pages, blogs etc.

My question is how best to structure the destination & property landing pages. In the current site the management of this whole aspect of the site is done externally to modx, through our custom editing pages, separate database holds data on destinations and properties. I am wandering if it would be wise to use the modx resource tree for the destinations in Revo, representing above country/region/subregion in the tree, and then allowing users to load properties by creating some kind of "property resources" in the tree below every destination rather than handle it externally.
Would Revo be able to cope with this "scaling up" ad infinitum, as is the case when you use a mysql dbase?

I know theres a thousand ways for this to be done, im asking what would YOU do to gain most out of the framework whilst making management easy.

First, from what I’ve seen MODx is so flexible that there is never a ’correct’ way to do anything. Just some ways are more optimal I guess

I’m in a similar situation to yourself, having built a property site in Evo and looking to completely rebuild it in Revo later this year.

With hindsight I went about it the wrong way first time around, creating a new resource for each property rather than storing them in a custom table. As I required more functionality (searching, sorting, filtering), and as the number of properties grew far beyond originally intended, this has created complications and unnecessarily slow db queries. Some of my custom queries needed over 5 joins to compare TVs from various resources.

Even so, it has handled over 3,000 resources without any major problems to date - knock on wood - and with cached pages performance has remained snappy for visitors.

As for Revo, caching is far improved and the mystical ’document limit’ no longer exists - but I’ve heard of the document tree becoming unmanageable with a large number of resources. There’s been quite a lot of discussion about how to handle large amounts of custom data, and the general consensus is that it should go into a custom table. That’s definitely the way I’m going next time around.

Hope that helps!

Yup, thats what im looking for, the most optimal way i guess.
Seems like I went about it the correct way the first time then, in regard to keeping this data in a custom table.
Yes 4,5 joins plus lots of subqueries is the norm for a typical property search query.

I like the idea of separating this data anyway, and letting modx deal with the actual framework of the site, this custom content and its myriad of intricacies would pose a problem for MODx as you explained, I was merely wandering if Revo had anything within it which would ease this.

I’ve just started laying the site out, setup the first template, and am wandering how to split the code, tutorials for revo are so scatered at the moment, it would be so useful for us mortals to have 1-2 complete projects/boilerplates for a modx site, which could be opened and explored as to how the framework/data structures are organised.
For instance, i’ve come across a tutorial where a person explores the option of using custom TVs to store custom JS/CSS for a particular section of a site. The tutorial moves on to talk about something else leaving me puzzled. If i had a working model of this which i could download as a package to look at, it would take me much much less to grasp the concept and use it. I think these "demo" projects would benefit the userbase tremndously, moreso than the manual pages.