hell

и проверьте в etc/php5...conf.d, пролинковано ли расширение

У вас два отдельных сайта, решающих, вообще говоря, разные задачи, но использующие единый источник данных. Никакого «заведомого» единообразия тут нет и быть не может — все зависит от типичных задач.

Просто в качестве примера — предположим, что в начале 30-х годов прошлого века уже есть интернет, и вы делаете сайт Эрмитажа. Вы делаете версию на русском языке и на английском языке. В обоих случаях у вас есть большая галерея превьюшек картин из коллекции. При этом, на версии «для внутреннего пользования» — то есть для отечественного потребителя — логично при нажатии на превьюшку открывать картинку большего формата — дабы сограждане могли ее просмотреть. А в англоязычной версии (для иностранцев — туризма у нас нету, а иностранцы нас интересуют лишь как источник твердой валюты) — открывать «карточку товара» либо с твердым указанием цены, либо — с контактами для возможных предложений о продаже.

Соответственно, вам надо просто подумать, какие операции у вас в админке будут наиболее востребованными (подозреваю, что все-таки — редактирование) и сделать эту операцию целевой по ссылке.

Я бы такую ссылку продублировал карандашиком для редактирования (дубль в данном случае лучше, чем недопонимание) + по наведению на ссылку выводил бы маленькую превьюшку личной инфы пользователя (с переходом на просмотр профиля). Таким образом, у вас получается минимум кликов и максимум юзабилити

Вообще говоря, встроенный в PostgreSQL полнотекстовый поиск работает весьма шустро. То еть, тормозов при граничных условиях поиска по 1000000 документам (объем каждого — от 1000 до 300000 символов, средний объем документа — 2000 символов) вообще говоря не наблюдается. Во всяком случае, на выделенном сервере (в данном конкретном случае используется Hetzner с 24Gb памяти, из них PostgreSQL кушает примерно четверть, версия PostgreSQL — 9.2 — на более ранних версиях результаты были немного другими.)
Я бы рекомендовал попробовать протестировать вашу текущую конфигурацию на производительность с разными движками. И, в случае использования постгреса, не использовать подсветку результатов.

From правильнее кодировать с помощью mb_encode_mimeheader до того, как кодировать прочие заголовки.
Т.е. алгортим примерно следующий:

Проверяем, что у нас есть mbstring (для старых версий php возможны варианты)
Проверяем, что у mbstring прописаны правильные значения кодировок по умолчанию (читаем доки, в том числе по функции mb_encode_mimeheader)
Кодируем поле FROM с помощью mb_encode_mimeheader
Устанавливаем все хидеры (имеет смысл посмотреть реализацию PEAR — там не без ошибок, как ни удивительно, но в целом оно рабочее)

Боюсь, что огребу за свой совет кучу минусов, но тем не менее:

Месяца три назад, я 2 недели посвятил тестам — что лучше. Правда — у меня стоял PHP 5.4, nginx 1.2 и все это на Debian
Тестировал (и, разумеется, в процессе тестов тюнил ОС и все прочие настройки) четыре варианта — nginx+PHP, nginx+ahache+PHP, nginx+nginx+PHP (в последнем случае есть внешний нгинкс, работающий со статикой и отправляющий запросы к PHP на внутренний нгинкс) и nginx+apache+PHP-FPM.

Внутренние нгинкс и апач запускаются в режиме keepAlive off
У апача отрублено все лишнее (в моем случае оставлены dir, auth, mime, rpaf). ,haccess не используется (если че-то нужно органичить — ставим напрямую в конфигах сайта, все перенаправления — через внешний нгинкс)
У внешнего нгинкса включен gzip, отключено кеширование
Внутренние сервера логируют только ошибки php

Во всех случаях на реальные сайты натравливался siege с увеличенным таймаутом и с 1000 конкурентных запросов.

Да — и машинка — Хетзнеровская с 24 GB памяти.

Результаты получились следующие:

nginx + php — не котируется вообще. выводит память в свап, нагрузка в top — 140 — 150 примерно через минуту после начала осады. Манипуляции с системой и настройками не помогли.

nginx+apache+php-fpm — жрет память и залезает в свап, процессор особо не грузит. Есть проблемы со стабильностью (siege стабильно отрабатывал с параметром не более -c 500)

nginx+apache+php и nginx+nginx+php — примерно одинаковые результаты — средняя нагрузка в top — 3, среднее потребление памяти — 14 — 16 Gb. Количество транзакций также примерно одинаково (apache показывал результаты примерно на 3-4 транзакции в секунду лучше)

nginx+nginx+php работал чуть менее стабильно, чем nginx+apache+php (не чуть, даже — чуть-чуть — то есть пару тройку раз сокет все-таки падал, а в случае apache тaкого не было)

Пришлось остановиться на классике (хотя очень хотелось ограничиться nginxом)

Впрочем — это все — лирика. Я бы рекомендовал провести серию тестов с вашим софтом (и с вашим админом) — возможно вы получите другие результаты. Впрочем — и это почти наверняка — вариант с реверс-прокси будет заведомо более производительным.

