Борьба с битыми ссылками в html5
18.04.2024
|
velkin
 |
Личная база знаний всё время меняется, в результате могут образоваться битые ссылки.
1. Меняются названия якорей атрибута id в html5.
2. Меняются названия страниц html5.
3. Меняются относительные пути к страницам html5.
4. Меняются ссылки к внешним ресурсам html5.
5. Меняются значения внутренних и внешних ресурсов.
Последний пункт относится к переосмыслению понятий, когда думаешь, что это одно понятие, а оказывается, что другое.
Причём понятие не обязательно полностью меняет смысл.
1. Оно может получить уточнение от общего к частному.
2. Или напротив нужно обобщить его от частного к общему.
3. Но, конечно, и не исключён вариант полной смысловой замены.
Речь о том, что даже не битая ссылка может.
1. Указывать на неверный ресурс.
2. Неправильно охватывать текст.
Так что никакое индексирование бы в итоге не помогло.
Я искал ручное решение без специальных программ и "нашёл".
Смысл в том, что ничего специально делать не нужно. Ссылка прверяется в момент нажатия на неё.
Казалось бы это не совсем правильно ведь очевидно, что разведётся куча неправильных или битых ссылок.
Да разведётся, но если на них не тыкать, то они и не мешают. А если тыкать, то сразу и узнаешь правильные они или нет.
Если бы использовался простой текст, то проблем бы не было по принципу нет ссылок, нет проблем. Но на мой взгляд ссылки нужны так как они явно указывают связи.
1. Меняются названия якорей атрибута id в html5.
2. Меняются названия страниц html5.
3. Меняются относительные пути к страницам html5.
4. Меняются ссылки к внешним ресурсам html5.
5. Меняются значения внутренних и внешних ресурсов.
Последний пункт относится к переосмыслению понятий, когда думаешь, что это одно понятие, а оказывается, что другое.
Причём понятие не обязательно полностью меняет смысл.
1. Оно может получить уточнение от общего к частному.
2. Или напротив нужно обобщить его от частного к общему.
3. Но, конечно, и не исключён вариант полной смысловой замены.
Речь о том, что даже не битая ссылка может.
1. Указывать на неверный ресурс.
2. Неправильно охватывать текст.
Так что никакое индексирование бы в итоге не помогло.
Я искал ручное решение без специальных программ и "нашёл".
Смысл в том, что ничего специально делать не нужно. Ссылка прверяется в момент нажатия на неё.
Казалось бы это не совсем правильно ведь очевидно, что разведётся куча неправильных или битых ссылок.
Да разведётся, но если на них не тыкать, то они и не мешают. А если тыкать, то сразу и узнаешь правильные они или нет.
Если бы использовался простой текст, то проблем бы не было по принципу нет ссылок, нет проблем. Но на мой взгляд ссылки нужны так как они явно указывают связи.
| 18.04.2024 11 комментариев |
V>Я искал ручное решение без специальных программ и "нашёл".
Опробовал ещё один способ, а именно установку динамического сайта на веб-движке wordpress. По идее можно было бы вести личную базу знаний точно так же локально только с использованием номеров как названий страниц.
Только в отличие от движка файловая система бы не показывала названия вместо номеров и не было бы категорий и меток. Понятное дело на динамическом сайте в отличие от статического плюс ко всему можно общаться.
У динамических сайтов, конечно, есть и недостатки. Централизованность заставляет повышать потребляемые ресурсы при возрастании количества клиентов.
Хотя у меня традиционно установлен nginx + php-fpm всё равно со временем придётся возиться с оптимизацией сервера и защитой от перегрузки канала.
Плюс в том, что я использую html5, а значит имею совместимость содержимого между статическим и динамическим сайтом. При переносе туда или обратно фактически изменятся только адреса ссылок.
А ещё я думал над стековерфлоу или другими форумо-подобными сайтами. Не очень удобно сваливать все темы в кучу, а ведь так обычно и происходит.
Да и тысячи по большей части глупых комментариев не то, что приветствуется веб-движком генерирующим страницу или пользователями, которые вынуждены всё это читать в надежде на умную мысль.
V>Опробовал ещё один способ, а именно установку динамического сайта на веб-движке wordpress.
А почему не wikipedia
V>>Опробовал ещё один способ, а именно установку динамического сайта на веб-движке wordpress.
_>А почему не wikipedia
Вот здесь в комментарии я объяснил, почему пока тестирую html5, а не другие разметки. Следовательно при переходе со статического на динамический сайт веб-движок мне тоже желательно с html5 разметкой.
А Wordpress выбран потому, что я пробовал много всяких CMS вроде Drupal, Redmine и сто пятьсот других, а вот его как раз проигнорировал, хотя он вроде как самый популярный.
Я решил, что для опыта подойдёт то, что налезет на nginx + php-fpm, ну то есть тупо php из коробки на последнем Debian 12. Очень простая установка чуть ли не на дурака и всё сразу работает.
Не хочу сейчас возиться с чем-то сложным, например, тот же Redmine потребует Ruby on Rails и установку кучу всякой муры. Я из-за этого когда-то его устанавливал на nginx, там то ли passenger, то ли ещё что. Ещё куча каких-то пакетов с зависимостями. Из-за этого в последний раз когда его решил потестить скачал bitnami-redmine-5.1.1-r84-debian-11-amd64.ova, потому что даже возиться не хочу с установкой. Да и не нужен мне сейчас Markdown.
Drupal 7 в своё время был не взломоустойчивым. У меня когда-то был заброшенный сайт, я годами на него не заходил. Потом смотрю, а он взломанный. И потом ещё кто-то пишет статьи, что Drupal надёжен.
Мне сейчас лень превозмогать как когда-то и тестировать какие-то движки, типа Joomla, Drupal и так далее по длинному списку, не говоря уже о Wiki. Я по простому поставил с нуля сайт с дубликатом в локальной сети для критичных опытов.
Разметка html5 есть, значит можно потестировать перенос со статического сайта. До этого я тестировал Zim, даже Obsidian попробовал. Но я уже писал, что там проблемы с индексацией.
Сейчас посмотрю какие нагрузки выдержит Wordpress. Может он тоже сломается как нечего делать. Zim, кстати, был на неком варианте вики разметки. И без WYSIWYG это конечно была бы полная жесть при наборе.
А вот html5 меня вообще не напрягает при полностью ручном наборе. То есть я не занимаюсь копипастой, а так и пишу из головы.
Отчасти меня rsdn натренировал на это дело. Хоть здесь и bbcode, но суть практически та же. Я бы даже сказал, что html5 проще из-за однозначности правил. И секрет успеха в том, чтобы использовать в содержимом только простые теги типа bius и прочих основных.
А с семантикой или сложной разметкой пусть возятся другие люди. Мне достаточно текста с параграфами, гиперссылками, списками, таблицами, кодом, изображениями, видео, и в принципе чем-то таким простым без сложных десятиэтажных конструкций.
Опять же если посмотреть на всё, что я пробовал, у меня было даже такое Электронная тетрадь в клеточку. Я не исключаю вероятности, я пробую то, пробую это. Может когда-то дойдёт до викидвижков.
Просто надо понимать, что наученный опытом первое, что я сделаю с движком, это засуну в него 10 тысяч пусть даже пустых документов, а потом ещё добавлю. И посмотрим потом будет он индексировать содержимое до состояния неработоспособности, или может срежется при запросе на количестве записей в базе данных, или ещё что.
Смешные же числа, даже миллион записей для таблицы в базе данных ничто, а ведь сколько у меня уже было фейлов на в тысячу раз меньшем количестве страниц. Вспоминается Compendium, между прочим написан на Java. А каждый опыт это время, всё сразу я проверить не могу. Нужно дойти до какой-то стадии чтобы сказать да, это работает, или нет, это не работает.
V>Вот здесь в комментарии я объяснил, почему пока тестирую html5, а не другие разметки. Следовательно при переходе со статического на динамический сайт веб-движок мне тоже желательно с html5 разметкой.
V>А Wordpress выбран потому...
Дык и для него есть wiki
https://ru.wordpress.org/plugins/yada-wiki/
Вот пример как это выглядит:
https://youtu.be/yixVePH3IpA?t=556
V>>А Wordpress выбран потому...
_>Дык и для него есть wiki
_>https://ru.wordpress.org/plugins/yada-wiki/
_>Вот пример как это выглядит:
_>https://youtu.be/yixVePH3IpA?t=556
Пока что из плагинов Classic Editor себя оправдывает, потому что редактор по умолчанию просто ужасен. Я вообще не знаю как авторы Wordpress додумались до такого.
Я приму к сведению Yada Wiki. Да, этот плагин появляется в списке.
Просто мне вики разметка пока не нужна, мне её в Zim хватило.
А для моих опытов хватит.
или
Я так-то нашёл разные интересные плагины. Но мой опыт работы с другими движками говорит пока их не ставить. Потому что плагины требуют обслуживания.
А мне интереснее проверить работу с содержимым. И содержимое я собираюсь прописывать руками. Да и визуализация в редакторе не работает не понятно почему. На локальном сервере дубликате работает, а на виртуальном сервере через cloudflare с принудительной сменой протокола с http на https не работает.
Я лет 15 назад, да и не только, и 10 лет назад, не очень понимал, что главное в сайте содержимое. Сайт реально может быть днищенским, но люди туда заходят не ради оформления. Главное это контент, содержимое. Причём абсолютно всё равно на чём он там написан, пока отображается как нормальный html.
В принципе если есть ещё интересные идеи пиши. Просто я тут не гружу людей всем, что я делаю.
А на самом деле если брать за основу ссылок названия так и хочется сказать, а как тебе такое Илон в Маске.
Или вот так.
И так далее.
Идея в том, что встроенные типы это вообще-то говоря просто набор команд процессора и регистров, то есть их можно связать с ассемблерными командами.
1. Но что насчёт имён?
2. А что насчёт категорий?
В топике то я, конечно, описал возможные случаи. Меняется то, меняется это. Но у меня то есть конкретные примеры как это на самом деле может меняться.
Кстати, про википедию у меня ещё была такая тема.
Списки понятий в википедии
Особо умные люди начали менять названия статей, перемещать их в подразделы, тогда как в английской википедии такого нет.
А как итог я вижу, что названия в википедиии не всегда идеальны, есть всякие дополнения, но она живёт не за счёт какой-то супер технологии, а за счёт продуманности названий ссылок.
Придёт человек, который решит, что он умнее всех и начнёт всё менять и появляются битые ссылки прямо в википедии. Причём это не шутка, в реальной настоящей википедии создали битые ссылки. Потому что этот человек отредактировал названия статей, поменял расположение устроив вложения, а другие авторы прочие статьи не исправляли.
Вся русскоязычная википедия как по волшебству не обновилась на.
https://ru.wikipedia.org/wiki/Проект:Математика/Списки/Список_алгоритмов
А что уж там, давайте ещё добавим пару категорий.
Это причём наглядный пример, когда не только я занимаюсь извратами, но самопровозглашённые редакторы википедии. Они решили, что им не сдался.
https://ru.wikipedia.org/wiki/Список_алгоритмов
Мы же умнее англоязычных пользователей, у нас список алгоритмов это именно математический список, а не список алгоритмов того же программирования, или просто список алгоритмов.
Короче википедия с моей точки зрения не имеет какой-то ультра технологии позволяющей не ошибаться. Всё там зависит от авторов. Ну и в моём случае всё зависит от автора, то есть от меня.
Насчет редактора: LibreOffice Writer умеет сохранять в HTML. Можно использовать его как WYSIWYG редактор.
А если потом этот HTML открыть в каком-нибудь текстовом веб-браузере типа Lynx/Links, то сразу будет ASCII версия — таблички и пр.
V>Я лет 15 назад, да и не только, и 10 лет назад, не очень понимал, что главное в сайте содержимое. Сайт реально может быть днищенским, но люди туда заходят не ради оформления.
V>Главное это контент, содержимое. Причём абсолютно всё равно на чём он там написан, пока отображается как нормальный html.
+1, даже не обязательно HTML, достаточно чтобы формат документ индексировался поисковиками.
Т.е. технически например ftp сервера с PDF файлами достаточно.
Есть такой проект public-inbox (это что-то типа аналога NNTP протокола на основе git SCM).
Так вот у них сайт это просто директория со списком документов: https://public-inbox.org
V>Личная база знаний всё время меняется, в результате
Просто интересно, рассматривал ли ты MyTetra ? текст в html, редактор wyswyg, но можно и прямо html. внутренние ссылки не портятся.
https://webhamster.ru/site/page/index/articles/projectcode/105
накопленные знания можно выложить на просмотр в публичный доступ
https://webhamster.ru/site/page/index/articles/projectcode/267
SK>Просто интересно, рассматривал ли ты MyTetra ? текст в html, редактор wyswyg, но можно и прямо html. внутренние ссылки не портятся.
Рассматривал, но не пробовал, потому что каждая попытка стоит месяцы.
SK>накопленные знания можно выложить на просмотр в публичный доступ
Для меня публичный доступ в wordpress что-то вроде побочного эффекта. У меня была синхронизация и она прекрасно работала. Wordpress в режиме простых ссылок отчасти решает проблему битых ссылок. Пока я не переосмыслю понятие, оно так и будет прибито к id страницы.
Сейчас думаю может личную базу знаний просто вести на сайте. Почему бы и нет, открытый доступ есть, закрытый доступ тоже есть. Минус в том, что точка отказа централизованная и на неё могут повлиять другие люди. Но в принципе там нет ничего критичного, то есть отказ в обслуживании ничего ужасного не сделает.
То что там все записи в бесконечной разработке тоже без разницы. Кстати, я раньше к сайтам, то есть лет 10-15 назад и в некоторых случаях даже ещё на 10 лет раньше относился по другому. В моём представлении, если писать сайты, те же блоги, то это когда сидишь и пишешь какую-то условную статью. Но с точки зрения систематизации знаний это ничего не даёт.
Посмотрел ссылку.
https://webhamster.ru/site/page/index/articles/projectcode/267
Далеко там люди не уедут, слишком малые объёмы и практически нет систематизации. Вообще я хочу увидеть базу не в 100-1000 страниц, а от 10'000-100'000 тысяч страниц. И причём не случайных страниц, которые напихали разные люди, а систематизированные записи.
Меня даже объёмы между 1000-10'000 не особо волнуют. Я просто знаю по своему опыту и читал у других, что проблемы начинаются после 10'000 записей. Могут, конечно, начаться и раньше.
А так мне каждая программа даёт некий опыт, который в последствии обобщается. Одним и тем же инструментом можно работать по-разному. Главное чтобы он не глюканул по дороге. К примеру, переход от статического сайта к динамическому открыл для меня то, что я мог бы и в статическом сайте пронумеровать ссылки по номерам.
Я это и раньше знал, но идея как-то не приживалась в голове. А сейчас поработав с wordpress я в общем-то понял, что будь у меня статический сайт 1.html .. 100000.html в одной директории с дополнительными директориями 1 .. 100000 для содержимого , то и это было бы нормально. Вопрос в том как люди смотрят на одни и те же вещи.
SK>>Просто интересно, рассматривал ли ты MyTetra ? текст в html, редактор wyswyg, но можно и прямо html. внутренние ссылки не портятся.
V>Рассматривал, но не пробовал, потому что каждая попытка стоит месяцы.
Можно оценить за день-другой на нескольких записях. Установки не требует. Он неплохо импортирует из веба. просто копи-пастой из браузера, выделенный текст вместе с картинками. нужно только заполнить название записи (добавить автора, урл первоисточника и метки и если есть перекрестные ссылки поправить их — можно позже ).
SK>>накопленные знания можно выложить на просмотр в публичный доступ
V>Для меня публичный доступ в wordpress что-то вроде побочного эффекта. У меня была синхронизация и она прекрасно работала. Wordpress в режиме простых ссылок отчасти решает проблему битых ссылок. Пока я не переосмыслю понятие, оно так и будет прибито к id страницы.
Понятие верное. id страницы, это просто id страницы. не нужно его привязывать к чему-то другому.
V>Сейчас думаю может личную базу знаний просто вести на сайте. Почему бы и нет, открытый доступ есть, закрытый доступ тоже есть. Минус в том, что точка отказа централизованная и на неё могут повлиять другие люди. Но в принципе там нет ничего критичного, то есть отказ в обслуживании ничего ужасного не сделает.
wordpress для простых вещей переусложнен, для сложных недоделан.
V>Посмотрел ссылку.
V>https://webhamster.ru/site/page/index/articles/projectcode/267
V>Далеко там люди не уедут, слишком малые объёмы и практически нет систематизации. Вообще я хочу увидеть базу не в 100-1000 страниц, а от 10'000-100'000 тысяч страниц. И причём не случайных страниц, которые напихали разные люди, а систематизированные записи.
На 100 тысячах могут быть проблемы, из за ограничений файловой системы.
V>Меня даже объёмы между 1000-10'000 не особо волнуют. Я просто знаю по своему опыту и читал у других, что проблемы начинаются после 10'000 записей. Могут, конечно, начаться и раньше.
V>А так мне каждая программа даёт некий опыт, который в последствии обобщается. Одним и тем же инструментом можно работать по-разному. Главное чтобы он не глюканул по дороге. К примеру, переход от статического сайта к динамическому открыл для меня то, что я мог бы и в статическом сайте пронумеровать ссылки по номерам.
V>Я это и раньше знал, но идея как-то не приживалась в голове. А сейчас поработав с wordpress я в общем-то понял, что будь у меня статический сайт 1.html .. 100000.html в одной директории с дополнительными директориями 1 .. 100000 для содержимого , то и это было бы нормально. Вопрос в том как люди смотрят на одни и те же вещи.
Оптимальный вариант, широко распространенный на начало 2000х, даже несколько файловых CMS было, а сейчас это просто не модно.
SK>На 100 тысячах могут быть проблемы, из за ограничений файловой системы.
На сайте MyTetra кстати есть описание формата данных и тесты производительности:
Формат хранения данных в MyTetra
Вызывает беспокойство, что список записей, их метаданных и связей хранится в одном XML файле.
Нагрузочное тестирование MyTetra 1.42 на 100 000 записей
Автор исходит из предположения, что 100K записей накопится за 50 лет. Но это не случай ТС.
Замеры:
К сожалению не приведено потребление памяти.
Я полагаю, что добавление новой/редактирование метаданных существующей записи будет приводить к полной перезаписи mytetra.xml, что неоптимально.
Также не вполне понятно, что версионностью заметок.
В описании упоминается следующее:
SK>>На 100 тысячах могут быть проблемы, из за ограничений файловой системы.
M>На сайте MyTetra кстати есть описание формата данных и тесты производительности:
M>Формат хранения данных в MyTetra
M>Вызывает беспокойство, что список записей, их метаданных и связей хранится в одном XML файле.
Да, но одновременно это и плюс — легко бэкапится простыми средствами.
Городить какую-то сложную БД (или "не сложную" БД) для персональной (однопользовательской) программы оффлайн заметок мне представляется избыточным усложнением. файловая система ничем не хуже БД.
M>Нагрузочное тестирование MyTetra 1.42 на 100 000 записей
M>Автор исходит из предположения, что 100K записей накопится за 50 лет. Но это не случай ТС.
M>Замеры:
M>К сожалению не приведено потребление памяти.
с пустой базой 26 мегабайт в оперативке, с 1500 записей (mytetra.xml 450 килобайт) в оперативке 28 мегабайт .
M>Я полагаю, что добавление новой/редактирование метаданных существующей записи будет приводить к полной перезаписи mytetra.xml, что неоптимально.
M>Также не вполне понятно, что версионностью заметок.
M>В описании упоминается следующее:
M> M>
не приходилось пользоваться версиями заметок, сейчас глянул — mytetra.xml тоже туда откладывается. как восстановить — хз.