mayorovp

А что это за код, который находится по адресу https://mc.yandex.ru и которому нужен доступ к вашему сайту?..

Проверьте в инструментах разработчика, какие заголовки ваш сайт возвращает браузеру. Тогда вы будете знать - проблема в заголовках или в сервере.

Видимо, проблема в wp-blog-header.php

.htaccess не может быть, скажем, защищен от записи?

Открывайте инструменты разработчика в браузере, переходите на вкладку "Сеть" - и посмотрите все запросы, которые браузер делает.

Особое внимание, во-первых, запросу к самому скрипту (что ему передается на вход и что он возвращает). Во-вторых, поставить обработчик, который стоял там раньше - и сравнить с во-первых. В-третьих, обратить внимание на любые неуспешные запросы.

PS ошибку я уже нашел, но не скажу, в чем она. Научитесь отлавливать запросы к серверу. Если найдете отличие, но не поймете, что там происходит - подскажу.

Извиняюсь за пустую придирку, но почему вы не написали url: '/search/test'? Откуда эта любовь к абсолютным ссылкам там, где можно без них обойтись?

Советую изучать не ajax (там изучать-то и нечего), а сопутствующие технологии. Javascript (обязательно знать, что такое замыкания/closures и обещания/promises)
что-нибудь серверное, тот же php
и протокол HTTP

Разумеется, уже известные пункты можно пропустить.

Одну ошибку вам уже нашел @Petroveg, вот вам вторая.
offset увеличивается только после успешного получения данных от сервера, а повторный вызов getData может произойти раньше. В таком случае на сервер отправится два запроса с одинаковым offset.

По-хорошему, надо еще до ajax-запроса заранее создать элемент, куда будет записываться результат, и запомнить ссылку на него в переменной. Offset же следует увеличивать сразу после запроса, не дожидаясь его окончания.

А запрос через секунду прерывается - или же сервер что-то отвечает? Если сервер успешно отвечает - то надо и копаться в сервере, а не в клиенте.

Лично я вижу в серверном коде два подозрительных места.
1. Если в базе есть хоть одно сообщение, то оно будет выдаваться клиенту каждый раз. Нужно либо удалять его из базы - либо добавить в запрос какой-нибудь фильтр, чтобы отсечь уже прочитанное. Если поле id - автоинкремент, то можно фильтровать по нему.

2. Делать long pooling на связке "клиент-сервер" - и активных опрос на связке "сервер - база данных" - не лучший вариант. Надо вам поискать способ серверному скрипту так же уснуть до появления события, иначе весь long pooling непонятно зачем.

Зря вы setTimeout используете для повторного запроса - лучше используйте $.ajax({...}).always(getmess)

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

А веб-сервер случайно не в chroot'е?

Что-то я не могу, как можно заблокировать ФАЙЛ по ISCSI. Похоже, что блокируется не файл, а часть хранилища. Взаимоблокировка случается, когда файл сессии пересекает границы подлежащих блокировке блоков.

Не используйте NTLM авторизацию в AD — это рушит всю идею домена.

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

Отправить письмо локальному MTA на том же сервере, а тот уже сам передаст дальше.
Если отключить строгое соответствие RFC, то локальная отправка должна быть очень быстрой.

Проблема в настройках не php, а apache. Похоже, что до интерпретатора php дело даже не доходит.

У объекта-модификатора должен быть метод combine, который возвратит скомбинированный объект. У скомбинированного объекта должен быть метод, который его снова разделит.

Иными словами, нужно что-то вроде вот этого: