FanatPHP

Вопрос, как всегда, поставлен жутко неграмотно, так сказать, по деревенски: без какого бы то ни было видения перспективы, хотя бы на 5 лет вперёд.

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

Это, я не знаю, как спросить "хочу быть столяром, какую отвёртку мне изучать, крестовую или шлицевую?".

Изучать, ради карьеры, надо столярное ремесло целиком. В данном случае - программирование. Принципы, на которых устроены фреймворки. Одного этого хватит на те же лет 5. Зато потом не будет проблемы адаптироваться к неизбежным изменениям.

А если считать пределом мечтаний клепание говносайтов на некоем идеальном фреймворке на все времена, то может так случиться, что через 5 лет к условным "ларавельщикам" будут относиться так же, как сейчас к вордпрессникам.

И кстати для изучения принципов симфони подходит лучше

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

Да, и самое главное я тоже забыл сказать. Коллега xfg в самую точку написал в комментарии:

Фреймоворк - это на самом деле тонюсенькая прослойка над приложением. Это, по сути, система подай-принеси, принять запрос с фронта и отправить ответ. А что именно будет в ответе - решает не фреймворк, он здесь уже не при делах.

Очень на эту тему прочищают мозги доклады и видео Дмитрия Елисеева. У него на сайте как раз появился доклад с PHP Russia 2019, который я горячо рекомендую.

На ту же тему был и доклад Томаша Вотрубы, кстати. Что фреймворки, по сути, можно менять как перчатки, при желании. И у него есть даже инструмент для этого. Но в данном случае речь не об инструменте а о том, что фреймворк- далеко не главная часть приложения, и упираться в изучение фреймворков это все равно что в изучение отверток.

Вопрос, конечно, тупой, но понять его несложно - автору надо вставить результат выполнения пхп кода

$json ='{"source":{"api":""}}';
$array = json_decode($json, true);
$array['source']['api'] = env('api')."@statistics";
$json =  json_encode($array);

$row = $conn->query("SELECT group_concat(age), sum(age) FROM table")->fetch_row();
echo $row[0];
echo "<br>";
echo $row[1];

Js на начальном этапе не нужен, музчина из соседнего ответа не в теме.
Ну точнее он живёт видимо в прошлом веке и подключен к интернету через модем по телефонной линии. Учителя же подключены по 4g, и "ждать" перезагрузки будут миллисекунд 50.

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

Продолжать читать.
Больше ничего не нужно.

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

Даже если многое понимается из контекста. На самом деле в детстве мы тоже многого не понимаем, когда читаем книжку, но - "пофиг - пляшем" - читаем дальше, понимание со временем приходит само.

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

5000 слов - это глупость. Язык учат не словами. Каждое слово, особенно в английском, имеет до десятка значений. А с предлогами-суффиками - до сотни. Школьное край - это не плакать, а кричать (благодаря игрушке это теперь все знают), у слова ass - два значения (с предлогами - далее везде), sound - четыре. Выучив по одному значению 5000 слов будешь спотыкаться на каждом втором.

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

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

Чтение - это ак раз способ с погружением, а вся зубрежка - это эффективность 19 века, когда она была изобретена.

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

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

Нет, неправильно.

- get_functions.php ужасное название, винегрет внутри. все эти функции разложить по своим модулям.
- inc/main_tpl.php подключается слишком рано. сначала надо закончить работу с данными, а только потом начинать вывод. Это азбука.
- 'modules/' . $_GET['section'] . '/index.php' инклюдится слишком поздно. модуль надо инклюдить ДО начала вывода. При этом основной шаблон должен вызываться не в индексе, а в модуле. модуль решает, бует ли он что-то выводить, если да - то присваивает переменной имя своего шаблона и вызывает основной шаблон, который в себе инклюдит шаблон модуля. Подробнее: phpfaq.ru/tech/tpl
- в include 'modules/' . $_GET['section'] . '/index.php' тебе напихают такого, что на ежика станешь похож. имя модуля надо обязательно валидировать. в идеале по белому списку.

В остальном нормально, только обычно все кроме индекса кладут выше корня.

Очень смешное предложение про md5 и длину.
Направление в принципе верное, но вот что делать с полученным результатом - вот тут мысль наших добестных похапешников останавливается.

А теперь внимание - правильный ответ
urlencode() - самая удобная отладчная функция. Читаемые символыв она оставит как есть, а непечатные - закодирует в удобный формат.

Мужчина в соседнем ответе не совсем в теме.

Хотя, конечно, вопрос и сам по себе дурацкий.
Phpmailer - это не почтовый сервер. Это всего лишь mail()-переросток. Доставкой писем не знаимается. И "поставить через композер" проблему доставки писем не решит - все равно нужен будет сервер.
То есть выбор не между "phpmaier" vs transactional email service, а "мой аккаунт на гмейле" vs mailgun.

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