Sanes, ну ты чо?!
а как же новый оператор "??"
это же в корне меняет весь подход к языку!
LeoDzhi, если материал написан в легкой для усвоения форме и без ошибок, ничего страшного в изучении его не вижу.
Разве что главы про настройку IDE и локального окружения можно пропускать или просматривать по диагонали
это называется - альтернативный способ загрузки стилей и он вполне имеет место быть в некоторых случаях.
Например, для уменьшения размера бандла на критически важных страницах для мобильных пользователей с узким каналом
либо так же запихнуть статично их через шапку ваших статичных страниц
а вот это уже с большей вероятностью можно назвать говнокодом.
конечно, если эти "статичные страницы" не должны выводить полностью другой код (например не должны срабатывать wp_head/footer - может быть проще совсем не использовать эти хуки)
Максим Виксна, посмотри в документации WP подключение стилей. Там очень подробно и с примерами.
в двух словах:
подключай через functions.php с условием, выводить на страницах, где ID = нужной странице
1VAAS1, в этом случае было бы хорошо посмотреть их гит - когда был сделан первый коммит по такому проекту, когда последний
Почему-то думаю, не будет там 3-4 дня. Мелкие студии часто имеют завышенные ожидания
Оба способа одинаково плохи. И оба способа имеют право на применение в некоторых случаях. Если вы знаете, зачем именно вам нужен именно такой способ, то проблемы нет.
В 90% случаев 1й способ применять нельзя. Аргументировать в тысячный раз почему нельзя мне лень. Читайте документацию, там все есть.
В вашем случае (если показывать инфу нужно с страницы этого же товара), я бы вообще отказался от аякса. Все такие запросы не кэшируются, зачем лишняя нагрузка?
Можно эту инфу предварительно выводить в скрытый див на этой же странице, показывать в попапе после клика уже готовое. Или, что лучше, выводить эти данные как значения js переменной, и по клику рендерить попап на основе этих данных.
Чтоб ответ был более полным - вместо запроса к admin-ajax.php можно использовать rest api, получать данные по товару оттуда.
Ну и "придется захломлять файл functions.php объемным кодом шаблона"
а что мешает вынести шаблон в отдельный файл и заинклудить его в functions.php?
Что делать, если контракт уже третий раз заморожен по вине заказчика?
Конечно же продолжать работать, пока его не заморозят и в 5й и в 8й раз!
Если серьезно, если в самом начале по заказу что-то идет не так, в 99% случаев и дальше заказ принесет проблемы.
Смотрите как у вас по обстоятельствам. Если без этого проекта прожить никак, продолжайте пытаться. Если есть другие заказы, пишите заказчику, что сможете работать по его заказу еще максимум неделю-две, попутно долбите саппорт, что заказчик морозится.
алгоритм такой:
1 отключить плагины, переключиться на стандартную тему
2 убедиться, что так ошибки нет
3 разбираться с плагинами, своей темой, своим кодом
Если сеошник не сможет аргументировать, что переход на webp это прям критично для продвижения, шли его лесом.
А аргументировать он не сможет, тк скорость - это не самый приоритетный фактор ранжирования
Вытягивать гуглопопугаи на 100/100 - особого смысла не имеет. Для 90% проектов достаточно будет подключить lazyload. Фанатично переводить все в webP так же не всегда оправданно - в некоторых случаях размер картинки в этом формате может даже стать больше.
Но если сильно хочется:
1. можно использовать тег picture для предварительно подготовленных картинок (ниже в комментах некоторые сеошники пишут, тег pictrue плохо поддерживается гуглом - полная фигня. Гуглоботы сейчас умнее некоторых сеошников, тег работает отлично).
2. или можно подключить CDN, который будет на лету конвертировать картинку в нужный формат. Такие есть даже бесплатные
azerphoenix, фигня.
На самом деле, к этой задаче как минимум 2 подхода:
1. делаем отдельную табличку (или кастомный тип записи), куда пишем все нужные события, потом тупо выводим эту табличку/записи в нужном месте
2. и от обратного - ничего никуда не сохраняем, для вывода такого блока обращаемся к текущим постам, тупо выводим последние n постов
1й вариант предпочтительнее использовать если нужны кастомные события или выборка по дате для таких событий будет нагружать сайт
2й вариант дешевле и тупо проще, подойдет, если все "события" можно брать выборкой по дате/дате изменения из wp_posts
Illia T, делать нужно на том, что лучше знаешь.
Если не можешь сам выбрать между двух инструментов, значит какой-то из них знаешь плохо.
Если одинаково плохо знаешь все инструменты, делай на том, на чем делает большинство - проще будет найти решение проблемы.
я, конечно, не специалист, но думаю, чтоб сделать "чтобы при пополнении баланса яндекс денег в командную строку приходило сообщение «+»", вам нужно написать скрипт, который будет при пополнении баланса яндекс денег в командную строку отправлять сообщение «+»
Владимир Брумер, еще и не факт, что ему именно такие графики нужны
чувак, в попытке зашифровать свой чудо стартап, выдал крайне общую задачу. Ему нужно дробить на мелкие непонятные подзадачки и уже их тут спрашивать.
алгоритм простой:
1 делаем запрос к WP, получаем к-во нужной таксономии/меню/прочего
2 полученные числа используем для построения графиков
графики можно строить по разному, куча готовых js библиотечек есть
конкретная реализация - это уже не в формате текущего сайта. Это лучше на фриланс
Роман Александрович, не не
пример с буквами не совсем подходит, сходу другую аналогию не скажу
имел в виду, что незнание реакта от изучения реакт натив его не блокирует.
можно начинать изучение. Да, с реактом сразу было бы продуктивнее, но оно по дороге выучится
а как же новый оператор "??"
это же в корне меняет весь подход к языку!
LeoDzhi, если материал написан в легкой для усвоения форме и без ошибок, ничего страшного в изучении его не вижу.
Разве что главы про настройку IDE и локального окружения можно пропускать или просматривать по диагонали