unix.ginras.ru (План обновления проекта)

[charlie]

доработка напильником готового - это добавление новых глюков. и всего лишь.

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

Пожелания:
RSS
блочный дизайн (css, а не таблицы)
возможность прикручивания сторонних средств (см. Орфус)
возможность менять декор, не трогая движка.

Насчет блочного дизайна весьма сомневаюсь....... <_<

[StraNNicK]

Ок. С движком убедили (правда не уверен - нужен ли он вообще... ). Но Бог с ним.
Что Вам не нравится в блочном дизайне? ИМХО - следование стандартам - unix-way.

[charlie]

Ок. С движком убедили (правда не уверен - нужен ли он вообще... )

Если требовать от сайта того, что требует alv, то спокойно можно обойтись SSI. Ну а если хочется несколько (много) большего, то естественно без движка не обойтись. Лично я за движок, но за движок грамотный. Т.е. не просто взяли ПХП и написали нечто, выполняющее функции того же SSI, плюс еще, допустим, оценку популярности статей. А вдумчиво спроектировали, подумали об отделении кода от дизайна, добавили элементы back-офиса, модульность и т.п..... А иначе за движок и браться смысла нет!!!!

Что Вам не нравится в блочном дизайне? ИМХО - следование стандартам - unix-way.

Согласен, стандарты - это хорошо. Но не надо забывать о том, что уж очень много сейчас "нестандартных" стандартов. Разработчики Opera порой пишут ее движок так, что страницы, которые отображались в предыдущих версиях ее нормально, в следующей показываются неправильно. (Про IE я вообще молчу). Поэтому не так уж много сейчас сайтов, где бы использовался только блочный дизайн. Вот хотя бы такой пример: заходим на сайт http://www.cssbeaty.com сначала огненной лисой, а затем ИЕ(у меня 5.5, но сомневаюсь, что в 6-ом будет иначе). Чувствуете разницу?
Да или возмем тот же XML. Он соответствует стандартам, все хорошо. Допустим я решил писать некий сайт ну на ПХП. Формируется XML страницы, пропускается через XSLT процессор -> на выходе HTML. Модель неплохая, отделимость кода от дизайна и т.п. Ну и через некоторое время, глядя на загрузку сервера, думаешь: А зачем мне это надо было? Ресурс вроде не такой большой, проще было бы написать свой шаблонизатор. Пусть он не был бы таким универсальным, но свое дело делал бы!!!! Так что же лучше в данном случае: универсальный стандарт или самопальный язык шаблонов?
Фу ты черт, ну и понесло же меня
Напоследок приведу пару ссылок по теме:
http://hostinfo.ru/htmltree/hosting/web/si...css/page-layout
http://www.hostinfo.ru/tree/hosting/web/si...gy/css/doctype/

[zenwolf]

Ок. С движком убедили (правда не уверен - нужен ли он вообще... ). Но Бог с ним.
Что Вам не нравится в блочном дизайне? ИМХО - следование стандартам - unix-way.

А как вы сами понимете " стандарт unix-way " ?

[alv]

2charlie
"Если требовать от сайта того, что требует alv, то спокойно можно обойтись SSI. Ну а если хочется несколько (много) большего, то естественно без движка не обойтись. Лично я за движок, но за движок грамотный"... и далее

Я от сайта требовал поначалу только того, что в принципе мог сделать сам - написать движок мне откровенно слабо:-) Но раз Инга влялась за это дело - я ЗА обеими руками и ногами. Преимущества движка (ИМХО) заключаются в первую очередь в базе данных для хранения материалов. Это дает возможность организации нормального поиска (а не слямзенного с Google), включения одних и тех же статей в разные разделы (2Инга! - первое пожелание) - я сейчас как раз столкнулся с этой проблемой при включении в структуру переводов из Дрю. С одной стороны, она пишет про FreeBSD, и место им - в этом разделе. С другой стороны, методы (а в значительной степени и инструменты) администрирования - практически одинаковы во всех юниксах, и ее статьи про руткиты или DHCP так и просятся в раздел администрирования, тем более что он пока практически пустой:-). Мне, конечно, не лениво было бы сделать это и руками, но с ростом количества материалов вероятность ошибок будет нарастать в геометрической прогрессии.

А вот оценка популярности статей как раз не нужна - на то логи сервера есть, или на худой конец - top.list.ru, тут каждый кликом мыши проголосует:-)

