Forum Webscript.Ru
Наши скрипты => Sanitarium WebLoG => Тема начата: Green Kakadu от 13 Марта 2004, 00:10:39
-
В общем ;) Sanitarium 2 SQL ver стартанулся. Все что было в Sanitarium + что-то еще... Что бы вы хотели увидеть в качестве этого дополнительного "что-то"? :super:
-
php версию
-
Во первых - спасибо за уже существующий движок - очень полезная вещь получилась
В следующих версиях хотелось бы видеть:
- Возможность влиять на порядок категорий в меню (сейчас приходится создавать меню ручками если нужно переставить категории местами)
- Сортировка статей в категории по алфавиту, дате, и т.д. с возможностью выбора параметров сортировки
- Многопользовательность - доступ к наполнению категорий на уровне авторов
-
И ещё
Чтобы одной кнопочкой все внутренности (база) сбрасывались в 1 абсолютно переносимый файл.
И другой кнопочкой всё из него доставалюсь обратно.
И тоже самое - из командной строки.
-
Спасибо за классный движок.
Green Kakadu, А когда ждать второй версии? Хотя бы приблизительно?
И еще нужен будет конвертор баз для перехода с 1 версии на вторую...
-
Green, здравствуйте. С возвращением Вас!
Да, программа хорошая уже тем, что очень гибкая система шаблонов.
А пожелания, кроме тех, что описал Belotelov:
1. сортировка по имени списка авторов в выпадающем меню на странице добавления статьи администратором admin.cgi?new_article=1 (если авторов больше, чем 15-20 - глаза сломаешь, пока найдешь нужного)
2. возможность сортировки категорий по выбору (по имени, времени добавления) на странице редактирования категорий admin.cgi?view_category=1
3. функция подключения-отключения оценки статьи в комментариях, т.е. рейтинг (одна звездочка, две звездочки, а лучше три звездочки... :) )
4. Страница, которая бы генерировалась скриптом при отрицательном результате поиска по сайту, на которой бы выводилась осмысленная информация, а не вроде "Нет соответствия Вашему запросу. Пожалуйста, измените условия и попробуйте снова."
5. Пусть в шаблон комментария можно будет делать php включения. А то приходится для него делать отдельные включаемые txt файлы. Это не страшно при двух-трех шаблонах. А если их порядка тридцати, то это вызывает некоторые неудобства :)
6. И вроде последнее, но едва ли не самое главное - можно ли сделать многоуровневые вкладываемые категории для статей? Но не заданные жестко, скажем - 3 уровня, а чтобы администратор мог сам создавать уровней подкатегорий столько, сколько ему нужно - 2, 3 или 6. Хотя 6 - это просто для примера, вряд ли кто-нибудь рискнет мучать посетителей своего сайта таким количеством переходов.
Если будет реализована такая гибкая система вкладываемых подкатегорий (подразделов), то не нужно будет делать шаблоны, которые сейчас играют роль разделов, включающих в себя несколько вкладываемых подразделов.
Вот вроде бы и все.
И конечно - спасибо.
-
Ещё хорошо бы при публикации статьи иметь возможность указать несколько авторов из списка.
-
AliMamed
А кто сказал, что он на Perl?
-
Да, но и никто не говорил, что он на php ;)
-
Судя по его письму мне всё таки на Perl :)
-
Да, совсем забыл, еще если можно - отсортировать на странице добавления статьи (/admin.cgi?new_article=1) названия категорий в выпадающем списке по наименованию. А то тоже, пока найдешь что нужно... можно устать :)
-
Green Kakadu
C Возвращением!
...А еще хотелось бы удалить пару-тройку сотен :) старых статей... по одной это делать долго и неудобно. А так или в списке статей поставить галки или в поле ввода ввести id с 0 по 100 и Delete.
Что-то ведь еще хотел...ладно, вспомню - напишу. А так еще раз спасибо за Sanitarium.
-
А еще, а еще... вот, чтобы... чтобы... :) возле ссылки "Ваши комментарии" (или кто как это называет), ведущую на страницу комментариев, отображалось бы количество уже существующих комментариев. Чтобы посетители могли понять, что там уже что-то есть и могли зайти просто почитать эти самые комментарии.
И автоматическое добавление новой статьи в поисковый индекс.
Вот.
-
и тишина...
Green Kakadu, можно узнать на ккакой стадии написание скрипта, простот не терпится посмотреть на сие чудо
-
С возвращением!!!!!!
Очень рад, что Sanitarium будет продолжать свою жизнь и в новой версии хотелось бы видеть, то, чего так не доставало эти два года, а именно
Хорошо, чтобы была возможность выводить для каждой категории определённое (своё) кол-во новостей
Как уже говорилось выше - да будет многопользовательский режим!!!
Рейтинг статей по числу просмотров, голосов отданых за них, кол-ву комментариев. И возможность вывода рейтинга статей по категориям и общего рейтинга с возможностью изменять число статей выводимых в рейтинге для каждой категории
Вывод календаря как в MP.
Возможность вывода в превью кол-ва комментариев для данной статьи, числа просмотров, числа голосов и рейтинг статьи.
-
ура создателю!
САМОЕ главное это возможность вставлять УДОБНО картинки в контент с возможностью превью и увеличения!
-
Ах, да! Ещё хорошо бы определять размер новостей и превью в количестве символов!
-
Green Kakadu
Привет!
Посмотри на это сообщение:
http://forums.webscript.ru/showthread.php?s=&postid=107551#post107551
может календарь во вторую версию интегрировать?
А по поводу изменений -- неплохо бы сделать возможность вывода определённого количества заголовков новостей (а не только того количества, которое общее по умолчанию, скажем из одного раздела 10 заголовков, из другого 5 и т. д. -- а то пришлось отдельный хак для индексной страницы писать, чтоб сделать это на своём сайте)...
По поводу пожеланий — многопользовательский режим был бы очень кстати (админ + авторы, которым доступ только к своим статьям)...
-
ну да... Мелочь, но всё же.
Sanitarium 2 SQL ver
Было бы хорошо, если бы была возможность выбора типа базы данных (как в MovableType), т. е. MySQL, BerkeleyDB или вообще текстовая...
Хотя это уже не настолько важно, как возможность работы SQL-базой :)
-
Ещё вспомнилось:
очень неудобно, что директории категорий нельзя назвать по-своему, т. е. удобнее было бы при создании категории прописывать ей в настройках и название публичной директории, где будут храниться файлы страниц новостей этой категории и индексные страницы категории.
Кроме того, хорошо бы иметь возможность давать свои названия файлам новости (сейчас они называются id_#страницы.html),
наличие ID новости в названии файла удобно при поиске статей по теме, поэтому было бы замечательно, если бы ссылка на статью могла была быть в виде:
httр://site.com/название_категории/название_файла_статьи_ID_#страницы.html
Это было бы полезно для иностранных поисковиков, если сайт на английском, кроме того, такие прямые ссылки на категории лучше запоминаются
httр://site.com/sport/
httр://site.com/culture/
чем такие:
httр://site.com/12/
httр://site.com/23/
-
Хы, я еще не вернулся - вернусь летом (где-то в июле)
А процесс идет :) календарь будет. Появились мысли о создании архива, т.е. после определенного срока статьи из основного индекса будут попадать в архив. О подкатегориях думаю. Ваши пожелания по возможности посараюсь учесь.
-
Даешь возможность создания независимых страниц, алиасов к ним и статьям :)
-
Green Kakadu
А процесс идет календарь будет.
могу кинуть код, который мы на сайте используем (http://www.citynews.net.ua/)... Само собой, что работа с базой не пройдёт для SQL-версии, но, скажем, тот же вывод месяцев и т. п. вполне можно взять готовый...
Ещё проверка отправленных посетителем данных даты граничит с паранойей :), так что может пригодится что-то оттуда...
Отправить?
-
Еще неплохо было бы организовать отсылку сообщений на указанный(е) e-mail(ы) для организации рассылки. Есть самопальный код на perl, могу поделится.
-
Magi
Еще неплохо было бы организовать отсылку сообщений на указанный(е) e-mail(ы) для организации рассылки. Есть самопальный код на perl, могу поделится.
Там после каждой публикации отправляется или по Cron\'у через промежутки времени?
-
После публикации, для выбранных категорий(есть свой конфиг), с проверкой на дубли и теоретически с использованием шаблонов ( текстовые использую, html- не проверял).
-
Magi
Есть самопальный код на perl, могу поделится.
А можете выслать на prajapati{#}mail.ru ?
Заранее спасибо!
-
Прежде всего хочу поблагодарить за скрипт Sanitarium WebLoG. Уже пользуюсь им в течение 2 лет и нахожу его одним из самых удачных новостных скриптов. :)
В новой версии Sanitarium\'а хотелось бы иметь возможность добавления одной статьи в несколько категорий. Но, чтобы на индексной странице выводилось одно превью этой статьи. Например, у меня футбольный сайт. Когда игрок из команды А переходит в команду В, то правильным было бы добавление статьи в категории новостей команд А и В. В данной версии Sanitarium\'а это невозможно. :(
-
усовершенствовать панель администратора
-
при открытие кода статьи или шаблона для редактирование
в менеджере сайта добовляется каждый раз пустая строка между
кодом
в результате код становится нечетабельным после 5~ 7 просмотров, вытягивается
Это у меня такой глюк или это фича
Гость
-
Имеется два самых главных (для меня) пожелания:
1. Чтобы можно было добавлять короткие новости. То есть не появлялась ссылка "далее". В общем чтобы можно было писать только превью.
2. Безболезненный переход с первой версии на вторую.
-
Очень хотелось бы видеть встроенную несложную баннерку. Огромное спасибо за санитариум, реально нужная и удобная вещь... За исключением мелких деталей вроде неполной кастомизации разделов, отсутствия баннерки...
-
Уважаемый Kakadu!
У меня есть еще одно пожелание. Можно ли сделать так, чтобы можно было бы менять дату. Мне часто приходится выкладывать статьи задним числом, а потом заходить FAR-ом в *.dat файлы и там ручками менять дату. Это не совсем удобно. И чтобы после изменения или добавления даты была возможность отсортировать по дате.
Спасибо!
-
Крутой скрипт!!!
-
Еще было бы неплохо при выборе *pасширение генерируемых статичных страниц*, например, $ext=\'php\', переменные передавались не через спецтеги типа <%peremennaya%>, а в виде удобнопереваривариумом php. Например, $peremennaya.:-)
-
Например, $peremennaya.:-)
а смысл? Ведь <%peremennay%> все равно заменяется значением этой переменной.. если нужно передать какие-то параметры php, то проще организовать что-то типа массива на php-шаблоне и туда кидать все эти переменные
Насчет того что будет.. уже скрипт на n% готов :) и с шаблонами там будет дело обстоять так:
- добавлена логика типа <%IF_параметр%><%ELSE%>
- обработка шаблонов стала намного быстрее
- шаблонов станет намного больше
P.S. большая часть пожеланий, которые тут были учтены (и в процессе реализации). Правда теперь понадобится mysql :) но с др. стороны - это будет скрипт для создания серьезного сми, с оч. большими воз-тями по настройке и высокой производительностью.
... и тут Остапа понесло. ладно. когда будет готово - все сами увидите. О лицензии. Будет GPL - 100% тут мы с NASом определились окончательно.
-
Green, боьшое Вам спасибо. Программа действительно классная. Я раньше отдавал предпочтение PostNuke, но сейчас вижу, что удобнее Вашей CMS - до сих пор не встречал.
Мой многолетний опыт говорит о том, что встроенные в программу CMS форумы, фотогаллереи, магазины и подобные серьезные программы ожидаемого результата не приносят - для таких задач нужно использовать специальные скрипты (конечно, если проект серьезный).
А санитариум удобен именно своим минимальным набором необходимых функций, но которые работают и работают качественно (ну, о функции поиска я не говорю :) ). При этом очень гибкая система шаблонов, которая может устроить любые требования дизайнеров или его начальство :)
А если программа еще заработает и на MySQL - это вообще супер.
Вобщем, еще и еще раз Вам спасибо, и дай Вам Бог здоровья :)
-
Магазинов, форумов, галерей не будет.
Будет воз-ть создавать неограниченное число вложенных категорий, архив, календарь. Из наворотов: Создание собственных "схем" документов (здание тех полей которые нужны вам) - это пожалуй основное.
+ Стараюсь сунуть нормальный файловый менеджер и по-воз-ти сделать систему плугабельной и конечно оч.хороший руссифицированный поиск.
о сроках выхода определенно не скажу ибо сейчас :) пытаюсь устроится наработу, а там как пойдет. Если не хотите ничего пропустить - то либо подпишитесь на рассылку новости вебскрипта либо почаще заглядывайте.
P.S. Переход со старого санитара будет конечно же.
-
а смысл? Ведь <%peremennay%> все равно заменяется значением этой переменной.. если нужно передать какие-то параметры php, то проще организовать что-то типа массива на php-шаблоне и туда кидать все эти переменные
В принципе если основной шаблон сайта висит на Санитариуме, то проблем нет. А вот если шаблон уже есть и хочешь посадить на него Санитариум, то у меня возникли маленькие проблемки. Если передавать переменные в удобном для php виде, то достаточно в шаблон добавить строчку include("/home/.../sitemaket.php"). Я, например, год назад пытался подогнать Санитариум под шаблон своего портала, но у меня так ничего и не получилось.:-( Index\'сный файл с горем пополам подогнал, а вот article ну никак не хотел идти. Все закончилось тем, что сдублировал шаблоны в Санитариум и заменил php-переменные на спецтеги. Хотя возможно мой уровень знаний в php не так хорош и проблему можно было бы решить проще.:-)
-
Приветствую :)
Оченно интересный скрипт. Сам пользуюсь похожим, но неподдерживаемым: товарищ писал, но бросил. Устарела давно...
Искал возможности формирования страницы с собственной схемой, - нашел в планах. Это просто замечательно :))) имеющаяся у меня система именно так и работает.
Чего бы хотелось?
- возможность ручного именования страниц
- возможность генерации страницы как "индексной" ("главной", в которую зашиты все прочие оглавления и ссылки)
- настройки сортировки категорий
- по умолчанию - интерпретация пустиой строки как абзаца, и оформление каждого абзаца одной "формы" специфическим тэгом (например, задаваемом в шаблоне) - это позволит гибко форматировать сложные страницы
- управлять полями, выводящимися в индексные файлы.
- иметь несколько (в идеале - задаваемое пользователем количество) "индексов" для категории, с индивидуальными настройками правил сортировкии сообщений, количества записей, наличием-остутствием ссылки "листания" для каждого из них. Может быть - с возможностью. ручного изменения порядка следования статей. (кроме прочего, таким макаорм мложно организовывать выносимые анонсы, архивы и прочие подобные штуки)
- отдельный тэг для вставки иллюстраций. Закачку иллюстраций через форму при создании страницы. Идеальный вариант - два тэга картинок, при этом один выводит выпадающий список загруженных "стандартных" картинок (например, из указанной для категории системной директории), другой - список картинок, загруженных юзером через форму для данной страницы.
- тэг для "прочих файлов" с закачкой файлов через форму (см. про картинки).
- индивидуальные настройки для категорий по максимальному сроку жизни статьи или количеству статей, после чего старые автоматически удаляются.
Ещё - хорошо бы систему юзеров с разделением прав. Права - на добавление статей - публикацию - правку, и - на доступ к определенным разделам.
Если что - пишите alex @ minsk2000 . to (простите за лишние пробелы, защищаюсь). Надеюсь, понятно излагаю. Мысли навеяны долгтм пользованием похожей системы, могу расшифровать подробнее, мотивировать, кстати - поделиться исходниками того, что есть в руках. Там может быть что-то интересное (сам не программист, аднака...)
-
2Alex-Minskij весьма интересно :) навеяли неск. новых мыслей.
-
Очень нужен счетчик количества просмотров, и возможность посетителям поставить оценку статьи, и вывод средней лценки....
-
Гость:
Очень нужен счетчик количества просмотров
такую ИМХО не очень нужную вещь всегда можно прикрутить отдельно, даже на имеющийся сейчас санитар.
-
По этому счетчику можно было бы выводить список самых читаемых статей. Тоже не помешала бы ф-я "Последние комментарии"...
-
По этому счетчику можно было бы выводить список самых читаемых статей.
это я понял. просто этот счетчик - можно без проблем подключить даже сейчас к обычному санитару, было бы желание :) это почти никак не связанная с движком вещь, просто передавать скрипту-счетчику id статьи (через <%..%>) и все, а там он пусть что хочет считает и выводит. Главное желание это сделать и кое-какие навыки программирования на perl/php :)
-
Рассылка новостей есть вещь полезная!
-
Гость:
Рассылка новостей есть вещь полезная!
не спорю, только какое отношение она имеет к CMS? прямого никакого :)
-
Green Kakadu
Уважаемый разработчик, а что если включить хороший редактор вроде htmlarea? Это было бы только преимуществом, особенно для неискушенных юзеров.
-
Я конечно не разработчик, но замечу, что визуальных редакторов в интернет хоть пруд пруди. Я, например, если есть необходимость, ставлю Typetool: http://vietdev.sourceforge.net/portal/html/index.php
И еще - Sanitarium пишет практически один человек. Причем пишет на собственном энтузиазме в свое свободное время, не имея из этого ничего, кроме некоторого портфолио для устройства на работу. Пожалуйста, учитывайте это при своих пожеланиях к программе. Всех наших желаний он выполнить не в состроянии. И это нормально.
Спасибо Green Kakadu уже за то, что есть и за то, что он посчитает нужным сделать.
Конечно, это только мое мнение.
-
ElWhite:
Причем пишет на собственном энтузиазме в свое свободное время, не имея из этого ничего, кроме некоторого портфолио для устройства на работу.
:) это да, кстати для устройство на работу мне санитар как-то и никак не помог :) сказалось присутствие на webscript.ru
Гость:
а что если включить хороший редактор вроде htmlarea?
я уже думаю об этом. И оно будет но учитывая структуру второй версии, где пользователь сам будет определять какой тип документов и с какими полями он будет постить + систему шаблонов для страниц администрирования у вас появится воз-ть встраивать на страницу постинга чего угодно.
ElWhite сказал прально, если нужно, то можно что-нибудь встроить в санитар и сейчас, код вывода редактирования статей в admin.cgi
-
одно добавление к теме визуальных редакторов:
лично меня javascript ни каким местом не привлекает, соотв. с дистрибутивом будет распространятся какой-нибудь готовый html редактор.. главная заковыка - лицензия. Нужно что-то чтобы не конфликтовало с GPL лицензией по которой будет распространятся новая версия. Если есть что посоветовать - кидайте сюда. Желательно:
- чтоб он был не оч.навороченный, и желательно без встроенных фреймов
- распространялся по GPL
-
На некоторых хостингах отключен SendMail если поставить модуль для отпавки писем через SMTP ?
я написал на пхп, а как его прикрутить к sanitariumu мне не посилам.
-
Green Kakadu
К концу января 2005 уже можно ждать 2-ой версии? =)
-
Гость!!!:
К концу января 2005 уже можно ждать 2-ой версии? =)
да, бета-версии.
Главное чтоб мое увлечение улучшательством не было чрезмерным, а то уже второй раз глобальную перестройку делаю :)
-
после опубликования статьи
все летит к чертям когда жмем на просмотр из панели админа (перед "Опубликовать статью! ")
много раз так было!!! как ща с такой темой ?
-
Движок классный, было бы еще класснее, если бы он поддерживал еще и этот сервак. А то у нас он в качестве основного хранилища используется... Я даже готов помочь в написании, если надо.
-
aefimov:
если бы он поддерживал еще и этот сервак.
какой сервак?
-
А где можно будет скачать бета версию?
-
Evg:
А где можно будет скачать бета версию?
еще нигде :)
-
а бетки нет...
-
не а :) к сожалению оно пока не в том состоянии, чтоб всем показывать.. увы, оффлайновая работа отнимает слишком много времени, но я полон оптимизма, и надеюсь смогу скоро всех удивить (было б выходных побольше!)
-
Много что писали чтобы хотелось видеть, но мне больше всего бы хотелось след.
1. чтоб база была SQL
2. рассылка подписчикам - желательно автоматическая
3. календарь
4. разграничение прав доступа и добавления статей и т.д.
-
Infringer2:
1. чтоб база была SQL
хех, готовьте MySQL, то что будет SQL база это 100% пока на MySQL ориентируюсь
Infringer2:
3. календарь
да, календаааарь.. Вот не могу сообразить как бы получше его сотворить на статичных страницах. Вернее как сотворить -понятно (подцеплять javascriptом или инклудить), но получается будет лишь календарь на текущий месяц.
-
а как тут можно уже готовый вариант довольно не плохо получилость и получается не 1 один мес. http://www.citynews.net.ua/
-
Green Kakadu
Infringer2:
хех, готовьте MySQL, то что будет SQL база это 100% пока на MySQL ориентируюсь
Хорошо бы, как в MovableType - выбор типа базы данных в настройках, а подпрограммы для работы с конкретными базами вынесены в отдельные модули (для начала можно оставить старую DB_File и добавить текстовую базу и MySQL, потом же при таком подходе все желающие после смогут добавить "драйвера" для работы с другими типами баз).
Вернее как сотворить -понятно (подцеплять javascriptом или инклудить), но получается будет лишь календарь на текущий месяц.
я отправлял ссылку на архив со своей нынешней верисией календаря... Может примерно так и организовать?
По поводу пожеланий к новой версии: очень было бы замечательно, если бы статьи сортировались не по id, а по дате (а также возможность изменения даты вручную при дополнении/обновлении материала).
Снова спасибо за скрипт! :)
-
CTN:
я отправлял ссылку на архив со своей нынешней верисией календаря... Может примерно так и организовать?
;) я для этого и хотел взглянуть (и скачал), так что вполне возможно
CTN:
По поводу пожеланий к новой версии: очень было бы замечательно, если бы статьи сортировались не по id, а по дате (а также возможность изменения даты вручную при дополнении/обновлении материала).
угу, думаю для каждой категории можно будет задать поле по которому будет происходить сортировка. По дате/по последнему изменению/по алфавиту.
Дата теперь изменяется.
CTN:
Хорошо бы, как в MovableType - выбор типа базы данных в настройках, а подпрограммы для работы с конкретными базами вынесены в отдельные модули
это навряд ли. Допустим между SQL базами это сделать несложно, а вот чтоб BerkleyDB туда припахать ИМХО слишком много телодвижений надо сделать. И появится излишняя запутанность кода - одна из проблем теперешнего Санитара..
-
Green Kakadu
CTN:
это навряд ли. Допустим между SQL базами это сделать несложно, а вот чтоб BerkleyDB туда припахать ИМХО слишком много телодвижений надо сделать. И появится излишняя запутанность кода - одна из проблем теперешнего Санитара..
К сожалению, под рукой МоваблТайпа сейчас нет, чтобы точно описать, но, по-моему, там используется принцип чёрного ящика: есть подключаемые модули, один из которых подключается к скрипту в настройках, в модулях названия подпрограмм для получения/выдачи данных одинаковые. Модулю отдаются данные (или происходит обращение к подпрограммам модуля для получения данных) и скрипт потом не заботит, что происходит с данными после передачи или каким образом они взяты из базы.
Т.е. стандартизирована работа с базой, а под этот внутренний стандарт уже пишутся модули для разных баз.
Кстати, при таком подходе будет опять же несложно устроить перенесение данных из той же BerkleyDB в MySQL или что-то еще...
-
CTN:
К сожалению, под рукой МоваблТайпа сейчас нет, чтобы точно описать, но, по-моему, там используется принцип чёрного ящика: есть подключаемые модули, один из которых подключается к скрипту в настройках, в модулях названия подпрограмм для получения/выдачи данных одинаковые.
да, я смотрел и в курсе реализации подобного.. но тут есть несколько моментов:
- приходится использовать дополнительный слой абстракции. Я буквально недавно переписал то что было на модифицированный SQL::Abstraction и потому в принципе легко использовать разные SQL БД, но если добавить BerkeleyDB то система утяжелится и усложнится, добавится некотарая избыточность. Тот же MT ИМХО весьма избыточен и не оптимален
- потребуется основательно перекромсать то что у меня есть сейчас и это мне больше всего не нравится :)
- Berkeley возникнут проблемы с сортировкой, она замечательно и оч.быстро работает с ключами, но если потребуется сортировка по какому-либо полю данных, то.. все считываем, разбиваем поля, берем нужное и сортируем непосредственно самим Perlом. Для больших контент- сайтов такие извраты будут весьма напряжными в смысле производительностиCTN:
будет опять же несложно устроить перенесение данных из той же BerkleyDB в MySQL или что-то еще...
это да.
-
меня интересует еще такой вопрос как буду реагировать поисковые системы? т.е. сейчас ссылки одни потом я так понимаю вид c SQL версией станет совсем другой и получится будут ошибки 404. предложение такое сделать скрипт который при обработке 404 ошибки выдавал новый путь к статье!
-
Cyberinfo:
предложение такое сделать скрипт который при обработке 404 ошибки выдавал новый путь к статье!
кстати дельное замечание, учту
-
Green Kakadu:
кстати дельное замечание, учту
По-моему, поисковики если получают в ответе сервера 404, то не индексируют то содержимое, что передаётся в виде страницы ошибки, а наоборот исключают адрес из индекса.
Разумнее вместо старых страниц разместить HTML-страницы с редиректом на новое расположение материала. Или же использовать mod_rewrite...
Так старая структура вообще сохранена не будет?
- Berkeley возникнут проблемы с сортировкой, она замечательно и оч.быстро работает с ключами, но если потребуется сортировка по какому-либо полю данных, то.. все считываем, разбиваем поля, берем нужное и сортируем непосредственно самим Perlом. Для больших контент- сайтов такие извраты будут весьма напряжными в смысле производительности
Это да, но мало ли — может кому-то надо будет временно на хостинге без MySQL пожить :-). Если страницы используются статические, то сервер одноразовый напряг при их генерации стерпит...
- потребуется основательно перекромсать то что у меня есть сейчас и это мне больше всего не нравится
понятно...
-
CTN:
Разумнее вместо старых страниц разместить HTML-страницы с редиректом на новое расположение материала. Или же использовать mod_rewrite...
я это и имел в виду. т.е. создать скриптик который бы выискивал соответствия (старый урл/новый) и переправлял
CTN:
Так старая структура вообще сохранена не будет?
нет.
/название_категории/id_статьи/название статьи
по идее разница лишь в том, что у категорий будут не номера, а названии (+не стоит забывать про подкатегории), ну а название статьи - это по желанию
-
CTN:
то сервер одноразовый напряг при их генерации стерпит...
хех, тут тебе виднее. Я то санитаром вообще не пользовался (запостил пару статеек и забросил это дело). Т.е. с трудом представляю как там обстоит работа при большом кол-ве статей. Мне кажется неудобно :)
наверное самый "объемный" сайт с санитаром, это http://www.gtnews.ru/ они работают в динамич.режиме, и возможно в этом есть логика, потому как генерить статику будет неудобно. (Правда при динамич.режиме довольно прилично ресурсов тратится на при построении индексных страниц)
Поразмыслив, мы с NASом решили при генерации сделать что-то типа "Генерить изменившиеся страницы за такой-то период" (день, три дня, неделя, месяц, квартал, год)
-
Green Kakadu:
/название_категории/id_статьи/название статьи по идее разница лишь в том, что у категорий будут не номера, а названии (+не стоит забывать про подкатегории), ну а название статьи - это по желанию
Это через mod_rewrite или же
/script.cgi/название_категории/id_статьи/название
?
Неплохо, кстати, в динамике выдавать в заголовках страницы Last-Modified и т.п. для поисковиков — чтоб считали выдаваемую страницу статической :)
Green Kakadu:
хех, тут тебе виднее. Я то санитаром вообще не пользовался (запостил пару статеек и забросил это дело). Т.е. с трудом представляю как там обстоит работа при большом кол-ве статей. Мне кажется неудобно
Ну не знаю, насколько виднее :)
Особых неудобств не заметил... Да и потенциально нагрузка на сервер меньше — одно дело при запросе генерить страницу, получая данные из базы, обрабатывать данные и навешивать их на шаблон перед выдачей, и другое — просто выдавать готовую страницу, возможно, с минимумом динамики (серверный счётчик, пара ssi-include\'ов и т.п.).
Green Kakadu:
они работают в динамич.режиме, и возможно в этом есть логика, потому как генерить статику будет неудобно.
Логика в том, что статика занимает довольно много дискового пространства (ну и при каждой правке шаблонов нужно перегенерировать все страницы, хотя правка шаблонов и нечастое действие).
С другой стороны, поисковики очень любят статические страницы.
Green Kakadu:
(Правда при динамич.режиме довольно прилично ресурсов тратится на при построении индексных страниц)
И я о том же... С SQL, конечно, на порядок меньше будет ресурсов расходоваться, но всё равно — любая динамика по ресурсам проигрывает статике :)
Green Kakadu:
Поразмыслив, мы с NASом решили при генерации сделать что-то типа "Генерить изменившиеся страницы за такой-то период" (день, три дня, неделя, месяц, квартал, год)
А так, как сейчас чем не подходит? (генерация страниц только при публикации/редактировании статей)
-
CTN:
А так, как сейчас чем не подходит?
не это подходит, но допустим если закинули сразу несколько статей, то чтоб каждый раз не генерить (индексы же все равно общие), сразу оптом.
-
Такс и еще одна просьба сделать счетчик прочтения каждой статьи, чтоб можно было делать рейтинги самых популярных!
-
Cyberinfo:
Такс и еще одна просьба сделать счетчик прочтения каждой статьи, чтоб можно было делать рейтинги самых популярных!
дык даже сейчас можно это сделать прикрутить там что-то типа Spesta (http://textus.ru/freeware/spesta) - она страницы по id зафиксирует, ну а там уж дело техники, ее слегка подправить, чтоб выдавала соотв. названия статей. Т.е. имея минимальные навыки в пхп можно это сделать
-
ну так это будет в новом движке?
-
Cyberinfo:
ну так это будет в новом движке?
не вижу смысла писать свой счетчик - может приспособлю какой-нибудь (например ту же спесту, только с лицензией там разобраться надо)
-
не когда все в одном движке лучше так как можно фичи сделать топы и т.д.! подумай над этим и народу будеть нравиться больше.
и еще, а что насчет RSS ?
-
и еще такое в нанешнем движке нет такого чтоб проверял коментарии, все окменты публикуются одинакого я имею ввиду на флуд! можно коннечно вкл. проверку, но это муторно! в новом вдиге будет?
-
Cyberinfo
и еще, а что насчет RSS ?
Могу для нынешнего движка дать:
http://www.citynews.net.ua/news/export.html
Правда, подробных инструкций по прикрутке (как для календаря расписывал) не писал, лень потому как :)
-
Cyberinfo:
и еще, а что насчет RSS ?
если про XML формат, то глянь на форуме в разделе "Модификации", я туда недавно кинул.
А так, думаю то же самое сотворить - js, txt, xml правда они все одновременно будут делаться (не так как сейчас).
Cyberinfo:
не когда все в одном движке лучше так как можно фичи сделать топы и т.д.! подумай над этим и народу будеть нравиться больше.
М.. мне чесно сказать не оч. нравятся системы все в одной и одними кривыми руками сделанные :) например про тот же счетчик если говорить, то сомневаюсь, что я сделаю что-то радикально лучшее.. и по умолчанию встраивать его в систему не есть гуд, т.к. есть вероятность, что "не оч.качественно написанный" счетчик :) загрузит весь сервер.
никто не мешает этот сторонний счетчик прикрутить к админпанели. Впрочем подумаю, может как плагин сделаем. Надо бы уж демкой разродиться (я помнится в январе еще обещал), да вот на работе небольшой навал - мешает творить так сказать.
+ рейтингование статей тоже появится.
Вроде как система получается весьма плугаббельной :) не то что нынешний Санитар, где без поллитра не разберешься, т.е. довинтим всякие штуки которые не должны быть в ядре, но хотелось бы иметь в системе. Например SBT-голосовалку тоже можно "обновить" и прикрутить в качестве плагина.
P.S. Вот что я до сих пор толком додумать не могу - так это систему генерации/управления меню. Так что если есть мысли -поделитесь. Исходить надо из:
1. будут подкатегории разной вложенности
2. должна быть воз-ть довольно вразумительно настраивать внешний вид
3. не надо забывать про специфику статического режима (я как то на него больше пока ориентируюсь)
4. система шаблона довольно гибкая (синтаксис HTML::Template, есть воз-ть использовать циклы), т.е. тут руки более менее развязаны
+ наверное должна быть воз-ть перемещать категории в меню (вверх/вниз)
+ должна быть воз-ть добавления разделов не относящихся к системе публикаций, типа "Форум"
в общем примерно такие соображения, потому как сейчас реализовал лишь автоматическую генерацию структуры, а над этим думаю, но это весьма нужно как мне кажется. А то многим приходится меню делать ручками..
P.P.S. странно что никто не высказал пожелания по поводу настройки главной страницы. ИМХО это должно быть (во-первых несколько вариантов, не обязательно стандартный и в общем-то не оч.нужный индекс всех статей как сейчас, во-вторых что-то типа фичи "главная новость" + отдельный шаблон для главной страницы
-
По поводу генерации: сам тут голову ломаю над чем-то подобным, поскольку проблема выбора/создания движка для сайтостроительства стоит в общем-то островато. ТАк вот есть кое-какие мысли. Для генерации страниц я подумываю использовать простой принцип формирования имен файлов - время создания самой страницы в системе: ГГГГ/ММ/ДД/ЧЧММСС таким образом получаем ветвистую систему каталогов с именами фалов ЧЧММСС в соответсвующих дате создания каталогах. Например файл/страница/раздел созданный 2005.02.08 в 15:58:00 будет лежать например от корня в каталоге 2005/02/08/155800/
файл просто index.html(shtml,php и т.п) таким образом мы:
1. "прячем" тип используемых нами документов 9бывает актуально, но главное более приятно на вид и более разумно поскольку изменив расширение нам не придется менять ссылку!!!)
2. не создаем неимоверное количество каталогов в любом существующем каталоге (как было раньше - много файлов-статей в каждой категории). т.е. обходим ограничение на количество каталогов, а главное при навигации по этим каталогам в случае желания че-то посмотреть или исправить, не теряем время на ожидание загрузки списка подкаталогово :)
С последней да и с первой проблемой сталкивался не раз :)
Далее названия (ссылки/пути) к разделам(старницам, статьям) создаем в системе произвольные и человекопонятные /about/history/ и т.п., обращаемся соответственно этому адресу в браузере... и делаем обработчик ошибок "документт не найден" который роется в базе и ищет соответствие введееного урла и реального /ГГГГ/ММ/ВВ/ЧЧММСС/ :) вот собственно и все если я правильно понял суть дела :)
Если нет, прошу больно не бить :)
-
P.S. насчет имени файла ЧЧММСС - ошибся :) путь будет ГГГГ/ММ/ДД/ЧЧММСС/ а имя файла Index.html(shtml,php и т.п.)
да и обработчика можно избавить от проблемы поиска соответствия набранного урла и реального файла а создавать соответственно набранному урлу (ссылке) реальный путь и оотуда вызывать например через SSI соответствующий ГГГГ/ММ/ДД/ЧЧММСС/
Может быть тоже не лучший выход но вариант вполне реальный к тому же как вызывать обработку тех же shtml через обработчик ошибок типа "документ не найден" без отображения в адресной строке реального пути пока не понимаю. Есть конечно реврайты урлов но это уже допсредства.
-
Да и когда же попробуем долгожданный Sanitar2? Очень ждем :)
-
Mikeo:
путь будет ГГГГ/ММ/ДД/ЧЧММСС/
мм, это один из вариантов, мне например такие календарные пути не оч.нравятся, хотя в этом есть резон
гггг/мм/дд/id статьи
-
CTN дай плиз код для RSS и еще я смотрю у тебя есть это - http://www.citynews.net.ua/news/js_export.html можешь тоже поделиться :)
---------------
да и когда интересно будет демо скажем версия санитиума 2 ? :)
-
Cyberinfo:
да и когда интересно будет демо скажем версия санитиума 2 ?
не хочу теперь говорить о сроках и так два раза обманул, я планирую в скором времени, тут многое зависит от наличия у меня свободного врмени
-
ну хотяб через сколько надеюсь к концу января появиться?!
-
Cyberinfo:
ну хотяб через сколько надеюсь к концу января появиться?!
дык уже февраль наступил! :)
-
Ну а вообще как идут дела? А то очень хочется увидеть новую версию движка.
-
Green Kakadu
мы ждем!!
мы ждем!!
мы ждем!!
мы ждем!!
где он!!! :)
-
Green Kakadu:
если про XML формат, то глянь на форуме в разделе "Модификации", я туда недавно кинул. А так, думаю то же самое сотворить - js, txt, xml правда они все одновременно будут делаться (не так как сейчас).
Я чето ненашел ничего в модификациях только пароль на админку... где лежит для RSS мод?
-
Cyberinfo:
http://www.citynews.net.ua/news/js_export.html можешь тоже поделиться
а там нечем делиться: код открыт (на javascript\'е), просто заголовки выводятся последние.
Просто смотришь код страницы, правишь ссылку и оформление — и пользуешься :)
-
а сам код формирования и вывода RSS сейчас пытаюсь в кучу собрать :)
-
у меня в моде RSS такая ошибка http://www.cyberinfo.ru/news/index.xml
все вроде сделал, но че то не пашет
-
а как скоро можно будет заюзать новый санитариум, хотя бы примерные сроки ????
-
А где можно взять старую версию Санитара во всеми ее модификациями?
-
Mikeo:
А где можно взять старую версию Санитара во всеми ее модификациями?
http://webscript.ru/sanitarium
ну а модификации :) прикручиваются самостоятельно
-
ну так че когда хоть увидим новую версию?
-
очень инетресно. добрые люди сказали что во всю идет такая работа. респект и уважуха Green Kakadu за его терпение и труд!
-
Народ очень прошо помочь настроить данный движок для формата новостей RSS ! Кто такое сделал помогите!
-
Еще было бы не плохо, если бы при редактировании страница открывалась точно в таком же виде, как была, когда я ее сохранял (создавал). Т.е. оставались на месте все пробелы, & nbsp; и т.п. (хотя сейчас вроде & nbsp; единственный, который остается, но к нему при каждом редактировании добавляется еще по два пробела).
-
кстати еще полезная фича автоматическое форматирование. т.е. возможность выбора автором/администратором использовать для форматирования хтмл или же скрипт сам будет форматировать ввденый текст!!!
-
Во первых большое спасибо за движок - очень неплохо работает у меня уже 3 месяца.
Во вторых, какой SQL будет поддедживать вторая версия?
MySQL? PostgreSQL?
Очень хотелось бы, чтобы постгрес тоже был в списке опций.
Готов даже помочь в кодинге, если потребуется.
-
Green Kakadu
Ну так что? Пока тишина... Очень хочтеся хотя бы на демо взглянуть! Расскажи хотбы на каком этапе находится движок.
-
Можно свои пожелания в копилку? А можно сделать, чтобы шаблоны были с расширением HTM или HTML а не TXT, а то их править невозможно в дримвьюере не переименовав. Я так и делаю, и меня это напрягает больше всего. Кстати, можно ли в текущей версии так сделать? SQL - очень хорошо. Еще для полного счастья не хватает тега количества комментов к статье.
А так - прекрвсный скрипт. Мой проект - http://www.minilabmaster.km.ru перекрасно на нем работает почти полтора года. Green Kakadu - респект.
-
Как дела продвигаются выложи хоть бетку для тестирования!
-
в силу некоторых причин дела пока никак не продвигаются нет времени, но скоро продвинутся. Как только так сразу.
-
Я так думаю, что не надо сильно увлекаться фичами. Ядро+шаблон и достаточно. Все остальное (календарь, RSS и т.д. и т.п.) можно добавить в виде модулей. :-)
-
Хорошо бы еще, чтобы была поддержка UTF-8.
-
Green Kakadu
А буржуи-то уже обгоняют:
http://pineappletechnologies.com/products/lore/
Демка:
http://pineappletechnologies.com/products/lore/demo/cp/
Username/password: admin/admin
Документация:
http://pineappletechnologies.com/kb/idx/11/0/Lore.html
Вот что они говорят в описании системы:
Lore is a professional knowledge base management system powered by PHP and MySQL.
Lore allows you to quickly and easily organize frequently asked questions, articles, and documentation into a categorized and searchable knowledge base.
With Lore, you can provide your customers with instant answers to their inquiries and support questions.
Надеюсь, может быть хоть это ускорит процесс разработки второго санитара ;)
-
Green Kakadu
А буржуи-то уже обгоняют:
http://pineappletechnologies.com/products/lore/
Демка:
http://pineappletechnologies.com/products/lore/demo/cp/
Username/password: admin/admin
Документация:
http://pineappletechnologies.com/kb/idx/11/0/Lore.html
Вот что они говорят в описании системы:
Lore is a professional knowledge base management system powered by PHP and MySQL.
Lore allows you to quickly and easily organize frequently asked questions, articles, and documentation into a categorized and searchable knowledge base.
With Lore, you can provide your customers with instant answers to their inquiries and support questions.
Надеюсь, может быть хоть это ускорит процесс разработки второго санитара ;)
Мы за поддержку отечественного производителя. :super:
-
да и платный он!
-
Мы все еще ждем!!!!!!!!!!!!!!!
-
Не то слово :( ОЧЕНЬ ЖДЕМ... если честно уже года полтора, а то и два лично я жду. Потому что пока не видел чего-то более простого, корректно работающего и удобного (бесплатного разумеется)
-
Вот и я тоже жду. Просмотрел на девере сапид, погрустил... Ну, может, пока выскажу несколько идей на обсуждение. Извиняюсь, если они где-то уже высказывались.
1. Может быть лучше для скорости и для всего Автору сконцентрироваться на ядре, но при это сделать внятную систему добавления плагинов. От "сторонних" производителей, то бишь нас. Т.е. выставить на обкатку первый релиз с самыми минимальными необходимыми возможностями, но чтобы вся система (директории и базы) уже пахали. В конечном итоге може получиться забавный широкий проект...
2. А может перенести часть операций на клиентскую часть? Я вот о чем. В общем, большая часть разработчиков сидит уже на firefox-е. Так написать внятные рекомендации или еще что для интеграции понятия расширения к лису. Тогда, наверное, можно использовать частично даже имеющиеся наработки xpi- расширений, как, например, есть уже таковые для livejournal, wiki, многих даже коммерческих сайтов. Т.е. необязательно самому Автору колбаситься с ними. Но если ядро ак-то заточено изначально с учетом данной идеи, то и расширения недолго заставят себя ждать. Тем более, скорее всего, можно будет брать уже сущестующие и переделывать. В итоге, часть работы переложить на Лис - те же html - редакторы, css-редактор, валидаторы и т.п.
3. Нужна "открытая" система регистрации. Дабы можно было бы легко (с помощью простых добрых слов Автора в описании) дописать связку-синхронизатор (автоматический) к, например, уже стоящему форуму.
-
К автору последнего коммента есть вопрос: Хотелось бы услышать Ваше мнение относительно той же xapid??? Желательно не в двух словах :) Спасибо
-
Ау... Ждеееееееееееееееееееееееееееемммм... Скоро уже пора летних отпусков :( Неужели раньше осени не ждать? :(((
-
Я вот одного не могу понять. Все так ждууууууут, просят, интересуются, а штоп скинуться для автора по 10 баков для ускорения процесса, так это что-то в голову никому не приходит.
Я тоже ждал, когда для моего форума будет примочка с созданием фотогалереек. Ждал я, ждал, а потом кинул автору 30 баков, так он за неделю все и сделал, да так, что ни на каком другом форуме такого больше и нет.
-
Давайте спросим Green Kakadu, сколько можно и нужно подбросить материальных средств, чтобы срипт был готов, скажем, через месяц.
Пора уже понять, что бесплатного сыра высокого качества с последующей поддержкой и регулярными обновлениями в природе не бывает. А если и бывает, то не в нашей стране.
Всем респект.
-
планирую уже на след.неделе запустить альфу-версию.
-
Отличная новость!! :)
-
А как там обстоят дела с trackback?
-
Идея оплаты вскладчину имеет место быть. Поддерживаю. Теперь слова от пернатых :)
-
Рeбятa, вы нe зaбывaйтe, чтo oплaтa зa рабoту нe тoлькo ускoряeт прoцeсc, но и налагает на автора кое-какие обязанности. ;)
-
А это что, плохо? Если твой сайт будет плохо работать из-за того, что автор скрипта не чувствует по отношению к тебе никаких обязательств, то это обойдется гораздо дороже 5-10 баков.
-
Честно говоря мне слабо верится, что автор горит желанием на себя вешать еще какие-то обязанности. ;)
-
Готов пожертвовать на развитие скрипта. Сообщите реквизиты webmoney...
-
Ну ждем типа альфа версию
-
Я за оплату в разумных пределах :)
10 - 20 вполне разумно
-
Fargus:
Честно говоря мне слабо верится, что автор горит желанием на себя вешать еще какие-то обязанности.
это точно, не хочу никаких $, потом может в качестве благодарности :) но процесс идет полным ходом (пораньше бы столько энтузиазма), так что не за горами :) во всяком случае у меня все на той стадии когда я по новой все переписал (раз в 4-й 100% ООП стиль) и уже все постится и генерируется. постараюсь короче.Полон энтузиазма.
-
Конечно как благодарность, не хватало еще что бы за 20 $, появились еще какие либо обязанности :)
-
Интересно узнать, новая версия будет целиком на php или по-прежнему на perl?
-
Moony:
Интересно узнать, новая версия будет целиком на php или по-прежнему на perl?
целиком на perl и никакого php :)
зачем он вам сдался, этот php - в статичном режиме возможно подключениние php скриптов со страниц системы.
конечно со временем можно будет и php примочку дописать для динамической работы на php, только ИМХО это не нужно, лучше на mod_perl :) перейти
P.S. ... на днях все увидите.
-
просто с трудом освоил пхп на самом начальном уровне, а перл вообще не суждено мне освоить. практика показывает, что все скрипты приходится доводить под себя. ладно, буду пользоваться DataLife Engine
-
>целиком на perl и никакого php
отлично
>DataLife Engine
это совершенно разные системы, я не думаю, что их надо сравнивать
-
чем же они так сильно разные?
-
Ну наконец-то скоро появится новая версия движка, очень долго ждал ее. Надеюсь это скоро будет совсем скоро :)
-
majix:
Надеюсь это скоро будет совсем скоро
совсем скоро будет альфа версия :) усиленно пытаюсь придать ей более менее законченный вид, уже третьи сутки по 18 часов с ноутбуком в обнимку.
Moony:
практика показывает, что все скрипты приходится доводить под себя.
это точно.
.. а кто-нибудь пользовался всякими модными mambo и т.д. и вообще, какие сейчас OpenSource CMS пользуются популярностью (в последние 3 года) - киньте ссылки/комментарии к CMSкам, а то я отстал от жизни - надо знать на что ориентироваться.
-
Green Kakadu
http://www.imho.ws/showthread.php?t=67079
В этой теме ссылки с описаниями на все стояшие CMS[/URL]
PS Только, наверное, чтоб увидеть - зарегиться прийдеться. Но, поверьте - тема того стоит.
-
Я тоже жду.
Как раз будет что и где попробывать.
-
мне кажется по функциональности цмс должна быть примерно такой:
- неограниченное кол-во категорий и их вложенности
- сортировка в по буквам в каждой категории по отдельности
- неограниченное кол-во дополнительных полей при добавлении материалов
- голосования за материал + комментарии
- календарь
- регистрация пользователей
- наделение правами некоторых пользователей
- индивиндуальные поля title; meta_des.; meta_key.;
- чпу
- настройка шаблонов таким же образом как в санитариуме
- ну еще пару мелочей о которых упоминать не стоит т.к. это было в первом санитариуме
-
все на днях увидите. Альфа версия будет без поиска (работаю над нормальным поиском с морфоанализатором), без рейтинга и комментирования (они пришиваются как отдельные прибамбасы, в бете уже будут)+статич.ржим. Динамичный тоже появится к бете (там надо с системой кеширования подумать).
majix:
- неограниченное кол-во дополнительных полей при добавлении материалов
в систему устанавливаются доп.расширения для каждого типа документа, соответственно там задаются и любые поля и разл.варианты их обработки.
majix:
- настройка шаблонов таким же образом как в санитариуме
уже оно лучше, удобнее и по производительности быстрее.
-
А будет возможность размещать статью сразу в нескольких категориях?
-
лично я считаю что для начала это слишком, лучше сосредоточится на основном, а потом уже остальное
-
Fargus:
А будет возможность размещать статью сразу в нескольких категориях?
нет. но впоследствии подумываю о добавлении плагина, статье присваиваются ключевые сллова,и помимо группировки по категориям можно быдет группировать слова по ключ.словам. А так, существует довольно жесткая привязка статьи к категории и не хочется ее менять (хотя в теории можно сделать в базе таблицу соответствий "статья-категория").
-
Green Kakadu:
нет. но впоследствии подумываю о добавлении плагина, статье присваиваются ключевые сллова,и помимо группировки по категориям можно быдет группировать слова по ключ.словам. А так, существует довольно жесткая привязка статьи к категории и не хочется ее менять (хотя в теории можно сделать в базе таблицу соответствий "статья-категория").
Жаль. :( У меня так процентов 30 таких статей.
-
Green Kakadu:
нет. но впоследствии подумываю о добавлении плагина, статье присваиваются ключевые сллова,и помимо группировки по категориям можно быдет группировать слова по ключ.словам. А так, существует довольно жесткая привязка статьи к категории и не хочется ее менять (хотя в теории можно сделать в базе таблицу соответствий "статья-категория").
Возможно это и правильно. Тот же Гугл при разработке почтового сервиса Гмейл пошел этим путем. Пока не слышал жалоб. Да и сам пользуюсь - не могу сказать что без папок не удобно, просто "по-другому".
-
R.V.:
Возможно это и правильно. Тот же Гугл при разработке почтового сервиса Гмейл пошел этим путем. Пока не слышал жалоб. Да и сам пользуюсь - не могу сказать что без папок не удобно, просто "по-другому".
да, вообще такой принцип мне больше нравится, но без жесткой привязки в "моем" случае тоже не очень удобно - некоторые настройки статьи зависят от категории (например шаблоны) + права доступа тоже привязаны к категориям. При выводе ленты с NN последними новостями в случае мультикатегорийности статей будут повторения - одна и таже статья сразу в нескольких лентах, если они окажутся на одной страницы, то не очень "правильно" это. + подобные подводные камни еще всплывут: регенерация одной статьи приведет к цепной регенерации индексов множества категорий, они же с неограниченным вложением.
Т.е. я над эим думал и даже делал кое-какие поползновения, но все-таки решил не делать, а оставить эту фичу для плагина.
-
О комментариях.
По-моему было бы удобнее, если вместе с уведомлением на email о новых комментариях, в тексте письма будут прямые ссылки на удаление или добавление данного комментария.
-
ListZone.Ru:
О комментариях. По-моему было бы удобнее, если вместе с уведомлением на email о новых комментариях, в тексте письма будут прямые ссылки на удаление или добавление данного комментария.
Это для администратора?
Green Kakadu
Такой вопрос: под какой лицензией будет распространяться скрипт?
-
R.V.
Да для администратора. Также можно сделать чтобы уведомление о новом комментарие высылались, помимо администратора, автору статьи.
-
ListZone.Ru:
Да для администратора. Также можно сделать чтобы уведомление о новом комментарие высылались, помимо администратора, автору статьи.
Согласен - очень удобно. Админу не прийдется лишний раз в админу лезть и выполнять лишние телодвижения, а автор всегда сможет оперативно отвечать на вопросы
-
ListZone.Ru:
О комментариях. По-моему было бы удобнее, если вместе с уведомлением на email о новых комментариях, в тексте письма будут прямые ссылки на удаление или добавление данного комментария.
ок. комментарии песня отдельная я, если честно, ими еще не занимался, так что все предложения принимаю на заметку. Вообще, это вещь спорная: с одной, обратная связь с посетителями и иногда комментарии читать интереснее статьи, с другой, часто они без модерирования превращаются в помойку. Поэтому:
1. система комментариев будет делаться как "независимая" часть системы
2. скорее всего при статическом режиме комментарии на отдельных страницах (думаю их тоже можно в статике распечатывать)
3. если есть идеи борьбы со спамом в комментариях на уровне скрипта - поделитесь мыслями.
Например, как я понял вебскрипт.ру от комментариев к статьям отказался из-за кучи помоев (спама различного рода) которые туда регулярно выливались.
R.V.:
Green Kakadu Такой вопрос: под какой лицензией будет распространяться скрипт?
какая-нибудь открытая лицензия (GPL или что-то типа того) -это 100%
скрипт делался с учетом того, чтоб у него была открытая понятная архитектура с широкими возможностями по расширению сторонними разработчиками (вот бы мне еще разродиться нормальной документацией).Проблема санитара 1 в том, что его работа завязана на один модуль с довольно запутанным/невнятным интерфейсом.
В новой версии я попытался реализовать модную ныне модель MVC - model-view-controller
В качестве контроллера выступают модули построенные на основе CGI::Application
View - система, работающая с шаблонами расширенного синтаксиса HTML::Template (причем синтаксис проверяется HTML::Template)
Модель хранения данных - система модулей на создание которой меня вдохновила работа с пакетом SPOPS + апгрейженный мною модуль SQL::Abstract. Пока работает только с MySQL но для перехода на Pg надо будет внести лишь небольшие изменения в один модуль который отвечает за то что называется object mapping (не знаю как по-русски).
Из каких-либо особенных модулей ничего не использовалось, т.е. подойдет обычный хостинг с CGI (все необходимые модули будут в составе дистрибутива они чисто перловые). Единственное что не помешает - наличие ImageMagic чтоб делать к картинкам превьюшки.
упреждаю ваши вопрос "Когда"?
Скоро. Хочется выпустить в свет его если уж не полностью готовым, то максимально законченным с неким базовым набором функций.
Поэтому довожу до ума.
На каком этапе разработка? Что уже есть?
Есть система которая:
1. имеет уже полностью функциональный, в меру симпатичный и удобный админский интерфейс, система авторизации (пока сессионная, планирую добавить воз-ть использования базовой апачевской авторизации)
2. Визуальный HTML редактор для статей и превьюшек (пока подключил наименее громоздкий RTE) планирую добавить поддержку других более навороченных, типа TinyMCE
3. работает с неограниченным кол-вом категорий, выстраивает деревья категорий, строит по ним меню. Соотв. удаление, изменение, создание, просмотр категорий.
Планирую: систему работу с меню. Пока сортирует по алфавиту.Воз-ть использования различных шаблонов для меню. Хотелось бы дать воз-ть устанавливать порядок следования + добавлять в меню ссылки не относящиеся к системе. (это уже после выхода альфы)
4. работа с документами. Краткие новости, многостраничные статьи (все документы - это что-то вроде плагинов,дефолтный, вшитый в систему - это один тип документа, краткие новости. Из расширенных есть пока только статьи. Создание, удаление. Добавление страниц, просмотр, сортировка по разным параметрам.
5. авторы (создание, изменение, удаление)
6. пользователи, система доступа с разными правами (+доступ привязан к категориям) : создание пользователя, изменение прав (не все авторы - пользователи). Какие группы пользователей:
------ "вируальный автор". Болванчик/заполнитель от имени которого пишут статью, доступа не имеет никакого и ни к чему и вообще не входит в число зарегистрированных пользователей.
------- "автор" - написание статей в разрешенные категории (рубрики). Редактирование своих статей.
-------- "редактор". Написание, редактирование, удаление статей из разрешенных рубрик. Управление "виртуальными авторами" (создает виртуалов, удаляет, пишет от их имени статьи).Публикация статей. Генерация страниц: отдельной категории, отдельной статьи, за последние nn дней.
---------"админ". может все.
(такая сисетма мне показалась наиболее разумной. Авторы, редакторы могут иметь/не иметь доступ в определенные категории)
7. система генерирует статичные страницы. (индексные страницы категорий могут быть двух типов: последниее NN статей на MM страницах или дайджест: последние т статей категории и ее подкатегорий на одной странице)
8. компилирует шаблоны (пользовательские/админские) (теперь шаблон после изменения должен обязательно компилироваться - после этого он превращается в полноценный перл-модуль, не требующий каких-либо библиотек шаблонизатора).
Что делаю сейчас: редактирование конфига через веб-интерфейс (довольно скучное и занудное занятие).
Что надо сделать к альфе:
- печать ленты новостей
- проверить систему с большим кол-вом докуметов (пока там у меня около 7 категорий, 3-х авторов и десяток документов)
- вывести часть данных из конфига в настройки категорий (типа кол-во статей на странице, кол-во страниц - все это имеет смысл настраивать для каждой категории индивидуально)
- календарь.
+ написать установщик
+ сделать более менее "перевариваемые пользовательские шаблоны" (пока там все скромно на уровне HTML 0.9b)
+разродиться минимальо-необходимым объемом документации.
и получается альфа для тестирования
-----------------------------
а потом добавлять все то что я считаю нужным и не хватает для беты - поиск... жду не дождусь когда приступлю к этому. Очень интересно. Уже достал кучу словарей для генерации словоформ, обчитался статей о морфоанализе, разных вариантах индексации документа .. но при этом вопрос производительности и скорости будет главным (может придется особо без наворотов обойтись)
- привинтить почтовые функции (sendmail,SMTP) проблем в этом не вижу, поэтому пока и не делал
- комментарии :)
- рейтингование (тоже отдельной системой)
- динамический режим и кеширование (довольно интересная задача).
- сделать поудобнее работу с менеджером файлов (написал системку на CGI::Uploader, довольно неплохая получилась, только надо будет расширить функциональность)
- родить парочку нестандартных плагинов-типов документов для того, чтоб продемонстрировать широкие воз-ти (например плагин для публикации FAQов или докуметов-фотоальбомов).
+ поправить те баги, которые кто-то из энтузиастов найдет и внести те предложения которые окажутся разумными.
-----------------------------------------
получается beta :)
ну а дальше видно будет. Надо будет нормальную документацию по программной части написать, написать конвертер со старого санитара в новую систему (+ ряд штук, которые мне кажется не помешают ,но о них рано пока говорить).
вот примерно план таков. Тружусь в меру своих воз-тей, забил на работу (уволился, а новую пока еще не искал и до выхода альфы не буду) так что стараюсь.
Если интересно, список используемых системой сторонних модулей на данный момент (будут поставляться в дистрибутиве, к сожалению, некоторые пришлось изменить).
CGI/CGI::Simple - на выбор
CGI::Application (переопределена часть методов), ф-ции контроллера
CGI::Application::Dispatch - ф-ции контроллера
CGI::Uploader (изменен мною) - основа менеджера файлов
Data::FormValidator (урезан мною) - проверка данных при постинге статей и т.д.
DBI :) dbd::mysql
Digest::MD5 - шифрование,, генерация id сессий
File::MMagic - используется файловым менеджером
File::Temp - используется файловым менеджером
File::Path - работа с каталогами категорий
HTML::Template - используется лишь при компиляции шаблонов и проверки их синтексиса.
Image::Size - используется файловым менеджером для определения размеров загружаемой картинки (Высота - Ширина)
ImageMagic - для генерации превьюшек к картинкам (опционально)
MIME::Type - используется файловым менеджером
MIME::Types - используется файловым менеджером
Params::Validate - используется файловым менеджером (думал убрать, но решил оставить)
SQL::Abstract (изменен) - генерация SQL запросов
----------------
+ кол-во файлов-шаблонов для админ интерфейса - 28
Но особо не пугайтесь (+ к этому еще 15 моих модулей ), все грузится только по мере необходимости и в основном при работе админа (проверки данных, загрузка файлов и т.д.)
[off]P.S.читаю, прям как Остап Бендер про Васюки-Москву..[/off]
-
А как насчет конвертации из первой версии во вторую? Очень бы хотелось:-)
-
Сергей К.
Читаем внимательно:
Green Kakadu:
Надо будет нормальную документацию по программной части написать, написать конвертер со старого санитара в новую систему (+ ряд штук, которые мне кажется не помешают ,но о них рано пока говорить).
-
Еще надо добавить возможность, перемещение нескольких материалов из одной категории (под-категории ...) в другую, в независимости от ее вложенности.
-
majix:
добавить возможность, перемещение нескольких материалов из одной категории (под-категории ...) в другую, в независимости от ее вложенности.
все перемещается без проблем, как сами документа, так и категории (и целые ветки категорий)
Сергей К.:
А как насчет конвертации из первой версии во вторую? Очень бы хотелось:-)
конечно, только надо вначале получить более менее стабильную, законченную 2-ю версию :)
Об урлах.
сейчас для статики урлы такие:
http://site.ru/Название Категории/Подкатегория/2005/06/22/id_page-номер страницы.расширение
:) есть большое желание вообще уйти к урлам без названй категорий
http://site.ru/2005/06/22/id_page-номер.расширение
на а индексы категорий в папках типа
http://site.ru/MyCategory/
есть ряд плюсов:
1 основной, что при смене категорий урлы статей остаются прежнимим
2 в построении урла (названии файла) не нужно использовать информацию объекта "Категория"
-
Green Kakadu
А даты из URL\'ов убрать можно будет, если они мне там не нужны? И какой уровень вложенности будет возможнен?
-
есть ряд плюсов:
1 основной, что при смене категорий урлы статей остаются прежнимим
2 в построении урла (названии файла) не нужно использовать информацию объекта "Категория"
второй вариант наиболее приемлем, ведь и вправду возможен перенос материала из одной категории в другую, что хорошо скажется для поисковиков.
Конечный урл предлогаю сделать таким: .../2005/06/22/532p1.*
А даты из URL\'ов убрать можно будет, если они мне там не нужны? И какой уровень вложенности будет возможнен?
для этого думаю придется поработать с .htacess
-
Все верно! Насчет Урлов на основе даты - рулез!!!! Я тут не так давно именно об этом и толковал. Для системы публикаций это особенно удобно и актуально, да и сама такая система формирования урлов позволяет без каких-либо дополнительных телодвижений изменять принадлежность документа (статьи) любой категории. Вообще подобная система кажется мне близкой к идеальной - когда урл некий однозначный буквенно цифровой идентификатор (слово/словосочетание по типу about-company или news-archive, company-year-report) и является адресом - например http://www.webscript.ru/sanitarium-documentation !!! Т.е. например в корне сайта лежали бы все документы (каталоги а в них index файл).
Таким образом проблема регенерации той же статики после изменения структуры сайта - просто нету! Хотя тут есть и свои минусы :) например закрыть доступ к разделу сайта средствами Апач уже не так удобно - придется прописывать каждый документ (которые в обычном древовидном представлении лежали бы в пределах одной ветки и было бы достаточно закрыть доступ к верхнему самому каталогу). Но пожалуй это единственный минус вместе с той кучей файлов (или каталогов с index файлами) которые бы заполнили либо корень сайта либо выделенный каталог. Хотя это не всегда проблема... если не считать стайтов с огромным количеством страниц, ввиду существования ограничения самой файловой системы на количество файлов (или каталогов уровня вложенности 1) в одном каталоге.
-
P.S. вернее речь шла о двух системах :) Одна с адресами типа "/ГГГГ/ММ/ДД/НОМЕР" а другая - "/some-document-name"
в первом случае получается та же древовидная стркутура статичных страниц а во втором "линейная" т.е. одного уровня вложенности
-
но вобще лучше что б урл был вида
/news/hardware/4324p1.*
а другая - "/some-document-name"
это как че-то не понял
-
если каждому документы дать некое название напрмиер about-company или documents&reports или bla-bla-bla то если их хранить (в статике) все в корне сервера например то обращение к ним будет - http://www.your-server.ru/bla-bla-bla/ и все. И ссылка легко запомнится и в случае изменения принадлежности к категории (разделу) не нужно физически файл ни перемещать ни переименовывать, а тем более целые ветки каталогов!!! все фидически остается на своих местах. Это же удобно прежде всего тем что реальный инетовсикй адрес не меняется при переходе статьи (документа) из категории в категорию (раздела в раздел)!!! Вот я о чем.
-
хм, а не ругнется ли сервак, если материалов будет эдак 5000 ? ведь всё лежит в одной папке, при добавлении чего-то он ж ведь сначало читает а потом создает а потом обратно читает (ну это я сужу по фтп проге), на это ж тратися время, причем огромное, да и на 1-ом санитариуме были кое какие проблемы когда кол-во материалов превышало 1500, пробдема есть в скорости их добалвения, уже ниже в раза 4 чем была когда материалов было штук 10.
-
majix:
/news/hardware/4324p1.*
не, все таки в одну папку пихать все нехорошо, можно либо к id привязываться, например хранить по 1000 в папке, т.е.
/news/hardware/4/4324p1.*
(тЗаглянувший:
А даты из URL\'ов убрать можно будет, если они мне там не нужны? И какой уровень вложенности будет возможнен?
думаю что при динамической работе можно будет различные варианты выбирать, хоть http://site.ru/123p1 или http://site.ru/Все что угодно/123p1 - главное к ID документа привязаться, а все остальное побоку. А вот со статикой.. надо определяться. Хотя я вынес генерации всех этих путей в одно место, так что поправить будет реально.
majix:
Конечный урл предлогаю сделать таким: .../2005/06/22/532p1.*
наверное к этому и придем.
сегодня закинул в систему 3200 статей (>42Мб текста) ничего, нормально.Всплыла парочка косячков поправил. Генерация по полной (т.е. более 3000 страниц, 19 категорий, 7 авторов) занимает 2-2,5 минуты (100-140 сек) под Win на PIII-500 128Мб. Порадовало то, что память он не сжирает - более 11 мб процесс не съедал, держался в районе 10,2 -10,5 (при этом около 6-7 уходит под сам перл). Под Linux на днях попробую, должно быть быстрее. В любом случае такую генерацию надо будет подразбить по nn статей. Предполагается что будет использоваться генерация изменений за последние nn дней, или просто изменившихся страниц с последнего обновления.
Насчет урлов, имхо это в некоторых случаях уже превращается в фетиш, мне кажется, чем короче - тем лучше. Была мысль прибавлять к названию файла страницы что-то по желанию автора,т.е. ../../../moj_super_rasskaz-123p1.htm но выглядит это довольно глупо :)
-
скриншоты:
просмотр информации о категории
http://gnezdo.webscript.ru/unews/view_cat.jpg
редактирование анонса
http://gnezdo.webscript.ru/unews/edit_preview.jpg
редактирование прав доступа для пользователя
http://gnezdo.webscript.ru/unews/permissions.jpg
генерация страниц
http://gnezdo.webscript.ru/unews/gen.jpg
так это все выглядит на сегодняшний день. сама админка работает тоже на шаблонах (а не как в первом санитаре где админ-интерфейс зашит в скрипте).
-
Green Kakadu
Приветствую! Спасибо огромное за работу!
да, вообще такой принцип мне больше нравится, но без жесткой привязки в "моем" случае тоже не очень удобно - некоторые настройки статьи зависят от категории (например шаблоны) + права доступа тоже привязаны к категориям. При выводе ленты с NN последними новостями в случае мультикатегорийности статей будут повторения - одна и таже статья сразу в нескольких лентах, если они окажутся на одной страницы, то не очень "правильно" это. + подобные подводные камни еще всплывут: регенерация одной статьи приведет к цепной регенерации индексов множества категорий, они же с неограниченным вложением.
В теории, чтобы избежать подобных проблем можно статью публиковать в одну основную категорию и, возможно, некоторые другие категории использовать для неё как дополнительные - затем в общей ленте выводить заголовки только по основной категории статьи, а дополнительные категории статьи использовать только при выводе лент категорий. Правда, с регенерацией всё одно так не складывается...
3. если есть идеи борьбы со спамом в комментариях на уровне скрипта - поделитесь мыслями.
- автоматический запрет комментирования в случае отсутствия данных в HTTP_ACCEPT, HTTP_ACCEPT_CHARSET, HTTP_ACCEPT_ENCODING, HTTP_CONNECTION и других типично браузерных заголовках запроса (частично поможет избавиться от автоматической публикации спама скриптами с других серверов);
- запрет публикации для одного пользователя/IP на небольшой промежуток времени (секунд 10-20 - чтоб избежать флуда);
- сравнение текста публикуемого комментария с текстом 5-10 последних уже опубликованных комментариев и последующий запрет публикации, если текст идентичен - поможет избежать случайных дублей комментариев и, опять же, поможет в борьбе с флудом;
- возможность блокировки пользователей не только по IP, но и по другим уникальным данным (скажем, уникальный md5-хэш по данным об установленных плагинах, разрешении экрана, временной зоне, navigator.userAgent и т.д. и т.п.)
Конечный урл предлогаю сделать таким: .../2005/06/22/532p1.*
наверное к этому и придем.
Насчет урлов, имхо это в некоторых случаях уже превращается в фетиш, мне кажется, чем короче - тем лучше. Была мысль прибавлять к названию файла страницы что-то по желанию автора,т.е. ../../../moj_super_rasskaz-123p1.htm но выглядит это довольно глупо
Без категории действительно удобнее, к тому же так и для подобных любителей вставлять текст в ссылки можно организовать что-то наподобие этого:
http://site.ru/2005/06/22/id_page-номер страницы/что_угодно_от_автора_статьи :-)
т.е. в директории /2005/06/22/id_page-номер страницы/ просто index.html, а дальше - что попало дописать можно...
Важный момент, касающийся прежде всего поисковиков: хорошо бы, если бы скрипт мог выдавать по старым ссылкам правильное содержимое без помощи mod_rewrite.
Другими словами, чтоб, скажем, по запросу
http://site.com/10/1234_1.shtml
какой-нибудь index.pl, расположенный в корневой директории site.com разбирал запрос и выдавал первую страницу статьи с id 1234.
Это важно, поскольку на ныне существующие страницы у многих, я думаю, есть ссылки с внешних сайтов. Не хотелось бы, чтобы эти ссылки стали мёртвыми...
В принципе, такое решается и через mod_rewrite или же сохранением неудалёнными старых статических страниц после обновления скрипта, но всё же чудесно было бы, если бы проблема решалась в самом скрипте.
Но это уже речь о динамике, поэтому к альфа-версии не относится :-)
OmulМожно свои пожелания в копилку? А можно сделать, чтобы шаблоны были с расширением HTM или HTML а не TXT, а то их править невозможно в дримвьюере не переименовав. Я так и делаю, и меня это напрягает больше всего. Кстати, можно ли в текущей версии так сделать? SQL - очень хорошо. Еще для полного счастья не хватает тега количества комментов к статье.
Можешь поэксперементировать следующим образом: берёшь все файлы скрипта, кроме файлов с данными, открываешь их в каком-нибудь Aditor\'e или любом другом редакторе, позволяющем автоматически производить одновременную замену по большому количеству файлов (дримвивер, по-моему, по cgi и pl файлам замену не делает при замене "по всему сайту") и просто в лоб меняешь по всем файлам "txt" на "html", потом меняешь расширение шаблонов... Должно получиться (в любом случае локально сначало поэксперементируй - сам не пробовал). Правда, так файлы для SSI-include\'ов тоже превратятся из TXT в HTML, но это не беда :-)
-
Green Kakadu
Выглядит все неплохо...
Насчет урлов, имхо это в некоторых случаях уже превращается в фетиш, мне кажется, чем короче - тем лучше. Была мысль прибавлять к названию файла страницы что-то по желанию автора,т.е. ../../../moj_super_rasskaz-123p1.htm но выглядит это довольно глупо
А возможно вместо ID в URL использовать только moj_super_rasskaz?
Т.е. ../../../moj_super_rasskaz.htm.
Насчет комментариев, можно поробовать прикрутить к ним фильтр спама Байеса (точно не помню как пишется), чтобы спам автоматом отливливал. Можно посмотреть как это сделано в Drupal, модуль spam (правда там на PHP). Впоследствии он неплохо может отлавливать спам в комментариях и скрывать их как сомнительные, чтобы админ потом сам решил, спам это или нет. Если нужно, могу дать ссылку на Drupal и сам модуль. Думаю такой фильтр бы не помешал.
Посмотрел новое название... Unews CMS. Т.е. это уже планируется больше чем просто система публикаций? А что еще возможно кроме собественно публикации статей? К примеру, возможно регистрация простых пользователей (не авторов), чтобы они потом могли постить комментарии от своего зарегистрированного ника? Это конечно не основной атрибут CMS, просто это первое что пришло в голову. :)
Галереи, опросы, каталоги чего-либо, будет возможно? :)
-
CTN:
какой-нибудь index.pl, расположенный в корневой директории site.com разбирал запрос и выдавал первую страницу статьи с id 1234. Это важно, поскольку на ныне существующие страницы у многих, я думаю, есть ссылки с внешних сайтов. Не хотелось бы, чтобы эти ссылки стали мёртвыми... В принципе, такое решается и через mod_rewrite или же сохранением неудалёнными старых статических страниц после обновления скрипта, но всё же чудесно было бы, если бы проблема решалась в самом скрипте.
да, это относится к конвертеру - при переносе со старого санитара на новую версию, id статей скорее всего поменяется, поэтому придется в базе (оставить ту же berkeley) хранить таблицу соответствия, старый id -> новый. Статья однозначно отыскивается по id (id категории не нужен). Проблема может быть с тем что у многих стоит несколько санитаров параллельно. Впрочем видно будет. Заглянувший:
А возможно вместо ID в URL использовать только moj_super_rasskaz? Т.е. ../../../moj_super_rasskaz.htm.
можно, только я от этого отказался потому как:
1. основна задача обеспечить уникальность этого названия. Когда несколько тысяч статей/новостей одной тематики это имхо непросто. Можно титул конечно в латиницу переводить, но все равно доп.проверки
2. использование для идентификации статьи "буквенный" id (а это в случае динамики будет так, т.е. id "moj_super_rasskaz" - не очень удачный вариант в смысле производительности (БД с числами работает значительно быстрее + числа меньше места занимают). Т.е. я на эту идею забил, появится система, может что-то и прикрутится для желающих (как я сказал, методы генерирующие пути/урлы вынесены в одно место)
Заглянувший:
Насчет комментариев, можно поробовать прикрутить к ним фильтр спама Байеса (точно не помню как пишется), чтобы спам автоматом отливливал. Можно посмотреть как это сделано в Drupal, модуль spam (правда там на PHP). Впоследствии он неплохо может отлавливать спам в комментариях и скрывать их как сомнительные, чтобы админ потом сам решил, спам это или нет.
спасибо, гляну. Drupal я на днях скачал :) правда не знал о том, что там есть такая фишка (читал что у него хорошая система кеширования)
Заглянувший:
Галереи, опросы, каталоги чего-либо, будет возможно?
галерея - это всего лишь определенный тип документа (от статьи мало чем отличается), т.е. это возможно. Опрос.. Думаю прикрутить свой SBT как отдельный компонент.
Заглянувший:
Unews CMS. Т.е. это уже планируется больше чем просто система публикаций?
Не, магазины к нему прикручивать не собираюсь, планируется что это будет все-таки система публикаций с большой свободой по выбору схем документов (не только дополнительные поля, а различные варианты обработки для различных типов документов)Заглянувший:
возможно регистрация простых пользователей (не авторов), чтобы они потом могли постить комментарии от своего зарегистрированного ника?
Да, возможно, это ж уже будет зависеть от системы комментариев, а не от самой системы публикаций. По хорошему, можно было бы вообще систему комментариев на какой-нибудь движок средненького (без лишних наворотов, но не тормознутого) форума прикрутить и все :)
-
спасибо, гляну. Drupal я на днях скачал правда не знал о том, что там есть такая фишка (читал что у него хорошая система кеширования)
Этом модуль в стандартный комплект не входит, для последней версии его можно скачать здесь (http://drupal.org/files/projects/spam-4.6.0.tar.gz). Насчет системы кеширования... что-то мне особо не понравилось как кешируется форум на drupal.ru для гостей. Там есть "фишка", показывается сколько времени показывается с момента последнего ответа в теме (показывается на главной странице времени), так вот сколько не заходил, время не меняется (хотя должно увеличиваться), пока новый ответ не появляется. Думаю с остальным видом контента такая же история. Если только он часто не обновляется, тогда возможно и есть плюсы.
p.s. Заглянувший тоже я, но только на работе. :)
-
Green Kakadu:
не, все таки в одну папку пихать все нехорошо, можно либо к id привязываться, например хранить по 1000 в папке, т.е.
/news/hardware/4/4324p1.*
(т
пожалуй да, это наиболее разумный варинт, может даже было бы лучше что б эта фишка была опциональна, т.е. можно было бы самому выбирать какое кол-во материалов будет храниться в одной папке.
Тут сразу вытекают, положительные последсвия поисковой оптимизации, а особенно хорошей запоминаемостью, обычным посетителеям. Им скажем легче запомнить /news/soft/1/24p1.* чем /2006/06/12/321p1.*
-
majix:
Им скажем легче запомнить /news/soft/1/24p1.* чем /2006/06/12/321p1.*
а зачем им это запоминать???
Другое дело, что глядя на /news/soft/ можно догадаться, что это относится к софту :) а даты мало информативны.
в общем, я уже с этим определился.
-
да и гугл учитывает именной путь :)
-
Green Kakadu:
в общем, я уже с этим определился.
???
выкладыйва какой из вариантов
-
majix:
выкладыйва какой из вариантов
с датой без привязки к категории.
-
будет ли возможность импорта базы на сервер ?
-
Green Kakadu
Ну когда же мы увидим новую версию?
-
phprus на днях. Все активно интересующиеся (т.е. тот кто тут проявляет активность) будут оповещены по ПС.
majix:
будет ли возможность импорта базы на сервер ?
поподробнее.. по идее, все импорты/экспорты можно проводить непосредственно через утилиты mysql, пока на эти фишки (через веб интерфейс системы) не заморачиваюсь. Если интересует воз-ть что-то кидать на локалхосте (например под вин), а потом импортировать это в веб базу, то возможно, т.к. под вин система отлично работает, без всяких заморочек, единственно что ID генерируются через AUTO_INCREMENT соотв. могут на двух базах не совпадать.
-
А остальным...
:(
-
ToXaNSK:
А остальным...
в любом случае будет объявление на этом форуме + наверное в новостях и в рассылке WebScript.Ru
Не стоит рассчитывать, что альфа версия это уже что-то готовое, это скорее демо - я показываю всем вам, что же это такое будет, все интересующиеся смотрят, высказываются,предлагают, тестируют особо интересующиеся посмотрят код и может что-нибудь предложат. Более менее годная к использованию система будет к бета версии
-
Green Kakadu:
поподробнее..
именно импорт с локалки.
Green Kakadu:
единственно что ID генерируются через AUTO_INCREMENT соотв. могут на двух базах не совпадать.
можешь про это подробнее...
т.е. после импорта у всех материалов просто поменяются id, со всеми вытекающими ?
-
Green Kakadu
ID генерируются через AUTO_INCREMENT соотв. могут на двух базах не совпадать.
А нельзя ли при конвертации сначала делать список существующих ID, а потом если определённый ID отсутствует добавлять вместо статьи какое-нибудь общее сообщение (вроде "статья отсутствует")?
Т.е., к примеру, есть статьи в старой базе с ID 1, 5, 6, 7, 8, 10... — при конвертации добавляем в базу сначала первую, затем вместо отсутствующих 2-й, 3-й и 4-й добавляем какое-то сообщение по умолчанию, затем 5-8, вместо 9-й снова значение по умолчанию и т.д.
Так новые ID будут совпадать со старыми (а после конвертации можно будет удалить все несуществовавшие статьи)
-
majix
т.е. после импорта у всех материалов просто поменяются id, со всеми вытекающими ?
Получается, что да.
-
CTN:
Так новые ID будут совпадать со старыми (а после конвертации можно будет удалить все несуществовавшие статьи)
да ,в общем-то можно и наверное так и нужно сделать.
тогда проще обрабатывать будет переходы по старым урлам статей на новые. majix:
именно импорт с локалки.
majix:
т.е. после импорта у всех материалов просто поменяются id, со всеми вытекающими ?
с локалки проблем нет, т.к. никаких вытекающих последствий там не видно :) ну и что, что разные? Об этом думать ИМХО рано еще :)
-
какая-нибудь открытая лицензия (GPL или что-то типа того) -это 100%
Это хорошо. Потому что и та лицензия что была – серьезно сдерживала развитие системы.
Есть предложение. Невысокая популярность первой версии скрипта обусловлена отсутствием какого бы то ни было набора приличных базовых скинов. Думаю что стоило бы бросить клич на форумах дизайнеров, потому что темы открытые здесь врядли кем-то кроме программеров просматриваются. А дизайнеры из них – никудышные.
Из каких-либо особенных модулей ничего не использовалось, т.е. подойдет обычный хостинг с CGI (все необходимые модули будут в составе дистрибутива они чисто перловые). Единственное что не помешает - наличие ImageMagic чтоб делать к картинкам превьюшки.
Нетребовательный хостинг – это первое дело. Только вот как обстоят дела с поддержкой библиотеки GD?
-
Дайте потестить бету версию!
-
Cyberinfo:
Дайте потестить бету версию!
немножечко терпения :)
я понимаю, что всех достал "завтраками".. но выход в свет - дело серьезное. Ближайшие два-три дня, все "закрыто" тестится на сервере вебскрипта.
-
Будем ждать!
-
Когда бета будет ? Достаточо ли она юзабильная и надежная она будет ? Можно ли ее будет небоясь ставить как осн. ?
-
Ну че не пора ли выложить версию?
-
Анонс альфа-версии:
http://forums.webscript.ru/showthread.php?s=&postid=129919#post129919
http://gnezdo.webscript.ru/unews_test Unews в тестовом режиме