Наши скрипты > Sanitarium WebLoG
SANITARIUM 2 ToDo List
Mikeo:
--- Цитировать ---
если каждому документы дать некое название напрмиер about-company или documents&reports или bla-bla-bla то если их хранить (в статике) все в корне сервера например то обращение к ним будет - http://www.your-server.ru/bla-bla-bla/ и все. И ссылка легко запомнится и в случае изменения принадлежности к категории (разделу) не нужно физически файл ни перемещать ни переименовывать, а тем более целые ветки каталогов!!! все фидически остается на своих местах. Это же удобно прежде всего тем что реальный инетовсикй адрес не меняется при переходе статьи (документа) из категории в категорию (раздела в раздел)!!! Вот я о чем.
--- Конец цитаты ---
majix:
хм, а не ругнется ли сервак, если материалов будет эдак 5000 ? ведь всё лежит в одной папке, при добавлении чего-то он ж ведь сначало читает а потом создает а потом обратно читает (ну это я сужу по фтп проге), на это ж тратися время, причем огромное, да и на 1-ом санитариуме были кое какие проблемы когда кол-во материалов превышало 1500, пробдема есть в скорости их добалвения, уже ниже в раза 4 чем была когда материалов было штук 10.
Green Kakadu:
--- Цитировать ---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 но выглядит это довольно глупо :)
Green Kakadu:
скриншоты:
просмотр информации о категории
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
так это все выглядит на сегодняшний день. сама админка работает тоже на шаблонах (а не как в первом санитаре где админ-интерфейс зашит в скрипте).
CTN:
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, но это не беда :-)
Навигация
Перейти к полной версии