БыстроSEF как концепция (взгляните, будьте то

[Dead Krolik]

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

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

Для примера сделан сеф только для com_content: просмотр статьи + просмотр раздела, com_rss и com_weblinks.

Жду тестирования по сути и общий взгляд на проблему.

Для установки - включить сеф + в .htaccess раскомментировать секцию для сторонних сефоф и оставить там только это

Код:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php

Одна из якобы фичей - убийство Itemid. Если он не нужен в принципе, то в /components/com_sef/main.ini надо сделать disable_itemid=yes.

P.S. Если будет версия под 1.5.х, то вполне возможно будет не чихая сделать кириллические урлы.
P.P.S. Выкладываю тут, а не на моем форуме, т.к. программистов тут поболее будет. Особенно (сам уже не помню почему) хочу услышать userxp, ибо с чего-то мне в голову взбрело, что он в этом шарит

Чуток обновил, инструкции те же: компонент ставим как обычно. Все расширения из sef_ext.zip просто копируем в папку /components/com_sef/sef_ext/ в распакованном виде.

[beliyadm]

Dead Krolik - я хоть и не UserXP, но задам сразу вопрос не вникая пока глубоко - что ты имеешь в виду под "убийство Itemid"?

[Dead Krolik]

>убийство Itemid
Полное уничтожение этой переменной из урлов. Мы теряем возможность привязки, но зато не будет разных урлов, указывающих на одно и тоже.

[beliyadm]

>убийство Itemid
Мы теряем возможность привязки

а тогда глупый вопрос - как реализовывать привязку модулей, элементов оформления к разным страницам\разделам?

[Dead Krolik]

Не понял ты меня. Я о том, что механизм Itemid уже сто раз обсуждали. Нет его - плохо, есть - тоже плохо.

Вообщем забей. Дело не в Itemid, не туда копаешь. 

Это просто как доп опция, вообще не стоящая внимания (ну и нафик я это вспонил )

[Arkadiy]

Привет Dead Krolik.
Проверил компонент на своем еще почти пустом сайте на локали, с меню работает нормально, заметил две непиятные вещи:
1. Главная страница имеет два (а то и три) адреса:
а) /
б) /index.php
в) /index.php?option=com_frontpage&Itemid=1
С двумя первыми можно управиться, а вот третий адрес - дублирование главной что есть не хорошо.
2. Ссылка с главного меню типа "Список - содержимое раздела" выдает страницу, на которой находятся работающие не SEF ссылки, далее (в содержимом категории) на открываемых страницах нормальные SEF ссылки.

Буду очень рад если доработаешь компонент до конца. Заранее большое спасибо.
P.S. А плагины для virtuemart и контактов сделаешь?

P.P.S. В списке транслитерации у тебя видимо "я" заменяется на "y", красивее было-бы на "ya". Посмотрел список - там все нормально, но при этом "Нормативная документация" выглядит как /_Normativnay_dokumentaciy/

[beliyadm]

Dead Krolik - ты попал, заставят теперь делать полноценный компонент SEF

[Arkadiy]

Dead Krolik - ты попал, заставят теперь делать полноценный компонент SEF

Взялся за гуж - не говори что не дюж.

[boston]

Кролик, негодяй!

[boston]

>Novosti/Poslednie_novosti/Spasibo_za_vbor_Joostina_98214a5e.html
98214a5e, это что бы людей пугать?

>index.php?option=com_content&task=view&id=4&Itemid=1:::***:::articles/Kratkie_novosti/Kratkie_novosti/Kratkay_novost
_3_98214a5e.html

В файле com_content.urls урлы некоторые переносятся на 2 строки, это зачем?

Компонент супееееееер!

[Dead Krolik]

Arkadiy все будет, если я сам оценю полезность данной затеи. Дубли фротпейджа это самое главное зло.

boston 98214a5e это и есть те самые левые переменные в запросе, которые не возможно никуда воткнуть. Например Itemid. Красиво пакуются в строку (ну нужно, например, какому-нибудь мамботу дописать свою переменную) и берется хэш.

Про перенос не знаю, может просто редактор у тебя такой

[Arkadiy]

Про перенос не знаю, может просто редактор у тебя такой

index.php?option=com_content&task=view&id=12&Itemid=32:::***:::articles/Prais-list/Prais-list/Prais-list
_RC_Bar
er-CS_0a19196f.html

выкопировал с листера тотал-командера с отключенным переносом строк

Заметил: переносы строк почти во всех случаях идут по знакам, которые не определены в таблице перекодировки, напрмер по мягкому знаку.

[Dead Krolik]

О. Значит косяк. И кажется я даже знаю в каком месте. Гран мерси.

[Arkadiy]

при чем перенесенные ссылки битые - вываливают на главную.

[userxp]

у... епрст... а у меня со временем звиздец....

[Arkadiy]

О. Значит косяк. И кажется я даже знаю в каком месте. Гран мерси.

А когда будет исправленный компонет?

[Dead Krolik]

От прст. Это же для пробы было. И вообще там они темные вещи в своих компонентах творят, это же надо - action у формы пропускать через sefRelToAbs(). Убить их мало. И в яваскрипт тоже через него ссылки пропускать. Я прямо на перепутье с этим com_content.

[elvin]

