German Jet

Без фреймворка SPA написать можно, только Flask там не при чем. 1) гуглите как писать REST API на фласк, 2) читаете фленегана про яваскрипт, 3) доганяетесь learn.javascript.ru про современные API браузеров и SPA собственного приготовления у вас в руках.

Берясь за написания импорта я обычно стараюсь думать не о том как побыстрее обновить побольше товаров, а о том, как побольше товаров не обновлять.
Первая и самая простая оптимизация добавить к свойствам товаров еще одно - HASH и писать туда md5 от сереилазованного массива которым вы хотите обновить товар. Дальше, при следующем обновлении вы перед Update будете вычислять от сериалазованного массива которым хотите обновить товар, этот Hash и обновлять товар только если он не совпадает с сохраненным хэшем и записывать этот новый хэш.
Такая схема очень удобна в случае если источник не умеет отдавать только изменившиеся товары или товар состоит из нескольких элементов ИБ (Товар+Торговое предложени+Элемент свойств). Кроме того помним что цена тоже хранится отдельной сущностью и для нее можно провернуть тот же трюк. Вычислить md5 прямо сильно быстрее чем сделать запись.

Кроме того следите за тем чтобы вашем кастомном импорте не было ничего кроме записи в update внутри цикла. А то всякое видеть приходилось.

Вообще записать 1000 товаров за минуту в базу, без картинок - это полная ерунда. Должно хватить любой производительности, если конечно не выяснится что у вас не 100 ТП к каждому товару.

И да - убедитесь, что и товары и ТП и все ИБ в которые вы пишите во время импорта хранят свойства в отдельных таблицах, а не в общей.

В настройках модуля веб-форм отключите упрощенный режим, заходите в редактирование вопроса, во вкладке Ответ будет таблица, в столбце Параметры пишите дополнительные параметры, например, placeholder="Значение"

Все, разобралась, надо приводить к единому типу данные, тк из json идет строка, а у меня в id идет int
SELECT pr.*, cat.name as cat_name, cat.alias as cat_alias, vn.name as vn_name FROM `jsonproduct` AS pr
LEFT JOIN `categories` AS `cat` ON cat.id = CAST(JSON_EXTRACT(`product_json`, '$.category_id') AS SIGNED)
LEFT JOIN `vendor` AS `vn` ON CAST(product_json->'$.vendor' AS SIGNED) = vn.id
WHERE product_alias = 'my-alias'

Я вам посоветую опубликовать ваш плагин под gnu-like лицензией без всякой защиты и продавать консалтинг и внеочередные хотелки юзеров

Любой тип защиты потребует вашего времени и с не нулевой вероятностью приведет к багам
А наивная защита для популярного плагина - еще и бесполезна
Надежная защита в виде бинарника с защитой от реверса - не тривиальная штука. И ее не написать без опыта в области реверса

вопросы у вас философские, на каждый можно отвести часы обсуждения

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

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

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

Что касается лексики. IT-шной лексики можно понабраться из соответствующих книг, сайтов и форумов. Чтобы овладеть более обширным и общим словарным запасом, нужно использовать самые разные источники с самой разной тематикой - художественная литература (но от разных авторов), нехудожественная литература, статьи о политике, экономике, культуре, искусству, науке и т.п., фильмы, - в общем, все подряд. Ибо в разных источниках используется совершенно разная лексика.

Еще одно (мое личное, субъективное) мнение. Чтобы уметь читать, нужно начать читать, чтобы уметь писать, нужно начать писать. Для развития навыков понимания устной речи, нужно слушать устную речь. Чтобы научиться разговаривать нужно начать говорить. При этом навык чтения может способствовать навыку понимания на слух, а письмо может помогать говорению. Но именно помогать, а не полностью заменять.

Прежде всего, не всегда нужен фронт с js-фреймворком. Часто вполне достаточно обычных страничек. Но если действительно нужен развитый фронт, то бэк перестаёт использоваться для рендеринга шаблонов и выступает как REST- или GraphQL-сервис. Из Django для этого даже специализированное и очень удобное решение выросло - Django REST Framework.

Как-то так примерно:

urls.py

urlpatterns = [
    path('check-username/', check_username, name='check_username'),
]

views.py

@require_GET
def check_username(request):
    if 'name' not in request.GET:
        return HttpResponseBadRequest()

    return JsonResponse({'exists': User.objects.filter(username__iexact=request.GET['name']).exists()})

registration.js

$('#id_name').change(function() {
    $.getJSON('/check-username/', {'name': $(this).val()}, function(user) {
        if(user.exists)
            alert('Пользователь с таким именем уже зарегистрирован');
    });
});

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 так далее, далее, далее... когда Вы будете всё это понимать - в голове будет складываться целостная картина происходящего, а не обрывки каких-то знаний. Разработка интернет-магазина в этом процессе, глобально, погоды не сделает, но какой-то опыт безусловно даст, главное, перед тем как будете разрабатывать собственный магазин - найдите какой-то уже готовый и постарайтесь в точности повторить его функционал, начиная от восстановления пароля заканчивая тем, как в корзине пересчитывается цена при изменении количества товара.