2Инга
Пока писал - родилось второе даже не пожелание, а информация к размышлению:-) (голосом Копеляна за кадром)
Можно ли технически реализовать разворачивающиеся 2- или 3-уровневые списки для оглавлений разделов, как это сделано в статьях на IBM'овском DeveloperWorks? Там это, кажется, JavaScript, работающий крайне медленно.

2All
К вопросу о блочном/табличном дизайне. Я лично табличный дизайн очень не люблю (то, что он есть в текущей версии - результат спешки и безвыходности, потому что фреймовый дизайн я не люблю еще больше). Проблема отображения в зависимости от браузера - да, есть такое дело. Однако она есть и при табличной системе - уже в зависимости от разрешения (если не делать, конечно, "резиновые" таблицы - с результатом вполне предсказуемым, то есть скверным).

Про XML я сейчас говорить бы не хотел - ИМХО, это такое же светлое будущее человечества, как коммунизм и UTF8:-) А с "А зачем мне это надо было?" - полностю согласен:-)

[Evgen]

Здорово!
Вот вы тут умные вещи говорите (и правильные), но есть одно требование с которым все согласятся - скорость. Очень не хочется чтобы проэкт развился до неповоротливого монстра (типа дистров на ...дцать дисков). В настоящем виде (какой он сейчас) он этому требованию отвечает. Давайте вспомним , что есть люди с ужасно тормозными линиями ( 19000 бит/сек).
Чим проще - тем меньше ошибок, выше скорость, да и удобства можно достичь не наворачивая понтов, а сделав логичное и простое перемещение по сайту.

[StraNNicK]

Насчет движка - убедили. Предлагаю перед тем, как писать код сформировать ТЗ. Чем снимем массу проблем в будущем.
Насчет блочного дизайна - учитывая, что наворотов практически не будет - как раз можно реализовать все его преимущества. При этом размер странички будет меньше, а сама она (в виде кода) - логичнее.
Насчет многоуровневых меню - если уж делать css, то делать всё. Вот пример. Обратите внимание на меню css/edge в левом верхнем углу. Что если браузер не поддерживает css? Ничего страшного - меню он всё равно увидит.
Так что, Алексей - ТЗ по дизайну/декору - в студию..

[alv]

2StraNNicK

1)ТЗ по движку - думаю, в свободное от сборки хтмэлок время:-)
2)касаемо блочного дизайна - я сугубо ЗА (впрочем, своб позицию уже высказывал
3)меню через css - посмотрел, впечатляет; но я имел ввиду немного другое, как на
http://www-106.ibm.com/developerworks/view...ux/articles.jsp

Если отсортировать по авторам и щелкнуть на какой-либо фамилии, должно выглядеть примерно так:
http://www-106.ibm.com/developerworks/view...thor&search_by=

Но это, насколько я понял, JavaScript со всеми вытекающими:-)

4)"ТЗ по дизайну/декору - в студию" - будет; только я сейчас шибко закопался с сортировкой и чисткой текстов - каждое утро кажется, что вот-вот закончу, а к концу дня - опять конца/края не видать; но сделаю обязательно - лучше кривое ТЗ чем вообще никакого:-)
Я так понимаю, для Вас самое важное на первом этапе - элементы, которым нужно приписать стили, и их иерархия? Попробую сочинить завтра утром


2Evgen
Назначение и css, и _хорошего_ движка, в том числе, и в том, чтобы свести к минимуму назрузку на сеть, за счет того, что повторяющиеся данные (скажем, оформление страницы) передаются один раз и кэшируются на локальной машине. То, что со многими движками страницы начинают дюже тормозить - это издержки не идеи, а ее реализации:-). Впрочем, один мой знакомый уеб-дизайнер умудрялся достигать такого эффекта на чистом html:-)

[VN_MAClover]

Я бы посоветовал обратить внимание на такой движок как SPIP

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

Пока,

VN

[Evgen]

Alv писал
Назначение и css, и _хорошего_ движка, в том числе, и в том, чтобы свести к минимуму назрузку на сеть, за счет того, что повторяющиеся данные (скажем, оформление страницы) передаются один раз и кэшируются на локальной машине.
----------------------------------------------
Я видел намёки для использования JavaScript (мельколо где-то вверху).
Надеюсь обойдётся без этого.

[alv]

Я видел намёки для использования JavaScript (мельколо где-то вверху).
Надеюсь обойдётся без этого.

Пока я жив:-), ни явы, ни яваскрипт на этом сайте не будет, разве что кому из авторов потребуется для представления контента (но не декора ради)

