Александр Филиппенко

Нууу давайте разбираться.

Для начала почитайте про HTTP на той же вики. Досканально знать не нужно, но стоит минимально понимать структуру запросов/ответов, понимать что у запроса и ответа есть заголовки и тело (тела может и не быть, зависит от типа запроса/ответа).

Так вот. Куки. Куки живут на стороне браузера. Они передаются HTTP заголовком на каждый запрос на сервер (даже если вы за картинками полезли). Есть просто куки, есть http-only куки. Куки могут быть разграничены по хосту и пути. Все это дает нам гибкость и помогает с секьюрностью. В PHP содержимое $_COOKIE предоставляет нам SAPI. Когда PHP получает на обработку запрос, SAPI используемое (php-fpm, cgi, mod_php имеют свои реализации SAPI) в данный момент берет заголовки и тело запроса, парсит их и заполняет все эти суперглобальные массивы типа $_SERVER, $_GET и в том числе и $_COOKIE. Все что прислал нам клиент (что-то что делает запросы это клиент, что-то что их обрабатывает - сервер), а куки шлет нам браузер только те что можно исходя из того куда шлется запрос. Устанавливаются куки заголовком Set-Cookie в ответе, то есть тут больше нужно читать в принципе про HTTP а не про PHP. PHP просто позволяет вам работать с этим добром. Вы можете сэтить куки напрямую работая с заголовками ответа при помощи функции header. Более того, если выставить время жизни куки в 0, то как раз таки они а не сессия будет сбрасываться при закрытии браузера так как тот будет забывать все такие куки.

Вот... сессии... В PHP сессия обычно это файл. Просто какой-то файл с рандомным именем. Если скажем в php.ini указано session.autostart или делается вызов session_start то создается файл под сессию пользователя (можно переместить в рэдис или мемкэш, свое хранилище и т.д в зависимости от нужд. Так же данные можно шифровать, что по умолчанию и происходит). Этот файл имеет ID, просто какая-то рандомная строка. И если при обработке запроса не нашлась сессия с предыдущего запроса - создается новая.

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

Когда запрос обрабатывается SAPI, при наличии session.autostart, перед тем как начинать создавать новую сессию, пых все же смотрит а есть ли у нас кука с идентификатором сессии, проверяет есть ли у него такая, и если есть успокаивается и не создает новую. Поскольку сессия привязывается через куки, то можно выставить время жизни этой самой куки (в php.ini) и таким образом регулировать время жизни сессии.

Вот... когда использовать куки а когда сессии? Желательно понимать, что чем больше данных в куках (а у них есть лимит к слову) - тем больше данных мы передаем на каждый запрос. То есть это не круто когда что бы получить 1 килобайт данных мы должны в заголовках передать пару килобайт кук. Люди, повернутые на оптимизации, даже картинки хранят на отдельных cookie-less доменах что бы уменьшить количество трафика и пакетов (обычно простенький HTTP запрос влазит в размеры одного TCP пакета). Если вам нужно работать с этими данными из JS на любой странице, например локаль выбранноую пользователем для того что бы применять переводы еще и в JS, то стоит использовать куки. Для всео остального лучше конечно же использовать сессии. Во всяком случае на начальных этапах когда что-то сильно сложное вам делать не придется.

Добавили, чтобы вы jquery спагетти не использовали. Vue (как и другие js фреймворки) сокращает количество кода на клиенте и уменьшает его запутанность.

Для примера вы создаете админку для магазина. У вас есть следующие варианты:
1. Делать статическую страницу. На клиенте никакой логики, все вычисляет сервер. При новой покупке администратор должен будет обновить страницу.
2. Писать динамический фронтэнд с использованием vue, angular и чего угодно остального. Бэкэнд шлет вам уведомления через вэбсокеты о новых заказах без перезагрузки страницы.
2.1 Вы берете jquery и сначала все идет хорошо. Первые полчаса. Затем ваш код обрастает огромным количеством обработчиков событий. Если товар заканчивается на складе, его надо убрать из таблицы, затем если заказ отменяется, его надо вернуть в таблицу. Вы его вернули, но почему-то кнопка в строке с ним, вызывающая модальное окно перестала реагировать на события, потом еще что-то случилось и еще. Проблемы с jquery растут как снежный ком и вы проклинаете свое решение создать динамическую админку.
2.2 Вы используете современный js фреймворк. Vue в этом плане хорош низким порогом изучения. Вы загружаете определенные обхекты и в зависимости от их свойств vue сам строит таблицы (с проданными и непроданными товарами), скрывает лишние элементы (не показывать такую-то кнопку, если товар всего 1), отправляет плагинам команды на обновление при изменении объектов и следит за тем, чтобы события, которые отваливались при jquery подходе работали.

