kerch.fm

Да, согласен, никому не пожелаешь с токсичным сообществом общаться. Но может мигрируют на что-то другое со временем.

Да не вопрос, вам виднее. Все равно передаю сайт другим людям, так что меня эти проблемы уже не касаются) Извините еще раз что отнял ваше время, и искренне желаю вам успеха в развитии движка.

При блокировке со стороны Гугла есть ошибка 403 и это уже хороший повод где нибудь в логах вывести что сайт отказался принимать соединение. При других блокировках есть ошибка резолва имени, либо таймаут соединения - тоже эти две ситуации детекитруются и их можно вывести в логи или показать пользователю. Если CURL нет на сервере - тоже можно понять и вывести соответствующее сообщение. Вот вам навскидку 4 разных сообщения, достаточно информативных чтобы начать мучать поддержку хостинга. А еще бывает что человек просто ошибся в адресе, и Ютуб ответил 404, это тоже можно вывести. И человек сра

Так в том то и дело, что причин недоступа к серверу ютуба может быть много и они все разные. Я просто привел вам один из вероятных примеров. А еще может быть что нибудь другое - например блокировка РКН, или отсутствие CURL - как оказалось из вашего ответа выше. По идее эти варианты вы как разработчик могли бы нам обозначить. А мы тут который день от вас пытаемся добиться перечня вариантов чтобы понять что может пойти не так ) Ну ок, просто мы же не на сайте "граммар-наци" )) Еще раз, претензия не за отсутствие связи, а за неинформативность при возникновении проблемы. Посмотрите

Я нигде не писал про какой-то сервис, имел ввиду технологию. Прочтите мое сообщение внимательно. Замечательный ответ: У меня на сервере все ок, значит и у вас должно быть ок. А то, что Гугл может банить айпишники по территориальному признаку (Крым например), вы вроде бы как и не знаете )) А о том, что проблемы с доступом к гугловскому серверу - где можно посмотреть в панели DLE? А вот нигде этого нет. Мне вот например нравится как сделано на Хабре, там при вставке видео прямо в редакторе рендерится видеоплейер. И ты сразу видишь - вставилось или нет, и что именно вставилос

@celsoft а технически - механизм получения кода встраивания с Ютуба у вас сделан через oEmbed, верно? Может тогда проблема в том что ютуб такие запросы на получение кода с адреса сервера и подозрительным юзер-агентом считает автоматическими и отклоняет? Ну или может капчу показывает, а мы ее конечно не видим.

А уточните, какие это могут быть настройки, а то у нас тоже перестала работать вставка ютуб роликов через тег media (после переезда на другой сервер)

Спасибо за подробные разъяснения и извините что отнял ваше время. Вопрос закрыт.

@celsoft Вообще изначально вашу CMS я выбрал в далеком 2012 году из за простоты работы с изображениями в статьях + поддержка мультикатегорий. Автоматическое раскладывание картинок по подпапкам + показ только тех картинок, которые загружены к новости стали киллерфичей на тот момент для журналистов (которым вечно надо как можно быстрее выложить статью и ничего не перепутать). Ну и конечно производительность скрипта была на высоте, недосягаемой тогда другим CMS. Но время идет, и все уже не так однозначно, хотя еще раз скажу без скрытого подкола - мне очень нравится что вы достаточно операти

Хук предоставляет возможность CMS взаимодействовать с плагинами (внешними программами). А значит такое взаимодействие попадает под определение API - "программный интерфейс, то есть описание способов взаимодействия одной компьютерной программы с другими". Но терминология тут конечно вторична, и спорить об этом нет смысла. При правильном спроектированном API, работа плагинов не будет зависеть от внутренней структуры БД. Если вы планируете какие то изменения, которые поломают обратную совместимость - помечаете аргументы или сами хуки как deprecated и постепенно выводите их из кода.

В принципе я не удивлен. Уже 6 лет прошло с момента выхода системы плагинов, а ваше мнение так и не поменялось ) Виртуальная файловая система которая была внедрена для поддержки нынешней систем плагинов также имеет влияние на производительность. Не думаю что проверка на зарегистрированные плагины в местах вызова хуков будут иметь сильное влияние. Хотя конечно все зависит от архитектуры вашего ПО и тут вам безусловно виднее. Просто вот именно такой подход с патчингом кода "на лету" я не встречал в других распространенных CMS. Вот тут я с вами не согласен. Хук имеет строго опред

Здравствуйте. Когда вы сможете реализовать нормальную систему плагинов - через хуки, чтобы не пришлось привязываться к написанному вами коду? Потому что сейчас каждое обновление это рулетка - слетит/ не слетит плагин. Сейчас есть несколько вариантов при обновлении сайта: 1. Накатить обновление сначала на тестовом сервере, там все поправить. Однако не у всех есть свободное железо и соответствующие навыки. К тому же на тестовом сервере лицензия слетает. А если сайт реально огромный, на сотни терабайт, то прям тяжко это все организовать. Риски - высокая квалификация админа, плюс дополнительн