campusboy

Обычно в разных коллекциях выкладывают картинки и делают упор на дизайн, т.е. текст писем придется самому анализировать.
Вот единственная коллекция с текстами, про которую я знаю, буду благодарен, если подскажете еще:
www.goodemailcopy.com

Вот несколько коллекций с примерами дизайнов писем:
https://www.mailcharts.com/
https://www.campaignmonitor.com/email-templates/
emailsfresh.com
www.htmlemailgallery.com
htmlemaildesigns.com
beautiful-email-newsletters.com
email-gallery.com

v-bind:src=""
или
:src=""

vuejs.org/class-and-style

interfaces.pro - живые
froala.com/design-blocks - шаблоны

1) На сколько удобны Homstead + Vagrant, которые они рекомендуют использовать? Посмотрел информацию по его установке, использовании. Разве это удобнее всем привычного openServer?

Насколько удобен конкретно именно этот стек, и насколько он удобен будет лично для Вас - сказать затрудняюсь, но в общей сложности, использование "родной" среды при разработке приложения - практика весьма правильная. Думаю что в данный момент, большинство моих эпитетов на тему "почему оно так и зачем" Вам будут не очень интересны, но, есть простой пример из реальной жизни: в *nix, чаще всего, файловые системы чувствительны к регистру имён файлов, в Windows [NTFS] (и OpenServer в частности) - такой чувствительности нет, что влечёт за собой потенциальные ошибки в самый неподходящий момент (когда Вы будете выгружать сайт на хостинг) и исправить их "по быстрому" удаётся не всегда, по этому, я бы рекомендовал использовать "родной" Linux при разработке. Какой стек взять - сакрального значения не имеет, мы используем: Docker (Hyper-V), VirtualBox + настроенную самостоятельно вирт. машину и различные другие варианты (среди которых, OpenServer проскакивает крайне редко).

2) Прямо из коробки Laravel поддерживает Vuejs, но посмотрев их курсы на Laracasts и ещё пару примеров компонентов для него, мне показалось, что он не совсем подходит для того, чтобы делать на нём те же слайдеры, системы частиц и подобные вещи.

VueJS - это JS фреймворк, волей судьбы "встроенный" в Laravel. Как мы знаем, JS относится к области вёрстки, что в целом с фреймворком серверным связано крайне слабо. Какие элементы в вёрстке использовать лично Вам - дело - лично Ваше. Из собственного опыта могу сказать, что мы в своей работе не гнушаемся ни VueJS, ни jQuery, ни различными готовыми слайдерами и вообщем всем, что может быть уместно в рамках конкретных требований конкретного проекта. По сему - я думаю Вам не стоит забивать себе этим голову. Насколько и чем хорош VueJS - можно узнать из массы уроков по оному.

Вообще не понравилось, что в HTML-разметке вставляются ивент-слушатели, как в стандартном JS прям (@click, onclick). Мне это напомнило встраивание CSS прямо в тэги. Мне нравится в jQuery то, что все ивенты вешаются прямиком в скрипте, не заглядывая в HTML-разметку.

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

Я просмотрел вакансии на разных сайтах, чтобы понимать, какой стэк технологий нужен работодателям, и в требованиях я вообще не нашёл, что им нужен jQuery, только Vuejs. Отсюда и вопрос, то есть мне нужно переписать свои слайдеры, системы частиц под Vuejs? Часто встречал сообщения о том, что переплетать эти две технологии плохая затея. Либо то, либо то. Посмотрел предложенные готовые слайдеры, вообще не впечатляют.

Работодателю нужны сотрудники способные принимать решения и выдавать конечный продукт. Остальное особого значения не имеет. Если Вы сможете выдавать продукт нужного качества в рамках поставленных сроков, а потом поддерживать этот продукт в надлежащем состоянии - поверьте мне, работодателю будет совершенно всё равно, на как и на каком языке Вы это делаете, хоть на С++ бекенд пишите.

3) Хорошим ли является планом, чтобы сделать воображаемый интернет-магазин для обучения и освоения Laravel? Или как лучше изучать эту технологию от легкого к сложному? Всегда была проблема с тем, чтобы структурировано изучать ту или иную область разработки. Чтобы не тупо копировать, а понимать, как всё устроено и как работает.

Что бы понимать что-то структурно - нужно понимать истоки. В области веб-разработки таковыми "истоками" могут являться например, протокол HTTP, фундаментом которого будет протокол TCP/IP, в основе которого лежат другие технологи... чем лучше Вы будете понимать как всё работает изначально, и в результате чего появилась, например, такая парадигма как MVC, как работает composer так далее, далее, далее... когда Вы будете всё это понимать - в голове будет складываться целостная картина происходящего, а не обрывки каких-то знаний. Разработка интернет-магазина в этом процессе, глобально, погоды не сделает, но какой-то опыт безусловно даст, главное, перед тем как будете разрабатывать собственный магазин - найдите какой-то уже готовый и постарайтесь в точности повторить его функционал, начиная от восстановления пароля заканчивая тем, как в корзине пересчитывается цена при изменении количества товара.

