Если уже нашёл решение, то почему бы не написать его в ответах, чтобы другой ищущий нашёл возможное решение?
Не-не, неправильно меня понял. я решения не нашёл. Я посмотрел api и сделал просто запросы на просмотр контента, добавление контента и удаление его. всё работает довольно быстро.
То что нет какого-то популярного решения (если бы существовало - оно легко бы гуглилось) говорит о том, что оно оно либо никому не нужно, либо что есть какие-то принципиальные проблемы в таком решении.
вот это меня и сподвигло задать вопрос. Для меня странно, что нет решения. Множество статей на тему github pages есть и везде это упоминается, как статические сайты (да даже ты сказал об этом), а информации о cms - нет. Хотя динамика доступна, но никто не пользуется. Я на себе проверил - с проблемами не столкнулся.
Авторизуешься на фронте через github oauth2 и можешь через api редактировать файлы.
не нужно этого. можешь просто взять api ключ и добавлять его в каждом запросе (закешировать в куках ещё можно). Либо зашифровать условным AES-128 прям в коде и расшифровывать через свой пароль.
1. При добавлении новых страниц или категорий нужно отредактировать все страницы, где есть какая-то навигация.
узко мыслишь. ты можешь в отдельном json хранить просто записи. Если запись большая - создаёшь для неё отдельный файл. Вся пагинация и прочая чепуха делается на фронтенде. Условно для 10 записей - отдельный json. Я это веду к тому, что всё может быть очень хорошо оптимизировано (поделено на части), что ты не ощутишь никаких проблем. Не нужно подгружать 100500 строк записей, чтобы отобразить только 4.
2. В GH Pages настроено кэширование ~10 минут => сам опыт редактирования будет очень странным. Вот ты открыл сайт - статьи нет. Залогинился, чтобы подключилось API - статья вроде бы в списке есть и даже можно открыть её по прямой ссылке.
не знаю откуда эта информация. Кеш около ~20 секунд. Я споткнулся только в моменте, когда добавил запись на сайт и через 5 секунд добавил ещё одну и мне вернулась 408 ошибка. Через секунд ~30 повторил операцию и вторая запись добавилась. Поэтому проблема кеша мне недоступна. Задержка есть, действительно чат не сделать (на самом деле можно сделать, но через костыль), но условный toster.ru - реализуем на github pages.
А это вообще курс по использованию Github pages. Каким образом вы ища CMS нашли курс и компонент для редактирования текста мне не ясно.
этот "курс" подразумевает, что я добавляю статьи. Пройди его до конца. Там всё-таки про блог, а не про сам github pages. Если бы про github pages, то я бы видел кишки cms, а там их нет. Там нет ничего (что меня действительно удивило). То есть все js расчёты происходят на стороне самого github и мне для редактирования недоступны.
Мне кажется - гораздо выгоднее будет инвестировать своё время на изучение markdown, чтобы он не казался решением "на любителя".
хорошая оптимизированная программа с грамотным UI/UX никогда не сравнится с консольной. Для меня в данной ситуации: markdown - консоль, editorjs - программа.
вабка, ты такой интересный, отвечаешь однозначно на вопросы, на которые ответа не знаешь. Я сегодня на коленке тестировал headless cms в github и всё у меня работает, а у тебя нет. Странно, не кажется?
Виктор, Под шлейфом оставил диск на 12 часов, он даже не нагрелся. Если подключить SATA и включить компьютер - диск будет немного тёплым. Простоял он в таком режиме 3 часа - система не загрузилась.
Викторию можно запустить из под системы. Диск в системе я не вижу, в следствии Виктория его не видит тоже.
Виктор, я викторию запустить не смог. У меня AHCI, IDE нет, включить негде. В виктории ошибка: Отсутствует DRSC+DRDY и что-то там дальше ещё. Ткните меня носом пожалуйста, куда жать, чтобы завести IDE... Мать Gigabyte H310M
не хочу рекомендовать говно, но придётся. Дело в том, что драйвера в w11 абсолютно другой версии (даже на старое оборудование), поэтому я хотел бы вам порекомендовать поставить w11 и посмотреть, как оно будет работать.
Ты описываешь избыточно сложный и непонятно как реализуемый сценарий.
я ночью проебался в моменте, когда забыл учесть, что dns запись во-первых, может быть кэширована, а во-вторых, может меняться херову тучу времени.
правда почему ты начал говорить о haproxy/nginx - мне не ясно. У меня логика была такая: имеем несколько серверов, где каждый сервер делает запрос на каждый, проверяя работоспособность. И в случае, если отрубается тот, который вбит в DNS, то нужно сменить DNS в автоматическом режиме на тот сервер, что работает. То есть, нужно иметь хостинг-провайдер со своим api, который имеет возможность смены DNS без участия пользователя.
поэтому доступ к dns записям должен быть через api. Ты постоянно должен делать запросы а-ля GET /health с каждого сервера на каждый, чтобы в случае чего оперативно сменить балансировочный (хотя в этом случае балансировочный вообще нафиг не нужен).
Это как Дозиметр (радиацию мерит), в котором 3 независимых канала. Результат выводит тот, который повторяется на двух.
Сергей П, не могу согласиться со всем, что вы написали. Если смотреть на ситуацию, до которой довёл автор, то да - дело плохо. Будем исходить из того, что автор не врёт и их забанили реально за логин на одном компьютере. Уже нарегали множество аккаунтов и что-то в суде доказать будет сложно. Нужно было делать всё сразу. И если сразу досудебку им направить, то тут не нужно обладать сверхспособностями, чтобы в суде свои права отстоять. Меня здесь выбесил больше поголовный идиотизм отвечающих, которые все как один начали нести бред о священности правил и неприкосновенности площадки. А я на своём опыте знаю, что есть закон, а есть никому ненужное правило площадки. И если будет разночтение, то ты помимо всего получаешь возмещение морального вреда.
Теперь по поводу суда. Дело в том, что у нас такое понятие есть: если пункт в договоре идиотский - он не считается, и вы почему-то упускаете это. Приведу пример: "Озон глобал" - покупка товаров из-за рубежа. в правилах у них написано: мы ни за что не отвечаем:
spoiler
И если что-то с товаром не так, то вы все претензии адресуйте туда (как правило, в китай). Дело в том, что я с ними судился, суд выиграл и правила уже наизусть знаю. Оспорил я именно этот пункт и пункт 4.6. Есть и у других суды с ними, я искал их, просматривал. Заканчиваются с переменным успехом, потому что от судьи зависит, но выигрыши есть. С обычном Озоном (не глобал) точно такая ситуация: если есть претензии, то мы никто, звать нас никак, все вопросы к продавцу. Себя деанонить не хочу, но вот пример, когда Озон боролся до посинения: мужчина хотел купить пальто, а оно закончилось, поэтому озон заказ отменил и деньги вернул. Мужчине не понравилось и он пошёл и купил это пальто в другом магазине, а потом вернулся в озон и попросил, чтобы те отдали ему разницу, потому что он купил в другом магазине пальто дороже. Озон его послал. Потом были суды: первый, апелляция, кассация и вот результат ссылка на дело. Озон говорил: мы никто, он покупал у ООО "Котон-Текстиль" - это у них закончилось пальто и это они его продать не могут, поэтому даже если у вас и есть претензии, то судитесь с этим ООО. Суд внимательно этот довод выслушал и сказал: деньги кому платились? Озону? Пускай Озон и возвращает деньги.
По факту мы имеем, что вроде как озон обезопасил себя, написав у себя в правилах, что он никто и что ответственности он не несёт, а на деле суд это правило проигнорировал.
Тут сумма была копеечная 700 рублей. У меня сумма в несколько сотен раз больше, но суть остаётся та же: суду плевать что там в правилах написано. В потребительском плане, я судился с Боссом, потому что у нас законы под этих агрегаторов написаны и до кучи у меня продавец - китаец, но даже этот нереальный суд я выиграл. А здесь мы имеем компанию, которая находится в юрисдикции РФ и блокирует с аргументацией "хачу баню, хачу не баню" - разумеется, если верить автору.
Также рекомендую ознакомиться с судом Букинга, который я упоминал постов выше. Там тоже в правилах была возможность заблокировать объект, однако суд проигнорировал это правило.
Резюмируя: я не рассматриваю действия автора вообще никак. Меня беспокоят эти хомячки, которые встали на сторону площадки. И беспокойство вызвалось от того, что у меня просто опыт есть. А у них нет, но они по какой-то причине стоят не в позиции: "ну хер его знает", а в позиции: "100% мамой клянусь". Не знаешь? Ну зачем тогда утверждать? А они утверждают
Не-не, неправильно меня понял. я решения не нашёл. Я посмотрел api и сделал просто запросы на просмотр контента, добавление контента и удаление его. всё работает довольно быстро.
вот это меня и сподвигло задать вопрос. Для меня странно, что нет решения. Множество статей на тему github pages есть и везде это упоминается, как статические сайты (да даже ты сказал об этом), а информации о cms - нет. Хотя динамика доступна, но никто не пользуется. Я на себе проверил - с проблемами не столкнулся.
не нужно этого. можешь просто взять api ключ и добавлять его в каждом запросе (закешировать в куках ещё можно). Либо зашифровать условным AES-128 прям в коде и расшифровывать через свой пароль.
узко мыслишь. ты можешь в отдельном json хранить просто записи. Если запись большая - создаёшь для неё отдельный файл. Вся пагинация и прочая чепуха делается на фронтенде. Условно для 10 записей - отдельный json. Я это веду к тому, что всё может быть очень хорошо оптимизировано (поделено на части), что ты не ощутишь никаких проблем. Не нужно подгружать 100500 строк записей, чтобы отобразить только 4.
не знаю откуда эта информация. Кеш около ~20 секунд. Я споткнулся только в моменте, когда добавил запись на сайт и через 5 секунд добавил ещё одну и мне вернулась 408 ошибка. Через секунд ~30 повторил операцию и вторая запись добавилась. Поэтому проблема кеша мне недоступна. Задержка есть, действительно чат не сделать (на самом деле можно сделать, но через костыль), но условный toster.ru - реализуем на github pages.
этот "курс" подразумевает, что я добавляю статьи. Пройди его до конца. Там всё-таки про блог, а не про сам github pages. Если бы про github pages, то я бы видел кишки cms, а там их нет. Там нет ничего (что меня действительно удивило). То есть все js расчёты происходят на стороне самого github и мне для редактирования недоступны.
хорошая оптимизированная программа с грамотным UI/UX никогда не сравнится с консольной. Для меня в данной ситуации: markdown - консоль, editorjs - программа.