Если бы показал какую-то явную асинхронность, то тогда можно было бы принять за реальность... А так, даже оф. документация говорит обратное твоей фразе...
Все что сделано в 8ке - это перемещение крона в отдельный модуль.
Это никуда не делось:
Недостаток автоматизированного модуля cron заключается в том, что он запускается запросом, и незадачливый пользователь, отправляющий запрос, может столкнуться с довольно большой задержкой.
Вообще непонятно откуда эта байка взялась, что крон тормозит сайт
Почему же "байка"?
В действительности, большие проекты при хорошей посещаемости, периодическом кроне с множеством задач, получают проблемы с отказами посещений в аналитике/метрике.
Статья даже где-то была в рунете, как распределяли реальный кейс на ultimate/elysia крон на пиковую посещаемость и получали положительные результаты, с графиками, исследованиями (не вспомню уже что/где/когда).
Да скорее всего так и есть, т.к. картинка даже 404 ошибку не отдает.
P.S. Буст - только там, где железобетонная статика, для инет-магазинов - не вариант.
ИМХО, не надо делать никаких проверок на фронте. Сугубо косметический (юзерфрендли) характер и не более. Все проверки должны быть на бэкенде.
Если все же хочется жесткие условия в jquery, то проще готовые скрипты подцепить (разновидности mask и т.д.). В любом случае вы их будете валидировать/реплейсить на бэкенде.
В форму можно очень просто передать любые значения, игнорируя скрипты. Полагаться на фронт - это недальновидность (имхо).
Выкинуть нафиг это дебильный html5 - type="number"... Не мучайтесь, он ни в одном браузере не стандартизирован.
И сделать как bumble говорит, только на textfield.
На своем...
Особенно, если будете затачивать под валидаторы html5, schema.org, ARIA и т.д.
В 8ке вы в любом случае будете от базовой темы отталкиваться (stable - по умолчанию)
P.S. Bartik - это пример, а не тема с нуля.
P.P.S. Бутстраповские библиотеки 3 строчками подключаются.
Этот модуль загоняет вас в топорную структуру, где все данные должны быть в поле body, в том числе и картинки.
Если структура сделана по-человечески, хотя бы с минимальными возможностями Друпал, то этот модуль автоматом становится нерабочим... именно так, как указал Semantics.
Проблема со скоростью. Ошибка в вебмастере, то появляется, то исчезает без изменений на сайте.
Надоело уже одно и то же талдычить...
Короче, следуйте документации - https://www.drupal.org/docs/8/administering-a-drupal-8-site/cron-automat...
И не выдумывайте всякую херню.
Проблема со скоростью. Ошибка в вебмастере, то появляется, то исчезает без изменений на сайте.
Потому что юзер получит ответ вместе с кроном, как раз в самом terminate.
Проблема со скоростью. Ошибка в вебмастере, то появляется, то исчезает без изменений на сайте.
Не сойдет, повторюсь еще раз:
Все же рекомендую углубиться в более детальное изучение архитектуры...
Проблема со скоростью. Ошибка в вебмастере, то появляется, то исчезает без изменений на сайте.
Вот когда будет, что-то подобное в коде:
<?php
fastcgi_finish_request()
?>
Тогда и можешь утверждать подобное.
Проблема со скоростью. Ошибка в вебмастере, то появляется, то исчезает без изменений на сайте.
Если бы показал какую-то явную асинхронность, то тогда можно было бы принять за реальность... А так, даже оф. документация говорит обратное твоей фразе...
Проблема со скоростью. Ошибка в вебмастере, то появляется, то исчезает без изменений на сайте.
Все же рекомендую детальней изучить:
https://github.com/symfony/http-kernel
а потом сопоставить с твоей же фразой:
Проблема со скоростью. Ошибка в вебмастере, то появляется, то исчезает без изменений на сайте.
Все что сделано в 8ке - это перемещение крона в отдельный модуль.
Это никуда не делось:
Источник - https://www.drupal.org/docs/8/administering-a-drupal-8-site/cron-automat...
Так что фраза:
Проблема со скоростью. Ошибка в вебмастере, то появляется, то исчезает без изменений на сайте.
Почему же "байка"?
В действительности, большие проекты при хорошей посещаемости, периодическом кроне с множеством задач, получают проблемы с отказами посещений в аналитике/метрике.
Статья даже где-то была в рунете, как распределяли реальный кейс на ultimate/elysia крон на пиковую посещаемость и получали положительные результаты, с графиками, исследованиями (не вспомню уже что/где/когда).
Установка Noindex и Nofollow - модуль Aggregator
Конкретней напишите, о какой ссылке речь.
Если о иконке, то сюда - https://api.drupal.org/api/drupal/includes%21theme.inc/function/theme_fe...
[Видео и текст] Форматирование вьюхи в виде селектбокса с определением активного элемента в зависимости от урла
Т.е. по факту ты закостылил обычное меню в селект (без формы) и еще одним костылем добавил для опции с текущим урлом атрибут selected...
Аналогичным способом (jquery) можно прятать все пункты меню, где у ссылки нет класса .active... А по клику выводить полное меню...
P.S. А так, хорошо все объясняешь, слушать можно. Контент бы тебе только годный...
Периодически не создаются превью изображений
Да скорее всего так и есть, т.к. картинка даже 404 ошибку не отдает.
P.S. Буст - только там, где железобетонная статика, для инет-магазинов - не вариант.
Периодически не создаются превью изображений
А у этого человека почему не спросите - https://drupal.ru/username/vasyok ?
Он же делал этот сайт.
form api #type' => 'number'
Ну да, не прав, жквери раньше. У меня pattern стоял, который на-лету ругается на значение (хром). Без паттерна норм все.
form api #type' => 'number'
Давай так:
Какая валидация отработает раньше: браузерная или джимкери с точкой?
А если нужно оставить стрелочки, но не страхожопные (с примером желательно)? Иначе в чем тогда смысл number?
Простое решение на сравнение Drupal 8
Проверка empty нужна?
https://twig.symfony.com/doc/2.x/tests/empty.html
form api #type' => 'number'
Да в браузерах всегда подвох.
Солидарен с email и tel. Они вполне юзабельны в html5.
Все же оптимальным будет отталкиваться от того, как данные хранятся в бд. Особенно по телефону, суммы транзакций и т.д. Или это только про точку речь?
form api #type' => 'number'
Так ли... но борьбу с type="number" - это никак не решает.
form api #type' => 'number'
ИМХО, не надо делать никаких проверок на фронте. Сугубо косметический (юзерфрендли) характер и не более. Все проверки должны быть на бэкенде.
Если все же хочется жесткие условия в jquery, то проще готовые скрипты подцепить (разновидности mask и т.д.). В любом случае вы их будете валидировать/реплейсить на бэкенде.
В форму можно очень просто передать любые значения, игнорируя скрипты. Полагаться на фронт - это недальновидность (имхо).
form api #type' => 'number'
На такие значения друпаловская валидация (php) отработает.
Какая может быть замена colorbox_node для Drupal 8?
Пользуйся на здоровье, полноценная альтернатива:
https://www.drupal.org/project/colorbox_load
form api #type' => 'number'
Типа того:
form api #type' => 'number'
Выкинуть нафиг это дебильный html5 - type="number"... Не мучайтесь, он ни в одном браузере не стандартизирован.
И сделать как bumble говорит, только на textfield.
На каком шаблоне лучше всего "верстать с нуля"?
https://drupal.ru/docs/veb-masteram-i-vladelcam-saytov/layout-builder-ko...
На каком шаблоне лучше всего "верстать с нуля"?
На своем...
Особенно, если будете затачивать под валидаторы html5, schema.org, ARIA и т.д.
В 8ке вы в любом случае будете от базовой темы отталкиваться (stable - по умолчанию)
P.S. Bartik - это пример, а не тема с нуля.
P.P.S. Бутстраповские библиотеки 3 строчками подключаются.
Вывод изображения для турбо-страниц
Этот модуль загоняет вас в топорную структуру, где все данные должны быть в поле body, в том числе и картинки.
Если структура сделана по-человечески, хотя бы с минимальными возможностями Друпал, то этот модуль автоматом становится нерабочим... именно так, как указал Semantics.