Коллеги, не нужно что-то выдумывать для себя, достаточно определиться с рекомендациями по оформлению кода PSR и придерживаться этого единообразия.
Какие-то специфичные формы оформления можно закрепить в технической документации проекта, построив свой гайдлайн.
Вы можете добавить атрибут data-id.
<div class="product-sku" data-id="1">Товар 1</div>
И тогда передавать ID этого атрибута с помощью jQuery-метода data();
Устанавливал на свой iMac Kaspersky Internet Security. Нужно было проверить несколько файлов и не хотелось их грузить для проверки на внешний сервис.
Удалил буквально в этот же день или на следующий, используя поставляемый в комплекте с KIS деинсталлер. Теперь несколько лет, время от времени после загрузки системы мне прилетает уведомление о том, что какое-то приложение, подписанное Kaspersky LAB UK Limited, установило системное расширение, которое не совместимо с будущей версией Mac OS X.
И не могу найти что это за системное расширение. Проверил каталоги с extenesion'ами, явно каких-то упоминаний kis/kav нет. Проверять подпись этих файлов, чтобы увидеть какое именно подписано Kaspersky UK Limited нет времени и лень.
Поэтому Касперский не советую.
Роутинг, авторизация, защита Cross Site Request, шаблонизация, события - первое, что в голову пришло из ряда универсальных для каждого сайта компонентов.
Это реализует практически любой фреймворк.
Я вот разработал движок, ядро, в котором все нюансы предусматриваются. То есть я заранее думаю, а вот если пользователь захочет сделать так, то как он это сможет сделать, а если так и тд. и под эти все нюансы ищу решения, пользователю надо будет только заглянуть в документацию и сделать по инструкции подготовленными примерами.
Он, наверное, подумал, что нужно прописывать редирект для каждой страницы. А если страниц тысячи, то нужно прописать тысячи редиректов.
Чтобы сделать редирект хоть на 1 миллион доменов достаточно в конфиге веб-сервера прописать этот редирект. Если это nginx, то это сделаться одной строчкой в блоке server.
server { server_name olddomain.ru; return 301 https://newdomain.ru$request_uri; }
Если вы используете любые внешние ресурсы, в том числе JS-файлы рекламных агрегаторов – и они подключаются по протоколу http:// будут выдавать ошибку на сайте. Поэтому при подключении внешних ресурсов можно использовать безпротокольную ссылку //
Например,
<script async src="//www.googletagmanager.com/gtag/js?id=UA-XXXX"></script>
Yii2 или любой другой нормальный фреймворк с компонентом RBAC.
Комментарии должны храниться в базе данных как вложенные множества. Тогда и получите необходимые нормальные древовидные комментарии. И jQuery тут не причем.
Я вообще не понял вопрос. Если вы создали скрипт, который позволяет работать с шаблонами сайтов для своих клиентов, то домены третьего уровня должны работать согласно запланированной Вами архитектуры.
С точки зрения проектирования мне представляется два варианта.
1. Ресурсы (css, images, js) шаблона копируются в WWW-каталог домена третьего уровня. Потом с этими шаблонами происходит манимуляция через WYSIWYG-редактор.
В этом случае Вам нужно создавать эти WWW-каталоги, добавлять конфигурацию WWW в nginx или Apache, смотря что у вас там используется.
2. Страницы сайтов клиентов генерируется backend скриптом. При этом и основной сайт и сайты ваших клиентов имеют единую точку входа. Работа сайтов третьего уровня эмулируется с помощью mod_rewrite.
Для любого из этих вариантов нужно прописать на DNS-сервере для всех субдоменов IP-адрес родителя.
На мой взгляд самым оптимальным способом сжимать изображения без потери качества это в фоне выполнять задание для утилит jpegoptim и optipng. Этот же метод рекомендует Google.
