Comments 14
У WP вполне сносное API. Зачем собаке пятая нога?
Жуть. Зря я на ночь это прочитал.
Мое имхо, если заказчик хочет WP и его ну никак не отговорить то уж лучше:
1) Нанять Wordpress гуру, который бы вел остальных разработчиков.
или
2) нанять 2-х wordpress гуру которые бы просто сделали отлично проект.
И еще, я думаю у Вас проблема с менеджером, если он хороший менеджер, то он бы убедил что Yii лучше подходит для решения его задачи и что вы по Yii супер профессионалы, а вместо этого он Вас заставил заниматься анонизмом.
Так же, я думаю программисты Yii тоже далеко не рады от этого франкенштейна, если это большой проект, то он пойдет под откос, потому что Вы встретитесь через какое то время с таким кол-вом проблем архитектурных несовместимостей, что половина сотрудников уволятся.
так же я думаю нормально вы не сможете использовать больше половины готовых решений WP коих огромное кол-во.
Ну и напоследок. Когда Вы будете сдавать проект, скорее всего заказчик будет ожидать Wordpress админку, под все задачи, он очень удивится.
Получается Вы заказчика просто обманули)
Мое имхо, если заказчик хочет WP и его ну никак не отговорить то уж лучше:
1) Нанять Wordpress гуру, который бы вел остальных разработчиков.
или
2) нанять 2-х wordpress гуру которые бы просто сделали отлично проект.
И еще, я думаю у Вас проблема с менеджером, если он хороший менеджер, то он бы убедил что Yii лучше подходит для решения его задачи и что вы по Yii супер профессионалы, а вместо этого он Вас заставил заниматься анонизмом.
Так же, я думаю программисты Yii тоже далеко не рады от этого франкенштейна, если это большой проект, то он пойдет под откос, потому что Вы встретитесь через какое то время с таким кол-вом проблем архитектурных несовместимостей, что половина сотрудников уволятся.
так же я думаю нормально вы не сможете использовать больше половины готовых решений WP коих огромное кол-во.
Ну и напоследок. Когда Вы будете сдавать проект, скорее всего заказчик будет ожидать Wordpress админку, под все задачи, он очень удивится.
Получается Вы заказчика просто обманули)
Вообще не понимаю суть задачи.
Да, повторю вопрос — а нахера такое вообще делать?
Если кастомер хочет только Вордпресс — тогда нужно реализовывать логику в рамках вордпресса.
Многие считают что правило — «Клиент всегда прав, так как платит деньги».
Вот от такого и появляются вот такие мысли докручивать непонятно что непонятно куда.
Я уже в ожидании новой статьи как к этому всему можно прикрутить бандлы от Симфони.
Да, повторю вопрос — а нахера такое вообще делать?
Если кастомер хочет только Вордпресс — тогда нужно реализовывать логику в рамках вордпресса.
Многие считают что правило — «Клиент всегда прав, так как платит деньги».
Вот от такого и появляются вот такие мысли докручивать непонятно что непонятно куда.
Я уже в ожидании новой статьи как к этому всему можно прикрутить бандлы от Симфони.
Заказчик хочет вордпресс, потому что потом придут программисты работающие с вордпрессом (и не знающие yii) и будут ставить плагины работающие с вордпрессом (кэширующие допустим) или пытаться работать через его апи (неплохое кстати), или не дай бог напрямую с БД или xml-rpc (что тоже иногда бывает)
Как думаете, что заказчик скажет, когда в разработанной Вами под него части «вордпресса» и в помине не окажется?
С тем же успехом можно было ограничить «скрещивание» размещением логотипа вордпресса:)
Как думаете, что заказчик скажет, когда в разработанной Вами под него части «вордпресса» и в помине не окажется?
С тем же успехом можно было ограничить «скрещивание» размещением логотипа вордпресса:)
Недавно любопытства ради интересовался вопросом возможности интеграции Wordpress с Symfony2 (благо что на основной работе собаку уже съел на интеграции legacy-кода с Symfony2). Нагуглил такую штуку: github.com/ekino/EkinoWordpressBundle — вроде бы большинство задач решает вполне грамотно. Впрочем, сам я никогда с Wordpress серьезно не работал.
Простите, но это какая-то попа-боль.
У меня тоже был проект сделать корп сайт с конкурсом на WP.
Да, я люблю писать на Yii и WP вызывает аллергию по всему телу.
Я тоже нашел эти статьи по скрещиванию.
Но не смотря на всю мою ненависть к WP, проще было изучить API WP.
Ибо как уже выше писали, если заказчик прыгнет куда-то в сторону, голова болеть будет у вас, а не у заказчика :)
У меня тоже был проект сделать корп сайт с конкурсом на WP.
Да, я люблю писать на Yii и WP вызывает аллергию по всему телу.
Я тоже нашел эти статьи по скрещиванию.
Но не смотря на всю мою ненависть к WP, проще было изучить API WP.
Ибо как уже выше писали, если заказчик прыгнет куда-то в сторону, голова болеть будет у вас, а не у заказчика :)
У меня аналогичный опыт, но полностью скрещивать Wordpress и Yii я отказался.
Нужный функционал сделали довольно быстро как независимый проект на фреймворке Yii в виде клиента на javascript и RESTfull API (кэширование, сфинкс, куча крон-задач, утилиты по конвертированию и сжатию изображений), а не в виде плагина к Wordpress. Запустить хотели на том же домене, где раньше был блог на Wordpress ( проект icons8 — иконки в стиле windows8, iOS7, Android ).
Но на Wordpress было огромное количество статей, хорошо проиндексированных в гугле и яндексе. Нужно было сохранить весь контент с его прежними URL. Переносить большой функционал CMS в небольшое приложение на Yii было неразумным решением с точки зрения трудоёмкости. Делать общую авторизацию пользователей не предполагалось.
В итоге сайт на wordpress оставили «в тени», а доступ к нему обеспечен средствами nginx.
Позаботились о сохранении всех прежних ссылок для гугля и о других специальных ссылках: файлы тем, загруженные картинки, RSS, sitemap.
Кусок конфига для проксирования через nginx выглядит так:
Полный вариант на gist.github.com
Обсуждали это решение неделю. Задача по созданию конфига заняла часа два.
Есть проблема в том, что если сайт заваливать запросами, гарантированно возвращающими 404, то их последовательно будут обрабатывать и Yii, и Wordpress, но это частично разруливается кэшем страниц в nginx, а в Yii оптимизирована работа с роутингом запросов, чтобы как можно меньше ресурсов потреблять на «нерасшифровываемые» URL.
Нужный функционал сделали довольно быстро как независимый проект на фреймворке Yii в виде клиента на javascript и RESTfull API (кэширование, сфинкс, куча крон-задач, утилиты по конвертированию и сжатию изображений), а не в виде плагина к Wordpress. Запустить хотели на том же домене, где раньше был блог на Wordpress ( проект icons8 — иконки в стиле windows8, iOS7, Android ).
Но на Wordpress было огромное количество статей, хорошо проиндексированных в гугле и яндексе. Нужно было сохранить весь контент с его прежними URL. Переносить большой функционал CMS в небольшое приложение на Yii было неразумным решением с точки зрения трудоёмкости. Делать общую авторизацию пользователей не предполагалось.
В итоге сайт на wordpress оставили «в тени», а доступ к нему обеспечен средствами nginx.
Позаботились о сохранении всех прежних ссылок для гугля и о других специальных ссылках: файлы тем, загруженные картинки, RSS, sitemap.
Кусок конфига для проксирования через nginx выглядит так:
# конфиг верхнего уровня для перенаправления запросов на приложение Yii или блог wordpress
server {
listen 80;
#server_name icons8.com;
location / {
proxy_intercept_errors on; # чтобы перехватить ошибки
error_page 404 = @wordpress_fallback; # при ошибке Page Not Found запросить wordpress
proxy_pass http://127.0.0.1:8889; # запросить приложение на Yii
}
location @wordpress_fallback {
proxy_intercept_errors off; # пусть теперь wordpress отрисовывает страницы ошибок
proxy_pass http://wordpress_upstream; # запросить wordpress
}
# несколько фиксированных URL, которые надо сразу передать в wordpress мимо Yii
# страницы блога http://icons8.com/2014/01/21/???
location ~ /\d\d\d\d/\d\d/ {
proxy_pass http://wordpress_upstream;
}
# стили и оформление блога http://icons8.com/wp-content/themes/icons8/style.css
location ^~ /wp-(.+) {
proxy_pass http://wordpress_upstream;
}
# новостные ленты http://icons8.com/feed/rss/
location ^~ /feed/ {
proxy_pass http://wordpress_upstream;
}
}
# Приложение wordpress
upstream wordpress_upstream {
server blog; # тут либо IP либо адрес сервера
}
# приложение на Yii - конфиг стандартный кроме порта 8889
server {
listen 8889;
set $yii_bootstrap "index.php";
root /var/www/icons8.com/www;
location / {
index index.html $yii_bootstrap;
try_files $uri $uri/ /$yii_bootstrap?$args;
}
# pass the PHP scripts to FastCGI server listening
location ~ \.php {
# ...
}
}
Полный вариант на gist.github.com
Обсуждали это решение неделю. Задача по созданию конфига заняла часа два.
Есть проблема в том, что если сайт заваливать запросами, гарантированно возвращающими 404, то их последовательно будут обрабатывать и Yii, и Wordpress, но это частично разруливается кэшем страниц в nginx, а в Yii оптимизирована работа с роутингом запросов, чтобы как можно меньше ресурсов потреблять на «нерасшифровываемые» URL.
Sign up to leave a comment.
Yii + WordPress = <3, или Увлекательный эксперимент получения Франкенштейна