ugodrus

В принципе можно попробовать через Files или FilesMatch методом от обратного. Но на мой взгляд лучше просто переложить защищаемый контент.

RewriteEngine On 
RewriteBase / 

RewriteCond %{REQUEST_URI} ^/(blog|board|forum)/(.+)(\.html?)?$
RewriteRule .* /%1/%2 [R,L]

RewriteRule ^index.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule .* /index.php [L]

Если дома без корпусов то все достаточно просто.
Таблица будет выглядеть вот так:
street char(30)
hfrom int(4)
htill int(4)
org char(30)

Для одного дома на улице для одной организации hfrom и htill будут иметь одинаковые значения.

Выборка организации:
SELECT org FROM table WHERE street = "улица" AND {номер дома} BETWEEN hfrom AND htill

Но это слишком грубо. Лучше сделать Организацию на стыке таблиц Улица и Номер дома.

Согласен с @aen. Есть ещё одна хитрость. Сейчас микроформаты набирают силу. И по этой причине стараюсь для общей вёрстки с использованием классов использовать префиксы.

Демон - мне кажется слишком громко сказано. Демону надо ещё умудриться скормить большой файл. Да ещё и указать что с ним сделать. Вы наверное пользуетесь стандартной xml библиотекой и соответственно большой файл обваливает интерпретатор.
Очень рекомендую покопать в сторону самодельного парсера. Как пример в PHP есть XML parser. При скромных потребностях на нем можно распарсить хоть 10Gb xml при потреблении памяти до 10mb. Главное чтобы по времени ограничений не было.
Пример реализации здесь.
Я себе что-то похожее собирал. Но не как полноценный парсер, а как утилиту первичного разбора xml для последующей обработки вне её и с поддержкой своего рода запросов (сделать что-то с элементами у которых определенный node-path). Разбирал максимум 100mb xml.

Была такая проблема. Через дырку в старой CMS размещали скрипты для рассылки Мылом. Зная что в CMS только две точки входа написал правило через mod_rewrite
Если метод запроса - POST и файл к которому обращаются - не один из этих двух, то показать ему кукиш.
Это на перифирии. А также, поставил запреты на доступ ко всем административным папкам, контент которых инклудится. И в конце отыскал все скрипты в которых используется eval(). И все их проверил на иньекции кода. Помогло. Хотя боты до сих пор стучатся.

Если вам так не терпится получать JSON из БД то полистайте вот это.
Вообще сам по себе такой принцип хорош ( извлечение данных в Json ), но только не в кривых руках. Я использовал такое в интернет магазине для выборки товаров. Реально выгоднее по скорости запросов. Чуть тормознутей обычного селекта, но куда быстрей целой серии запросов. Но хранить в Json на мой взгляд уместно лишь небольшие клочки данных. Фрагменты конфигов например.

Я бы настоятельно рекомендовал сменить тип для полей широта и долгота. Поставьте decimal. Восемь цифр после запятой вполне должно хватить.

Всё зависит от реализации связки PHP Apache. Напимер в режиме fcgi PHP не работает с директивами в htaccess и единственная возможность на него повлять - подключение дополнительных ini файлов.
Работаю с ISPmanager. В нем под каждый модуль доступный для всех пользователей на сервере свой ini файл. И это очень удобно - не надо долго искать настройки. Также имеется конфиг для конкретного пользователя, от имени которого запускаются скрипты. Там меняются дефолтные настройки всего сервера под конкретного пользователя.

Вообще не совсем понятны манипуляции.
Прежде чем позориться со своими вариантами почитайте документацию по mod_rewrite раздел переменных среды.
Это размещаете в корне domain1

RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain1\.ru
RewriteCond %{REQUEST_URI} ^/site
RewriteRule .* http://www.domain2.ru/ [R,L]

Если вы хотите это использовать для алиасов то тогда добавьте ещё так.

RewriteCond %{HTTP_HOST} ^www\.domain2\.ru
RewriteRule ^(.*)$ /site/$1 [L]

function downloadFile ($URL, $PATH) {
    $ReadFile = fopen ($URL, "rb");
    if ($ReadFile) {
        $WriteFile = fopen ($PATH, "wb");
        if ($WriteFile){
            while(!feof($ReadFile)) {
                fwrite($WriteFile, fread($ReadFile, 4096 ));
            }
            fclose($WriteFile);
        }
        fclose($ReadFile);
    }
}

Метод отлично работает на больших объемах.
Можете также реализовать через сокеты. Тоже няшка получается.

Вот так.

Ваш вопрос упирается в ваши потребности. Если MODX не может воплотить ваши потребности в жизнь, то есть смысл перейти на собственную разработку на любом понравившемся фреймворке. Но прежде чем принимать такое решение, удостоверьтесь все ли возможности CMS вы исчерпали для получения того или иного функционала, и сможете ли вы в достаточно короткое время реализовать всё что хотите на фреймворке.
На мой взгляд MODX`а вполне достаточно для нормального ресурса. Чего не хватает - можно дописать и подключить как модуль.

Вы имеете в виду хранение атрибутов товара в корзине?

Кросбраузерно - никак. По моим сайтам до сих пор ходят с ИЕ6 но не более 1%. Полноценная поддержка SVG с 9ки. А пользователей с 8 очень много (свыше 5%). В общем вопрос актуален и требует костылей. Я в свое время делал с svgweb.

Автор - фантазёр. Мало того, что картинки разные, ещё и разные пути, и разные домены. Если оба домена располагаются в одной директории (алиасы) ещё реально. Можно конечно ещё с символической ссылкой поиграть. В остальном.. (чуть не ругнулся)
Вобщем, смысл такого колдовства не ясен. И решение сложное и смысла так колдовать ради таких преобразований для пары-тройки картинок нет.

Это будет иметь отношение к производительности почитайте. Плюсов никаких. Обращение к view = субселект. А если обьем view большой, то это будет вообще смерь.

Если есть желание ограничить пользователя в доступе к данным, то лучше покопайте в сторону процедур и функций. Можно сделать конструкторы запросов на стороне сервера БД и возвращать результат собранного запроса.

@dez-fafara: Несколько некорректный ответ. Если посмотреть как отражается сессия в COOKIE то сессия представляет собой пару Ключ -> Значение. Где Ключ - это имя сессии, а Значение - её уникальный номер в системе, тоторый обычно создается через md5 алгоритм по времени инициализации сессии. В среде PHP ключ ( или имя сессии ) - это наименование переменной окружения в которой хранится уникальный номер сессии. По умолчанию Имя сессии в PHP - PHPSESSID. Функции session_name() и session_id() работают с Именем сессии и её номером. Обе могут принимать новые значения и отдавать текущие (запуск функций с параметром и без). Обе должны быть вызваны до начала работы с данными сессии. Их можно и не трогать, если настройки по умолчанию для хранения сессий вас устраивают, поскольку session_start() самостоятельно присваивает как имя, так и идентификатор сессии. Если данных о сессии нет (переменной с именем сессии не установлено) то создается новый Id. Если переменная есть, то session_start() продолжает вести уже существующую сессию.