Это нормально, видено мной на форуме Ru-Board. А вот с какой-либо страницы можно перейти только на одну-две соседние - действительно неудобно а если нужно к примеру попасть на страницу 50 сразу то листать 25 страниц придется, а зачем?
yura3d
Можно ли внизу при большом количестве страниц (>15) количество переходных ссылок на ответы темы как-то добавить, шагать например с шагом по 10?

Так подобная стыковка нескольких файлов темы в рамках одной темы была реализована в более ранних версиях (по крайней мере, в ExBB 1.9.1 и первых сборках ExBB Full Mods), только вот работало это не очень. Сложность заключается не столько в обеспечении визуального единства одной темы в нескольких файлах, сколько в обработке таких тем. Чтобы не описывать всё долго, приведу пример. Предположим, Вы удаляете (перемещаете) тему, в которой много ответов (как Вы потом предложили, 500 страниц). Пиковый расход ресурсов (как следствие, увеличение нагрузки на сервер) и пиковое снижение скорости работы форума увеличится примерно в n раз, где n - кол-во файлов, из которых состоит тема (в текущей реализации, не допускающей деления тем на файлы, n = 1). Но помимо расхода на удаление (перемещение) файлов темы, который по сути не такой большой, есть также дополнительные расходы, такие как обновление профилей пользователей, оставлявших в удаляемой (перемещаемой) теме сообщения. Если тема удаляется, то из информации статистики сообщений пользователя (которая есть в файле профиля каждого пользователя) нужно вычесть число сообщений, которые пользователь оставил в удаляемой теме (соответственно обновляется и счётчик сообщений пользователя, значение которого также хранится в файлах профилей пользователей). Если тема перемещается, то также обновляется статистика сообщений пользователя (для исходного раздела, из которого перемещается тема, и конечного раздела, в который перемещается тема). Подобное обновление профилей "на лету" - довольно ресурсоёмкая задача, нагрузка на удаление/перемещение темы (с учётом уже имеющегося n) возрастает ещё в приблизительно m раз, где m - кол-во пользователей, отвечавших в тему, причём отношение m/n лежит в пределе приблизительно от 1,5 до 3. Снижение же нагрузки методом разбиения темы на файлы (при сохранении единства представления темы, как Вы предлагаете) можно получить только для случая просмотра темы, либо при обработке темы частями. Последний метод наиболее универсальный, но его применение не удобно и не всегда практически реализуемо в рамках единого представления, поэтому и было принято решение разделять большие темы на части

Используемый вариант разбития тем на части мне нравится и как концепция, форум по сути сам себя архивирует, закрывая старые дискуссии и открывая их продолжения. На многих крупных форумах (например, onliner.by или приведённый выше ru-board.com) подобная практика широко распространена, только там разделения выполняются администраторами/модераторами вручную, у нас же это сделано автоматически

Многие форумные движки (яркий пример - IPB) чтобы снижать и без того сильную с их стороны нагрузку на сервер, при удалении тем не обновляют счётчики сообщений у пользователей, отвечавших в удаляемые темы, т.е. обновление информации профиля "на лету" невозможно (подобный вопрос обсуждался здесь). Для актуализации информации там применяется метод полного пересчёта сообщений пользователей, но пиковая нагрузка этого метода (равно как и частая необходимость его применения) также далеко не лучший вариант

yura3d
О переносах я не подумал.
Тогда да, это единственное решение....

Хотя... есть ещё один вариант - делать для каждого поста отдельный файл.
Тогда нагрузка на сервер будет вообще маленькая, впринципе такая же как при работе с таблицами в БД.

И при этом варианте темы можно не делить и они могут быть сколь угодно большими.
Что думаешь?

Может стоит поменять структуру размещения тем в категориях.
То есть, чтобы до данной темы
http://exbb.info/community/topic...um=3&topic=2
нужно было добираться не через параметры forum и topic, а только topic.
А в базе данных или где помечать, что эта тема принадлежит какой-то категории. Сделать нумерацию тем не в пределах каждой категории, а в пределах всего форума.
Так будет удобно, если оставлены где-то ссылки на тему, а она перенесена в другой раздел.

В БД применяется иной принцип, принцип потокового хранения данных, поэтому для извлечения какой-то части информации из одной таблицы (каждая таблица в БД - файл) достаточно знать только расположение этой информации и занимаемый её объём. Первое достигается за счёт использования индексов, второе задаётся на этапе создания таблицы. В результате мы можем читать из файла только те данные которые необходимы, а не считывать всё подряд и потом заниматься выборкой

