Быстро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 для обработки - это две большие разницы
во-вторых, как все таки поступать с урла-ми сторонних компонентов?

[Dead Krolik]

Почему я не люблю /content/view/xx/zz/? Потому что там нет ключевых слов. Сеф давно уже перестал быть штукой, которая служит для запоминания чего-то там. Гугль/яндекс уже давно очень симпатично делает жирными ключевые слова, если они есть в урле.

[VETERINAR]

Ребят, ЧПУ это не только красивые имена.

Возьмём ссылку:

syte.ru/razdel/categoriya/material.html

Видим материал какого-то раздела, какой-то категории. Стираем имя материала из ссылки:

syte.ru/razdel/categoriya/

Если у нас ЧПУ, то по этой ссылке мы должны видеть список материалов раздела и категории. Стираем дальше.

syte.ru/razdel/

Если у нас ЧПУ, то тут мы должны видеть список категорий раздела


Вот оно как должно быть. Вот самый кайф ЧПУ.

[beliyadm]

Вот оно как должно быть. Вот самый кайф ЧПУ.

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

Гугль/яндекс уже давно очень симпатично делает жирными ключевые слова, если они есть в урле.

кто из знатоков сеошников может аргументированно подтвердить? Ибо что там любят поисковики - не знает никто (да и предмет любови у них меняется периодически)

[VETERINAR]

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

Я названия движков просто не знаю, просто кучу сайтов таких видел. Да и по URL трудно определить движок, если хорошо его не знаешь и шаблон полностью уникален.  Кстати, с помощью OpenSef делал так, но приходилось, конечно, вручную некоторые URL добавлять для создания эффекта.

кто из знатоков сеошников может аргументированно подтвердить? Ибо что там любят поисковики - не знает никто (да и предмет любови у них меняется периодически)

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

+ мне не однократно как в Яндекс, так и Гугл выдавал результаты, когда ключевик был ТОЛЬКО в ссылке на страницу. Даже на самой странице его не было. Это уже года полтора так точно. Так что под сомнение ставить это преимущество не стоит.

[userxp]

а поисковик будет выделять в url русское ключевое слово, написанное по-английски?
народ, вы не чего не перебарщиваете?

[VETERINAR]

а поисковик будет выделять в url русское ключевое слово, написанное по-английски?
народ, вы не чего не перебарщиваете?

http://yandex.ru/yandsearch?text=televizor&lr=187

Восьмой сайт по списку. ( www.peoples.ru/art/music/rock/televizor ), "televizor" выделено.

Или что-то не так понял?

[userxp]

нет. не так.
почему ищешь "televizor", а не "телевизор"???

http://yandex.ru/yandsearch?text=%D1%82%D0%B5%D0%BB%D0%B5%D0%B2%D0%B8%D0%B7%D0%BE%D1%80&lr=187
3-е место:

Телевизоры . Плазменные телевизоры, ЖК телевизоры, LCD. Цены, описание ...
www.mobila-ua.com/magazine/televizoru.php  · 46 КБ

слово televizor в ссылке НЕ выделено
ибо можно написать televisor, telewizor и т.д.

[VETERINAR]

Держи другую ссылку

Видишь, русское название тоже выделяет

[userxp]

от жеж... ну шо ты выкручиваешься?
ссыла-то в UTF-8 и с русскими буквами. тебя это устраивает?
ну так в чем проблема - делайте. не вопрос.

я же сказал про другое - "конвертация" русского названия в английскую транскрипцию ни к чему не приведет

[VETERINAR]

тебя это устраивает?

А почему нет?

я же сказал про другое - "конвертация" русского названия в английскую транскрипцию ни к чему не приведет

На тебе Первая ссылка. Поисковик транслитизировал запрос и подчеркнул слово "kursk" в адресе "www.kursk.ks.ua".

И сылка ниже:

"Работа в Курске - www.vipmarket.org"

vipmarket.org/city/69/kursk/ - тут kursk тоже болдом.

