gto6120

Судя по всему здесь возникает состояние гонки (race condition) из-за множества параллельных запросов, пытающихся записать свои данные в файл с сессиями. Добавьте перед session_regenerate_id(true); вызов session_write_close(); читайте, кстати, описание к этой функции.
Вообще, чтобы такого не происходило, session_regenerate_id(true); обычно ставят сразу после вызова session_start();.
С вашим синтетическим примером у меня получилось в обоих случаях.

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

Докер - это двойная изоляция. Изоляция того, что лежит внутри контейнера Докера от операционной системы и изоляция операционной системы от того, что лежит внутри Докер. Изоляция подразумевает изоляцию всех файлов, портов, приоритетов.

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

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

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

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

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

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

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

Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

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

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

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

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).

у Вас неверное название класса, классы фикстур должны иметь суфикс Fixture, например

class UserFixture extends ActiveFixture {
}

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

На мой взгляд надо переписать контролер миграции (создать свой и подключить в конфиге)
Вот есть пример, для двух баз, но там есть пример конфига для кастомного контролера:
https://habrahabr.ru/post/279701/
Далее в экшене migrate можно добавить копирование файла в папку console/migrations например и иметь их в проекте не зависимо от изменений в vendor.

1. Откатываем миграции до нужной нам с помощью migrate/to
2. Откатываемся к необходимой версии исходников

Я сталкивался с подобной задачей, насколько помню мы делали потабличный и построчный дамп базы перед merge-м dev ветки в master. Т.е. всегда была "последняя версия базы" в дампах + "последние миграции". А при откате, презаливали дампы. Пришли к этому, т.к. кроме миграций, нужно было хранить некоторые данные, которые попадали в бд не из миграций (настройки пользователоей и т.д.). Наверное, сумбурно написал, но думаю, идея понятна..

что Вам даст изучения готово проекта? Ну посмотрите Вы его, а через месяц забудете что к чему. Лучше всего учиться на практике. Сделайте какой-то учебный проект, сведите набор своих знаний на практике. А потом ищите новую работу как Junior. Это будет гораздо эффективнее чем просто учить теорию и размышлять о том как разрабатывать проекты.

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

Направляющие очень удобные в AI. Можно задавать координаты вручную в полях трансформации (в этих полях даже арифметические операции можно делать + - * /). Также можно наклонять направляющие под любые углы (И быстрые направляющие тоже можно настроить под разные углы). Можно настроить привязку к пиксельной сетке. Даже объекты можно превратить в направляющие. Да и вообще, направляющие в АИ это по сути и есть почти полноценные объекты, в отличие от фотошоповских. И, как было сказано выше, направляющие лучше объединить в один отдельный слой. Так что в АИ с этим все норм. Есть еще куча плагинов для выстраивания сетки. Можно самому создать набор направляющих в 12 колонок, предварительно выровнять их и объединить в группы, а потом копировать и накладывать на макеты - вот вам и адаптивная сетка.
По началу - да. Макетирование сайтов в АИ может показаться геморным, Но если разобраться в принципе работы инструментов и вообще всей логики работы в программы, то можно очень удобно настроить под себя.

Совсем не понятно, если я рисую в масштабе 1:1, то сталкиваюсь с проблемой, что мелкие элементы (~ менее 10 пикселей) нарисованные в этом же масштабе потом плохо масштабируются в большую сторону, начинаются проблемы с толщиной обводки, к примеру, когда элмент скэйлится, а обводка - нет.

Этот момент решается одной галочкой в настройках, как уже было сказано. Scale strokes and effects. Scale corners. Scale patterns. Есть еще 9png

Растровый фон - совсем беда, хорошо если масштаб 1:1 в пискельном выражении, а если нет?

Растровый фон помещается в АИ, а редактировать можно в фотошопе. Причем не надо перетаскивать постоянно. Просто в панели вверху выбираете Edit и автоматически открывается фотошоп. Сохраняете там - обновляется в иллюстраторе. И растр также можно быстро и удобно заменять просто меняя линки Relink.

