Дмитрий: тогда ответ прост - никак. Но того же эффекта можно добиться через custom taxonomy и немного кастомного кода. Кстати, недавно стартануло обсуждение среди разрабов ядра, вполне вероятно что скоро (максимум к апрелю 2016) post formats будут выпилены из ядра в плагин.
cainiao: именно. Если сразу в корневую - сразу бы все и заработало. На самом деле, установка в своей папке - абсолютно нормальный подход, даже больше - среди опытных разработчиков он считается правильным. Например, мы используем такую структуру - в корне у нас index.php, wp-config.php, папки core (содержит все файлы вордпреса), modules (содержит папку wp-content - с темами, плагинами всем, что выходит за рамки WP).
1. Отвечайте комментариями, а не ответами) Функционал тут чуть другой
2. Аккуратность всех детекторов - штука весьма относительная. Мой адблок в хроме, например, Хабр не определяет. Я просто вижу чистенький Хабр без какой-либо рекламы. И никаких просьб не вижу.
3. Вы спросили похожее решение - я вам их предоставил. Если что-то не подходит - уточняйте вопрос.
Пума Тайланд: ну это нормально для обычного юзера (у которого и задачи примитивные). А для продвинутого норма - сначала почитать доку, чтобы понимать как эта фича работает. И только после этого принимать решение - ставить галочку или нет. Тем более что галочка обходится в 20% от стоимости дроплета.
Пума Тайланд: ладно, проехали. Бесполезный спор, так как вы упрямо не замечаете, что проблема не столько в бекапе DO, сколько в ваших ожиданиях, которые не соответствуют этому решению. Вы хотите и ожидаете, чтобы было так, как вы хотите, но на самом деле то там все иначе. Проблема будет существовать, пока ваши ожидания будут завышены и оторваны он реальности.
Пума Тайланд:
1. "хочу в момент когда дигитал ошен запускает свою систему бекапа на мой дроплен он не умирал без всяких признаков жизни" - выключите автобекап, используйте свое, более контролируемое решение.
2. "приплатить за чудесний сервис заключающийся в том что дроплет может зависнуть в любой момент из за проблем на стороне хостера" - это не проблема на стороне хостера, это how it works, о чем хостер предупреждает изначально (читать доки надо перед включением опции бекапа). Для большинства простых серверов этот вариант подходит и работает. Для особых случаев, как ваш - выключайте и делайте свою бекап-рутину. Денег заодно сэкономите.
И вообще. Суточный / еженедельный бекап в виде снапшота, если честно, абсолютно ненадежная система бекапа. Если у вас есть критичность данных - этот вариант изначально не подходит. Вы должны иметь живую репликацию БД, чтобы ни одна транзакция не потерялась (а при суточном снапшоте вы же потеряете все данные за время с момента последнего бекапа до фейла). Это первое и основное. Код, естественно, на CVS. Файловая система (аплоады, например) не столь критичны обычно, но если и в них есть что-то критичное - используйте свою автоматическую синхронизацию, зеркалирование. Ни одна стандартная система backup'ов по расписанию не подходит для случаев где нужна надежность и актуальность бекапов. Не пытайтесь участвовать в гонке Формула-1 на обычном городском хетчбеке, пусть даже тюнингованом. Это совершенно разные вещи.
Пума Тайланд: ну право же :) это софтверная проблема, не железная. При чем тут хостер, если за софтовую часть VPS он не несет ответственности? Для мониторинга и ребута сервера / ребута или убивания процесса / рестарта процессов используйте соответствующие тулзы - Monit, Cactus, New Relic и иже с ними. То, чего вы ожидаете в этой ситуации - возможно. Но такой сервис называется Managed VPS. Вот в этом случае вы платите им деньги за мониторинг и администрирование и железа, и софта. Ну вы и сами в курсе. Я понимаю, что необходимость дополнительных телодвижений напрягает, но это обратная сторона медали. Не хотите ничего делать - берите Managed, хотите дешевле - берите self-managed и делайте все сами.
Пума Тайланд: ну как бы да. Если вам нужен надежный бекап - делайте свой. Родной бекап - это банальный фоновый снимок. Из документации, например - "Please note that automated backups running on a server with an active database can result in an incomplete backup of your database." То же самое касается активной записи в файловую систему. Тут, как бы, изначально хостер говорит, что наш автобекап - штука не совсем надежная, если вам надо что-то большее, чем просто регулярные снимки - используйте кастомные решения (которых масса).
Пума Тайланд: ну и где здесь в тексте утверждение "да такое может произойти" (по крайней мере по вашим словам я уловил контекст "ну это типа нормально, бывает, не парьтесь")? Вам четтко написали:
1. Возможную причину
2. Что делать
3. Пообещали мониторить ваш дроплет на предмет залипания
Абсолютно корректный и адекватный ответ. Вообще, в данном случае, если проект критичен к аптайму - создать новый дроплет и перенести все на него (хотя, как я уже говорил выше, для совсем критичных проектов, нужна схема fail-proof). Хотя я бы не делал, если подобное не повторится. Ну и, судя по озвученной возможной причине, произошел конфликт I/O, что вполне может случиться с write-intensive приложениями. В данном случае, дейсттвительно, стандартный backup попросту не подойдет. В подобных ситуациях как раз и помогает fail-proof архитектура - на время бекапа сервера он исключается из цепочки, передавая свою функцию вторичному, после бекапа возвращается в строй.
Пума Тайланд: Вообще-то для проектов где минута простоя смерти подобна нужно делать fail-proof решения, с репликацией бд и балансировщиком :) Пруф что "суппорт говорит да такое может произойти" есть?
Пума Тайланд: Ну как раз я про остальное не упомянул даже, так как там проблем не возникает, DO как раз из тех, что "включил и забыл" - все просто работает, как техника Apple. По твоим случаям:
1. Ни разу не было, а под моим контролем много дроплетов разного размера в разных датацентрах (чуть больше 40, плюс регулярно создаются-удаляются временные для тестов и тп). Если ребут больше 1 минуты - либо проблема с настройками сервака при загрузке, либо реально с железом (иногда случается). В первом случае - это ваша забота, во втором - пишите в саппорт, решат быстро (проверено).
2. Все дроплеты бекапятся, ни разу не было ничего подобного. Я вообще не замечаю даже существование этой фичи, она "просто работает".
Не обобщайте на своем негативном опыте (тем более без объективных доказательств, что вина на стороне DO). Под моим контролем там более 40 серверов, все они мониторятся через New Relic. Аптайм практически равен 100%, единственный даунтайм - это когда мы сами ребутим серваки, например после апдейтов.
SergPro: можно, мне же удается. Просто разговаривать надо языком чистых цифр. Показываете статистику, объясняете как обстоят дела на данный момент и как они будут обстоять через 1 год (а сайт ведь делается с рассчетом наперед). Ну и, как я уже писал выше, просто добавляете, что поддержку старых ИЕ можно сделать - за дополнительную плату и дополнительные сроки. Как отдельную услугу.
VladimirZhid: вот-вот. Такой маленький нюанс, размером в $100 :) Хотя, если заниматься разработкой сайтов на WP на заказ, то покупать однозначно стоит - экономит кучу времени и денег, стоимость лицензии отбивается за первый же заказ.
sim3x: кроме того, ничто не мешает делать нормальный mobile-first progressive enhancement, тогда старые версии просто получат облегченную мобильную версию. Это значительно дешевле и быстрее.
sim3x: фразу из контекста не дергайте. Забили все, кто умеет считать деньги. Делать поддержку старых браузеров если это действительно НУЖНО (все верно - госсектор в РФ, например) - тогда это идет отдельной строчкой и в прайсе, и в графике работ. Во всех иных случаях эта поддержка не нужна. Еще на этапе написания ТЗ проводится анализ и определяется, нужно ли поддерживать столь архаичные версии самого любимого браузера. В большинстве случаев - игра не стоит свеч. Тратить кучу времени и денег на 1-3% юзеров, при этом это заставляет отказываться от каких-то плюшек для остальных 97-99%? Спасибо, не надо.