Да там вообще вся страница примерами напичкана.

Сдавайся

[userxp]

а ну так это уже гугл.
вот за это я и спрашивал.
но! это скорее исключение, чем правило
потому, что чем длиннее/сложнее слово, тем выше вероятность промаха ("курск" - простое слово)
а еще есть "варианты", скажем, как писать gretsia/greece/ellada???

или возьмём название некой категории "как построить железную дорогу" и материалы на эту тему...
имхо - вы воюете с ветряными мельницами

[VETERINAR]

Гугл контролирует русскую аудиторию сразу же после яндекса. С него траффик тоже очень приличный. Поэтому "а ну так это уже гугл" говорить некорректно.

"но! это скорее исключение, чем правило", да ну какое же исключение, когда это уже полтора года как существует

Хорошо, возьмем запрос "как построить железную дорогу". Если в url будет слова "dorogu", "postroit" и т.п. ( главное, чтобы транслит был правильный ), то он их выделит.

Т.е. http//www.site.ru/razdel/categoriya/kak_postroit_geleznuju_dorogu_u_sebya_v_tualete.html

Гугл выведет как:

http//www.site.ru/razdel/categoriya/kak_postroit_geleznuju_dorogu_u_sebya_v_tualete.html

[userxp]

главное, чтобы транслит был правильный

ТАК ВОТ с этого и надо начинать!
любой механизм может быть уничтожен плохим механиком

[Dead Krolik]

Ну, ваще говоря, на транслит даже госты есть.

[userxp]

можно подумать, что их будут придерживаться...

я не говорю, что не стоит над этим думать, ноооо....

[Dead Krolik]

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

[userxp]

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

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

зы. а по опенсеф надо еще хорошенько пройтись, что бы его быстродействие вычистить

[VETERINAR]

вопрос же не в том, где и как хранить, а КАК доставать быстрее

И при этом не завалить сервер

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

ой, адни тока разговоры 

[VETERINAR]

ой, адни тока разговоры

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

[Dead Krolik]

Ладно. Держите что есть на данный момент. Компонент ставим как обычно. Все расширения запиханы отдельно не потому, что мне лень, а потому что так проще будет по фтп, например, права выставлять. Тупо копируем их в папку /components/com_sef/sef_ext/.

Не надо ожидать чуда. Просто еще один сеф. С минимальными опциями.

Что делать с com_content не знаю до сих пор. Ту же категорию можно просмотреть двумя способами, а урл хочется иметь один.

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

Админка дохлая, сам хочу туда аякс, но пока что фиг с ним.

Урлы бывают обычные, которые делают расширения и пользователькие. Понятие префикса вынесено в конфиг, но я чую, что оно будет зашито жестко. Это быстрее и удобнее.

А я в Турцию поеду, ну вас с вашими Itemid'ами

[Lexx]

А я в Турцию поеду, ну вас с вашими Itemid'ами

Буду слать тебе смс-ки с баглистом

[Arkadiy]

http://yandex.ru/yandsearch?text=televizor&lr=187

Восьмой сайт по списку. ( www.peoples.ru/art/music/rock/televizor ), "televizor" выделено.

Или что-то не так понял?

Результаты исследования передернуты т.к. в поиске использовалось слово televizor которое и было выделено жирным в урл.

[Arkadiy]

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

[VETERINAR]

Результаты исследования передернуты т.к. в поиске использовалось слово televizor которое и было выделено жирным в урл.

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

[Timon_Crazy]

как понимаю тему умерла? или Кролик не вернулся из Турции?

P.S.
Вернулся к Joomla! так-что будет наблюдаться оживление темы )

[Timon_Crazy]

Предлагаю для включения в данную концепцию решения предложенного тут , просто многие разработчики SEF решений забывают запретить использование "старых" адресов, без SEF и позволяют использовать два вида адресации, что на мой взгляд вносит и неразбериху   со стороны пользователей и со стороны поисковых систем.
Также, в идеале, при включенном, стронем SEF компоненте, также использовать переадресацию с адресов стандартного SEF компонента на адреса стороннего компонента, чтобы они не потерялись и склеились с новыми адресами.
Ну и сделать, опционально, переадресация с адресов таких компонентов как OpenSEF, JoomSEF, при условии использывания данного решения, после того как какое то время использовались, указанные мною, SEF расширения .