[StraNNicK]

Java вещь хорошая, но её место - на сервере...

Насчет меню - Алексей - такое?
В самом низу странички. Оно работает (в демо-режиме), т.е. можно тыкать и наблюдать раскрытие/закрытие...
Добавил @ 27.06.2004 20:14
Почему я так проталкиваю css - в т.ч. уменьшения трафика для...
Все эти таблицы с кучей атрибутов нехило раздувают страничку, и их удельный вес составляет приличную долю от общего веса странички. Особенно на форумах...

[alv]

Java вещь хорошая, но её место - на сервере...
Насчет меню - Алексей - такое?
В самом низу странички. Оно работает (в демо-режиме), т.е. можно тыкать и наблюдать раскрытие/закрытие...
Добавил @ 27.06.2004 20:14
Почему я так проталкиваю css - в т.ч. уменьшения трафика для...
Все эти таблицы с кучей атрибутов нехило раздувают страничку, и их удельный вес составляет приличную долю от общего веса странички. Особенно на форумах...

Во-во, оно самое - именно такой принцип мне и представлялся!

И в отличие от явы, срабатывает прктически мгновенно

[charlie]

А вот оценка популярности статей как раз не нужна - на то логи сервера есть, или на худой конец - top.list.ru, тут каждый кликом мыши проголосует:-)

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

Если отсортировать по авторам и щелкнуть на какой-либо фамилии, должно выглядеть примерно так:
http://www-106.ibm.com/developerworks/view...thor&search_by=

Но это, насколько я понял, JavaScript со всеми вытекающими:-)

Неа, это не JavaScript. Разворот веток дерева, как и сортировка, осуществляется на стороне сервера(в данном случае на Java). У такого подхода только один плюс - работает в любых браузерах. Минусы - тормозит до бесподобия.....
Мне очень понравилось последнее меню, которое привел Strannick. Правда и IE, и Opera показывают его поначалу в развернутом виде, хотя функция сворачивания работает.

[StraNNicK]

Зато lynx его тоже показывает.
Правда только в развернутом виде, но. Главное что показывает...

P.S. Я как-то почитал статью про SSI и росто офигнел. Оказывается он может много больше, чем динамически собирать странички...

[t.t]

Java вещь хорошая, но её место - на сервере...
Насчет меню - Алексей - такое?
В самом низу странички. Оно работает (в демо-режиме), т.е. можно тыкать и наблюдать раскрытие/закрытие...

Во-во, оно самое - именно такой принцип мне и представлялся!
И в отличие от явы, срабатывает прктически мгновенно

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

[charlie]

Да, возможности SSI многие недоценивают. А если вместе с ними использовать что-то вроде Perl/Python, то цены им не будет
Странно, у меня в Opera все нормально, не тормизит.

[alv]

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

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

Так что предложение:

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

Далее (или выше? - как с точки зрения эстетики?) - заголовок, отбитый <hr>: для индексной станицы - Демониада, для страниц корня сайта - их имена собственные (Карта сайта, Команда, О проекте и т.д.). Для все страниц каждого раздела в качестве заголовка - название раздела: POSIX-сага, POSIX-журнал, Сообщество, под ним указание на копирайт мелкими буквами (как в посленном варианте), и hr. Все это - с выравниванием по центру.

Это вся хидерная часть. Соответственно для нее нужно 5-6 индивидуальных блоков (для index, about и т.д.) и три общих шаблона - по одному на раздел. Примерно так:

<!--Block 1 единый для всех-->
<!--Здесь, естественно, DOCTYPE, head, title, метатэги, html и body-->
<div align=centre>
POSIX-сага POSIX-журнал Сообщество
<!--End of Block 1-->

<!--Block 2 свой для каждого раздела и страниц корня-->
POSIX-журнал
© Коллектив авторов, 2004, отныне и вовек
<hr>
</div>
<!--End of Block 2-->

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

Футерная часть - еще проще, собственно, как есть в последнем посланном варианте:

<!--Block 4 единый для всех-->
<div align=centre>
<hr>
Обсуждение на форуме
<br>
Лого форума
<br>
Counter
</div>
body
html
<!--End of Block 4-->

Футерная часть - одинакова на всех страницах.

Блок 3 - это тело страницы, будет различаться для страниц корня, индексных страниц разделов и подразделов, и для станиц собственно с контентом (статей, глав etc.). Тем не менее, структура их однотипна. Для индексных страниц разделов и подразделов:

