BoShurik

Этому посвящена добрая часть документации компонента Dependency Injection и Service Container'а, который является центральной частью этого компонента.

Если совсем вкратце - то вы либо описываете сервисы вручную через конфигурацию (есть несколько поддерживаемых форматов, включая аннотации, хотя они вроде реализуются внешним пакетом) либо используете преимущества autowiring'а, предоставляя Symfony всё описать за вас (с помощью compiler pass'ов, если потребуется). Собственно основная "магия" преобразования всех источников данных в кучу компилированного PHP находится как раз в compiler pass'ах, их много и можно писать свои.

Поскольку у вас в примере - controller's action - то здесь вся магия реализуется через обработку тега controller.service_arguments, который по-умолчанию добавляется ко всем контроллерам в конфиге сервисов.

И не найдёте. Это вопрос из серии «Как правильно использовать дрель + холодильник + ноутбук» — согласно документации каждого. Вы или не знаете, чего хотите, или одно из двух.

Переопределение конфигурации в Symfony вне основного процесса загрузки конфигурационных файлов - не самое простое дело. Этот процесс закрыт от прямой кастомизации т.к. основной процесс загрузки и обработки конфигурации bundles целиком отдан на откуп им самим. Причина подобных ограничений в том что загрузка конфигурации - один из самых ранних этапов работы и, как и для всех подобных частей кода - там довольно мало пространства для манёвров. В связи с этим путь (и сама возможность) переопределения конфигурации будет очень сильно зависеть от того что же именно вы хотите переопределить.

Для того чтобы лучше понять как это происходит - вам стоит подробнее изучить вопрос того как именно организована загрузка и обработка конфигурации в Symfony.

Если вкратце:

1. В процессе конфигурации контейнера происходит сбор данных конфигурации из конфигурационных файлов. Эти данные сохраняются в container'е через ContainerBuilder::loadFromExtension().
   
2. Далее, собранные данные передаются в качестве основы в bundle extension (через метод load()). То, как именно bundle extension будет работать с собранными данными - целиком зависит от кода bundle'а, так что в целом с ними может произойти всё что угодно.
   

Как вы, надеюсь, понимаете - из-за п.2 какого-то общего подхода к переопределению данных в Symfony не существует. Поэтому, как я уже писал выше, вам необходимо определиться с тем что именно вы хотите переопределить, а дальше смотреть на код загрузчика соответствующего bundle (вот он для LiipImagineBundle).

Как видно - в случае LiipImagineBundle в целом ничего страшного не происходит, полученная конфигурация сразу отправляется в processing и потом используется для регистрации сервисов и параметров.

Поскольку процесс сборки контейнера начинается с merge pass, то вы не можете вмешаться в этот процесс через compiler pass, как это делается обычно, однако вы можете воспользоваться вот этим куском логики для того чтобы добиться своей цели: вам достаточно определить в своём bundle собственный extension и отметить что он реализует PrependExtensionInterface. Это позволит вашему extension получить экземпляр ContainerBuilder до того как будут загружаться остальные extensions, именно это позволит вам воспользоваться ContainerBuilder::loadFromExtension() для добавления параметров конфигурации к нужному вам bundle.

Несколько нетривиально, но должно работать :)

Укажите page тоже как {slug}. И задайте для него значение по умолчанию и обязательное значение только page.

@Route("/products/{page}/{pageNum}", name="product_paged_index", defaults={"page":"page", "pageNum": "1"}, requirements={"page"="page", "pageNum"="\d+"})

Listener — слушатель одного или более событий, некий такой атомарный исполнитель. Не знает на что он подписан, но легко управляется через конфигурацию. Если разные слушает — нужно самому логику разделения обработки писать.
Subscriber — подписчик имеет реализацию интерфейса SubscriberInterface с методом getSubscribedEvents(), то есть сам объект слушателя знает, на что он подписан и какие методы какие события будут отрабатывать

По сути одно и тоже, но такая разница иногда пригождается. Иногда нужно иметь контроль снаружи, иногда наоборот.

Теги — отдельный механизм контейнера. Проставляя тег на набор сервисов — мы во время компиляции контейнера можем достать помеченные определенным тегом сервисы и заинжектить в др сервис (очень часто используется мной например), отсортировать по допатрибутам или сделать любую иную логику
https://symfony.com/doc/current/service_container/...
Ну например есть десяток сервисов, которые обрабывают каждый свой тип файла, еще и лежат в разных бандлах. Как получить их в одной фабрике? Правильно — проставить им тег, в компиляторе приложения достать все и в фабрику засунуть. При появлении нового сервиса с тегом - он автоматом будет в фабрике.

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

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

Используйте нормальный шаблонизатор, Twig.

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

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

Я понимаю что без примера сложно.
Вот простейший пример того, о чем я писал выше:

main.twig.html

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
{% block stylesheets %}
    <link href="/css/main.css" rel="stylesheet">
{% endblock %}
        <title>{% block title %}Twig Example{% endblock %}</title>
    </head>
    <body>
        {% block content %}{% endblock %}
    </body>
</html>

index.twig.html

{% extends "main.twig.html" %}

{% block content %}
<h1> index page </h1>
<li><a href=/page1.php>Page 1</a>
<li><a href=/page2.php>Page 2</a>
{% endblock %}

page1.twig.html

{% extends "main.twig.html" %}

{% block stylesheets %}
    {{ parent() }}
    <link href="/css/page1.css" rel="stylesheet">
{% endblock %}

{% block title %}Page 1{% endblock %}

{% block content %}
<h1> page 1</h1>
<li><a href=index.php>index</a>
{% endblock %}

В Symfony 4.4 будет добавлена возможность безопасного хранения ключей, подробнее в анонсе.

В общем вся мишура произошла из-за использования sqlite...
При переходе на mysql все стало корректно отрабатывать

Сам неделю назад столкнулся с похожим, судя по подпискам вещь нужная, так что выложил в паблик раньше чем планировал:
https://github.com/LoginovIlya/words-to-numbers
P.S. Другие языки и нормальный readme будут позже

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

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

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

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

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

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

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

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

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

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

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