[Dead Krolik]

Эх, с удовольствием застял бы в Турции. Или еще где-нибудь

Конечно я забил на это дело. У меня где надо все работает, а интереса я не заметил, поэтому тема не оживет.

[Вязной]

1. Хранить ЧПУ в файле - далеко не новое решение, и, к слову, удачное. Так что спорить смысла нет (имхо)
2. И гуглу и яндексу не все равно, они тоже разеный транслит понимают. В ранжировке, естественно, сильно не поможет, но плюшки есть.
3. Стоит задуматься об отказе от привязке к категориям, разделам... Слишком уж не гибко это все
4. ЧПУ надо писать не физически для джумлы. Главная задача - написать общий регламент для веток, чтоб не было заморочек с компонентами. Просто некому этим заниматься.

[Timon_Crazy]

Эх, с удовольствием застял бы в Турции. Или еще где-нибудь

Конечно я забил на это дело. У меня где надо все работает, а интереса я не заметил, поэтому тема не оживет.

может все таки совместными усилиями оживим тему? востребованно.

1. Хранить ЧПУ в файле - далеко не новое решение, и, к слову, удачное. Так что спорить смысла нет (имхо)
2. И гуглу и яндексу не все равно, они тоже разеный транслит понимают. В ранжировке, естественно, сильно не поможет, но плюшки есть.
3. Стоит задуматься об отказе от привязке к категориям, разделам... Слишком уж не гибко это все
4. ЧПУ надо писать не физически для джумлы. Главная задача - написать общий регламент для веток, чтоб не было заморочек с компонентами. Просто некому этим заниматься.

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

[Vladzimir]

А почему бы не использовать нароботки от JPromoter.
В плане хранения настроек для каждого компонента в .xml файлах.
Тогда ЛЮБОЙ ЮЗЕР сможет настроить под себя, да и создание новых настроек для нового компонента займет всего 30 минут.

И объясните мне, почему нельзя хранить КАЖДУЮ ссылку в ОТДЕЛЬНОМ файле, а не в текстовой базе ссылок???

[Timon_Crazy]

А почему бы не использовать нароботки от JPromoter.
В плане хранения настроек для каждого компонента в .xml файлах.
Тогда ЛЮБОЙ ЮЗЕР сможет настроить под себя, да и создание новых настроек для нового компонента займет всего 30 минут.

И объясните мне, почему нельзя хранить КАЖДУЮ ссылку в ОТДЕЛЬНОМ файле, а не в текстовой базе ссылок???

если хранить каждую ссылку в отдельном файле - то на нормальном портале мы получим >2000-3000 файлов, а у ОС есть ограничение на кол-во файлов.
плюс, учтите, время на поиск данного файла, и его обработку.
ну и 100 юзеров в системе, активных - не один хостинг не выдержит + будет тормознее чем в БД.
тут важна мера.

[Vladzimir]

А как же тогда стандартый кеш работает?
Ведь на одну страницу он ищет до 20 файлов.

Вопрос. А если для организации базы ссылок использовать не название компонентов (типа com_content.db), а хеш урла страницы котора вызывается по типу md5(index.php?option=......ItemId=1).db, а уже в ней хранить все ссылки но только данной страницы.
Т.е. получаеться одна страница - одна база ссылок. Дмаю что это должно убрать недостатки двух предыдущих вариантов. У первого варианта - при большом количестве ссылок в одной базе возникают тормоза, а второго - очень большое кол-во файлов что то-же не гуд. А так получается что создается оптимальное кол-во файлов с оптимальным количеством ссылок в нем.

А все-таки как на счет хранение настроек для каждого компонента в .xml файлах???

