Форум PHP

Порылся я в инете в поисках сабжа. Но что-то все какое-то было не такое... В итоге взялся сам. Приглашаю потестировать http://alna.spb.ru/forum2/ обо всех багах пишите прямо туда. После тестирования - выложу на растерзание:)
Там есть еще админка, но в ней слишком много всего разрешено, поэтому доступ туда пока прикрою.
Не реализован пока постраничный вывод... потому как лень, но я надеюсь с собой справится;)
Да, совсем забыл: в БД реализована возможность иерархического вывода сообщений (как на софттайме) и при коррекции из админки эта структура корректно изменяется. Но так как мне это было не нужно, то соответствующий фрагмент кода заблокирован.
В общем, смотрим, высказываемся:)

Отвечая на вопросы:
Регистрация с самого начала не задумывалась - это малопосещаемый ресурс.
Поиск происходит по теме и по тексту сообщения.
Защиту от инъекционных запросов сделал.
Постарничную навигацию - тоже. Вроде все?

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

Я же написал что она есть, просто там нет никакой защиты от некорректных запросов. Поэтому доступ к ней закрыт:)

Вроде все причесал немного. Выкладываю тут. Надеюсь, специалисты проверят на грубые косяки. А так - пользуйтесь кому надо:)

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

<textarea class=input  cols=96 rows=10 name=message><?php echo htmlspecialchars($message); ?></textarea>

Но подозреваю, что я где-то не там искал, так как у меня эта конструкция аналогичным образом не работает.
Как сделать правильно?

Тема быстро уйдёт, хотите мы выложим его в раздел downloads?

Я не против.
Единственное, что хотелось бы исправить, это файл редактирования в админке - сейчас приходится расставлять переносы строки вручную.
Собственно, я описал проблему в сообщении выше.

Давайте я посмотрю весь код в целом и переносы в админе и вечером отпишусь...

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

Нашёл ещё пару незначительных фич:
1) Имя автора

// Левин Александр aka Loki loki_angel@mail.ru

написано в не тэгов <?php ?> поэтому многократно появляется на страницах форума.
2) Много где стоит ссылка на include "../count/count.php", на отсутствие которого ругается форум.
3) Текст выводится чёрным по чёрному форуму - неудобно, приходится исправлять.

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

1) Согласен - лопухнул:( вставлял эту строку уже в запакованный архив перед самой отправкой.
2) Об этом тоже вспомнил уже отправив - надо хотябы закомментировать.
3) Издержки моего дизайна - удалив header.php - лишились всех стилей... В общем, тоже косяк:(
А что-либо более криминальное попалось?
И вышеуказанные пункты вы уже поправили, или у меня есть возможность реабилитироваться?:)

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

Из криминального :))), пожалуй вот, что - в reply_in.php вместо

<?php     $name = str_replace("'","'",$name);     $subject = str_replace("'","'",$subject);     $email = str_replace("'","'",$email);     $text = str_replace("'","'",$text); ?>

лучше использовать

<?php   if (!get_magic_quotes_gpc())   {     $name = mysql_escape_string($name);     $subject = mysql_escape_string($subject);     $email = mysql_escape_string($email);     $text = mysql_escape_string($text);   } ?>

Хотя конечно ничего криминального в первом варианте нет, но просто со вторым удобнее работать.

А чем ваш вариант правильнее/корректнее?

Внес необходимую правку, убрал почти все лишнее.
Хотел уточнить: ваша конструкция не убирает одинарные кавычки, а только отсекает текст после них. Это достаточно для целей защиты?
Осталось две просьбы: админка заточена под сохранение "древовидности" структуры БД. Просьба проверить корректно ли это работает.
И второе: если это не противоречит политике вашего сайта, то разместите пожалуйста в разделе downloads ссылку на рабочую версию форума http://alna.spb.ru/forum/, а то без оформления он получился такой страшный, что я бы сам на него не позарился:)

>Хотел уточнить: ваша конструкция не убирает одинарные кавычки, а только
>отсекает текст после них. Это достаточно для целей защиты?
Хм... вообще говоря странно - она должна экранировать кавычки на манер \'
>И второе:
Напишем, что это движок форума, а на его работу с наложенным дизайном можно посмотреть по ссылке http://alna.spb.ru/forum/, я примерно так и собирался сделать. Так как посетители любят попробовать, посмотреть перед тем как закачивать Web-приложение.

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

