Хочется пожелать хороший поиск, странно, что его в списке нет

и вывод последних комментов... например, как категории, и это не должен быть плагин, т.к. вещь необходимая для всех; думаю, объяснять не надо почему
вот... лети лети лепесток.....

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

Лёха zloy и красивый, привет,  нашел, что есть возможность журналюге публиковать в неоткрытую ему категорию, эта дырка еще с кюте а-ля 2.5... может и раньше вроде есть... Вобщем это при  груповом перемещении новости в категории, там нет проверки "на вшивость", кстати я б тебе советовал переписать твой category_get_tree();, с возможностью указывания $usergroups или $member

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

Немного запоздал, но всетаки...
Можно добавить:
<div align="left"></div> - такое же по центру, справа и по ширине

Еще на мой взгляд было бы удобнее если такие теги добавлялись как BB коды, т.е. [left]текст[/left] [right]текст[/right], также добавить [red]красный[/red], [blue]синий[/blue], [green]зеленый[/green] некоторые основные цвета, по средствам <font color="red"></font> и т.д. Такое же для величины шрифта. Еще эти теги можно выделить относительно остального редактируемого текста. Можно сделать УРЛ и мыло по запросу сценария, т.е. при нажатии на кнопку УРЛ, выводиться форма в которой спрашивается сам УРЛ и текст ссылки, а потом все автоматом добавляется в тег. Это конечно ламерский вариант, но нужно помнить что не все люди знают HTML и в курсе куда вставить УРЛ, а куда текст ссылки, тоже касательно мыла.
ИМХО
Смысл в BB кодах через панель быстрых тегов есть, ведь HTML текст можно сократить при редактировании и добавлении новости, тем самым повысить удобство и отойти от использования WYSYWIG редакторов, хотя последние в ряде случаев не заменимы.

Предлагаю в таблицу с пользователями добавить ячейку онлайн/офлайн

cannaba, по-моему, эта функция уже давно присудствует в скрипте...

Было бы не плохо добавить суперадмина, а простым админам запретить изменять настройки системы

Dimon, я хочу тебя забанить.

muhas, в inc/mod/login и logout.mdu правь и будет тебе перекидывать куда нужно. У logout:

header('Location: '.$PHP_SELF);

у login:

<form action="<?=$PHP_SELF; ?>" method="get">

Замени $PHP_SELF на то, что нужно и всё.

upd можно ставить ссылку на пост, например в этом треде посмотри пост #64, слева есть "12 Jun 2006 19:59:46", тыкни на это и получишь пермалинк поста.

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

RocketeeR, я понял идею, хорошая идея, но проблемная.

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

Недавно выяснил что скрипт не использует метод архивации как в cutephp, что делает его с бОльшим ограничением для использования с текстовой базой. Посчитал что в моем случае через 14..15 месяцев файл store.MYD будет иметь больше 10 метров. В таком случае могут быть проблемы на сервере и скорость замедляется (также на некоторых хостингах имеются ограничения по максимальному объему файлов). Будет очень досадно удалять старые новости (особенно страницы которые получили в течение года хорошую релевантность и трафик из поисковиков), если не имеется проблемы с объемом хостинга. Нужно было унаследовать этот важный момент, т.к. даже работа скрипта при использовании MySQL с обьемом 20..50 метров, будет хуже чем на текстовой базе с маленьким файлом активных новостей (store.MYD) и множество архивных (помесячных) файлов, которые создаются автоматически как делается в cutephp. Такой метод делает скрипт практически с неограниченными возможностями и постоянной (стабильной скоростью). Также есть подводные камни для MySQL - на некоторых хостингах это имеет ограниченный объем, поэтому предпочитаю текстовые базы по методу cutephp.

Отредактировано SS (13 Jul 2006 21:21:46)