<!--Block 3-->
<h1>
Заголовок раздела
</h1>

Вводная фраза (краткая характеристика)

<h1>
Содержание
</h1>

unordered list с перечислением подразделов (для разделов) и собственно статей (для подразделов).
<!--End of Block 3-->

Для страниц со статьями:

<!--Block 3-->
<h1>
Название
</h1>

<div style 1>
Подзаголовок (если необходимо)
</div>

<div style 2>
Стихотворный эпиграф (если есть)
</div>

<div style 2>
Прозаический эпиграф (если есть)
</div>

<h1>
Содержание (если требуется)
</h1>

ulist с пунктами

<h2>
Подрубрика
</h2>

Текст и т.д.
<!--End of Block 3-->

В разделах Журнал и Сообщество многостраничных статей не будет - существующие я ликвидирую как класс путем объединения или деления на самостоятельные статьи, - поэтому необходимости в Prev, Next и т.д. не будет, а перейти к содержанию раздела/подраздела можно будет через меню.

А вот что касается книги - там это было бы не худо. Вопрос: можно ли ссылки на предыдущую и следующую страницы генерировать автоматически? Точнее, насколько это сложно технически (что в принципе можно, это я понимаю). Если не очень сложно - это собственно к Инге вопрос, то для раздела Сага о POSIX предлагается следующая структура:

<!--Block 3а-->
<div align="center">
Назад Содержание Вперед
</div>
<!--End of Block 3а-->

<!--Block 3b-->

Тело статьи
<!--End of Block 3b-->

<!--Block 3а-->
<div align="center">
Назад Содержание Вперед
</div>
<!--End of Block 3а-->

Логическая рубрикация - как в файле rubricator.html посланном Инге и Страннику. Я его сегодня подкорректирую (надеюсь, это будет последний и окончательный вариант:-) и вышлю или выложу здесь.

Физическая структура сайта.

Я пока не придумал ничего лучшего, как иерархию каталогов:
Раздел -> Подраздел 1 -> Подраздел 11 (если есть) -> ... (если есть) -> file.
Система именования файлов - имя_родительского_каталога.порядковый_номер.html (.shtml?)
В каждом каталоге уже непосредственно с файлами - подкаталог images с иллюстациями (если есть), имена файлов - filename###.номер_рисунка.png(gif,jpg).

Если все же будет база данных, в ней хотелось бы видеть такие поля:

ID - главный идентификатор (скорее всего, просто counter?)
ID1 - идентификатор, который я мог бы вбивать вручную, он должен определять порядок размещения статей в оглавлениях разделов (подразделов); или - какой другой способ задания их произвольного (по моему произволу:-) порядка; иначе (как на том, который мы теперь назваем) могут возникать весьма странные вещи:-)
Автор статьи (или три поля - Имя Фамилия ник - не знаю, как лучше)
Название - хорошо бы из него генерить тэг title кумулятивно, по схеме: Daemoniada -> Раздел -> Подраздел -> Название статьи
Собственно контейнер для контента - не знаю, как в MySQL это реализовано
Что еще нужно для функционирования базы - типа там keywords etc.

Вот пока все, что пришло в голову.

Добавил @ 29.06.2004 08:16
И еще о логотипе. М.б. в этом качестве использовать просто слово Daemoniada, или, если это длинно (а судя по текущей версии, это так), то - Daemonia. А в подзаголовок вынести - Демон с Пингвином братья навек. И все это хозяйство оформить через css - я некогда на W3C видел очень эффектные примеры и такого использвания стилей.


Добавил @ 29.06.2004 08:40
И еще: название третьего главного раздела - Сообщество - мне не очень нравится, но ничего лучшего я не придумал. М.б. у кого будут предложения? Желательно скорее, потому что сегодня-завтра я хочу поставить точку в рубрикаторе:-)

[Evgen]

Alv писал:
Подчеркиваю - каждый из верхних пунктов есть корень для своего выпадающего меню. Соответственно, главный вопрос для обсуждения - должна ли эта панель быть в самом верху или в самом низу хидера.
_________________________________________________
На мой взгляд панель должна быть в самом верху и выпадать вниз - так логичнее, ведь оно обеспечивает доступ ко всем разделам статей (как я понял). Если оно будет внизу, то для доступа придётся страницу крутить вниз, а это неудобно.

[charlie]