А какие версии MySQL и PHP используются.... странно у меня на локальной машине работает, на сервере не могу проверить - там включен режим "Magic quotes".

MySQL 3.23.49
PHP Version 4.1.2

Версия данного форума выложена в раздел downloads http://www.softtime.ru/info/forum.php - если вам не сложно проверьте текст описание на предмент неточностей и очепяток.

>неточностей и очепяток
1. Моя фамилия Левин
2. Переменная $num отвечает не только за количество тем на странице, но и за коничество сообщений при просмотре темы.
3. Хотелось бы пояснить что структура БД именнт подобный вид, потому что форум потенциально поддерживает древовидрую структуру (необходимый фрагмент кода закомментирован в админке.

Попровил - посмотрите, так нормально или следует ещё что-то добавить?

http://www.softtime.ru/info/forum.php

Все нормально, только стилистически первые два предложения неплохо бы подправить:)
Уже нашел два косяка:
при удалении последнего сообщения в ветке не обновлялся последний ответивший в списке тем. Это мелочь - я поправил.
А вот по второй ошибке прошу совета:
В файле index.php за формирование списка тем отвечает запрос:

SELECT subject, name, count( theme_id ) AS reps, theme_id, last_date, last_user FROM board001 WHERE 1 GROUP BY theme_id order by last_date DESC

Я с самого начала был уверен что в нем ошибка, но он исправно работал:)
Наконец, ошибка вылезла: если в базу первое сообщение темы занесено раньше чем ответ на него (по порядку), то все работает нормально - это логичное состояние. У меня так получилось, что ответ следует перед головным сообщением. Тут получается ерунда:(
Можно ли корректно составить этот запрос? Или лучше его разделить на 2 запроса - для определения количества постов в теме и для определения всего остального?

Есть еще вариант: при операции с сообщениями из админки давать базе команду

ALTER TABLE 'board001' ORDER BY 'm_id'

Что скажете?

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

Не раньше, а на свободное место... видимо, это как-то связано с местами освобождающимися после удаления записей.

Есть! Вывел алгоритм:
1. делаем ответ в теме
2. создаем новую тему
3. удаляем ответ сделаный в п1
4 отвечаем в тему из п2
В итоге имеем ответ на тему из п2, который в базе следует раньше нее самой.
Если упорядочить базу - будет нормально, но я не знаю сколько это требует ресурсов и будет ли это грамотно делать после каждого удаления.

Если честно с налёту у меня разобраться не получилось, всё-таки рекурсия достаточно сложно-читаемая штука, не могли бы вы описать назначения полей в таблице?

m_id - автоинкрементное поле. идентификатор записи
r_id - ссылка на родительскую запись
theme_id - идентификатор темы. Присваивается значение m_id первого сообщения.
name - имя пользователя
subject - тема сообщения (присутствует только у поля где m_id=theme_id)
msg - текст сообщения
email - понятно
m_date - дата сообщения
last_date дата последнего ответа (присутствует только у поля где m_id=theme_id)
last_user автор последнего ответа (присутствует только у поля где m_id=theme_id)

При создании новой темы theme_id присваивается значение m_id.
При добавлении сообщения, last_user и last_date первого сообщения в теме присваивается значения name и m_date последнего ответа.
При удалении записи r_id следующих по иерархии сообщениями присвамивается значение r_id удаляемого значения. А last_user и last_date присваивается значения name и m_date самого старого сообщения в теме (определяется по theme_id).

Выкладываю файл del.php из админки с необходимыми затычками. Все работает, но вопросы заданные ранее не снимаются:)

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

