Игорь Воротнёв

А если вот так (опция All Desktops)?

Вам понадобится посмотреть код плагина кеширования и найти то место, где можно включиться и помочь ему понять, что если wp_is_mobile() у нас true, то берем (или создаем и берем) мобильный кеш, если false - десктопный. Если используется их метод кеширования через mod_rewrite, то и настройки этих rewrite надо будет подкрутить, на уровне сервера определяете desktop/mobile.

В описании плагина есть:

8. Enable/Disable cache option for mobile devices

То есть, плагин уже умеет различать девайсы, по определению. Возможно стоит поискать есть ли у него там хуки.

Все время, затраченное на почасовой проект, должно быть оплачено. Коммуникация с клиентом тоже сюда входит.

Единственное, что если вы действительно много времени тратите на переводы туда-сюда и ваш таймлог будет пестрить скринами гуглопереводчика, а не мессенджера, то можете договориться с клиентом коммуникацию вносить как manual time. Тогда вы сможете по итогу переписки с клиентом подвести итог - "Чувак, мы с тобой проговорили в сумме 2 часа, но из них 1 час у меня ушел на переводы. Поэтому я сейчас в manual time добавлю 1 час, ок?". С одной стороны, manual time не попадает под escrow protection вроде. С другой стороны, если коммуникация у вас в мессенджере апворка, то в случае диспута саппорт это сможет посмотреть и подтвердить, если клиент будет письменно одобрять каждый такой manual time в чате.

Вы немножко не в ту сторону смотрите и не совсем понимаете реальный смысл (и пользу) CDN как сервиса/технологии в целом.

Время, которое уходит именно на скачивание файла с сервера CDN не является главным пожирателем времени. Еще до того, как эта закачка начнется, браузер вынужден отрезолвить DNS, отправить запрос на конкретный сервер, пожаться ручками, сверить сертификат и установить соединение. Именно на это уходит большая часть времени. Плюс сама загрузка, в силу влияния механизма Congestion Control и специфики работы протокола TCP не начинается моментально с максимальной пропускной способности канала, а с минимальных пакетов и растет по мере их успешной доставки. А если еще и канал не очень ок в плане потери пакетов (и отката размера пакета), например мобильный 3G, то в результате скорость скачивания будет не особо высокой. А если у вас еще и каждый скрипт со своего CDN подключается - проблема увеличивается многократно. Частично ситуацию можно улучшить с помощью prefetch / preconnect / preload. Но полностью она не решается.

Также, нужно учесть что утверждение "у пользователя уже закешировано" сильно преувеличено. Кеши не такие уж огромные чтобы все умещать, они чистятся, инвалидируются, устаревают чуть более чем постоянно. А с учетом целого зоопарка версий - вероятность что именно ваша версия будет у пользователя вообще-то не так уж и высока.

В это же время если у вас HTTP/2 и все отдается одним или несколькими файлами (для HTTP/2 это действительно не принципиально до определенного уровня) - DNS, SSL и соединение уже установлены на момент запроса, и предшествующий поток данных уже достаточно раскачал канал. Поэтому загрузка (которая и так не самая медленная часть этого процесса) произойдет быстро. Плюс, еще же можно push сделать, сдвинув время начала загрузки.

А теперь про сам CDN и зачем он нужен.

Если у вас основная целевая аудитория находится в РФ (а еще лучше - в Мск и регионе например, что вполне нормально для локальных бизнесов), ставите сервер в этом же регионе и не паритесь. CDN вам не нужен ни свой, ни сторонние CDN для скриптов, ни Google Fonts какой-нибудь. Со своего сервера по HTTP/2 это будет отдаваться всегда быстрее.

Но если аудитория у вас - весь мир, а сервер всего один - вот тут CDN придет на помощь. Живой пример - клиент из Австралии, 60% аудитории - Австралия. Естественно, сервер мы берем в Мельбурне, прямо под боком у его ЦА. И для этих 60% все работает максимально быстро без каких-либо CDN. На среднем мобильном девайсе и на 3G - пару секунд. А вот для оставшихся 40% - США, Канада и Европа - один только RTT до Мельбурна 400-800ms даже на хорошем офисном вайфае. А на среднем девайсе и 3G - вообще жесть - TTI порядка 30 секунд, иногда до 40-45 проседает. И вот тут на помощь приходит CDN - пользователям из Канады, например, файлы начинают отдаваться с ближайшего сервера в Монреале. Да, мы потеряем <0.5 секунды на установку соединения с этим CDN (он ведь прямо под боком, RTT ~50ms), но благодаря скорости передачи данных сэкономим очень много. В результате, на среднем девайсе на 3G, с использованием CDN пользователь из Канады получит TTI практически такой же, как и пользователь из Австралии, на секунду-две больше максимум.

Вот для этого и нужен CDN. А вся эта ересь про "у пользователя уже закешировано" - муть. Использовать CDN только для скриптовых библиотек а не для всех файлов, а тем более разные CDN для разных библиотек - это антипаттерн и проявление лени 80го левела.

Update:

Та же ситуация, кстати, со всеми этими маркетинговыми скриптами и трекерами, которые так любят наши клиенты понавешивать на свои сайты. Вот пример waterfall-графика загрузки странцы и всех ресурсов. Обратите внимание, что все ресурсы с нашего сервера по HTTP/2 (независимо от приоритета ресурса с точки зрения браузера) прилетают вообще мгновенно и практически одновременно. Это заслуга именно HTTP/2. А вот все сторонние скрипты с внешних CDN - при чем казалось бы, которые должны быть быстрыми, ведь это Google, Facebook и тд - занимают кучу времени. И большая часть этого времени это соединение с этими серверами. Кстати, здесь стоит preconnect для всех до единого внешних адресов, без него еще печальнее.



