FAQ

Parser — это технология для самостоятельного создания сайтов с помощью простого языка. Parser начал создаваться в Студии Лебедева в 1997 году. Сегодня подавляющее большинство сайтов, создаваемых Студией Лебедева, делаются с его помощью.

Язык специально спроектирован и оптимизирован для того, чтобы было удобно создавать хорошие сайты. Безопасная работа с формами, cookies, табличными файлами, базами данных и XML — часть языка, а модульность языка позволяет легко наращивать функциональность.

Можно постепенно заменять конструкциями Parser файлы уже готового сайта, например описать заголовки и таблицы HTML-документа методами, использовать переменные окружения через Parser, упростить обработку данных форм. Или изначально продумать удобную конструкцию сайта, и писать код, исходя из возможностей Parser. Parser не подменяет собой HTML-код, он генерирует его.
Поэтому изменять исходные тексты очень легко, и всегда сразу можно увидеть, что получилось в результате той или иной команды.

Parser в известном смысле — макроязык, в нём нет оператора print; весь текст, набранный в исходном файле, суть большой оператор print. Конструкции Parser являются погруженными в текст.
Получается, что вы не пишете программу, которая выводит текст — наоборот, в имеющийся текст вы добавляете логику, ^if(условие){действие}, и организацию, блоки(методы), на которые вы разбиваете HTML-код:

@header[]
...
@footer[]
...
@navigation[]
...
@body[]
...

Все исходные коды доступны в CVS сервере.
Возможна сборка и под Unix/Cygwin, стандартная для GNU проектов компоновка проектов с INSTALL, configure и Makefile'ами, и под Microsoft Visual Studio 2003+.
Мы приветствуем дополнения и улучшения.

cvs -d :pserver:anonymous@cvs.parser.ru:/parser3project login
Пароль пустой.
cvs -d :pserver:anonymous@cvs.parser.ru:/parser3project get -r release_3_4_4 parser3

Также в репозитарии имеется ряд других модулей, см. раздел «Сборка Parser из исходных кодов» в документации.

Мы в Студии Лебедева абсолютно убеждены в том, что ни одна закрытая технология не может долгое время оставаться современной и актуальной. Всегда будет появляться что-то новое, что будет превосходить технологии предыдущего поколения. Делая Parser доступным каждому, мы не хотим ни с кем конкурировать в области инструментов разработки сайтов. Широкое использование Parser поможет технологии оставаться современной. Продажа технологии сужает круг пользователей и замедляет развитие новых проектов. Мы не продаем инструмент, а даем его бесплатно любому желающему, рассчитывая на то, что этот шаг поможет развитию российского интернета.

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

Не претендуя на полноценный анализ:

Parser макроязык, в нем нет оператора print, а синтаксис PHP похож на C. Поэтому Parser сам по себе готовый обработчик шаблонов, в PHP приходится использовать сторонние библиотеки.
В Parser поддержка UTF-8 интегрирована и прозрачна для разработчика, а в PHP это набор функций.
В Parser единый интерфейс для работы с серверами баз данных, включая blob поля, а в PHP для каждого сервера свой набор функций.
В Parser объектная технология активно используется в системных типах — строка это объект с методами, а в PHP есть просто набор функций для работы со строками.
В Parser использовать XML и XSL проще, чем в PHP.
В Parser есть системный тип таблица, а в PHP нет.
В Parser встроены функции кеширования, а в PHP нет.
В Parser повсеместно реализована автоматическая обработка пользовательского ввода — это когда например при формировании SQL запроса вам заменят ' на '', а в PHP только зачатки этого подхода.

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

На безопасность вашего сайта версии с включенным safe mode действует скорее косвенно, не давая возможность, например, запустить:

rm -rf

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

Грубо говоря safe mode версия позволяет администраторам уделять меньше внимания настройкам безопасности в случае использования парсера, а в случае ошибки разработчика сайта затрудняет нанесение вреда сайту.