[Timon_Crazy]

А как же тогда стандартый кеш работает?
Ведь на одну страницу он ищет до 20 файлов.

Вопрос. А если для организации базы ссылок использовать не название компонентов (типа com_content.db), а хеш урла страницы котора вызывается по типу md5(index.php?option=......ItemId=1).db, а уже в ней хранить все ссылки но только данной страницы.
Т.е. получаеться одна страница - одна база ссылок. Дмаю что это должно убрать недостатки двух предыдущих вариантов. У первого варианта - при большом количестве ссылок в одной базе возникают тормоза, а второго - очень большое кол-во файлов что то-же не гуд. А так получается что создается оптимальное кол-во файлов с оптимальным количеством ссылок в нем.

А все-таки как на счет хранение настроек для каждого компонента в .xml файлах???

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

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

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

опять же разбор xml более ресурсоемок чем sql, также при активном сайте, чтение настроек (если без кеша), замедлил рабоут сайта, ибо чтение с файлов, более медленнее чем работа с базой.

отказываться от базы конечно не стоит, если для чпу будет делаться не более 1-3 запросов, а не 40-200 как на всех сторонних сефах.

[Timon_Crazy]

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

[Vladzimir]

На счет хранения настроек в xml-файлах вы наверное немправильно меня поняли!
Даній пример реализован в JPromoter и позволяет за пять минут простому юзеру склепать СВОИ правила генерации урлов для каждого компонента. К тому-же настройки при каждом обращении не распарсиваются, а только если отсутствует ЧПУ-ссылка.
Я не предлагаю хранить ссылки в xml. А все сторонние сефы правила генерации ссылок для каждого компонента реализуют через "типа плагины" т.е. в файлах пхп. А для того что-бы их написать надо знать пхп. А здесь все просто. ЧПУ ссылки нет - распарсили правила-настройки, сгенерировали ЧПУ ссылку.

Очень советую найти JPromoter (он хоть и платный но в инете его полно) и посмотреть как там это реализовано. И я считаю что это намного проще для пользователя.
А вот уже где и как хранить ссылки - да этот вопрос остается открытый.

[Timon_Crazy]

Вопрос: а как в xml файле указать, например, что надо вставить в ссылку название категории товара, название товара, да еще все в транслите? (пример для магазина виртуемарт) Вам не кажется что это уже как раз и надо "php плагином" делать.
а пользователю надо будет часто генерировать правила для урлов?  мне кажется нет. темболее компоненто-писатели могут включать готовый набор правил, они то знают php (ну почти все )
проще для пользователя != хорошо для проекта
должна быть середина, в зависимости от задачи.
хотя для простых случаев Ваше предложение подходит, но надо давать возможность более полной настройки.

[Vladzimir]

Код:

<?xml version="1.0" encoding="utf-8"?>

