Oversec

https://help.apple.com/itunes-connect/developer/#/... , если кратко, то должна быть кнопка по нажатию на которую появится модальное окно с вопросом по экспортным требованиям, после ответа и сохранения вы сможете отдать на тестирование.

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

хорошим ли выбором будет react?

Если вам действительно важно SEO (вы упоминаете об этом), то react как раз таки снимает эту проблему, т.к. умеет рендериться на сервере.

SPA проще со стороны бэкенда (хотя что может быть проще бэкенда). Есть строго определенный контракт на API, достаточно его выполнить (причем, чаще всего, для платформы есть готовое решение по организации REST) и можно идти пить чай.
SPA проще со стороны фронтенда, можно начинать работу (и даже всю ее сделать) еще до того, как бэкендер перестанет пить чай (при наличии, опять же, контракта на API).
SPA лучше по архитектуре (как правило). Никакого тебе PHP+SQL+HTML+JS+CSS в одном файле, даже при всем желании.

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

просто хранишь стейт с выбранной темой в компоненте и вешаешь обработчики для смены стейта

class MyComponent extends Component {
	constructor() {
		super()

		this.state = {
			currentTheme: "dark"
		}
	}

	changeTheme(themeName) {
		this.setState({
			currentTheme: themeName
		})
	}

	render() {
		return (
			<div>
				...

				<button onClick={() => this.changeTheme("dark").bind(this)}> {/* байнд для доступа к this внутри ф-и */}
					I wanna dark!
				}
				</button>

				<button onClick={() => this.changeTheme("light").bind(this)}>
					I wanna light!
				</button>
			</div>
		)
	}
}

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

onClick={() => this.props.goDark()} /* например это вызов из ребенка, который очень глубоко */


/* в это уже самый верхний (корневой) компонент */

goDark() { ... }
goLight() { ... }

<RootComponent>
	<Child currentTheme={this.state.currentTheme} />
</RootComponent>

можешь это еще дополнительно куда-то в локалсторадж писать и при инициализации читать оттуда.

------------------

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

<div className={ this.props.currentTheme === 'dark' ? 'dark-wrapper' : 'light-wrapper' }>
	<button className={this.props.currentTheme === 'dark' ? 'btn-primary-yellow' : 'btn-primary-blue' }></button>
</div>

Конкретный код я вам не напишу, так как это не быстро, но в целом алгоритм скажу.
1) То что дубли это назовем свойством wordpress. Решаю эту проблему тем что бы везде правильные ссылки были конкретно на этот элемент. В меню, хлебных крошках и т.д. Также надо правильно настроить постоянные ссылки. Робот поисковика не будет методом подбора все страницы перебирать и искать дубли. На страницу дубляжа может быть ссылка со стороннего сайта, тогда надо делать редирект. Может быть в карте сайта, если она автоматически генерируется, тогда карту надо настраивать. Так же для хлебных крошек и меню.
2) С пагинацией надо разбираться. Часто такое бывает если вы кастомизируете wp_query. Решается установкой стороннего плагина и передаче в вызов функции плагина запроса wp_query.
3) от слова category можно избавится плагином.

Ну для того что бы выводить либо подкатегории если они существуют, либо продукты алгоритм прост
1 Получить id текущей категории
2 Получить дочерние элементы этой категории
3 Если есть дочерние элементы, то выводим их, если нету то делам запрос товарам этой категории и выводим их.

Представьте, что вам нужно найти определенную главу в книге, но вы не знаете, на какой страницу она находится. Вам придется листать всю книгу, пока вы ее не найдете. Но если у книги есть оглавление, вы быстро его просмотрите и увидите номер нужной страницы. Индексы нужны для этого.
Для каких полей они нужны? Если отвечать в общем - то для тех полей, на которые вы будете накладывать условия where, или сортировки, или группировки в своих sql-запросах.

https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B4%D...

Прочитал обсуждения и хотел бы добавить что редиректы кэшируются на разных уровнях(браузер, роутер) и надо проводить их отладку через сторонний сервис bertal

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

используйте для этих целей ExistValidator

Если Вы хотите реализовать этот функционал более корректно, тогда не стоит его пихать в контроллер т.к. ему там просто не место. Контроллер только должен осуществлять обработку запроса пользователя, взаимодействовать с уровнем бизнес-логики и представлений.
Реализуйте отдельный компонент/поведение, который будет:
1. Ловить события сохранения данных в моделях
2. Получать из этих событий сами объекты записей
3. Вынимать из объекта измененные данные с помощью метода getDirtyAttributes()
4. Собственно формировать объект лога и сохранять его

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

www.yiiframework.ru/forum/viewtopic.php?t=18090

Я хорошо знаком с yii1/2 и laravel. В yii много вещей сделано не удобно для разработчика.
Вам не надоел этот фреймворк? свой плюшками который тратиться не мало времени.

https://laravel.com/

Добрый день.
Возможно надо вызвать функцию

[
  'attribute' => 'user_id',
  'value' => function($model){
        return $model->user->name;
  }
]

kenwheeler.github.io/slick

Посмотрите https://revolution.themepunch.com/ - самый адекватный и мощный из всех решений, что я видел. Если слишком тяжелый для вас - делайте через OwlCarusel и кастомные поля ( ACF + repeater )

Из-за класса adv очевидно. Нужно поменять его на другой, менее "рекламный"

Кратко:
Тех. поддержка - это починить, если поломалось и не допустить поломки.
Всё остальное - доработки.

По-видам работ для ТП:
1. следить за объемом свободного места на хостинге (логи и прочее)
2. следить за безопасностью и своевременно устранять "дыры"
3. при внезапно возросшей нагрузке на сервер/сеть - быстро находить и устранять проблему (лучше - причину).
4. обеспечить безотказную работу веб-сайта/сервиса на протяжении всего времени ТП.
5. делать резервные копии и обновления ПО или его модулей (при необходимости)

Остальное - ТЗ/доработки и/или доп.работы.