[На сайте не встраиваться видео с youtube]

7 часов назад, Captain сказал:

Бедные люди, реально их жаль.

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

[На сайте не встраиваться видео с youtube]

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

Извините еще раз что отнял ваше время, и искренне желаю вам успеха в развитии движка.

[На сайте не встраиваться видео с youtube]

1 минуту назад, celsoft сказал:

Когда нет связи ее просто нет

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

А еще бывает что человек просто ошибся в адресе, и Ютуб ответил 404, это тоже можно вывести. И человек сразу поправится а не будет терзать техподдержку и вас ))

[На сайте не встраиваться видео с youtube]

43 минуты назад, celsoft сказал:

Во первых вы нигде не указывали откуда вы, поэтому догадаться об этом никто не может. Банит Youtube крым или нет, я не не знаю, я не Youtube.

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

50 минут назад, celsoft сказал:

Это вы прочтите что вы написали, к слову технологию не применяется приставка "через", когда имеется ввиду ее использование.

Ну ок, просто мы же не на сайте "граммар-наци" ))

52 минуты назад, celsoft сказал:

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

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

[На сайте не встраиваться видео с youtube]

8 минут назад, celsoft сказал:

Не через oEmbed а с использованием протокола обмена данными oEmbed. oEmbed это стандарт обмена данными для получения вставки кода, а не сервис через который что то делается.

Я нигде не писал про какой-то  сервис, имел ввиду технологию. Прочтите мое сообщение внимательно.

 

9 минут назад, celsoft сказал:

Нет не может. Протокол обмена данными oEmbed официально поддерживается сервисом Youtube. Да и проблемы были бы у всех, а не только у вас после смены хостинга. Никаких проблем в поддержке oEmbed у Youtube на данный момент нет. Специально проверил сейчас.

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

Мне вот например нравится как сделано на Хабре, там при вставке видео прямо в редакторе рендерится видеоплейер. И ты сразу видишь - вставилось или нет, и что именно вставилось. А тут ты вставил и не уверен что оно отрендерится после сохранения. Так еще и после того как успешно отрендерилось - через некоторое время редактируешь текст и видео может слететь если Гугл закрыл доступ с сервера.

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

[На сайте не встраиваться видео с youtube]

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

[На сайте не встраиваться видео с youtube]

16.03.2024 в 16:18, celsoft сказал:

Это зависит от настроек сервера в первую очередь.

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

[Сделать нормальную систему плагинов]

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

[Сделать нормальную систему плагинов]

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

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

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

4 минуты назад, MSK сказал:

А что вы вкладываете в понятие "на лету"?

В комментарии все есть, прочтите внимательно

4 минуты назад, MSK сказал:

Это относится ко всем сторонам полемики ;)

А вы адвокат celsoft?

[Сделать нормальную систему плагинов]

1 час назад, celsoft сказал:

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

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

 

1 час назад, celsoft сказал:

Если структура БД изменилась, то ваш код который работает со старой структурой конечно же не сломается. Вы в это искренне верите? Вопрос риторический.

Ломается все одинаково и в Wordpress плагины отваливаются на ура при обновлении. Так что тестировать предварительно нужно всегда обязательно и везде перед обновлением, независимо от CMS. Поэтому все ваши перечисленные пункты никоим образом не отменяются.

При правильном спроектированном API, работа плагинов не будет зависеть от внутренней структуры БД. Если вы планируете какие то изменения, которые поломают обратную совместимость - помечаете аргументы или сами хуки как deprecated и постепенно выводите их из кода. Ведь все уже давно придумано, надо просто взять удачную реализацию API за основу. А вот то, что сейчас у вас реализовано - это не плагины, это хаки. И вот как раз эти хаки крайне жестко связаны с кодом и структурой БД.

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

 

1 час назад, celsoft сказал:

Для вас может быть важнее не тратить время на проверку, хотя придется все равно, но для нас абсолютный приоритет производительность и максимально возможный низкий расход ресурсов сервера. Поэтому хуков не будет никогда.