<sefconfig component="com_virtuemart">
    <cond Itemid="*" page="shop.browse" category_id="*" limit="*" limitstart="*">
        <tpl>{lang}/{holder}/{category}{orderby}{kw}-{page}.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.browse" category_id="*">
        <tpl>{lang}/{holder}/{category}{orderby}{kw}.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.search">
        <tpl>{lang}/{holder}/Search-shop.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.registration">
        <tpl>{lang}/{holder}/Shop-registration.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.parameter_search">
        <tpl>{lang}/{holder}/Parameter-Search-shop.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.getfile" product_id="*" file_id="*">
        <tpl>{lang}/{holder}/{product}/{file}.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.view_images" product_id="*">
        <tpl>{lang}/{holder}/{product}/images.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.view_images" category_id="*" product_id="*">
        <tpl>{lang}/{holder}/{category}/{product}/images.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.product_details" category_id="*" product_id="*" flypage="0" manufacturer_id="0">
        <tpl>{lang}/{holder}/{category}/{product}.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.product_details" product_id="*">
        <tpl>{lang}/{holder}/{category}/{product}.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.product_details" category_id="*" product_id="*" flypage="*" manufacturer_id="*">
        <tpl>{lang}/{holder}/{category}/{manufacturer}/{product}.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.product_details" product_id="*" flypage="*">
        <tpl>{lang}/{holder}/Product-detail/{product}.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.index">
        <tpl>{lang}/{holder}/index.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.cart" product_id="*">
        <tpl>{lang}/{holder}/{product}/add-to-cart.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.cart">
        <tpl>{lang}/{holder}/Cart.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.browse">
        <tpl>{lang}/{holder}/All-Products.html</tpl>
    </cond>
    <cond Itemid="*" page="shop.infopage" vendor_id="*" output="*">
        <tpl>{lang}/{holder}/{vendor}/infopage-{output}.html</tpl>
    </cond>

    <cond Itemid="*" page="checkout.index" ship_to_info_id="*" shipping_rate_id="*" checkout_next_step="2">
        <tpl>{lang}/{holder}/{shiprate}{nextstep}/shipto-code-{shipto}/checkout.html</tpl>
    </cond>
    <cond Itemid="*" page="checkout.index" mosmsg="*">
        <tpl>{lang}/{holder}/checkout/{mosmsg}.html</tpl>
    </cond>
    <cond Itemid="*" page="checkout.index" ssl_redirect="*">
        <tpl>{lang}/{holder}/{ssl}/checkout.html</tpl>
    </cond>
    <cond Itemid="*" page="checkout.index">
        <tpl>{lang}/{holder}/checkout.html</tpl>
    </cond>
     <cond Itemid="*" page="checkout.paypal_pro_ec_error">
        <tpl>{lang}/{holder}/{message}/checkout.html</tpl>
    </cond>
  
    <cond Itemid="*" page="order.order_print" order_id="*">
        <tpl>{lang}/{holder}/print-order/{oid}.html</tpl>
    </cond>
   
    <cond Itemid="*" page="account.index">
        <tpl>{lang}/{holder}/account.html</tpl>
    </cond>
    <cond Itemid="*" page="account.shipping">
        <tpl>{lang}/{holder}/account/shipping-information.html</tpl>
    </cond>
    <cond Itemid="*" page="account.billing" next_page="*">
        <tpl>{lang}/{holder}/account/billing-information/{next}.html</tpl>
    </cond>
    <cond Itemid="*" page="account.billing">
        <tpl>{lang}/{holder}/account/billing-information.html</tpl>
    </cond>
    <cond Itemid="*" page="account.shipto" next_page="*">
        <tpl>{lang}/{holder}/account/ship-to/{next}.html</tpl>
    </cond>
    <cond Itemid="*" page="account.shipto">
        <tpl>{lang}/{holder}/account/ship-to.html</tpl>
    </cond>
    <cond Itemid="*" page="account.order_details" order_id="*">
        <tpl>{lang}/{holder}/account/order-details/{oid}.html</tpl>
    </cond>
   
    <cond Itemid="*">
        <tpl>{lang}/{holder}.html</tpl>
    </cond>
    <!-- Variables -->
    <var name="file" type="query">
        <query>SELECT `file_title` FROM `#__vm_product_files` WHERE `file_id` = {file_id}</query>
        <empty>?</empty>
    </var>
    <var name="category" type="query">
        <query>
SELECT `category_name`, `category_id`, category_id, category_parent_id FROM #__vm_category AS c
LEFT JOIN #__vm_category_xref AS x ON category_id = category_child_id
WHERE `category_child_id` = {category_id}

 
</query>
        <empty>?</empty>
    </var>
    <var name="product" type="query">
        <query>