В пользу иллюстратора еще могу добавить такие фишки, как работа с символами. Создав, например, символ кнопки, можно отредактировав один экземпляр сразу отредактировать и все кнопки на макете. Или навбар и футер. Причем экземпляры символов можно масштабировать как 9пнг, в отличие от смарт-объектов в фотошопе. Это удобно, когда страниц много. И еще в иллюстраторе можно задавать глобальные цвета. Тоже очень удобно, когда надо "поиграть с цветами" интерфейса - изменяешь глобальный цвет в палитре и все объекты с этим цветом тоже меняют цвет.
Для экспорта х1,5 х2 х3 есть плагины.
В общем если всерьез и с усердием взяться за изучения AI и PS - то вместе они очень мощная сила. А если еще освоить и Muse или хотя бы панель Timeline в фотошопе, то можно и анимацию отдельных элементов интерфейса забабахать для наглядности, чтобы верстальщик лучше понимал что и как должно действовать.
Да и вообще AI и PS с каждым обновлением становятся все лучше и лучше, удобнее и удобнее. Сейчасс юзаю CC 2017. Там есть хорошие усовершенствования и нововведения.
Скоро должен выйти полноценный Adove XD для Windows. Хотя бета версию уже можно опробовать абсолютно БЕСПЛАТНО, но при условии, что у вас стоит Win10 anniversary edition (build #14393). И, надо сказать, что бета-версии УЖЕ ДОСТАТОЧНО, чтобы делать годные макеты :)
Успехов!

насколько удобно и возможно ли вообще работать веб-дизайнеру в illustrator при создании макета сайта.

Работать возможно и вполне удобно. Проблема в другом — верстальщики не жалуют т.к. плагины и утилиты, облегчающие вёрстку под Фш есть, а под Аи нет. Это не раз обсуждалось даже здесь, на Тостере. Поищите.

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

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

мелкие элементы (~ менее 10 пикселей) нарисованные в этом же масштабе потом плохо масштабируются в большую сторону

Очередная странность, никогда не было таких проблем. Это же вектор, его можно масштабировать как душе угодно. Смотрите какие настройки выставлены, возможно, «сложности» из-за этого.

начинаются проблемы с толщиной обводки, к примеру, когда элмент скэйлится, а обводка - нет.

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

С растром тоже не вижу проблем. Если в макете его очень уж много, то что мешает сделать его (растр) в Фш? Инструменты надо подбирать исходя из задач и совсем не обязательно чтобы это был строго только Фш, только Аи или только какая-то другая программа.

А уж если растр всего лишь в виде превью картинок в макете, то вставить их для презентации также легко как и в Фш. Причём, на вёрстку отдавать уже можно и без них. Т.е. не проблема сделать интерфейс, например, в Аи, а растровую графику (фоны и прочее) положить отдельно. Не забыть только пояснить верстальщику где и как всё это должно располагаться. Или наоборот, сделать макеты в Фш, а все элементы (иконки, кнопки и т.п.) отдельно в svg положить (и не надо париться с кучей размеров).

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

Не существует программы, которая сделает работа за дизайнера :) Лень по Alt+Tab переключаться между программами? Ну идите в копирайтеры, там одного Word'a хватит))

Если выбрал 1:1, встает вопрос, как потом графику нарезать для ретины? Если больший, то насколько? Так чтобы на ту самую ретину хватило?

В Фш есть assets, также есть куча сторонних плагинов — выбирай что удобнее. Инструкций, статей и обзоров, благо, хватает. По поводу размеров для Ретина и прочих также существует масса статей с инструкциями (не считая гайдлайнов), вы их легко найдёте.

Но тогда как работать с растром, ведь зачастую нет фотоматериалов хорошего качества и приходится использовать бэкграунд шириной 1400 пикселей на экраны 1920 пикселей шириной, а если масштаб еще увеличенный скажем x1.5, тогда этот фон в макете начнет размываться при растяжении.

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

Если ни одна программа не идеальна, то логично сделать выбор об использовании более одной программы в работе ;)
Индизайн не для веба, хоть в нём, порой, и удобно сделать даже такой макет (например, сделать скелет, а затем продолжить работу в Фш; особенно, если в макете основа это текст). Всякие Muse и прочие полуавтоматические или автоматические инструменты тоже могут быть использованы — всё зависит от конкретной задачи. Для таких как вы сделали еще Affinity designer, но если и он не нравится, то прям не угодишь. Ждите полнофункциональную версию Adobe XD под Win.
Будете ограничивать себя одной программой — будете вечно ныть, что где-то неудобно.