Если для опыта, то вам стоит двигаться примерно следующим образом:
1) Крепко-крепко подумать, а надо ли оно вам (потому как, если вдруг начнет получаться — процесс сам по себе затягивает и отвлекает от зарабатывания денег, личной жизни, да и жизни вообще)
2) Прикинуть, что вам не нравится в тех готовых движках, на которых вы делали сайты
3) Составить краткий список того, что должна уметь делать ваша CMS (в глаголах, желательно)
4) Поизучать фреймворки (на разных языках) и выбрать лучший, или, убедившись, что их авторы козлы полнейшие возможности, предоставляемые фреймворками избыточны, либо не достаточны — перейти к следующему пункту
5) Исходя из списка из пункта 3, выбрать хранилище данных. Критерий выбора — как ни удивительно — не его распространенность, но, скорее — возможность выборки требуемых данных минимальным количеством простых запросов.
6) Исходя из выбора хранилища данных, выбрать фреймворк/язык программирования
7) Подобрать хостинг, на котором есть все, что вам нужно
8) Пробежаться по списку из пункта 3 и быстро-быстро все написать. При необходимости — конкретизировать и расширить этот список. При необходимости — вернуться к пункту 4.

Как-то примерно так.

namespace указать надо в html.
типа примерно как-то так
<html xmlns:og="http://ogp.me/ns#">

Не без бубнов (индивидуальные стили для ИЕ и JS fix для Opera — но у меня было еще выпадающее меню привинчено, для которого этот JS fix и потребовался), зато в целом без JS, на одном CSS, без привязки к CMS и к текущим ширинам.
chikuyonok.ru/2011/04/inline-vertical-align/

См. комментарий от Ткаченко Артем. ТО есть оформляется все спанами с инлайном/инлайн-блоком в качестве display, последним ставится span шириной 100% и все выравнивается justify.

Там придется попотеть на предмет блоков, инлайн-блоков и просто инлайнов. Кроме того, если общая ширина пунктов окаждется больше ширины контейнера, «лишние» пункты переедут на следующую строчку.

На таком бюджете и с такими задачами, лучше, пожалуй, самим.
Посмотрите в сторону Twin SuperMicro. Что-нибудь вроде 1026TT-TF
50000 — платформа
50000 — процессоры (E5620)
36000 — 110000 — память (48 — 96 GB на каждый из двух узлов, 4GB модули можно брать обычные, 8GB — REG/ECC, перед покупкой необходимо договриться с поставщиком о возможности обмена рабочих модулей на другие рабочие — у меня с SupreMicro подобных проблем не возникало, но слухи ходят, что вся память может не завестись)
Остатки бюджета — диски. Можно штатно поставить по 4 быстрых SATA (дешевле, но относительно медленнее), можно запихнуть SAS контроллеры и быстрые диски (дороже).

Само по себе право авторства неотчуждаемо. Посему, ни владельцы сайта, ни возможные юридические докум енты или устные договоренности, ни всевозможные обстоятельства изменнеия сайта тут совершенно ни при чем.

Важно — был создан дизайн, и был прикручен движок. И то и другое было подписано.
Затем дизайн остается прежним, в движке что-то меняется (Если я правильно понял автора). И меняется подпись. Поскольку дитзайн не изменился — подпись меняется не обоснованно.

Естественный выход — коррекция подписи. что-то вроде создание сайта (нового) — новые ребята. Дизайн сайта (старый) — старые ребята. Если естественное решение не прокатывает — (тут имеет смысл еще разок прояснить тему у новой конторы) — обращаться в суд.

С максимальной вероятностью (то есть чудеса в нашей юриспруденции слуаются и мы в них верим) результатом станет запрет упоминания нового сайта в портфолио новой конторы, а также коррекция копирайтов. Правда, владелец сайта (и это уже его право, если в изначальном договоре на создание сайта не было прямо указано иное) может вообще снять с сайта копирайты создателей. Но это будет уже совсем другая история.

Выбираете налогообложение доходов. НДС не платите, НДФЛ не платите, отчеты о расходах не предоставляете. Оплачиваете 6% от всех поступлений на счет + около 12000 в год в ПФ (эту сумму можно уменьшить, вернее учесть ее в общем налогообложении).
Официально на первых порах работаете как один человек, субподрядчикам переводите деньги так, как сочтете нужным (посльку по расходам не отчитываетесь) — главное, чтобы субподрядчики или были как-то отдельно от вас, или чтобы официально их не было вовсе. То есть строго не зарплатные варианты. Договора подряда — возможно, но лучше бы, чтобы субподрядчики тоже оказались чем-то вроде ИП.
Работатет так до конца года — если обороты получаются больше 1000000 в месяц, в конце года считаете, не будет ли выгоднее перейти на налогообложение «доходы — расходы» (но надо иметь в виду, что в последнем случае будет намного больше возни с бумажками и всегда существует риск различия подходов к понятию «расходы» между вами и налоговой).