Боюсь, что для того, чтобы увидеть готовый код, надо поставить чёткое ТЗ и оплатить его реализацию.
И правильно это реализовать как модуль, а не на слое темизации.
А подсказку дать могу - hook_page_title_alter(), http://drupal.org/node/1204018
Ещё посмотрите на http://drupal.org/project/simple_page_title, возможно вам этого хватит.
При заданных вами условиях локейшен правильный.
Корень phpmyadmin у вас относительно корня сайта - /pma? Как выглядит ссылка на отсутствующую картинку?
root правильно прописан?
Что в логе nginx?
Надо
location /pma/\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf|swf|ico|flv|txt|docx|xlsx)$
Заменить на
location ~* ^/pma/(.*)\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf|swf|ico|flv|txt|docx|xlsx)$
Раз уж вы задаёте location регулярным выражением. И тогда будет обрабатываться нужный локейшен.
А всё будет хорошо - он вставит запись со следующим ID и второй экзкмпляр скрипта будет работать именно с ним, т.к. mysql_insert_id() возращает ID записи вставленной не последним запросом на mysql сервере, а последним запросом в рамках текущего подключения. И не надо ни транзакций ни локов.
seosniks:
Ваш код будет корректно работать до тех пор, пока у вас не будет конкурентных запросов на вставку. В реальном приложении он некорректен напрочь, т.к. между получением ID и INSERT, может пройти ещё один INSERT для которого был получен тот же ID.
И что будет, если в этот замечательный момент другой поток вставляет запись? =))))
Первым запросом создаёте запись, получаете её ID, после выполнения запроса (INSERT). Вторым запросом вписываете в неё вычисленное на основе ID значение(UPDATE), или например удаляете запись, если она вдруг не нужна.
Чем проще? Тем что не надо осваивать фреймворк, который потом ещё не раз пригодится - возможно но довод слабый...
В плане самой реализации это не так, особенно учитывая возможность сгенерировать часть кода и дополнить по необходимости, работать с удобным ORM, иметь поддерживаемый код, в котором потом будет проще разобраться.
Выбрав битрикс вы столкнётесь с тем, что работает он весьма неспешно, требует совершенно неадекватных ресурсов, функционал который не укладывается в стандартные решения прикручивается намного сложнее, чем к любой другой CMS, пожалуй.
За деньги которые вы за неё платите, вы покупаете не хорошую работу разработчиков CMS, а офигенно хорошую работу отдела маркетинга, который убедил вас, что это Г является хорошей современной CMS и стоит своих денег.
Dimank:
Возможно наилучшим для вас решением будет переписать ваш портал на основе какого-нибудь популярного фреймворка, и привлечь для этого квалифицированного разработчика/команду.
Если же вы рассматриваете использование более-менее готового решения, что далеко не всегда оправдано на сложном проекте с высокой посещаемостью, т.к часто это оказывается более трудоёмким процессом, чем написание с нуля именно того что нужно, посмотрите в сторону Drupal, точнее даже Pressflow.
Ну есть ещё и денормализация, и как раз применяется для повышения быстродействия, но действительно сначала надо почитать про нормализацию. =)
По поводу огромного количества таблиц, да, это имеет смысл, когда вам надо получать данные только из одной из них, но если надо из нескольких, вам придётся делать объединение в запросе и в итоге быстрее не будет. Правильная индексация куда полезнее обычно, чем разбиение на отдельные таблицы, хотя например выносить редко используемые данные в некий архив, в принципе можно и иногда имеет смысл.
Вы задали вопрос для телепатов. =)
Если на php, то примерно так:
<?php$data = file('filename',FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);if($data===false) die("А файла-то на месте нет!");echo implode('',$data);?>
Где filename имя соотв. файла.
Откуда уверенность, что проблема действительно в сервере? Как проверяли скрипты?
Опять же всё рано или поздно при наличии достаточных ресурсов взломать можно всё что угодно, как не настраивай. Можно лишь максимально усложнить процесс.
В вашем случае нужен выделенный сервер и хороший администратор. Операционку на выбор администратора, т.к. умение её правильно настроить важнее.
А скриптам стоит всё же устроить качественную проверку, хотя это может быть довольно накладное удовольствие, но уязвимости в них куда чаще встречаются чем в настройках сервера и серверном ПО.
