Skrolea

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

Если речь идёт про стандартные yii2-app-basic или advanced, то вы можете найти это в папке app/frontend/views/layouts/main.php для advanced или app/views/layouts/main.php для basic. Там инициализируется NavBar, туда же и изменения вносить.

upd:

Для внесения изменений в сам виджет можно добавить в папку widgets класс CustomNavBar extends yii\bootstrap\NavBar, и... самое простое решение - переопределить функцию renderToggleButton;
renderToggleButton() {return ''}
а в layouts/main.php вместо use yii\bootstrap\NavBar; написать use app\widgets\CustomNavBar;
Потому что в стандартном NavBar bootstrap функция renderToggleButton() выполняется вне зависимости от options и её нельзя отключить массивом настроек.

во-первых если вам нужны данные не для gridview\listview нет необходимости возвращать dataProvider в ArchiveSearch модели достаточно вернуть $query->all();
а чтобы получить по годам - предварительно сгруппируйте массив результатов по годам

$result = [];
         $dataProvider = $searchModel->search(Yii::$app->request->queryParams);
         foreach($dataProvider->models as $model){
              $result[$model->year][] = $model;
         }
         return $this->render('index', [
                    'searchModel' => $searchModel,
                    'result' => $result,
        ]);

<?php foreach($result as $year=>$models):?>
     <h3><?=$year?></h3>
    <?php foreach($models as $model):?>
          <?=$model->data?>
     <?php endforeach?>
<?php endforeach?>

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

Как вариант могу предложить сделать это с помощью JS. Положить модальное окно в index.php, а при клике на картинку вставлять в модальном окне src для картинок, который мы берем у картинки на которую кликнули.

$(document).on('click', '.item img', function (event) {
    var src = $(this).attr('src');
    $('#foto img').attr('src', src);
});

www.yiiframework.com/doc-2.0/ext-imagine-index.html офф. плагин основан на хорошей библиотеке imagine.readthedocs.org/en/latest

или вот

https://github.com/himiklab/yii2-easy-thumbnail-im...

require('es6-promise!./about/about')('About')

что же это за чудо такое?

Попробуем разобраться. Заходим на документацию к вебпаку тык.

Т.е. эта конструкция require('es6-promise!./about/about') является вызовом загрузки модуля с помощью переопределенного лоадера, а не просто лоадера, который прописан в webpack.config.js этой сборки

loaders: [
  // See: https://github.com/s-panferov/awesome-typescript-loader
  {test: /\.ts$/, loader: 'awesome-typescript-loader', exclude: [/\.(spec|e2e)\.ts$/]},

Идем в исходники es6-promise-loader, который как раз у нас является одной из devDependencies сборки. Там можно маленько посмеяться над комментариями).
Смотрим, что тут, ага - это pitch лоадер, который делает обертку es6-promise. А внутри метод из вебпака ensure, который позволяет отделять chunk и загружать его динамически. В итоге получается примерно такой модуль (пути я порезал маленько)



Т.е. require('es6-promise!./about/about') грубо говоря превращается в функцию с параметром namespace. И вобщем когда придет время сдерживать своё обещание и возвращать модуль, то сработает следующее выражение
require("......app\\about\\about.ts")[namespace]
Require вернет нам как раз наш exports объект, который мы возвращаем в about.ts
export class About {
Смотрим на практике

А к свойству объекта мы уж по namespace сможем легко обратиться. Именно поэтому там 'About'.

Если напишете about, то не видать вам

ngOnInit() {
  console.log('hello `About` component');
}

из компонента

Создайте отдельные файы в папке routes/route1.js, routes/route2.js и тд, дальше и экспортируйте их модули.

// routes/route1.js

module.exports = [
    { 
      method: 'GET', path: '/routes1', 
      handler: function () {} },
    { 
      method: 'GET', path: '/routes1/{id}', 
      handler: function () {} }
];

далее в папке роутинга создать index.js где соединить все route1.js, route2.js, route3.js......routeN.js и экспортировать их всех в массиве

//  /routes/index.js

var route1 = require('./route1');
var route2 = require('./route2');
var route3 = require('./route3');
var routeN = require('./routeN');

module.exports = [].concat(route1, route2, route3, routeN);

а теперь весь этот массив можете вызвать в файле сервере и передать массив из роутеров в сервер.

//  /server.js

var routes = require('./routes');
server.route(routes);

Какие инструменты могут понадобится для реализации такой системы?

Вопрос скорее всего не совсем уместен. Вам могут перечислить инструменты, которые нужны для постройки дома, однако дом вам построить это не поможет. Но, чтобы не быть голословным, вам понадобятся:
1. Git server (Bitbucket, Gitlab, etc). Если работаете один или проект очень простой, то достаточно будет gitolite.
2. CI server (Bamboo, Jenkins, etc).
3. Любой язык программирования для написания pre-receive/post-receive хуков и задач для CI.

Правильно ли я представляю себе этот процесс?

Вне зависимости от того, будете ли вы работать один или в команде, с моей точки зрения процесс выглядит усложненным и надуманным. Я бы начал с простого процесса и усложнял бы его только по мере появления каких-то проблем. Если вы начнете со сложного, то вы сразу создадите себе проблемы. И будете создавать новые, решая старые.
Как я вижу простой процесс:
1. Возьмите одну ветку, которая будет стабильна, например, master.
2. Для каждой фичи создавайте отдельную ветку из стабильной. Например, ivan-news-block или ivan-search-bug-fix. Правила нейминга придумать можно любые.
3. Тестируйте код на своей виртуалке. Обычный vagrant + virtualbox. Если у вас добавляется второй разработчик, то он просто берет Vagrantfile и у него на машине появляется виртуалка с готовым окружением для работы. Зачем вам общий dev сервер?
4. Процессом деплоя управляет или CI сервер, или ansible/puppet, или самописные скрипты.
5. Когда ветка готова к релизу, то запускайте процесс деплоя на тестовый стенд, где вы можете показать это заказчику или кому-то еще. Там же CI может прогонять тесты.
6. Когда фича аппрувнута заказчиком или ПО задачи, то запускайте процесс деплоя на бой.

Как это реализовать?

Вопрос явно требует уточнения. Сейчас ваш вопрос звучит так: "Как нарисовать сову?".
Но что-то могу порекомендовать:
Начать надо с построения процесса с проделыванием всех действий вручную. Далее постепенно каждую ручную операцию переводить на автоматику. Не стоит сразу пытаться сделать какой-то идеальный механизм.

map - для каждого результата
toPromise - преобразовать Observable в промис
subscribe - подписаться на изменения в observable

разница между observable и промисами - промисы отрабатывают только один раз, observable можно перезапускать множество раз. То есть вместо того что бы запоминать конфиг, мы буквально создаем объект, описывающий запрос (до вызова subscribe/map запрос реальный не отправляется). Если у вас отвалилась сеть и мы хотим повторить запрос - достаточно еще раз вызвать метод объекта, а не создавать новый запрос. Банально удобнее, особенно в плане реюза кода (можно сделать на уровне сервиса перехватчик запросов, который бы хэндлил за нас такие ситуации).

'one two three'.split(' ').reverse().join(' ')

<ul>
				<li>Один Два Три</li>
				<li>Четыре</li>
				<li>1234567890</li>
			</ul>

var list = $('ul li')
			list.each(function(index, item)
			{
				currentItemText = $(item).html();
				$('li:eq(' + index + ')').html(currentItemText.split('').reverse().join(''));
				// console.log($(item).html());
			});