Этот код можно еще сокращать и сокращать.
Тернарные операторы - это нормально. Возможно сейчас прибежит кто-нибудь с криками "ой, наши джуны не понимают их, поэтому не используйте", и будут бросаться тапками. Аргумент так себе.
Несколько условий в одном if'е - это нормально. Другое дело, что эти условия аццки длинные и не читаются, от слова совсем. Можно было бы переписать как-то так:
$is_admin = $name->permission('administrator');
$is_section_available = $data[0]['section_available'];
if ($is_admin || $is_section_available
&& ( // в том-же духе для остальных трех условий
)
...
Что не нормально - вот эта адская лапша с какими-то невнятными массивами. Проверка доступа привязанная к шаблонам(!) на основе какай-то вуду-магии (check_access_by_forum_group_id_and_theme_id, лолшто?).
минутка диванной аналитикиПодозреваю, что создание этого всего происходило примерно по такому сценарию:
1. пишется что-то кастомное, дешево и "на позавчера" (в результате архитектура слабая)
2. заказчик захотел чего-то странного, и тоже "срочно-припадочно", и это странное было интегрировано при помощи кувалды, проволоки и синей изоленты.
3. прошло Х месяцев, разработчик понимает что он какбэ уже немножко в аду, но когда он заикается о рефакторинге, заказчик говорит что это не его проблема и оплачивать не хочет.
(3б. бывают тяжелые случаи, когда разработчик не знает такого слова как "рефакторинг")
4. разработчика это все достало, а заказчика не устраивает нытье разработчика и провалы по срокам
5. проект передают по наследству вам. АХАХАХА!!111
Чтоб такая фигня не происходила, давно придуманы стандарты разработки:
всякие
style guide'ы,
PSR'ы и так далее. они мешают писать quick'n'dirty код, но в долговременной перспективе окупают себя на этапах роста проекта или на поддержке.
Хинт: если вы заподозрили, что начальство не хочет правильно, а хочет быстро и грязно, то вам решать продолжать ли с ними работать.