Врядли я до конца понял вашу мысль, но попробую переделать - неплохая будет практика.
Как человек не доверяющий авторитеатм (до сих пор не могу забыть как прокололся послушав вас про модернизацию таблицы ip в счетчике:), постараюсь подойти к вопросу критически. У меня перед глазами таблицы liteforum. Меня интересуют две таблицы: posts и themes.
На мой взгляд, таблица themes излишне дублирует таблицу posts:
author и id_author - не нужны, так как автор первого сообщения и есть искомый, а к таблице posts все равно надо делать запрос чтобы определить автора последного сообщения.
hide - на мой взгляд не нужна, так как сокрытие первого сообщения и должно быть сокрытием темы (но это спорный вопрос)
time - вообще не понял где используется.
Прокомментируйте пожалуйста цели создания этих строк, пока я снова не пошел своим путем:)

Дублирование вызвано вот чем: скорость. Нужно было всеми средствами избежать многотабличного запроса (выборки из posts и themes) при формировании списка тем и дерева ответов. Ведь если оставить в themes и authors только первичный ключ id_author (из таблицы authors), нам придётся каждый раз формировать двухтабличные запросы, а они всегда медленнее однотабличных.

PS Авторитетов следует слушать всегда очень осторожно :))) они бывают спать хотят, да и вообще у них перед глазами только кусочек задачи, а не вся картина в целом. В такой ситуации человек домысливает собирая из сознания свои текущие задачи...

Я поэтому и задал вопрос. Ведь многотабличного запроса вам в этом случае избежать не удается (чтобы узнать автора и дату последнего ответа надо обращаться к таблице posts).
Кроме того, вы так и не объяснили для чего используется дата создания темы?

cheops, вы развеете мои тягостные сомнения или предпочтете оставить меня в счастливом неведеньи?:)

>Я поэтому и задал вопрос. Ведь многотабличного запроса вам в
>этом случае избежать не удается (чтобы узнать автора и дату
>последнего ответа надо обращаться к таблице posts).
А нет, это тоже дублируется - в таблице themes (темы) имеется поле для автора темы и последнего ответившего посетителя - это поле обновляется при каждом ответе.
>Кроме того, вы так и не объяснили для чего используется дата
>создания темы?
Эта дата обновляется при каждом ответе. Т.е. в этом поле хранится дата последнего изменения темы, и оно используется при сортировке. Это позволяет активным темам оставаться "на плаву". Вот как этой, не смотря на то, что она начата в прошлом месяце, постоянное обновление поля даты приводит к тому, что она всё-время на первой странице :)

>А нет, это тоже дублируется - в таблице themes (темы) имеется поле для автора >темы и последнего ответившего посетителя - это поле обновляется при каждом >ответе.
Хе... Дублируется только id автора, а чтобы узнать его имя все равно надо вызывать таблицу authors, так что неправда ваша:)
Но тем не менее, спасибо за разъяснения, а то я в очередной раз собирался "упростить":)

Возможно у вас под рукой старый вариант таблицы, вот таблица themes, которая сейчас используется на форуме

CREATE TABLE themes (   id_theme int(11) NOT NULL auto_increment,   name tinytext NOT NULL,   author tinytext NOT NULL,   id_author int(6) NOT NULL default '0',   last_author tinytext NOT NULL,   id_last_author int(6) NOT NULL default '0',   hide enum('show','hide','lock') NOT NULL default 'show',   time datetime NOT NULL default '0000-00-00 00:00:00',   id_forum int(2) NOT NULL default '0',   PRIMARY KEY  (id_theme),   FULLTEXT KEY search (name,author) ) TYPE=MyISAM;

Автор темы хранится в author, а последний ответивший в last_author, соотвествующих первичные ключи тоже дублируются, так как они нужны для ссылок.

Действительно старая...
Хотя версия у меня последняя (2.1.4), но файл forum.sql создает такую таблицу:

CREATE TABLE themes (   id_theme int(11) NOT NULL auto_increment,   name tinytext NOT NULL,   author tinytext NOT NULL,   id_author int(6) NOT NULL default '0',   hide enum('show','hide','lock') NOT NULL default 'show',   time datetime NOT NULL default '0000-00-00 00:00:00',   id_forum int(2) NOT NULL default '0',   PRIMARY KEY  (id_theme),   FULLTEXT KEY search (name,author) ) TYPE=MyISAM;

Проверьте что у вас выложено в архиве...
Тото у нас какой-то странный диалог получался:))

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

Переехал сюда
http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=3603&page=1