sim3x: Ок, продолжайте так думать, я ж не настаиваю. А я продолжу создавать крупные проекты не зная горя :) Каждому свое. А вот заявления громкие делать и обобщать не стоит)
sim3x: Можно. Та же БД - WP поддерживает drop-in класс для работы с БД. Если он присутствует, используется он вместо стандартного. Весьма легко происходит отвязка от родного "шаблонизатора". Да, на WP_Query все сильно завязано, поэтому его приходится оборачивать. Впрочем, это малая жертва и при правильном подходе проблем не создает. Кроме того, никто не отменял headless-wordpress, когда он работает на shortinit или же вообще на фронте не используется напрямую. Фронт сайта можно делать полностью на MVC, а для админов функционал разширяется легко. В общем, проблем никаких нет. Вопрос исключительно в понимании того что и как делать. Имеет ли это смысл? Если команда / разраб заточен под фреймворки, то понятно что смысла нет - нужно хорошо знать ядро. Если команда хорошо знает и WP, и фреймворки, и чистый PHP в адекватном виде, то решение использовать WP - чем бы оно ни было продиктовано - так же имеет смысл, как и использование любой другой платформы. То есть, вопрос не "можно ли", а "стоит ли". И ответ зависит от множества факторов, и да, не всегда он в пользу WP. Но "выбрасывать" WP только потому что это WP - однобоко.
sim3x: Собственно, я полностью согласен, что надо писать нормальный продукт - это ключевая мысль. Возможно ли его написать на WP? Да, возможно. Хоть и требует очень глубоких знаний как самого ядра WP, так и адекватных фреймворков - Symfony, Laravel etc.
Ян Александров: просто ваш файл /file.php выполняется ВНЕ WordPress, поэтому вызов WP-функции в нем ничего полезного не делает. Странно что ошибку undefined function не вываливает.
sim3x:
Идти на фриланс - да
Выбрасывать вордпресс - совершенно необязательно, достаточно выбросить этот шаблон
Писать нормальный продукт - да, да, да черт возьми
О боги, прекратите нести эту устаревшую чушь. Да, codebase WP не является самой современной, не является чисто ООП и тд. Но WP еще как рассчитан на high-load, скейлинг, и очень крупные и сложные проекты.
Илья:
1. Вы удивитесь, но в документации много чего нет (хотя в целом документация у WP отличная)
2. В документации не описано как все работает, что за чем, как себя ведет environment на разных этапах работы приложения.
Прогонка пошагово через xDebug - один из лучших советов, который мне когда-то дали, потом и я его давал, и очень рад, что другие тоже советуют этот метод. Попробуйте сами. Узнаете много нового :)
Rad Cor: На здоровье! :) Просмотрите все плагины этого автора, возможно еще что-то пригодится. Они упомянуты в описании на странице плагина. Качество этих плагинов на высшем уровне, очень советую.
Александр Медведев: Роман Краббз: сами по себе сериализованные данные не слетают, кроме transients. Но если вы делали поиск-замену по дампу, и в том числе была произведена замена в сериализованной строке - вот только тогда строка будет побита. Она импортнется в новую базу, но при попытке чтения unserialize() вернет false вместо значения. Отсюда и "слетевшие" данные. Случается, если в меню у вас есть пункт с произвольным URL например - project.dev/some-url в локальной базе вы заменили на project-live.com/some-url. Поменялось значение в сериализованной строке, и она побилась.
По идее должно работать.