Дорогой Кролик, мы очень все хотим доработанный сеф) пожалуста-пожалуста-пожалуста-пожалуста! 
 

[eX]

Компонент очень ценный! Жду тоже обновленный релиз! Респект. Загрузка страничек - уменьшилась даже по ассоциативному ощущению в полтора раза!

[Dead Krolik]

От прст. Вы меня в неудобное положение ставите. Я уже от дяди бостона отбрыкиваюсь как могу тем, что вот мол я ленивый и в коммунисты не гожусь. И нечего на меня надеяться в быстросефе.

[..С...е...р...ы...й..]

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

[VETERINAR]

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

К сожалению не имею возможности провести полноценный тест на производительность, но всем нутром чувствую, что это засада.

Кстати, разве в unix-ах нет ограничение на количество одновременно открытых файлов или что-то подобного? Я слышал, что есть.

Не нравится мне это всё. ЭТо как бы шаг назад, имхо.

[Mitrich]

не верится, что работа с текстовыми файлами может быть быстрее работы с базой данных

ну в общем то каждой задаче свое решение
если можно 10-20 килобайт держать в памяти и активно их юзать а не спрашивать тыщу раз базу, то вполне оправдано

[VETERINAR]

Не знаю, думаю, изучу этот вопрос в скорем времени. Возможно удастся провести тесты на производительность. Отпишусь. Но пока отношусь очень скептически

[Dead Krolik]

Ты в чем-то прав. И на эту тему мы с дядей бостоном говорили. Так и не договорились. И там и сям есть плюсы, а разница начинается со скольки-то сотен килобайт. Где эти килобайты искать - вопросище.

[userxp]

нужен гибрид.
так сказать - золотая середина
имхо.
т.е., изначально нужен интеллектуальный модуль, который бы КАКТО распределял нагрузку (тока не спрашивайте как - я понятия не имею)

как по мне, так SEF-ссылки должны по максимуму строится в режиме on-fly и кэшироваться
но должны быть и "жесткие" ссылки в БД, привязанные к конкретному internal URL

ps. может, у каждой ссылки должен быть свой TTL ???

[Dead Krolik]

userxp все в наших руках. Давай поговорим. Я тему создавал не для того, что бы тут что-то готовое выкладывать. Я изначально не совсем верил в правоту такового подхода.

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

"Жесткие ссылки" - это я так понимаю "пользовательские ссылки"? Смысл хранить их в БД?

И вообще - нужен какой-то критерий, что бы ссылка лежала там или сям.

P.S. Про TTL не понял. Он вообще на что должен влиять?
P.P.S. Еще идея - если генерация ссылок на странице начинает хавать N% от генерации всей страницы, то есть повод подумать и ссылки перекинуть из одного хранилища в другое. Но не более чем идея. Критерий какой-то смутный.

как по мне, так SEF-ссылки должны по максимуму строится в режиме on-fly и кэшироваться

Нннет. А если предположим я изменил заголовок статьи и ссылка зависит от этого заголовка. Перегенерировалась. И бац - человек попадает из поисковика на неверный урл. Поисковикам может и по барабану, но как быстро они перегенерят урл. Тут конечно можно еще одну таблицу бабахнуть - редиректы после смены урлов: если в результате новой генерации урл отличается от старого.

Но мыслей чета мало. А победить урлы хочется. Я даже напишу компонент. Тока бы стратегию придумать.

[userxp]

попробую "набросать" в качестве бреда

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

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

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

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

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

для меня остается вопрос - как делать упреждающее чтение ссылок из БД?
тоже по совокупности факторов?
(я имею ввиду, что бы не производить обращение к БД по каждой ссылке индивидуально )

[Dutch]

мдя...
чем вам не нравится обычный сэф джумлы?

Раньше тоже на ЧПУ был помешан, но когда ссылка имеет вид типа:

http://www.site.name/ecology/doc/nadanna-dozvoliv-na-znesenna-zelenih-nasadzhen-krim-tih-shho-rozmishheni-na-zapovidnih-teritorijah-i-na-zemlah-derzhavnogo-lisovogo-fondu.html

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

Как по мне, то проще и лучше убрать лишнее из стандартного сэфа:

http://www.site.name/content/view/247/9/

на

http://www.site.name/content-view-247-9.html

или

http://www.site.name/content247-9.html

где, content - com_content (com_docman = docman, com_archive = archive) и т.д.

да и реализовать такое проще, просто взять да и немного по-умному переписать файл sef.php и добавить правила в .htaccess

Это как идея, которую реализовать не могу, так как не программер.

Но что мы получим с такой идеи?

1. поисковики не выдают результаты если вы ввели на русском, а ссылки в транслите (для ютф-8 такое срабатывает, см. википедию), посему мы получим немного легче запоминающийся юрль.
2. все страницы будут, как бы в первом уровне, относительно корня сайта, а это поискови любят.
3. ну и не будет у нас километровых юрлов (как пример, каталоги, магазины и т.д.)
4. не нужно ничего хранить в базах, так как мы используем механизм родного сэфа джумла, но немного переписанный и устроенный в качестве отдельного компонента, дабы не патчить систему.

[userxp]

Dutch,
во-первых, content/view/247/9/ и content-view-247-9.html для обработки - это две большие разницы
во-вторых, как все таки поступать с урла-ми сторонних компонентов?