Да не вопрос. Никогда так никогда. Ваша система, вы решаете. Просто я отметил, что для использования плагинов нужно привлекать PHP разработчиков (как минимум для написания плагина и потом для обновления системы). А с этим у клиентов часто большие проблемы. Поэтому как бы ни была хороша ваша система, но обслуживать даже несколько сайтов на DLE с разными "плагинами" - занятие утомительное для обычного вебмастера. Не говоря уже о том, чтобы как то серьезно модифицировать функциональность скрипта. Поэтому на десятках других сайтов я использовал иные CMS, потому как отдать заказчику сайт на котором потом надо каждый раз для обновления проверять все плагины, править стили и шаблоны - ну так себе идея. А уж если заказчик захочет что нибудь нестандартное реализовать, то вообще "туши свет".

 

2 часа назад, celsoft сказал:

Регистрация событий происходит при каждом выполнении CMS и при каждом просмотре страницы, а не один раз и на всю жизнь когда вы его поставили. Зарегиструйте тысячи обьектов, похраните их, попроверяйте и повызывайте, проведите тесты, и только потом делаете выводы. Чтобы ваш код выполнился через хук, его нужно зарегистрировать в системе, пройтись по всем плагинам, зарегистрировать их в памяти, и только потом выполнять в нужных местах и событиях. И все это при каждом выполнении, т.е. просмотре страницы. Смотрите например обратную связь, а CMS еще и пройдет по плагинам регистрации пользователя на сайте и т.д. разместит в памяти код, и зарегиструет события и для этого ненужного точно на данной странице плагина, потому что пока его код не выполнен, неизвестно что он там делает, а его выполнение как раз и регистрирует события и хуки где его вызывать, потому что события нужно зарегистрировать в системе. Пример прожорливость приведенных выше других CMS, таких как Wordpress, 1С и других.

Не спорю что это много работы. И хотя по скорости и прожорливости у меня нет под рукой данных, но например правильно настроенный Wordpress с кучей плагинов у меня выдавал примерно такие же показатели как и сайт на DLE (на одном и том же физическом сервере) в Lighthouse. Но в Wordpress гораздо больше настроек и возможности кастомизации + визуальный билдер Oxygen. Что для клиента явилось достаточным аргументом в пользу выбора первого - он просто дешевле в обслуживании и быстрее в запуске.

 

2 часа назад, celsoft сказал:

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

Да, возможно я и не прав. Но и вы также никаких цифр не предоставляете, а просто утверждаете что другие CMS хуже потому что то вроде "хуки тормозят систему, а виртуальная файловая система нет". По правилам полемики тот кто что либо утверждает, берет на себя бремя доказывания.

[Сделать нормальную систему плагинов]

1 минуту назад, celsoft сказал:

Никогда !!!! Потому что эта система не имеет преимуществ и имеет колосальные недостатки по производительности.

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

 

7 минут назад, celsoft сказал:

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

Вот тут я с вами не согласен. Хук имеет строго определенное API - перечень передаваемых аргументов и возвращаемых значений, и если внешний контракт плагина с хуком не нарушен, то ничего сломаться не должно. На этом стоит вся система плагинов, и именно в этом её сильное преимущество перед тем что вы предлагаете.

[Сделать нормальную систему плагинов]

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

1. Накатить обновление сначала на тестовом сервере, там все поправить. Однако не у всех есть свободное железо и соответствующие навыки. К тому же на тестовом сервере лицензия слетает. А если сайт реально огромный, на сотни терабайт, то прям тяжко это все организовать. Риски - высокая квалификация админа, плюс дополнительное время и ресурсы на разворачивание на тесте.
2. Перевести DLE в сервисный режим, накатить обнову и править на продакшене. Все время пока будут делаться исправления - сайт будет простаивать. Не факт что все плагины удастся легко исправить. Риски вывода сайта из работы на неопределенное время.
3. Вариант который я сам использую. Перед обновлением скачиваю архив, локально его изучаю и по каждому плагину прохожусь вручную, пытаясь выполнить те действия которые есть в плагине. Если надо, создаю обновленную версию плагина для новой версии DLE и после обновления на продакшене включаю эти плагины, отключая их старые копии. Риски - велика вероятность ошибок (можно что то не заметить) и огромный объем работы впустую, если плагинов скажем несколько десятков.

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

 

P.S. не туда написал ((
Целился в раздел "Пожелания для новых версий DataLife Engine"