On 7/22/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 22 Jul 2006, at 03:18, Khalid B wrote:
This way, we cut down on the number of useless aliases (for that particular site). If a site restricts aliasing to $_GET['q'] of ^taxonomy/term/\d$ ^taxonomy/term\d/feed$ ^node/\d$ ^node/\d/feed$ Then menus become a non issue. They do not take up space in the database, they are not queried either.
The above pattern is enough for the majority of sites (perhaps with user/* as well). Modules like pathauto can use that to add or remove patterns too.
So we have a number of viable ideas here. Let's try to summarize them:
1. Build a caching algorithm that uses an heuristic to pre-load frequently used URL aliases.
* Advantages: transparent, no configuration required
* Disadvantages: it a heuristic, we don't know how it would perform, it might be tricky to implement, and MySQL does this implicitly (but not as aggressive).
2. Provide a textarea that allows administrators to _white_list_ URL patterns.
* Advantages: fine-grained control, easy to implement
* Disadvantages: users usually don't like messing with regular expressions, it might take a lot of effort to get the list Just Right, and it takes a certain amount of familiarity with Drupal's URL scheme (learning curve for new Drupal users). The behavior might be confusing: you add an alias, and it doesn't work because you forgot about the list of URL patterns.
3. Provide a textarea that allows administrators to _black_list_ URL patterns.
* Advantages: fine-grained control, easy to implement
* Disadvantages: users usually don't like messing with regular expressions, it might take a lot of effort to get the list Just Right, and it takes a certain amount of familiarity with Drupal's URL scheme (learning curve for new Drupal users). The behavior might be confusing: you add an alias, and it doesn't work because you forgot about the list of URL patterns.
4. Stop doing SQL queries when you cached all possible URL aliases.
* Advantages: transparent, no configuration required, can co- exist with (1), (2), (3) and (5).
* Disadvantages: only works for a subset of all Drupal sites, not a solution for larger Drupal sites.
5. Improve Drupal's high-level page caching so we have to rebuild pages less frequently.
* Advantages: no configuration required, can co-exist with (1), (2), (3) and (4), eliminates many more SQL queries.
* Disadvantages: doesn't work for authenticated users.
Thoughts?
For 2 and 3, giving the end user (non technical site admin) regexp is suboptimal. I was thinking more of a using regexp internally, perhaps via an API, and modules would provide a user interface on top of it, such as pathauto, where they can select caching for nodes, ...etc.