Настройки поиска (Страница 1 из 183)

Конечно есть! Человек начнет искать инфу по хостеру, зайдет в тему через поисковик, а тут вон что оказывается! Все ходы записаны!

Добавлено спустя 3 минуты 25 секунд:

Можно сделать отдельный подфорум "Сомнительные хостеры" и туда их.
А так в принципе мне всё равно, что там, что здесь, после наших комментариев в здравом уме никто не рискнет связать свою судьбу с подобными коммерческими предложениями.

в хуке, имя которого можно узнать в строке ошибки

Цены раза в 2 выше, чем если арендовать сервер напрямую у хостера.
Пользовательского соглашения нету, договора нету, контактов нету. Что за контора? А пёс его знает, вчера из ниоткуда возникла.

Нужно нажать ссылку "Отметить как важную", которая находится внизу темы.
Скриншот сделать или сам осилишь?

Зачем изобретать велосипед, нам бы хватило задорухотябы  репозиторий расширений сделать.

Я доредактировал уже кем-то отредактированное, мне спасибо только за ссылку и картинки.

значит пора сделать то что мы задумали

Можно на  js сделать - добавить слушателя события onClick на объекте .main-content .item-subject на странице index.php, в слушателе парсить ссылку из объекта и открывать ее используя например document.location = "распарсенная ссылка". Чтобы при наведении мышью на ячейку подсвечивалась вся ячейка и менялся курсор на hand, просто добавить соответсвующие стили для  объекта .main-content .main-item, можно при инициализации js, чтобы работало только у тех у кого включен js в браузере.

Форум так и пишет - "Выдаю ошибку"? Папка должна называться f_post

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

Вот именно, разные версии штампуются с целью продать премиум. Нам достаточно одну версию поддерживать в нормальном рабочем цикле. К тому же это GNU\GPL, а премиум пользователь может сделать себе сам, установив расширения, в том числе и платные. Впрочем если есть желающие заниматься премиумом версией, то они наверно могут даже получить поддержку информера, вдруг получится хороший бизнес.

Он с 2008 года все умирает и никак не умрет ))

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

Борьба со спамом не относится к вопросам безопасности.
Технологии обхода защиты от спама динамичны, вчера была эффективна капча, сегодня мозаика и смс, завтра будет цифровая подпись и отпечаток пальца. Как эти меняющиеся тенденции может учитывать ядро? Да никак. Оно может быть запрограммировано бороться со спамом при помощи капчи, а через пол-года условно говоря этот код можно будет выкинуть, т.к. он просто потребляет ресурсы и не справляется с задачей. Ядро должно предоставить механизм изменения своего поведения, вот правильный путь, который однажды был избран еще командой во главе с Рикардом, и эту точку зрения пока еще никто аргументированно не опроверг. И кстати fluxbb, тоже не спешит обрастать жиром за счет функциональности способной прекрасно жить в отдельных пакетах именуемых "расширениями".
Вот примеры другого ПО - Firefox, Eclipse.

Я сначала подумал, что речь о какойто другой загрузке. Вопрос скорости загрузки страниц PunBB на даннный момент на мой взгляд не требует к себе внимания, т.к. скорость приемлема. Разницей между 0,05 и 0,1 можно пренебречь, особенно в условиях ограниченных ресурсов на разработку, когда лучше заняться чем-то более полезным. Тем не менее, если кто-то будет этим заниматься, проводить тестирование скорости, экспертное исследование кода, выявление "узких мест" и предлагать варианты решения, то это нельзя не приветствовать, я был бы например рад, если бы кто-то этим занимался хотя бы эпизодически.

Вот это настолько бесполезный функционал, что я буду всегда выступать против. Ну чем оно в пакете хуже чем в ядре? Гораздо полезнее половая и возрастная дифференциация пользователей, и здесь я сторонник включения в ядро.

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

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