Александр

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

На работе:

1. Создать аккаунт на bitbucket.org
   
2. Создать там пустой проект
   
3. Гитом клонировать его в локальную папку
   
4. Скопировать в папку свои файлы
   
5. Занести node_modules в gitignore-файл
   
6. Сделать коммит
   
7. Сделать push
   

Дома:

1. Склонировать гитом проект в локальную папку
   
2. запустить npm install
   
3. и работать
   

P.S. Bitbucket позволяет создавать приватные git-репозитории бесплатно, в отличие от github. Поэтому выбираем его.

> Качественный графический браузер для MongoDB под линукс

Google Chrome

Хочешь больше зп?
Найди новую работу

АПД
Теоретически, нужно поговорить с начальством. Да

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

Даже теоретики в коментах

АПД2
У прохождения собеседования есть еще преимущества
- ты получаешь подтверждение своей квалификации и необходимости тебя на рынке
- ты получаешь денежный еквивалент своей ценности
- ты получаешь повышение навыка прохождения собеседований - ето отдельный навык, который не часто пересекается с навыком программирование/разработка/администрирование/...
- в случае провала собеседования у тебя нет никаких побочных еффектов
- ты получаешь срез навыков необходимых рынку

https://www.youtube.com/watch?v=nPYmp586EE0

Видео
Мне оно помогло научиться дебажить правильно.

Вставать на его место с кратным повышением зп, это же очевидно.

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

<?php
  $list = array("hello", "privet");
  $arr = array("hello" => "Vasya", "privet" => "Petya", "zdorovo" => "Misha");
  $arr = array_filter($arr, function($key) use ($list) { return in_array($key, $list); } , ARRAY_FILTER_USE_KEY);
  print_r($arr);
?>

Самое разумное - делать прототипы. В этом случае какие бы слабые спецификации ни были, клиент в итоге получит то, что хотел за относительно разумные деньги (по сравнению с переделкой готового функционала).
Всё описать никогда не выйдет, особенно при таком длинном процессе и большом количестве ответственных звеньев.

Не должны хранится в одной ячейке такие инпуты. Сделайте OneToMany отношение и с collection их прицепите в форме. Будут атомарными данные и всё как полагается :)

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

Любая задача решается не более, чем за одну неделю. Подавляющее большинство программ выпускаются в бету за 2-3 месяца. Если дольше - нужно бить тревогу. Или неправильное планирование, или проблемы в команде.

Мониторить просто - по списку задач в трекере и/или по коммитам. Не нужно ожидать, что разработчик будет выдавать какой-то прогресс ежедневно. Программирование - это не линейный процесс. Можно день-два протупить, а потом за десять минут сделать - такое происходит постоянно. Удобными для всех будут ежеденедельные итерации. Например, каждый понедельник проверять прогресс за неделю, и при необходимости, скорректировать его.

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

Это удивительно, но многие, будто конченные олигофрены, не понимают, что консультации отнимают и силы, и время. И именно поэтому должны быть регламентированы.

С консультациями, как с сексом. Хотите, чтобы было качественно? Тогда нужно хорошо подготовиться. И вести себя прилично. Всегда. Хотите хорошие ответы? Продумайте свои вопросы.

В состоянии потока любая хрень может отвлечь и нарушить рабочее состояние. Особенно - вопросы. Особенно - глупые вопросы. Глупые не с вашей точки зрения, а с точки зрения разработчика. Программист работает циклами по 2-4 часа. Если нарушить цикл (например, задав глупый вопрос или позвонив по телефону) - теряется ПОЛОВИНА ДНЯ.

Поэтому мое второе замечание - проверьте, а не мешаете ли вы ему работать?

почитайте про дебаг, про print_r, var_dump
они помогут вам найти причину

Посмотрите какие данные приходят на сервер, и как они обрабатываюся

посмотрите настройки формы, все ли указаны данные

А крон Вам чем не подходит? Да и зачем придумывать велосипеды?
Раз в минуту проверяем есть ли новые неотконвертированные файлы, если есть добавляем в очередь..

Если файлы меньше 1.5гб, то самый простой способ - класть файлы на второй сервер http-POST-ом, в базу сохранять путь до этого файла, пользователю отдавать прямую ссылку на файл на втором сервере по http.
Ну то есть что-то в духе такого:
0) есть 2 сервера, отвечают на domain.tld и на http://files1.domain.tld, соответственно.
1) при аплоаде файла делается http-post в, например, http://files1.domain.tld/upload/что-тотам, где что-тотам = уникальный идентификатор файла в базе (случайное имя или что-то вроде).
2) при запросе этого файла с основного сайта, пользователю подсовывается ссылка на http://files1.domain.tld/что-тотам (можно с защитой от hot-linking'a, как примитивную защиту от прямого скачивания файла).

На втором сервере может быть установлен только голый nginx с upload-модулем. Можно и через PHP всё это делать, впрочем.

Немного погуглил, есть вариант woocommerce + wp user frontend pro, но мне кажется, что все равно прийдется много допиливать.

На мой взгляд, лучше выбрать другую cms или же писать с нуля.