location = /config.php {
deny all;
}
Как же не смогёт, когда можно сделать следующее:
RewriteRule ^robots.txt$ robots.php [L]
И запрос будет обработан вашим вышеописанным скриптом, безо всяких редиректов - вы не отдаёте такой конструкцией редирект, а лишь изменяете обработчик, и нет способа снаружи узнать о том, какой конкретный скрипт отдал данные. Никаких модулей, обычные robots.txt в корне соотв. папок, один скрипт в корне сайта.
Скрипт конечно лучше немного доработать, чтобы отдавать стандартный друпаловский robots.txt, если в папке домена его нет.
На самом деле, вообще можно обойтись alias, даже без mod_rewrite.
К тому же, при мультисайтинге на одном и том же движке, не так уж часто вообще разные robots.txt нужны.
Где тут перенаправление? Его нет.
Если вы делаете для работы этого варианта редирект в .htaccess, так это не нужно.
aftamat4ik, я говорю не про зубрёжку, а про планомерное изучение, а не потыкал там, потыкал здесь. Тогда у вас и не будет возникать таких вопросов.
Запрос надо отправлять на тот адрес, который вернёт нужные данные. При чём тут вообще index.php?
Это, например, может быть ваш модуль, который будет формировать нужные вам данные, и использовать hook_menu(), для того, чтобы отвечать по заданному адресу, и запускать соответствующий обработчик.
Ошибка 500, это "внутренняя ошибка сервера". Может возникать по совершенно разным поводам, чаще всего из-за проблем с конфигурацией. Обычно причину можно найти в логе веб сервера.
В вашем конкретном случае, это ошибка о отсутствии расширения php-curl. Установите и радуйтесь жизни. Как установить, зависит от дистрибутива.
Можно, но на таких хостингах не дают настраивать nginx по своему вкусу. Поэтому в теории-то можно, на практике нет.
Отнюдь. Drupal очень гибок и позволяет создавать весьма сложные приложения. Есть огромное количество модулей, практически на все вкусы.
Просто бывают ситуации, когда проект очень специфичный, например, какая-нибудь панель управления хостингом, или проект должен работать в распределённой среде, или нагрузки планируются настолько большими, что требуется очень сильно бороться за производительность... И тогда хочешь не хочешь, а велосипед изобретать придётся. =)
Есть много задач, где использование фреймворка и CMF примерно одинаково уместны, при наличии навыков проектирования таких систем, это как раз будет большинство достаточно сложных порталов и.т.п.
Есть типовые задачи, где применение фреймворка будет не оправдано, т.к. процесс разработки на CMF или специализированной под задачу CMS, будет в разы менее затратным.
И, наконец, какой-нибудь личный бложек делать на фреймворке(да и на CMF в общем-то), имеет смысл только ради саморазвития, иначе лучше взять предназначенную для этого CMS.
Там поднимался вопрос не архитектурный прежде всего, а административный, т.е. кто куда одеяло тянет. =)
Редактирование файлов ядра и модулей, это очень плохая практика, появляющаяся от непонимания архитектуры Drupal, и пришедшая из CMS где без этого не обойтись, и где, кстати, очень всё плохо с поддержкой. Возможность перекрывать функции темизации, и другие хуки, огромная сила Drupal, на самом-то деле, такой метод сильно упрощает дальнейшую поддержку.
Этот подход, эквивалентен перекрытию методов родительского класса. То, что это делается не на основе ООП, а системой хуков, имеет на самом деле свои плюсы и минусы. Но обсуждать это довольно холиварная тема, главное, что такой инструмент есть и позволяет не залезать в ядро или модули, и соответственно спокойно их обновлять.
Без самостоятельного изучения основ, вы не сможете делать сколько-нибудь сложные вещи самостоятельно. И не сможете понять, какой из предлагаемых вам методов решения, стоит выбрать и почему.
Drupal достаточно сложен и учить его по ответам на форуме и готовым примерам плохая идея.
Если вы решили переписать код в includes/theme.inc то да, конечно вмешательство, и так не делают.
Если вы почитали о темизации, и перекрыли её у себя в template.php, то это именно то, что надо было сделать.
Есть одно принципиальное отличие фрейморка от CMS|CMF. Для того, чтобы сделать на основе фреймворка специализированную CMS нужно не только овладеть фреймворком, но и хорошенько продумать архитектуру будущего приложения. На практике, на это способны далеко не многие.
Т.е. в идеальном случае, сделать проект на фреймворке, особенно крупный проект и посещаемый делать выгоднее. Будет заметно меньше оверхеда, не сильно больше кода придётся писать, не сильно больше времени займёт, если есть нормальные разработчики, и если всё продумано и есть наработки, но... В результате обычно получается всё совершенно не так, и вместо этого получается велосипед на квадратных колёсах, с массой дыр, который потом не только расширять, а и обслуживать-то сложно.
В случае CMS/CMF есть оверхед, т.к. необходима универсальность. Куда больше моментов продумана уже. Кодом пользуется большое комюнити, находятся и заделываются дырки, предлагается большое количество готовых решений, куда более законченных обычно, в частности и по поводу оптимизации производительности. С другой стороны, иногда приходится писать немало кода, если необходимый функционал сильно своеобразен, и часто реализация его бывает даже сложнее, чем в случае фреймворка, т.к. существенно больше ограничений...
Так что вопрос что лучше использовать это вопрос не только выбора инструмента, но и подготовки. И вопрос на самом деле сложный очень и не однозначный.
Вот и надо не дёргать без дела. =) На самом деле, 90% проблем с производительностью CCK либо надуманы, либо от неправильной реализации. Например выборке во Views нод, вместо их полей и.т.п. С хранением большого количества данных у Drupal, всё как раз довольно хорошо.
Узкие места тут в другом скорее - например, намного сложнее сделать проект, который будет распределённым, выполняться будет куда больше кода - плата за универсальность и гибкость.
function theme($hook, $variables = array());
$pos = strpos("<body>",$output); $output=substr($pos,$output); $output=$output."<p>1231313131231231</p></body></html>";
В том то и дело, что так делать нельзя. Нельзя лезть в код модулей и тем более ядра. Для изменения вывода есть темизация. Когда разберётесь, как она работает в Drupal, тогда поймёте, НАСКОЛЬКО вы хотели сделать неправильно.
Тут всё сделано для того, чтобы не вторгаться в код, поэтому Drupal весьма легко поддерживать. То, что вы делали на Joomla тут делать совершенно не нужно. Нужно понять, что это идеологически совершенно разные CMS, и ваш прошлый опыт и приёмы, тут могут быть более чем неуместны.
Почитайте сначала, как организована темизация в Drupal, и станет понятно, что вам не нужно переопределять или каким-то образом изменять функцию theme().
Для работы с AJAX у Drupal тоже есть соответствующее API (http://api.drupal.org/api/drupal/includes%21ajax.inc/group/ajax/7). Пишите модуль и пользуйтесь, для своих нужд. Только злоупотреблять AJAXом не стоит. Это экономия на спичках. Сама страница, весит очень немного, её передача будет не быстрее, чем AJAX запрос, или быстрее на ничтожно малое время. А картинки, которые обычно и составляют практически весь объём страницы, повторно не грузятся (если у вас всё правильно настроено конечно).
