Dunadan

Может, рендерится дефолтовый шаблон?
Или фреймворк отдает свои заголовки ответа?

Обычно в современных фреймворках идет работа с экземпляром специального класса а-ля Response, которому и надо назначать верные заголовки и тело ответа.

Если есть возможность - лучше перенести хранение сессий в мемкеш.

hybridauth.sourceforge.net поможет, не только для ВК.

Есть модуль php-unserialize.
Мы для одного из проектов патчили его (валился на циклических ссылках в объектах), довели до нужной нам работоспособности ( читать объекты из сессии, назад писать не пробовали ). Вроде работает :) Но следует понимать, что читает он не все - циклические ссылки просто пропускает.

$xml = simplexml_load_string($xml);
$tables = $xml->TABLES->children();

foreach ($tables as $xmlstr) {
	echo (string)$xmlstr['COMMENT'] ."<br /><hr />";
}

Внимательнее к структуре файла и к регистру нод.

phpExcel поможет, но а) кушает много памяти б) для сложных файликов может "бить" форматирование. Мы довольно успешно работали с phpExcel с файликами до 6000 строк, дальше начинались уже проблемы по времени / потребляемой памяти.

Если сервер под Windows, можно попробовать покопаться среди www.php.net/manual/en/refs.utilspec.windows.php .

Мы лично разработали свои инструменты сами.
В последнее время с клиентами таскаем таски в Канбане, но внутренний учет у нас свой.
CRM - свое
Документоборот, всяческие дизайны и верстка - в СВН
Трекер - свой
Система контроля версий - свн или git.
Деплой - написали свой, простенький пхп-скрипт с набором инструкций ( сделать чекаут, создать/удалить директории, откатится на предыдущую версию и пр). Дописываем по мере возникновения трудностей.
Для всего этого приобрели виртуальный сервер. Пока хватает.
Почему писали свое?
Изначально существующие системы были или сильно монструозные, либо сильно дорогие. Решили начать с простого, потом подпиливать по мере необходимости.
Нам понравилось :)

Мы использовали ExtJS как раз для разработки CRUD «на все случаи жизни».

Kohana смотрели? Он не подходит под определение «микро», но под 5.2 вполне успешно живет.

Как правильно ответили выше, пора переходить от теории к практике — решать прикладные задачи. В конце-концов, язык — это только инструмент.

Вообще, профессиональный рост программиста обязан идти в двух направлениях: технологическом и теоретическом.

Например, что бы оценить технические знания, можно самого себя спросить и честно ответить:
— Для каких задач PHP подходит, а для каких — нет? Почему?
— Смогу ли я написать простейший файловый менеджер? А так, что бы не давать доступа к системным папкам и файлам? Не давать загружать зловредный код?
— Смогу ли я написать робота для парсинга страниц? А такого, что бы умел ходить по ссылкам внутри страниц? Если учесть еще множество кодировок?
— Знаю ли я о понятии «уязвимость»? Если знаю — смогу ли я найти их в своем же старом коде?
— Знаю ли я, что такое «регулярное выражение», где они используются и, главное, зачем?
— Знаю ли я о последних изменениях в языке?
— Смогу ли я написать простейший чат? Гостевую книгу? Баннерокрутилку? Что произойдет с ними, если одновременно туда зайдет 10000 посетителей и почему? Что надо сделать в таком случае?

Теоретическая часть — это вопрос об архитектурном проектировании программных продуктов, как таковых, причем далеко не обязательно речь идет о PHP. Рано или поздно программисту приходится участвовать в постройке «больших» систем и адаптировать некие алгоритмы для решения задач и придумывать свои.

Если речь о популярных алгоритмах — тут можно посоветовать таких монстров, как Дональда Кнута и его «Искусство программирования».

Model-View-Controller, Dependecy Ingection — вот о чем следует почитать для понимания принципов современных подходов проектирования приложений. Так же почитайте о «паттернах» / шаблонах программирования.

И все пробуйте на практике, без этого никак :)

А что мешает сделать аггрегацию статистики?

Например, Вы считатете количество просмотров определенной страницы.
Каждый хит — одна запись в БД с ай-пи адресом посетителя.

Для сводной таблицы вполне достаточно будет записи вида page_id, page_view_count, week_id, где
page_id — индекс страницы
page_view_count — просмотров страницы за неделю
week_id — порядковый номер недели в году.

Для отчетов из серии «за неделю-месяц-полгода-год» вполне пойдет. Можено еще количество хостов считать.

В результате вся статистика по одной странице за год займет аж 52 записи.

Вы говорите о чем-то похожем на bCompiler?

Hybrid Auth в помощь.
Для своих проектов пришлось дописать к нему поддержку ВК и Одноклассников.

Сразу смиритесь с тем, что в ВК Вы сообщения не сможете отправлять (разве что договоритесь напрямую с офисом ВК). Про Одноклассников не в курсе.

Мы у себя в чате добились отправки сообщения за 0.04 секунды.
php + MySQL.

В Вашем случае лучше подумать над не столько Доктриной как таковой, сколько над архитектурой приложения. Как именно у Вас получаются сообщения конечным пользователем?

На случай, если кому-то будет интересно, как эта задача была успешно решена:

1) В качестве кроссплатформенного демона был использован скрипт на NodeJS
2) На Windows-платформе соединение от веб-сервера IIS пробрасывается к демону при помощи модуля IISNode от Томаша Янчука, работающего в Майкрософте. Модуль бесплатен, часто обновляется, автор адекватен и отвечает в багтреккере.

Изменения в коде демона «под винду» — аж одна строчка.

Ваш покорный слуга принял посильное участие в тестировании ранних веток модуля :)

Некоторое время назад столкнулись с подобной задачей.
На самом деле, в этом случае документация вполне аккуратна: там указано, что метод wall.post доступен только для десктоп-приложений (сиречь — мобильных клиентов, которые имеют полный контроль над окном браузера).

Как показало небольшое исследование, ВКонтакт проверяет, кто и каким образом пытается токен получить и на ходу «режет» привилегии для не-десктопов (окно запроса не содержит иконки «с кирпичиками» для разрешения публикации сообщений на стену).

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

Хотя и странно — тот же Фейсбук разрешает цивилизованно через АПИ постить на стену, даже на стену друзьям пользователя (если память не подводит).

Ну если нужно только считать, то вполне достаточно просто добавить поле rating в таблицу со статьей и увеличивать / уменьшать ее значение программным образом.

Таблица нужна только тогда, когда требуется накладывать ограничения по времени, ай-пи адресу и пр. Хорошим тоном считается не хранить ай-пи адрес в виде строки, а записывать его числовое значение (если пишете на php — php.net/manual/en/function.ip2long.php).

Причем при выводе ленты новостей весьма полезно аггрегированное значение рейтинга таки хранить в отдельном поле в таблице статей — что бы не пересчитывать его каждый раз. Обновлять его можно триггером на стороне СУБД или программно.

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

ionCube, Zend, SourceCop, SourceGuardian, bCompiler в некоторых случаях усложняют поддержку продукта как такового (идут трудноуловимые ошибки, которых нет в «чистых» исходниках).

Впрочем, можно использовать обфускаторы исходников — если не всех, то каких-то критических частей.