Просто не надо так делать. Один ресурс = один URL. Можно разве что через GET-параметр передавать tid, если на целевой странице в зависимости от него что-то меняется. А это легко делается в шаблоне ноды, так как у тебя есть доступ к параметрам через функцию args и доступ ко всем полям ноды через $content['field_name']['#items']. Если используешь views, то просто выводи unformatted list, renered entity.
Там даже upgrade path с беток не работает. Т.е. следующая бета может отказаться работать с текущей схемой бд. Начинать работать можно будет году так в 2016. Преимущество одно - новая кодовая база.
Так как в тегах друпал, отвечаю про друпал — вы попробуйте натянуть хоть один свёрстанный шаблон на готовый сайт. Вы всё поймёте через по часа :) Если лень, отвечу сразу — свёрстанный шаблон для друпала не нужен.
Minimum sitemap lifetime
The minimum amount of time that will elapse before the sitemaps are regenerated. The sitemaps will also only be regenerated on cron if any links have been added, updated, or deleted.
Recommended value: @count день.
Если пользуетесь cms, то делать отдельную вёрстку как правило бессмысленно. У того же друпала есть определённая структура темы (регионы, блоки, поля, идентификаторы, классы) нарушив которую вылезут проблемы. Поэтому двигаетесь в правильном направлении — создание drupal темы по psd шаблону. Плюс как правило на этом же этапе делается и функционал сайта.
Я для лендингов использую модуль Panels. Панели очень удобные для таких задач.
Также для есть отличная сборка Panopoly, там всё построено на панелях и используется интересный модуль Panels Everywhere.
@Morbit многое зависит от настроек! 99% дыр не в друпале, а в голове тех кто его ставил и настраивал. Drupal, Wordpress, Modx можно без проблем пользовать если при установке, настройке CMS и хостинга сами не накосячите, оставив "дыры".
В выборе между Drupal и Modx, я за друпал, имхо он удобней.
На мой сугубо скромный взгляд нет в этом никакого смысла (Как разработчика на symfony2).
Почему нет: потому что у руби нет в данном случае никаких приемуществ. Как вы сказали - стоимость разработки выше, профита с точки зрения производительности - 0, руби даже больше жрет ресурсов.
Если бы был выбор между JVM-языками(java, scala) или в последнее время популярными go и erlang, ради производительности - возможно стоило бы. Но явно не тормознутый руби.