SELECT `product_name`, `product_id` FROM `#__vm_product` where `product_id` = {product_id}
</query>
        <empty>?</empty>
    </var>
    <var name="shipto" type="query">
        <query>SELECT `mf_name` FROM `#__vm_manufacturer` WHERE `manufacturer_id` = {ship_to_info_id}</query>
        <empty>?</empty>
    </var>
    <var name="manufacturer" type="query">
        <query>SELECT `mf_name` FROM `#__vm_manufacturer` WHERE `manufacturer_id` = {manufacturer_id}</query>
        <empty>?</empty>
    </var>
    <var name="page" type="query">
        <query>SELECT ({limitstart} div {limit}) + 1</query>
        <empty>0</empty>
    </var>
    <var name="mosmsg" type="string">
       <value>{mosmsg}</value>
    </var>
    <var name="shipto" type="string">
       <value>{ship_to_info_id}</value>
    </var>
    <var name="shiprate" type="string">
       <value>{shipping_rate_id}</value>
    </var>
    <var name="message" type="string">
       <value>{message}</value>
    </var>
    <var name="nextstep" type="string">
       <value>{checkout_next_step}</value>
    </var>
    <var name="next" type="string">
       <value>{next_page}</value>
   </var>
   <var name="ssl" type="string">
       <value>{ssl_redirect}</value>
   </var>
   <var name="oid" type="string">
       <value>{order_id}</value>
   </var>
   <var name="holder" type="query">
        <query>SELECT `name` FROM `#__menu` WHERE `id` = {Itemid}</query>
        <empty>?</empty>
   </var>
   <var name="uid" type="string">
       <value>{user_info_id}</value>
   </var>
   <var name="lang" type="string" ifpresent="lang">
        <value>/{lang}</value>
   </var>
   <var name="orderby" type="string" ifpresent="orderby">
        <value></value>
   </var>
   <var name="kw" type="string" ifpresent="keyword">
        <value>/{keyword}</value>
   </var>
</sefconfig>

Вот код настроек для Виртуемарта для JPromoter.
Все просто и наглядно и главное ОЧЕНЬ гибко. Это по моему гораздо проще чем писать новый плагин. Например я без обширных знаний php смог создать за пол-часа для редкого компонента новіе настройки, по аналогии с представленніми настройками.
+ У JPromoter в связи с игнорированием Itemid нет дублирования ссылок.
ОЧЕНЬ РЕКОМЕНДУЮ его более внимательно изучить и взять все самое лучшее.

[Timon_Crazy]

JPromoter - платный компонент, по закрытой лицензии.
приведенные настройки - по мне так не проще php ) синтаксис разбора правил замудренный )

а как там без Itemid реализовали привязку меню и т.д. к странице? как?

[Vladzimir]

Он не по закрытой лицензии, а под GPL (только платный и с открытым кодом), правда только под 1.0.*.
А синтакиси и не такой уже и замудренный. Сначала лепим шаблоны урла, а потом уже для каждого шаблона пишем правило, или из запроса или из переменной. Просто после того как я пытался настроить Джумсеф, скоко матюгался, а потом приобрел JPromoter и дело пошло на поправку. + Я его немного допилил (всего один запрос), так он у меня теперь просто летает на хосте.

а как там без Itemid реализовали привязку меню и т.д. к странице? как?

Наверно е Вы опять немного не поняли. Привязка как была так и осталась, просто пригенерации ссылки не учитываеться/учитывается Itemid, т.е на одну ЧПУ ссылку в базу записываются разные урлы.
Например при запросе на одну ссылку /super-puper.html в базе могут быть ссылки такого вида:

index.php?option=com_content&task=view&id=11&Itemid=208
index.php?option=com_content&task=view&Itemid=208&id=11
index.php?option=com_content&task=view&id=11&Itemid=55

и даже такого вида

index.php?task=view&id=11&Itemid=208&option=com_content

Дело в том что очень часто разные модули плодят разного вида ссылки, как например последняя. Что кстати было в Виртуемарте и до сих пор осталось. Для этого я сначала пытался править код Виртуя, но в некоторых ситуациях оно всеравно не помогало.

[Vladzimir]

Кстати с 9 мая ВСЕ продукты с http://joomlaequipment.com теперь под GPL лицензией и в свободном доступе.

[newleax]

И на этом сдохло... тааак, пошла читать дальше...