Для базы данных необходимо, на мой взгляд, добавить еще поле
PID- идентификатор родительского раздела(подраздела). Тогда можно будет генерить title кумулятивно.
Кроме того, если хранить статьи в поле типа TEXT, то можно будет использовать полнотекстовый поиск(имхо, keywords тогда не нужны)

[alv]

Alv писал:
Подчеркиваю - каждый из верхних пунктов есть корень для своего выпадающего меню. Соответственно, главный вопрос для обсуждения - должна ли эта панель быть в самом верху или в самом низу хидера.
_________________________________________________
На мой взгляд панель должна быть в самом верху и выпадать вниз - так логичнее, ведь оно обеспечивает доступ ко всем разделам статей (как я понял). Если оно будет внизу, то для доступа придётся страницу крутить вниз, а это неудобно.

Имелось ввиду - внизу хидерного блока, а не всей страницы

Добавил @ 29.06.2004 10:20

Для базы данных необходимо, на мой взгляд, добавить еще поле
PID- идентификатор родительского раздела(подраздела). Тогда можно будет генерить title кумулятивно.
Кроме того, если хранить статьи в поле типа TEXT, то можно будет использовать полнотекстовый поиск(имхо, keywords тогда не нужны)

Согласен.

Я только не знаю, есть ли в MySQL такой тип поля - мое знакомство с СУБД ограничивается Gupta, да и то было почти 10 лет назад
Добавил @ 29.06.2004 10:46
Призыв к волонтерам из Москвы и пределов досягаемости

Для проекта unix.ginras.ru неплохо было бы отсканировать и распознать некоторые бумажные материалы:

1) глава о шрифтах из учебника Кисина для полиграфических ВУЗов (1947 г.) - ей-богу, кто прочитает, не пожалеет

2) несколько статей из старого Byte/Unix - в онлайне их нет и не будет, с авторскими правами непонятно (Byte давно сменил и хозяина и команду), так что готов взять грех на руку (аналогичных материалов на Руси не было)

3) возможно, еще несколько статей из старых журналов.

Материалы для работы готов передать (ввиду уникальности) в хорошие (и очень чистые) руки с гарантией возврата под подпису кровью о неутерянии:-)
Добавил @ 29.06.2004 11:04
И еще одна мысль появилась:
генерировать имена файлов из базы данных по схеме:

раздел.подраздел.порядковый_номер.html(shtml)

согласитесь, что нечто вроде http://unix.ginras.ru/journ.sys.bsd.install1234.html - не верх изящества, но все же несколько более осмысленно, чем подобное вот этому:
http://www.linuxshop.ru/unix4all/?cid=&id=432
пример со всеми нами ныне называемого:-), еще не самый кучерявый
Добавил @ 29.06.2004 12:54
Окончетальная (надеюсь) версия рубрикации:
<title>Daemoia</title>
<subtitle>Демон с Пингвином - братья навек</subtitle>

<h1>Сага о POSIX</h1>
<h2>Преамбула</h2>
<h2>Введение</h2>
<h2>Глава 1</h2>
...
<h2>Глава #</h2>
<h1>Вопросы POSIX'ивизма</h1>
<h2>Дорога, открытая всем</h2>
<h3>Ресурсы по теме</h3>
<h3>Статья 1</h3>
...
<h3>Статья #</h3>
<h2>FreeBSD и другие</h2>
<h3>Ресурсы по теме</h3>
<h3>Устройство</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Установка и настройка</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Применение</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Другие BSD</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Другие ОСи</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h2>Linux</h2>
<h3>Ресурсы по теме</h3>
<h3>Система</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Source Based</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Пакетные дистрибутивы</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Live CD</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h2>Приложения</h2>
<h3>Ресурсы по теме</h3>
<h3>Шелл и утилиты</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Иксы и десктопы</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Редакторы и процессоры</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Web и коммуникации</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Графика и мультимедиа</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Игры и эмуляторы</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Сети и безопасность</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Разработка программ</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h2>Тесты</h2>
<h3>Ресурсы по теме</h3>
<h3>Софт</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h3>Железо</h3>
<h4>Статья 1</h4>
...
<h4>Статья #</h4>
<h1>Сообщество</h1>
<h2>Встречи</h2>
<h3>Статья 1</h3>
...
<h3>Статья #</h3>
<h2>Публицистика</h2>
<h3>Статья 1</h3>
...
<h3>Статья #</h3>
<h2>Беллетристика</h2>
<h3>Статья 1</h3>
...
<h3>Статья #</h3>
<h2>Мемуары</h2>
<h3>Статья 1</h3>
...
<h3>Статья #</h3>

