Блог

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

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

Примеры того, что мне нужно сделать:

• добавьте некоторую дополнительную информацию в профили, например, систему кармы / очков / репутации
• предложите пользователям создать свою собственную страницу после того, как им разрешат это сделать
• извлечение данных из какого-либо внешнего API и отображение их в профиле пользователя

Я действительно привык ко всему гибкому рабочему процессу BDD, где я перехожу от функций Cucumber к RSpec для реализации материала, и вся архитектура WordPress выглядит для меня как хорошо, я просто должен молиться, чтобы это сработало.

Я не уверен, разумно ли вообще пытаться написать какую-то часть приложения на Ruby и попытаться заставить его работать вместе с WordPress, или мне следует просто использовать WordPress как единственное, что у меня есть, и максимально использовать его сильные и слабые стороны.

Основная проблема для меня заключается в том, что все, что я собираюсь написать на PHP, займет примерно в 5 раз больше времени, чем если бы я делал это на Ruby, и это, вероятно, также будет более безопасным и надежным, поскольку у меня не так много опыта работы со сложными PHP-материалами. Я имею в виду, что в прошлом я много работал с PHP, но мне всегда казалось, что все это развалится в один момент.

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

Мы интегрировали приложение Rails в установку TYPO3. Это сработало довольно хорошо. Ключевым моментом является использование поддержки Rails для адаптации моделей к таблицам устаревшего приложения. Важным моментом является обработка аутентификации, которую мы обрабатываем, передавая ключ сеанса TYPO3 в приложение Rails скрытым способом (используя PHP в качестве веб-клиента и передавая соответствующие заголовки) и просматривая его в таблице сеансов (с учетом таймаутов сеанса).). Само приложение Rails отображается в подкаталог с помощью passenger. Производительность очень хорошая, она даже удивительна по сравнению с нашей предыдущей реализацией, пытающейся использовать Extbase.

Итак, в заключение: если вы все сделаете правильно, и интерфейсы между двумя приложениями хорошо спланированы, такой подход может предложить большие преимущества и лучшее из двух миров. Если все сделано неправильно или вы не понимаете некоторых последствий WordPress (например, безопасности), вы создадите большой беспорядок, подверженный нарушениям безопасности.

Кстати: мы достигли равенства функций с решением Extbase (MVC framework в TYPO3) после 4 дней использования Rails. Решение Extbase заняло 6 недель и вызвало много головной боли и проблем. Таким образом, ваш временной коэффициент может быть даже лучше, чем 5: 1.

Почему бы не научиться разработке на основе поведения на PHP для WordPress? На самом деле, это одна из замечательных возможностей для разработчиков в 2017 году. Теперь мы используем полномасштабные фреймворки BDD в WP-Codeception, так что вы можете даже автоматизировать файлы функций Gherkin, как в Cucumber. Проверьте WordPress-BDD.com для получения некоторой полезной информации.