Успешно работают люди и в Аи, и в Фш, и в Скетчах и т.п. И каждый из них когда-то чего-то не знал, чего-то не умел и не понимал. Всё придёт с опытом и вместо того чтобы искать единственный универсальный инструмент лучше бы изучали возможности разных и учились применять это на практике. Сейчас, многие умеют создавать практически идентичный результат не зависимо от того растровый это или векторный редактор. Разница лишь в навыках специалиста.

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

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

Проблема #1: если вы уберете кавычки, то символы < > будут вызывать ошибки, т.к. это служебные символы в батниках - символы перенаправления. Попробуйте их экранировать: ^> ^<
Попробуйте, может с экранированием прокатит. Вообще в батниках проблема с экранированием, порой нерешаемая. Я несколько раз сталкивался с тем, что проще было написать скрипт, например на javascript из-за проблемы с экранированием служебных символов.
Но у вас простой вариант, должно получиться. Я сейчас пока сам не могу проверить.
Проблема #2: Приведите цикл к такому виду:
for /f "tokens=* delims=" %%a in ('dir /b /a:d /o:n "H:\fonts\*"')
Проблема #3: Я бы предложил вам сделать 2 заготовки для результирующего xml - часть до вставки (header) и часть после вставки. После формирования вставки просто сложите 3 части таким образом:
copy header.xml+insert.xml+footer.xml library.xml
Либо и остальной xml так же генерируйте батником.

sed -i '/^user/s/= .*/= my_user_1/' ${PATH_CONFIG_FILE}

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

Это знает ПРОЦЕСС, который Вы запускаете.
Для некоторых задач ему необходима привязка к локальной машине, и пользователю, чтобы другие пользователи не могли иметь доступ к этим данным.

Если надписи сугубо декоративные, то тянуть 6-7 полных шрифтов, конечно же, нет смысла.

1. Можно выкусить из шрифтов по небольшому субсету буквально в те несколько символов, которые составляют надпись. Весить этакой обрезанный шрифт будет единицы килобайт. Далее кодируем в base64 и все легко грузится.
2. Можно сделать SVG-картинкой.
3. Можно растровой картинкой, дав запас по разрешению в 2-3 раза на любые ретины и масштабирования. Если в надписи мало цветов, весить это будет немного.

Лично я за последний вариант.

У Вас и не может произойти обновление формы - потому что Вы его не делаете на клиентской стороне.
Сейчас Вы:
1. Сохраняете модель
2. Рендерите _form
3. Отправляете результат рендеринга на клиент, но на клиенте Вы этот результат по всей видимости никак не обрабатываете и не отображаете.

Соответственно Вам нужно:
1. Либо писать JS скрипт который будет обрабатывать ответ от сервера и заменять форму на него. Только в этом случае не вижу смысла использовать renderPartial для вывода одной строки текста, т.к. этот функционал можно реализовать на уровне JS
2. Либо копать в сторону PJAX
3. Либо реализовать обработку данных, как написал slo_nik

Логи пустые.

Вы всё врёти, ищите лучше, где ваши логи и какая ошибка. Потому что

один фиг не отвечает.

вы опять врёте, nginx вам отвечает, посмотрите в веб инспекторе.

Для работающего SELinux

chcon -t httpd_sys_rw_content_t /path-to-wp-content -R

И я бы добавил права, и пользователя:

chown -R apache:apache "/path-to-wp-content"
find "/path-to-wp-content" -type f -exec chmod 644 {} \;  
find "/path-to-wp-content" -type d -exec chmod 755 {} \;

от пользователя, которому принадлежит сайт. не php-fpm и не nginx. Если сайт находится в /var/www/username/site.com то php-fpm должен быть настроен на /var/www/username с правами username, сервер nginx с правами www-data
это нужно чтобы запереть пользователя только в его директории и не иметь возможность лезть в чужие папки.
/var/www/username устанавливается с пользователем/группой username:www-data и правами 0760. так пхп от пользователя не может ходить в чужие папки, а www-data не управляем кодом пользователя и не может причинить вред, но ходить должен.