Вариант с хранением каждого сообщения в отдельном файле также неприемлем из-за особенностей работы с файлами. На операции открытия, закрытия, блокировки и прочие служебные операции с файлами также тратится часть ресурсов, и чем больше число файлов, с которыми мы работаем, тем больше ресурсов тратится на эти служебные операции. В то же время при работе с одним файлом темы ресурсы на его открытие, закрытие и прочие служебные операции расходуются лишь единожды, соответственно нагрузка на сервер меньше, скорость работы выше. За примером далеко ходить не нужно, выше Вы приводили пример темы с 500 страницами, предположим, на каждой странице распологается 10 сообщений, итого 5000 файлов. Теперь представьте себе нагрузку, которая будет идти при попытке поиска по такой теме, ведь нужно за отведённые 30 секунд пересмотреть 5000 файлов со служебными расходами на их обработку. В итоге Вы прочитаете всё тот же объём данных, который был бы и при размещении всех сообщений в одном файле (!!!), но при этом потратите немалую часть ресурсов на служебные операции с файлами. Ситуация ещё более осложниться, если сообщения содержат большие по объёму тексты. Или ещё более сложный пример - индексирование поиска. Предположим, у Вас в каком-то разделе находится, допустим, 3 темы из 500 страниц, итого для индексации этих тем индексирующий скрипт должен проанализировать немного-немало 15000 файлов, ни один хостер такого изврата не поймёт

Кстати, вышесказанное в этом и предыдущем моих сообщениях в разной степени справедливо и по отношению к движкам на MySQL



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

Можно открывть только 10, которые составляют одну страницу.
Нет смысла открывать 5000 файлов, но только 10, что довольно мало, согласись.
А вот по поводу поиска могу подкинуть ещё идейку
Нужно делать поиск в кешированных СТРАНИЦАХ, тогда будет всё великолепно.

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

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


Скажите, а сколько лет Вы работаете с PHP на уровне программиста и какие у Вас есть готовые проекты? Просто закрадываются определённые сомнения. Скорость обработки файлов интерпретатором PHP приблизительно обратно пропорциональна квадрату их объёма (для нашего случая). Кешированные СТРАНИЦЫ будут занимать в любом случае объём больший, чем исходные текстовые данные, особенно заранее подготовленные для поисковой индексации (с вырезанием коротких слов, смайлов, бб-кодов, тегов и прочей лишней для поиска информации). Где же тут "будет всё великолепно"? Также не будет лишним отметить, что хранить кеш имеет смысл только для актуальных (посещаемых) тем, а не для всех подряд, ведь не имеет смысла увеличивать скорость открытия тем, которые редко просматриваются (если вообще просматриваются), т.к. объём занимаемого дискового пространства таким кешем может быть колоссальным (полный кеш всех тем - это же как минимум двукратное увеличение занимаемого пространства, и не забывайте, что кешем тоже нужно время от времени управлять - обновлять, чистить и т.п. - на это тоже затрачиваются ресурсы)


Проверяйте свои предложения, создайте небольшой скрипт, имитирующий простейший форум, и примените различные варианты хранения информации. Во время работы замеряйте время выполнения скрипта, нагрузку на ЦП, использование ОЗУ. Результаты измерений выкладывайте здесь. Я не пожалел времени и проверил подобные характеристики для различных методов обработки данных, в результате выбрал наиболее производительный и с наименьшими (как мне и многим другим пользователям ExBB кажется) последствиями для функциональности форума. А так, не приводя никаких технических аргументов в пользу того или иного метода хранения данных ("по-моему", "а вдруг", "мне кажется", "не знаю почему" и т.п.) - всё это не более чем слова


Пусть здесь отпишутся те, кто считает, что темы выглядят не по-человечески. Смысл фразы "никто даже незаподозрит что форум на файлах" мне вообще не понятен. Я не вижу никакой разницы между форумом на БД и форумом на файлах, за исключением метода хранения данных. Есть определённые ограничения, накладываемые различными методами хранения данных, но они есть как в случае с файлами, так и в случае с СУБД. И Ваша задача состоит в том, чтобы взвесить все плюсы и минусы и выбрать то, что наиболее подходит Вам

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

Про меня никаких сомнений нет, я ламер.
Искал через поиск, не нашёл.
Версия форума, такая же как тут. Не могу сделать так что бы картинка отображалась в теме. Фотография какая-нибудь или просто картинка. Сделал всё что мог - появилась строка в сообщении "Скачать файл".
Можно ли, что бы картинку помещать в посте? В прошлой версии с этим у меня проблем не было : ) а, тут, что-то не дойду никак.
Извините ...
ps. везде всё разрешил, размер загружаемого файла 40кБ поставил. в темах разрешил.
Извините, ещё раз ...

Попробую тут ...
(Добавление)
.. вот, тут у вас хорошо ... : ) Смотрю админку, не найду никак, где что подправить.
(Добавление)
Всё, я нашёл, извините ... Это в "Безопасность" надо было указать типы расширения файлов для загрузке. Не кидайтесь в меня.
Извините ...

вопрос такого характера...:

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

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

новый адрес форума ввел в файл data/boardinfo.php ??? так же проверь права на папки из пункта Q3 из FAQ форума

права выставлены, адрес изменен был сразу...не помогает

При авторизации на форуме (не в админке) проблем с учётными записями этих же администраторов не возникает? Если проблема до сих пор не решена, скиньте мне в личку данные для FTP соединения с проблемным форумом, как будет свободное время, посмотрю

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

Вопрос другой:

У себя на локалке добавил на форум очень много смайликов...Какие файлы вместе со смайлами перенести на другой форум, чтобы смайлики были в том виде, в котором они сейчас на локалке...?
Заранее благодарен!

LordShad0W
data/smiles.php