Для сравнения:

- Скорость загрузки страницы целиком без всех этих счетчиков, все файлы со своего сервера по HTTP/2 (включая, кстати, 2 autoplay видео по ~1Mb каждое) - около 250-300ms.
- С Google Tag Manager и зоопарком трекеров под ним - 3000ms. В 10 раз больше.

Если вопрос еще актуален, смотрите мой ответ вот в этой теме. Кое-что полезное о процессе сможете почерпнуть.

Если кратко - забудьте про всякие ftp и прочий олдскул. Работаете локально, коммитите и пушите в нужную ветку. Дальше на стороне удаленного репозитория (GitHub, Bitbucket, Gitlab) происходит вся магия, с которой нужно разобраться единожды как настроить (Travis CI, Jenkins, Bitbucket Pipelines и тд). Запушили в ветку develop - автоматом собралось, протестилось и залилось на staging. Смерджили в master - залилось на прод. Дополнительно пишете скрипты для автоматизации остальных действий (синхронизация БД, медиа-файлов и еще бог знает чего - зависит от проекта и задач).

Если я правильно понял задачу, то я бы на Apache / Nginx сервера с самим WP который слушает 80й порт ловил запросы с https:// в урл и перезаписывал их в http://. Но честно говоря хз, не уверен что WP согласится на такую схему. Подобная связка у меня с CloudFlare, но трафик между CF и моим сервером тоже https, поэтому проблем не возникает. С haproxy экспериментировал, но никогда не работал в проде, поэтому не сталкивался с такой проблемой.

Специалистов катастрофически не хватает. Всякого сброда, который умеет в конструкторы и немножко говнокода по тюториалам - пруд пруди, именно эта категория имплементаторов создает видимость перенасыщения рынка. Впрочем, для них работы тоже хватает, вот только зарабатывать 50-60к на этой работе вряд ли получится - там бюджеты копеечные. А нормальные бюджеты - они только на западе, плюс там уже требования другие, и вот как раз там требуются специалисты. Которых очень мало. И зарабатывают они все заметно больше чем 50-60к. Но это не простенькие плагины и не темы. Это полностью кастомные решения, чаще всего под ключ, или же узкоспециализированные плагины, требующие опыта и знаний. Ну и ecommerce, там просто много работы и нужно хорошо понимать специфику.

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

Во-первых, ссылка должна приходить /wp-login.php?action=lostpassword, а не wp-admin.

Что касается изменения этой ссылки - можете поискать плагины в репозитории, они есть. Если вы не разработчик, который понимает что делает, сами не пытайтесь "написать" эту фичу основываясь на ответах на Тостере - здесь есть ряд вопросов по безопасности, которые нужно досконально понимать. Кратко - встроенная система (wp-login.php) блокируется, вместо нее создаются свои rewrite rules, им отдаются нужные templates, в которых размещены свои формы, у которых есть свои обработчики. Или, вместо rewrite rules используются страницы, созданные в админке, а в их шаблоны или шорткодами выводятся формы и далее опять же свои обработчики. Если хотите углубиться - изучите вот этот урок. Впрочем, он уже староват, можете гуглить по плюс-минус тем же ключевым словам.

Эта фича уже встроена в WordPress с версии 4.4 (2015й год), он умеет корректно создавать нужные размеры, в том числе под ретину. Учимся читать документацию. Начните с пресс-релиза.

Потому что плагин (ACF) пытается максимально угадать, что же вы имели в виду. Посмотрите код функции acf_get_valid_post_id( $post_id ) в файле acf/includes/api/api-helpers.php. Именно эта функция вызывается в начале get_field() (которая, в свою очередь, вызывается в the_field()).

Советую поковыряться во ВСЕХ настройках, несколько раз. Со временем придет понимание как удобнее лично для тебя, и на выходе будет именно так, как надо. Вот как выглядит мой PhpStorm:

Придерживайтесь нескольких простых правил:

- Только западные биржи (а точнее Upwork, его одного хватит с головой)
- Только старательно отфильтрованные заказчики (с рейтингом, рейтами, адекватным подходом и тд)
- Только почасовка, никаких fixed priced
- Только проекты "от Х часов", никаких мелких доделок на пару часиков
- Почасовая ставка, соответствующая уровню верстки и сервиса в целом

То есть, сидите и ловите адекватные заказы, которые проходят данные фильтры. Вероятность долгоиграющих проектов или постоянных клиентов при таком подходе достаточно высока. Со временем получаете контракты на частичную загрузку от одного или нескольких клиентов и работаете на них на постоянной основе, через тот же Upwork.

Если отвечать на это, как на вопрос (а не задание, коим по сути данный вопрос является), то ответ сводится к оператору сравнения множественных аргументов параметров meta_query и tax_query. У вас, скорее всего, используется оператор AND - что подразумевает совпадение ВСЕХ перечисленных условий. А вам нужен оператор OR или комбинация операторов.

Создавайте локальные self-signed сертификаты корректно, подписывая их специально созданным локальным рутом. Его (рут-сертификат) добавляйте в keychain. Уроков в сети - масса, разжевано уже сто лет назад.