Резюме: версия с safe mode (по умолчанию) более безопасна по определению, независимо от настроек прав у конкретного провайдера.


Пример: из незащищенной версии можно сказать

^exec[/../../bin/rm -rf /]

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

Для этого, согласно документации, нужно в файлах .htaccess или httpd.conf (секция <virtualhost>) добавить следующие строки (подразумевается, что /cgi-bin указывает на каталог, прописанный в ScriptAlias в httpd.conf):

AddHandler parsed-html html
Action parsed-html /cgi-bin/parser3.cgi

Также можно установить Parser в виде модуля к Apache.

Согласно документации по веб серверу Apache, для этого нужно в файле .htaccess для соответствующей директории добавить следующую строку:

RemoveHandler html

Для этого в программе конфигурации IIS кликаете правой клавишей мыши на веб-сайт и выбираете Properties. Открывается окно Web Site Properties. Затем в странице Home Directory нажимаете кнопку Сonfiguration. В появившемся окне нажимаете Add, и прописываете путь к parser3.exe или parser3isapi.dll. В строке Extension пишете html, и жмете OK. Затем в окне Web Site Properties выбираете страницу Documents, и добавляете index.html в список файлов, открываемых по умолчанию.
Заодно советуем убрать обработчики тех расширений, которые вы не используете.

Бинарные CGI версии Parser под *nix в разделе для скачивания собраны в SAFE MODE. Такой Parser проверяет группу и владельца файла перед его считыванием, и считывают только те файлы, группа или владелец которых совпадает с группой или владельцем процесса, в котором работает Parser.

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

Бывает, что системный администратор настроил вам веб-сервер таким образом, что и группа и пользователь, от которой работает CGI процесс (параметры Group и User в httpd.conf, для Apache) не совпадает ни с группой ни с пользователем, которому принадлежат файлы, создаваемые вами.

В этом случае вы  получите сообщение «…safe mode…»
Варианты действий:
Попросите вашего системного администратора прочесть это сообщение, он поймет.
Если хотите, соберите Parser из исходных кодов, выключив эту возможность.

Посмотрите в лог ошибок веб-сервера, а также suexec.log (если такой есть), там подробно написано, что случилось.
Типичная ошибка, «Premature end of script headers», означает, что вы забыли поставить бит «executable» или выбрали версию Parser, не соответствующую операционной системе вашего сервера (уточните ее у системного администратора).
Также причиной может быть то, что вы «закачали» исполняемый файл на сервер не в режиме binary. В этом случае размер закачанного файла будет отличаться от файла, лежащего на вашем локальном диске.
Другой причиной может являться опечатка в .htaccess файле, запись в лог файле будет содержать подробное указание, что вы сделали не так.
 В случаях, когда в логе вы увидите иную ошибку, ее текст подскажет вам, как ее исправить.

Есть предположение, что под «браузером» подразумевается MSIE и что забыли что по умолчанию в этом браузере показываются
[x] Выводить подробные сообщения об ошибках http (Friendly HTTP error messages)
Эта опция говорит браузеру, что если будет получен HTTP ответ размером менее 512 байт он не будет отображен, а будет показано собственное сообщение об ошибке. Лечится это соответственно отключением данной опции в MSIE.

Парсер все-таки не назначен обработчиком ваших документов.
Для проверки функционирования парсера наберите в адресной строке броузера:
http://ваш_сайт/cgi-bin/parser3.cgi (или .exe, для версии под Win32)
Вы должны увидеть примерно следующее:

Parser/3.x.x

Если вы это увидели, парсер скопирован куда следует, права на него установлены правильные.