Я не сказать что спец в javascript, но (именно поэтому) меня vuejs на текущем проекте очень выручает.

во-первых, никаких миграций

Как вариант, использовать – https://github.com/worksolutions/bitrix-reduce-mig...

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

Мы PhpStorm'у скармливаем это (Languages&Frameworks => PHP => Include Path) – https://github.com/Prominado-ru/bxApiDocs . Проблему разных версий не решает, но пока проблем с этим не было)

Весь код проекта только в /local/

Если все правильно поняли, то

async asyncData(ctx) {
            let products = await ctx.app.$api.products(ctx.params.slug, ctx.query);
            return {
                products: products.data,
                total: products.total,
                perPage: products.per_page,
            }

watch: {
            '$route'() {
                this.getProducts();
            },
        },

getProducts() {
                this.$api.products(this.$route.params.slug, this.$route.query).then(products => {
                    this.products = products.data;
                    this.total = products.total;
                    this.perPage = products.per_page;
                });
            },

И при клике на пагинацию:

this.$router.push({
   query: {
      ...this.$route.query,
      page: page,
   },
})

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

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

Ну фигачишь ты функцию, которая превращает строки в массив слов в этой строке. И нафигачил ты её настолько круто, что дали тебе премию на работе, а в отдельном тёмном уголке офиса поставили "Уголок Поклонению Делителю Строк". Даже включили в дайджест на хабре.

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

И решил ты её перетащить в другой проект. Но решил не с помощью Ctrl+C -> Ctrl+V, а по-хитрому, создал целый файл с исходным кодом. Так вот этот файл и есть библиотека.

P.S. В ходе рассказа ни один котик не пострадал.

P.P.S. Но потом конечно же ты опубликовал её в npm и назвал фреймворком, но это уже другая история...

Укажи в модели public $timestamps = false;

Карту давненько не обновлял но может, что полезное найдешь для себя Карта развития Back-end разработчика

Для практики рекомендую взять что то из этого списка build-your-own-x, можно посмотреть как сделать простой веб сервер, поисковый движок, БД

Плюс вот еще статья Не убивайте свою мотивацию: осваивайте Ruby on Rai... хоть для руби, но есть список интересных проектов

Все зависит от размера проекта и фреймворка. Если проект не большой то подойдут laravel с Eloquent. Отдельно ставить Eloquent смысла мало он всеровно затянет половину ядра laravel.

Если проект уже среднего размера тогда подойдут Symfony + doctrine. Правда для того что работать с ними нужно достаточно много знать один dql чего стоит.

Если же проект огромный и дико нагруженный то есть смысл попробовать сделать его не на php а например на java + spring + hybernate.

Ещё советую попробовать ddd и можно будет в любой момент поменять laravel на symfony а eloquent на doctrine или на тот же propel

1. button тоже имеет type
2. input type="submit" и button type="submit" отправят форму. Но button может иметь контент, а input нет. Если Вам достаточно иметь просто текст типа "отправить", то годится и то и то, но input лаконичнее.
3. Если управление отправкой идет с помощью js, то иногда удобнее использовать button type="button" потому как она не вызывает отправку формы.

Так что совершенно не важно что использовать, если не имеете весомых аргументов в пользу какого либо варианта. А они появятся только по мере изучения js.

Да, всё почти верно. Одна поправка: JSON не является обязательным форматом взаимодействия, хоть и является самым удобным в использовании. Например, есть ещё бинарный msgpack