Здравствуйте.

Хм, возможно, так:

$taxonomy = get_taxonomy( 'tag' );
print_r( (array) $taxonomy->object_type );

$cats = array(91,22)
if ( has_term($cats, 'product_cat', $product_id ) ) {
    // выводим что нужно
}

Есть такая штука в ООП как инкапсуляция. С этого стоит начать и в принципе можно было бы закончить, если бы не static и не protected.

public
Публичные методы класса. Логично да? Какие методы у нас должны быть публичными - те которые составляют интерфейс класса. То есть для, например, класса кеширования у нас должен быть такой интерфейс:

interface Cache {
    public function get($name);
    public function set($name, $value);
    public function has($name);
    public function remove($name);
    public function removeAll();
}

Давайте введем понятие "клиентский код". Это тот код который будет использовать ваш код, ваши объекты. Что он должен знать о реализации ваших классов? Да ничего он знать не должен. Он должен знать только как им пользоваться. Это как раз таки интерфейс и регламентирует. Мол "этот объект позволяет вам брать/сохранять/удалять данные в/из кэша. Клиентский код не знает где кэш находится, есть ли он вообще... да и ему и не нужно.

private
Внутренние методы классов. Те которые не входят в интерфейс но нужны, скажем, для уменьшения дублирования реализации.

class FileCache implements Cache{
    public function has($name) {
          return is_file($this->getCacheFilePath($name));
    }

    public function get($name) {
         if (!$this->has($name)) {
              return null;
         }
 
         return unserialize(file_get_contents($this->getCacheFilePath($name)));
    }

    private function getCacheFilePath($name) {
         return $this->cacheDir . '/' . $name;
    }
}

protected
Иногда у вас появляется необходимость вынести общую реализацию внутренних методов в базовый какой-то абстрактный класс. Например у вас есть несколько реализаций кеша для одного и того же хранилища или что-либо такое. Тогда вы заводите абстрактный класс, выносите туда всю общую реализацию в protected методах ну и т.д. Придумывать пример лень... Придумайте сами. Суть в том что protected методы желательно использовать только в абстрактных классах (но не как абстрактные методы, хотя всякое может быть) или если вы планируете дать возможность расширять ваш класс (но если честно, это крайне редко бывает).

static
Статические методы, это всяческие методы хелперы. Например в языках типа Java есть такое понятие как именованные конструкторы. Мол когда для конструирования объектов нужно много данных переделать или что-то еще, для удобства заводят статический метод какой а в нем уже реализуют какую-то логику. Желательно вообще что бы статический метод не содержал много логики, но... всякое бывает. Вообще тут стоит еще поподробнее почитать о том как себя ведут статические методы и свойства, в чем их особенность и т.д. Попробуйте тот же сингелтон сделать к примеру.

class Template($content) {
    public static fromFile($path) {
         return new static(file_get_contents($path));
    }
}

Вот... Возможно человеки вроде FanatPHP разгромят мой ответ, или дополнят его...

Так же если вам хочется научиться правильно составлять интерфейсы классов, следует почитать про low coupling и high cohesion. Эти два принципа должны заставить вас соблюдать баланс и держать в интерфейсе класса только то, что там должно быть. Так же к вопросу о наследовании можно подключить принцип подстановки Барбары Лисков. Даже на той же википедии почитайте. А там если станет интересно в принципе можно поискать интересные материалы по GRASP и SOLID.

Вариантов снять нагрузку - несколько (речь про AJAX):
1. Запрашивайте (раз в 5 секунд) только тогда, когда пользователь: водит мышку, скролит страницу, уходит или возвращается на вкладку в браузере, если блок с обновляемой информацией находится внутри границ viewport'a (или оказывается там).
Т.е., все случаи, когда пользователь не следит за обновлением информации, то и не нужно "мучить" сервер по-пусту...
2. На стороне сервера - кладите информацию (предназначенную для всех) в общий кэш: в память и затем проверяйте оттуда без обращения к БД.
3. Используйте проверку и обновление данные по cron, чтобы обновлять кэш (как для контента, предназначенного для всех, так и по-пользовательскому контенту) для всех, находящихся в данный момент on-line.

Или используйте сокеты (и, конечно, про кеш - не забывайте).

the_header_video_url — это для темы, а не для записей. С помощью этой функции можно получить видео, которое прикрепили в настройках темы. Оно будет одно. Подробнее.

Если хотите добавлять видео для каждой записи, то можете воспользоваться Advanced Custom Fields. Для него на github есть поле для видео.