Если парсер скопирован правильно и вы не забыли прописать в .htaccess инструкции, указанные в документации, возможно вы забыли разрешить апачу обработку .htaccess в файле httpd.conf с помощью инструкции AllowOverride.
Чтобы проверить, обрабатывается ли у вас .htaccess — впишите в него какую-нибудь заведомо неверную инструкцию, например «mytest», в самое начало. Если при релоаде страницы вы не увидите 500 ошибку (она обязательно появится если все настроено верно) — значит данный файл у вас не обрабатывается. Измените значение AllowOverride или обратитесь к вашему администратору.

Из исходников парсер собирается с ключом -g [отладочная информация].

Если она вам не нужна, можно сделать: strip parser3

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

Да, конечно. Обратитесь непосредственно к парсеру и он напишет свою версию. Но предварительно не забудьте выключить IE friendly messages.

Конечно. Как сказано в документации, все служебные символы необходимо предварять символом «^». Там кстати можно найти полный список служебных символов парсера.
Например, если необходимо вывести список, разделив элементы точкой с запятой:

^table.menu{…}[^; ]

Почитать о внешних и внутренних данных в документации и примерах об операторах taint/untaint.

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

Однако если вам нужно иное (например для выдачи содержимого <pre />), то вы можете изменить поведение парсера, прочитав про taint/untaint и использовав соответствующий язык (обычно <pre>^taint[html][тут текст с идущими подряд пробелами, которые нужно сохранить]</pre>).

Создайте себе удобный оператор, см. раздел «Операторы, определяемые пользователем» в документации.

Используйте

${name}.jpg

Почему? Потому, что нужно отличить эту ситуацию от…

$table.field

…дать понять, что точка, это не часть языка, и не означает, что необходимо взять поле с именем «jpg» у объекта «name».

$form:[$hash.key]
$form:[$table.field]

Создать форму с <input type="file" name="attach" />, указать у формы action, method="post" и не забыть про enctype="multipart/form-data", и при посте формы в $form:attach у вас будет файл, который вы можете проверить (def $form:attach), узнать его имя ($form:attach.name) или размер ($form:attach.size) и наконец сохранить (^form:attach.save[binary;/path/to/file.^file:justext[$form:attach.name]]).

Согласно документации в данном выражении происходит вывод содержимого переменной с именем a$b, для того, чтобы вывети содержимое двух переменных, не разделенных символами-разделителями нужно написать ${a}${b} или проще: ${a}$b

Дело в том, что ^#0A эквивалентно написанию символа перевод строки. Таким образом мы создаем таблицу, у которой первая строка ничего не содержит. Для того, чтобы парсер не воспринимал ^#0A как разделитель строк таблицы, он должен быть «грязным». Напишите например так:

