Deploy на shared-хостинг, как с этим жить

Строго говоря в таком говнокоде как вордпресс это не лишено смысла, ибо 95% всех плагинов написаны задней левой ногой убитого индуса. На практике выражается в скорости работы, и что важнее - в дырявости. Если задача простая, то часто действительно проще и надежнее писать свой велосипед чем поддерживать чужое УГ.

+100500

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

Беседу разнесло вширь настолько, что и однозначно ответить всем нельзя.

Ситуация на мой взгляд такая:

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

В стартпосте автор обозначил свою хотелку, ему подсказали пути её удовлетворения, по-меньшей мере, 2 участника, первым без ложной скромности, был я.

Делу время, потехе час. Ну давайте теперь обсудим говнокод внутри плагинов CMS и предложим ТС перейти на самопис :)

Не убивай меня, плиз!!! Нет такого варианта - правка на продакшене)))

Любой сайт, с которым я работаю, у меня должен быть на локалке в том же виде как и на продакшене, включая базу. Что бы потом не отлавливать призраков. Соответственно и

- внес изменения

- проверил работоспособность на локалке

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

Зачем страдать фигней с файлменеджерами, думать, что нужно заливать, что нет, когда все это делает Меркуриал??? Я уже который день безуспешно это пытаюсь донести.

Соответственно меня и бесит, что на шареде я трачу бесполезно время.

Sly32, ну вы что, не решили что-ли? Больше разговоров, давно бы лисапед сделали.

Подсказка: базу можно дампить командой cUrl, который понимает статус выхода!

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

Эх…

/ru/forum/928074

Вот я как раз решал эту задачу.

Sly32, а зачем в этой цепочке локалхост если демосервер уже есть?

Копировать на демо из ИДЕ, а на прод уже руками. Если у вас частые релизы на прод, то сделать автомат. Но опять таки, как вы автоматом деплоите? Делаете отдельную ветку для прода и отдельную для тестового?

Ну сделайте тогда какой-то вебхук или что-то вроде.

У меня помню в одном проекте автодеплой был сделан так:

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

Сделайте что-то вроде.

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

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

Тоже иногда так делал (и с датой).

Но важный момент, вдруг кто об этом еще не задумывался:

не оставляйте в папках файлы вроде index.php.bak (*.bak), так как они же не парсятся сервером и отдаются так как есть, т.е. какие-нибудь сканеры могут нащупать такие файлы и вытянуть. А вдруг там логины-пароли всякие?

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

Есть и не редко. Речь конечно не идёт о больших разработках, а вот "добавьте вот форму обратного звонка" или "хочу, что бы картинки листались круто" - для этого даже можно не применять maintenance-плаги (или файл .maintenance). Для чуть более сложных задач уже стоит.

Это я заморачиваюсь клонированием сайта для смены, напр. темы. А многие, очень многие это делаю "по живому". Как далёк ты от современной реальности :)

И что, его нет? Да даже из ВП он есть :) Чем тебе ПМА на шареде стыдоба? Нет консоли? Есть у многих.

Это ппц. Это ты говоришь о простоте?!!! 2(или 3?) промежуточных (лишних по сути) звена до продакшена? Да это ахтунг просто.

Если речь о более-менее серьёзном проекте, то я по возможности делаю всё на сервере (да-да шареде) заказчика, но на левом закрытом домене. Это позволяет работать в абсолютно идентичных условиях, не нарываясь на косяки с настройками разного серверного ПО (ты, видать, мало с эти сталкивался. А я уж наелся...).

---------- Добавлено 19.07.2016 в 17:00 ----------

Каких только фантазий не услышишь на сёрче летом :)

Файлы с такими данными не требуют ревизий :)