Александр Торопов

Ох...

Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.



Вообще в этом всем важно не только то, что каждая буква обозначает, а как они друг с дружкой связаны.

View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

Но на начальной стадии можно слегка нарушать эти правила, делать толстые контроллеры и т.д. В этом случае бизнес логика будет потихоньку "вытекать" из модели. Это не хорошо, и на хоть сколько нибудь больших проектах может привести к проблемам. Потому важно находить баланс.

Можно через CURL,
Можно через php ftp https://www.php.net/manual/ru/book.ftp.php

Зависит от вашего протокола ftp.

Пару месяцев назад я делал проект, где использовался Implicit FTP over TLS . Через CURL в итоге получилось запустить.

Начните с чтения доков по работе с FTP https://www.php.net/manual/ru/function.ftp-connect.php

На самом деле надо качать Лару а ещё лучше - Симфони.
Только не тупо зазубривать, а пытаться понять, почему там так сделано. Это и будет теми самыми примерами.
И да - не Лару точно. Потому что там очень много магии которая полезна тем кто понимает как она работает и очень вредна для тех кто учится.

И вот изучая нормальный фреймворк ты как раз и будешь учиться примерам хорошего кода.
Начать можно с этой хрестоматийной статьи https://symfony.ru/doc/current/introduction/from_f...
А потом переключаться на https://github.com/symfony/demo

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

И кстати я совсем забыл. У нас же есть гений в своем отечестве, Дмитрий Елисеев. На фоне бесчисленных неграмотных выскочек типа хаудихи или, прости господи, руселлера, это реально человек который знает, о чем говорит.
И - что гораздо реже случается - умеет донести эти знания до аудитории.
И насколько я понимаю, твой уровень уже должен позволять в принипе понимать, о чем он говорит.
В общем начать можно отсюда, https://elisdn.ru/blog/113/psr7-framework-http
и дальше остальные материалы.

правильно
ты, главное, идею пойми
а как поймешь - поймешь что csrf лучше ставить JS кодом, уже сложнее для атакующего, ну и прочие навороты
ну и проверка-то правильная
а вот вставил ли ты ее ВО ВСЕ страницы где она нужна?

так wp-panda.com/woocommerce_posts/woocommerce-shortco...

цикл сильно прощще

<ul class="products">
	<?php
                $product_ids_on_sale = wc_get_product_ids_on_sale();

		$args = array(
			'post_type' => 'product',
                        'post__in' => array_merge( array( 0 ), $product_ids_on_sale )
			);
		$loop = new WP_Query( $args );
		if ( $loop->have_posts() ) {
			while ( $loop->have_posts() ) : $loop->the_post();
				wc_get_template_part( 'content', 'product' );
			endwhile;
		} else {
			echo __( 'Продуктов не найдено' );
		}
		wp_reset_postdata();
	?>
</ul><!--/.products-->

Нет конечно.
у гуглотаблиц есть api, а для экселя есть PHPOffce

Если не нужны навороты вроде формул и графиков, то и то и другое сохраняется как CSV, а для него уже есть встроенная функция fgetcsv().

laravel нежели на CMS- битрикс?

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

прикрутить личный кабинет пользователя, с графиками + vue

- на самом деле Битрикс это коммерческий фреймворк, а админка это продукт на его основе. Если вы будете писать новый функционал, которого нет в продукте, что в Битриксе, что в ларавел вы будете это делать с нуля, писать и там и там на фреймворке.

1) Удобная система ( админ панель) с быстрой тех поддержкой

- это реальный большой плюс, который сокращает расходы на поддержку проекта.

2) Много функционала из коробки

- это тоже реальный большой плюс, который сокращает расходы на создание аналогичного функционала.

3) Удобно интегрировать с CRM битрикс

- хороший плюс, который сокращает расходы на создание аналогичного функционала.

масштабировать проект очень сложно

- точно также как и в Ларавел пишутся модули и функционал.
Когда имеет смыл рассматривать преимущества Ларавел
- когда не типовой, индивидуальный интернет-магазин
- когда возможностей CMS Битрикс кардинально не хватает
- когда глубокая интеграция ТЗ в готовый функционал занимает больше времени, чем сборка аналога с нуля. И в итоге дороже. В этом случае бизнес считает деньги.
- гибкость для сложных проектов, но нужно эту гибкость представить в виде пункта коммерческого предложения, иначе это для бизнеса просто слово
- создание и полная кастомизация административной панели сайта под не типовые и сложные проекты
- скорость работы, для крупных интернет-магазинов это важно. Интернет-магазин получается реально шустрее тиражных решений.

Очень сложных проектов на Yii2 с открытым, да ещё и хорошим кодом очень мало)) Прежде всего, потому что Yii создан для быстрой разработки нарушая все правила сложных архитектур. А учитывая его устарелость, то тем более таких проектов мало. На форуме давно обсуждался этот вопрос. Там есть ссылки на проекты и код. Так же на сайте yiipowered.com есть список проектов, у некоторых с исходным кодом.

Вам лучше изменить тактику и искать проекты с хорошей архитектурой вне зависимости от фреймворка. Так ваша вероятность найти что-то стоящее на много выше. В целом, хорошая архитектура - это всегда дорого. Мало кто будет выкладывать проект большой команды, на которую были потрачены сотни тысяч и миллионы в открытый доступ. Кроме того хорошая архитектура всегда зависит от требований, задач и самого проекта. Что и где применять, как строить - придет только со знанием и опытом. Здесь не получится сделать по примеру.

Если по теме, то начните изучать или искать DDD, CQRS, SOA, Микросервисы. В принципе это основные архитектурные подходы в разработке. На Yii по DDD есть хороший пример. Однако начинать НОВЫЙ проект на Yii2 используя даже самую сложную архитектуру - путь в никуда. Yii2 создан для других целей. Чтобы понять можно посмотреть ответ на вопрос: Актуален ли Yii2 Фреймворк в 2020?