$tReplace[^table::create{from	to
^taint[^#0A]	<p>}]

и после выполнения метода ^sMyString.replace[$tReplace] все символы перевода строки будут заменены на <p>

Начиная с версии 3.4.4 реализовано редактирование таблиц. Теперь можно изменить значение ячейки и вставить строку ($t.name[value] и ^t.insert{row}).

Можно обратиться к документации и прочитать, как написать свой оператор for, который будет делать то, что требуется.
В частности, там есть пример оператора steppedfor, который имеет функционал, аналогичный оператору for, но которому можно передать параметр «шаг»:

@steppedfor[name;from;to;step;code]
$caller.$name($from)
^while($caller.$name<=$to){
    $code
    ^caller.$name.inc($step)
}

Теперь возможен такой вызов…

@somewhere[][i]
^steppedfor[i](1;10;2){$i }

…при этом изменяется локальная переменная метода somewhere.

Обращаемся все к той-же документации, и пишем свой оператор, который затем используем вместо стандартного метода foreach:

@foreach[h;key;value;code;order_direction][tkey]
$tkey[^h._keys[]]
^tkey.sort{$tkey.key}[^if(def $order_direction){$order_direction}{asc}]
^tkey.menu{
    $caller.$key[$tkey.key]
    $caller.$value[$h.[$tkey.key]]
    $code
}

Пример вызова:

^foreach[$myhash;k;v]{
    key=$k
    value=$v
}[desc]

Например я привык писать код в подобном стиле:

^if(условие)
    {если истина}
    {если ложь}

Но парсер не позволяет делать этого, требуя подобное написание:

^if(условие){
    если истина
}{
    если ложь
}

У парсера код погружен в текст и это одна из мелочей обусловленная этим. Пробельные символы также попадают в результирующий html/xml и игнорировать те из них, которые размещенны между скобками было бы неверно. К тому же возникают некоторые сложности с пониманием написанного, например в конструкции:

^if(условие){текст} [вася]

' [вася]' - это буквы такие, или код если условие ложно? Было принято решение быть с подобными конструкциями строже, но однозначнее.

Да, глобального модификатора для отмены чувствительности к регистру у ^file:list[] нет, однако в связи с использованием достаточно свежей библиотекой PCRE доступен локальный модификатор и можно сделать не чувствительной к регистру всю маску или её часть, например:

$tFileList[^file:list[/dir;\.(?i:jpe?g|gif|png)^$]]

Так:

$method[$$name]
^method[...параметры...]

или так:

^self.[$name][...параметры...]

Как говорится в документации, при обнаружении парсером необработанной ошибки вызывается метод @unhandled_exception[], который по умолчанию определен в конфигурационном auto.p, входящим в поставку парсера. Для того, чтобы кто ни попадя не видел текстов об ошибке, из метода @unhandled_exception[] вызывается метод @unhandled_exception_release[], который лишь сообщает, что произошла ошибка (Unhandled Exception), и для её уточнения предлагает заглянуть в parser3.log или включить debug режим, чтобы текст сообщения об ошибке выдавался на страницу. Для того, чтобы включить этот debug режим, необходимо отредактировать конфигурационный auto.p таким образом, чтобы из метода @unhandled_exception[] вызывался метод @unhandled_exception_debug[] (который как и @unhandled_exception_release[] находится в этом файле).

Такую ошибку парсер выдает когда метод @conf[] вызывается повторно.
Этот метод должен присутствовать только в конфигурационном auto.p (который находится рядом с исполняемым файлом). Необходимо проверить:
— нет ли его в других файлах
— не вызывается ли он где ручками
— не вызывается ли через use конфигурационный auto.p

Как правило это не закрытые скобки или забытый префикс в виде символа ’^’ перед спецсимволами парсера ’;’, ’^’, ’$’ и др.
Если вы хотите, чтобы в тексте странички появился символ ’;’ его надо написать так ’^;’. В принципе, префиксы ставить нужно не всегда, однако если вы их поставите — хуже не будет ;)

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

Это означает, что вы вызываете метод, и пытаетесь передать ему больше параметров, чем тот может принять. Очень часто такая ошибка происходит, когда вы передаете в метод строку, содержащую спецсимволы, вероятно, символ «точка с запятой», не предварив её символом «птичка». При этом парсер воспринимает этот символ как разделитель передаваемых в метод параметров.

Производится попытка добавить в тело страницы объект, который не может быть выведен парсером. Например, если написать в чистом поле ^date::now[] то получим такую ошибку. Чтобы вывести дату нужно сделать примерно следующее:
$now[^date::now[]]
^now.sql-string[]
Аналогично с объектами таблица, хеш и т.д.

Вы пытаетесь использовать @USE или ^use[] но не задали переменную $MAIN:CLASS_PATH и парсер не знает, где искать классы, которые вы пытаетесь подключить. Подробности в документации.
Одна из возможных причин: переменная $MAIN:CLASS_PATH определена в конфигурационном auto.p, однако по каким-либо причинам на вашей системе он не выполняется. В поиске данной проблемы вам может помочь тестовый документ, скачанный из соответствующего раздела.
Другая возможная причина: вы пытаетесь подключить классы раньше, чем определили переменную $MAIN:CLASS_PATH. Такое обязательно произойдет если вы в корневом auto.p будете подключать дополнительные файлы в @USE, а определять упоминаемую переменную будете в методе @auto[], который выполняется после @USE.

Файл с операторами или классами, которые вы пытаетесь подключить через @USE или ^use[] не найден по путям, указанным в переменной $MAIN:CLASS_PATH.
Часто проблема имеет место быть, если после имени файла в @USE закрался пробел/символ табуляции.
Также бывает, что после @USE и списка модулей забывают объявить метод и начинают писать код страницы, подразумевая, что это будет @main[]

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

libparser3mysql.so это не клиентская библиотека MySQL, а драйвер парсера. Вам в таблице драйверов нужно указать путь к этому драйверу и путь к клиентской библиотеке libmysqlclient.so. Местоположение драйвера вам известно (вы его сами копировали на сервер), а местоположение клиентской библиотеки вам может подсказать администратор вашего сервера если оно отличается от общепринятого.

Попытка парсера обратиться к клиентской библиотеке SQL сервера libmysqlclient.so не увенчалась успехом. Вам нужно узнать у вашего системного администратора полный дисковый путь к этому драйверу и прописать его в таблицу $SQL:drivers в главном конфигурационном файле.

Версия установленного и требуемого парсером драйвера (например libparser3mysql.so) не совпадают.
Причина может быть в том, что вы перешли с одной версии парсера на другую, но не обновили драйвер базы данных.

В главном конфигурационном файле (auto.p который находится рядом с парсером) не определен протокол, который вы пытаетесь использовать в операторе ^connect[>>тут<<]{код}

Происходит попытка выполнить SQL запрос (^table::sql{}, ^int:sql{} и др.) вне оператора для подключения к БД ^connect[строка подключения]{запросы тут}.

Тот кто настраивал вам parser или совсем не положил предлагаемый конфигурационный файл, или испортил его.
По-умолчанию, если $request:charset не задан (сейчас подходящий момент посмотреть в документацию) он равен UTF-8.
Parser’у не объяснили, в какой кодировке его документы ($request:charset), и он считает, что они в UTF-8.
Соответственно, если попросить его перекодировать из UTF-8 в windows-1251 (определив $response:charset), задав на входе текст в windows-1251, он честно возмутится.
Подобное может случиться если по каким либо причинам парсер не считывает конфигурационный auto.p, что можно проверить разместив в последнем ^throw[check;] или проанализировав в корневом auto.p какие-либо настройки, заданные в конфигурационном файле.

После @USE закрался невидимый символ пробела/табуляции, который можно заметить, если приглядеться к тексту в первых одинарных кавычках. Удалите его, сразу после @USE должен быть символ перевода строки.

Подобное сообщение появляется, если парсер обнаруживает очень длинный цикл. Например, если вы напишите конструкцию ^while(1){что-то} то будет подобное сообщение об ошибке. Кроме того, если вы сделаете большой цикл for или menu в котором будет более 20000 итераций, то тоже увидите подобное сообщение.

Подобное сообщение появляется, если парсеру кажется, что код зациклился. Очень часто причиной может быть некорректная или очень глубокая рекурсия (более 1000 вызовов).

Когда ответ от CGI-скрипта больше клиенту веб-сервера не нужен, например пользователь нажал кнопку stop, или потерялась связь, веб-сервер посылает скрипту сигнал «послушай, тут твой output больше никому не нужен». В версиях parser до 3.0.0006 этот сигнал специально не обрабатывался, и происходила его обработка по-умолчанию = убивание процесса посередине его работы [исключение составлял parser, соединившийся с oracle, там oracle библиотека включала игнорирование этого сигнала].
Это нехорошо, что нас убивали, и мы ничего не могли аккуратно закрыть.

С версии 3.0.0007 parser отлавливает этот сигнал и создаёт ошибку «parser.interrupted».

В том случае, если до обработки запроса ещё дело не дошло, или, наоборот, запрос уже обработан, в лог и попадёт приведённая вами запись.

Ошибка означает следующее: от броузера посетителя на сервер пришёл POST запрос, в заголовке которого написано content-length:YY однако попытки считать это количество байт из stdin CGI процесса не увенчались успехом — было считано только XX байт.

Если подобная ошибка изредка встречается в parser.log, то можно просто не обращать на неё внимания, возможно в процессе POST-а данных от посетителя с нестабильным соединением произошел его разрыв и до сервера просто не дошла часть данных. Однако если каждый POST вызывает эту ошибку то проблема с настройками сервера.

Кто-то через форму на вашем сайте попытался закачать на сервер файл размером XXXX байт, в то время как у вас в главном конфигурационном файле указано, что серверу разрешено принимать файлы с максимальным размером YYYY байт.

Обычно такая ошибка возникает когда вы записываете содержимое переменной на диск и думаете что переменная содержит файл, а на самом деле в переменной — строка (например забыли написать нужный enctype у формы и пытаетесь загрузить файл на сервер). Для решения проблемы просто сделайте перед записью проверку на тип переменной.

Дело в том что и у строки и у файла есть метод save, но он принимает разные параметры.

Вы попытались выполнить ^file::load[http://сайт/документ] и удаленный сервер в заголовке ответа вернул статус не равный 200, что для парсера является ошибкой. Если вам нужно иное поведение парсера и вы желаете самостоятельно разобраться с ответом укажите в параметрах $.any-status(1) как сказано в документации.

Вашему коду для выполнения потребовалось памяти больше, чем ему позволил занимать системный администратор. Для решения этой проблемы вам потребуется оптимизировать код (убрать SELECT *, не загружать большие объемы данных, периодически обнулять переменные и выполнять ^memory:compact[], изменить логику работы кода) или попросить вашего администратора увеличить лимит памяти процессу.

Для поиска узкого места в коде вы можете воспользоваться методом @run_time[] из полезных пользовательских операторов.

Данная ошибка означает, что вы допустили ошибку в методе @unhandled_exception[], который как раз и должен сообщать об ошибках. PAF утверждает, что начиная с версии 3.1.4 даже если вы допустите ошибку в этом методе парсер все равно внятно о ней сообщит.

Вы всегда можете перехватить исключение парсера "file.missing" и сами отобразить вместо несуществующего документа документ /404.html. Можно изменить метод @unhandled_exception например так:

@unhandled_exception[exception;stack]
^if(^env:REMOTE_ADDR.match[^^IP адрес вас как разработчика]){
	^unhandled_exception_debug[$exception;$stack]
}{
	^if($exception.type eq "file.missing"){
		^rem{*** если нет файла то делаем внутренний ***}
		^rem{*** редирект на страницу с 404 ошибкой ***}
		^rem{*** не забывая написать в ней $response:status(404) ***}
		$response:location[/404.html]
	}{
		^unhandled_exception_release[$exception;$stack]
	}
}

Прежде, чем задавать вопрос попробуйте найти ответ в FAQ, в документации и в форуме.

Если вы не нашли ответ на свой вопрос, задайте его в форуме придерживаясь следующих правил:
1. Главную мысль вопроса впишите в заголовок. Заголовок вида 'Помогите' или 'Не знаю что делать' не несет смысловой нагрузки и не поможет вам в решении проблемы (или сообщение будет удалено модератором)
2. В теле сообщения напишите что вы хотели получить, что вы делали и что получили
3. Помните, что вашу проблему будут пытаться помогать вам решать исключительно по вашему описанию, поэтому описывайте всё максимально подробно, последовательно, старайтесь не использовать сленг, транслит и иные вещи затрудняющие понимание вашего описания другими. Не удивляйтесь, если вы не получите помощь на сумбурно изложенное описание проблемы или copy/paste 10 страниц кода. Посетители не будут тратить время на попытки расшифровать или понять его.

Если вопрос касается парсерного кода то:
1. Приведите его фрагмент (не надо приводить 10-и страничные тексты, их никто не будет читать)
2. Очень желательно отформатировать фрагмент кода и обрамить его псевдо-тегами [code][/code]. Это будет способствовать лучшему пониманию вашего кода другими.
3. Укажите полную версию используемого парсера/веб сервера/ОС.

Если вопрос касается не парсера а Apache, MySQL, IIS и т.п. — не забудьте поискать ответ в соответствующих документациях (google и yandex тоже могут оказаться полезными).
Написали? Теперь внимательно перечитайте ещё раз своё сообщение. В 80% случаев в нем уже содержится ответ на ваш вопрос.

Возможные причины удаления сообщений:
1. Модератору не понравился агрессивный тон собщения;
2. На заданный вопрос есть ответ в FAQ или он элементарно находится поиском;
3. Тема, затронутая в сообщении, недавно обсуждалась;
4. Сообщение не имеет никакого отношения к парсеру;
5. Задавая вопрос, вы полностью проигнорировали приведенные выше рекомендации;
6. Опубликованное сообщение — спам.

Нужно почитать про «команды форматирования в форуме» и воспользоваться ими.

В некоторых почтовых клиентах это сделать возможно.
1. настроить фильтр сообщений, чтобы сообщения с форума падали в отдельную папочку
2a. The Bat!: для этой папки установите: View|View threads by|References
2b. Outlook Express: View|Current View... (*) Group messages by conversation

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

Это треды, в которых принимал участие пользователь, просмотривающий форум. Этот вид проосмотра доступен только залогиненым пользователям. Посылать ссылку на какую-либо страницу «Своих тредов» бесполезно, никто кроме вас не увидит это так, как вы.

Первая дата — дата публикации сообщения пользователем. Вторая — дата последнего редактирования сообщения. Свое сообщение можно отредактировать до тех пор пока на него никто не ответил.
P.S. Модератор может только удалять чужие сообщения, но не исправлять их.

Своё сообщение можно отредактировать только до тех пор, пока на него никто не ответил.

У новых сообщений даты выделены красным цветом.
По умолчанию новыми считаются сообщения, которые опубликованы менее 72 часов назад. Зарегистрированный пользователь может установить у себя в профайле опцию, согласно которой новыми будут считаться сообщения, которые появились после момента его последнего логина.

Это означает, что у данного сообщения нет «текста», т. е. можно не кликать на него, ничего более чем написано в заголовке вы не увидите. Данный значок ставится автоматически, писать руками его не нужно. А ссылка на это сообщение показывается для того, чтобы можно было ответить на него.

Для того, чтобы найти что-то попробуйте следующее:
1. Из своего вопроса выделите наиболее важные ключевые слова, выкинув незначащие (в том числе имена переменных). Если в вопросе встречаются базовые методы/классы парсера обязательно включите их имена в список;
2. Поиск по форуму не знает морфологии, поэтому замените окончания ключевых слов символом '*';
3. Если хотите найти сообщение, содержашее какую-либо фразу целиком (например текст сообщения об ошибке) - заключите её в кавычки;
4. Поиск ищет сообщения, содержащие любое из перечисленных слов. Если вам нужно, чтобы были найдены сообщения, содержащие все перечисленные вами ключевые слова, перед каждым словом поставьте символ '+';
5. Нажмите кнопку «Найти», при этом будет произведен поиск по всем авторам;
6. Если вы не получили результатов, или их оказалось слишком мало попробуйте убрать часть ключевых слов;
7. Если вы получили слишком много результатов попробуйте отфильтровать по авторам, где в качестве последних используйте ники сотрудников студии (Александр Петросян (PAF), Misha v.3, Luzhnikovskiy) или завсегдатаев форума из top-а «писателей»