[charlie]

И еще одна мысль появилась:
генерировать имена файлов из базы данных по схеме:
раздел.подраздел.порядковый_номер.html(shtml)
согласитесь, что нечто вроде http://unix.ginras.ru/journ.sys.bsd.install1234.html - не верх изящества, но все же несколько более осмысленно, чем подобное вот этому:
http://www.linuxshop.ru/unix4all/?cid=&id=432
пример со всеми нами ныне называемого:-), еще не самый кучерявый

Ну вот, дошли и до ЧПУ . Имхо, если уж делать ЧПУ, то так
раздел/подраздел/порядковый_номер.html(shtml)

Код: Выделить всё

http://unix.ginras.ru/journ/sys/bsd/install1234.html

Или даже не использовать порядковый номер, а предоставлять возможность при добавлении статьи задать ей кроме основного названия имя латиницей для URL(ну или генерить на основе русского названия в латиницу по н-букв из каждого слова)
Получится вроде:
http://unix.ginras.ru/journ/sys/bsd/install/UsingFdisk.html
mod_rewrite нам поможет!!!

[alv]

Ну вот, дошли и до ЧПУ . Имхо, если уж делать ЧПУ, то так
раздел/подраздел/порядковый_номер.html(shtml)

Код: Выделить всё

http://unix.ginras.ru/journ/sys/bsd/install1234.html

Или даже не использовать порядковый номер, а предоставлять возможность при добавлении статьи задать ей кроме основного названия имя латиницей для URL(ну или генерить на основе русского названия в латиницу по н-букв из каждого слова)
Получится вроде:
http://unix.ginras.ru/journ/sys/bsd/install/UsingFdisk.html
mod_rewrite нам поможет!!!

Согласен, и так, так логичней, чем предложенное мной.
Что выбрать - на усмотрение кодера, что проще в реализации. Хотя второй вариант, конечно, более осмысленный.

[alv]

Скорбный труд по подготовке контента для новой версии unix.ginras.ru завершен. Собрано, отредактировано, вычищенно в отношении кода:

полное (почти) собрание сочинений Алексея Федорчука - все, что я вспомнил, нашел, и что ИМХО не потеряло актуальности

все авторсикие статьи, размещенные ранее на unix.ginras.ru

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

Суммарный объем - 3,6 Мбайт pure html.

Таким образом, я готов к размещению новой версии. Дело за движком и дизайном.

[alv]

Дурацкий вопрос от человека, никогда в жизни ничего не администрившего, касаемо SSI.

Дома у меня apache стоит так:
/usr/local/www/data есть ссылка на ~/site_dir, соответственно инклюды прописаны как
/ssi/file_name

На служебном сервере, соответсвенно, все мое хозяйство лежит в VirtualHost, и инклюды не видны. Судя по всему, потому что /ssi/ не воспиринимается как корневой каталог. Миль пардон за невнятность... но что делать? И кто виноват?

[StraNNicK]

Надо в конфиге Апача раскомментировать
AddType text/html .shtml
AddHandler server-parsed .shtml

А потом обозвать файл с директивами не .html, а .shtml

P.S. Приношу извинения за дикую задержку. Были фовсем форс-мажорные обстоятельства... В ближайшее время дизайн будет.

[charlie]

Все-таки решили все делать при помощи SSI или это временная мера???

[alv]

Надо в конфиге Апача раскомментировать
AddType text/html .shtml
AddHandler server-parsed .shtml

А потом обозвать файл с директивами не .html, а .shtml

P.S. Приношу извинения за дикую задержку. Были фовсем форс-мажорные обстоятельства...    В ближайшее время дизайн будет.

↑

Дык ведь в том-то и дело, что прописал я
AddHandler server-parsed .html

И дома все работает

[alv]

Все-таки решили все делать при помощи SSI или это временная мера???

↑

Это проба пера - оказалось не совсем удачно:-)

[charlie]

В принципе, как уже сказали

Код: Выделить всё

AddType text/html .shtml
AddHandler server-parsed .shtml

должно быть достаточно. Но если не работает посмотрите httpd.conf на предмет Includes. Допустим это может выглядеть так:
================================
<Directory "/">
#А вместо / может быть путь к вашему каталогу
Options Indexes FollowSymLinks Includes MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>
===================================
Либо если работает поддержка .htaccess, то попробуйте

Код: Выделить всё

Options +Includes

в корне вашего каталога.