Комментарии 14
У WP вполне сносное API. Зачем собаке пятая нога?
+6
Тут, исходя из формулировки задачи, скорее «YII вполне неплохо работает как CMS, зачем, ну зачем заказчик хочет видеть WP...»
+1
Да там и с плагинами полный порядок, не могу представить для чего такое может пригодиться :)
+2
Жуть. Зря я на ночь это прочитал.
Мое имхо, если заказчик хочет WP и его ну никак не отговорить то уж лучше:
1) Нанять Wordpress гуру, который бы вел остальных разработчиков.
или
2) нанять 2-х wordpress гуру которые бы просто сделали отлично проект.
И еще, я думаю у Вас проблема с менеджером, если он хороший менеджер, то он бы убедил что Yii лучше подходит для решения его задачи и что вы по Yii супер профессионалы, а вместо этого он Вас заставил заниматься анонизмом.
Так же, я думаю программисты Yii тоже далеко не рады от этого франкенштейна, если это большой проект, то он пойдет под откос, потому что Вы встретитесь через какое то время с таким кол-вом проблем архитектурных несовместимостей, что половина сотрудников уволятся.
так же я думаю нормально вы не сможете использовать больше половины готовых решений WP коих огромное кол-во.
Ну и напоследок. Когда Вы будете сдавать проект, скорее всего заказчик будет ожидать Wordpress админку, под все задачи, он очень удивится.
Получается Вы заказчика просто обманули)
Мое имхо, если заказчик хочет WP и его ну никак не отговорить то уж лучше:
1) Нанять Wordpress гуру, который бы вел остальных разработчиков.
или
2) нанять 2-х wordpress гуру которые бы просто сделали отлично проект.
И еще, я думаю у Вас проблема с менеджером, если он хороший менеджер, то он бы убедил что Yii лучше подходит для решения его задачи и что вы по Yii супер профессионалы, а вместо этого он Вас заставил заниматься анонизмом.
Так же, я думаю программисты Yii тоже далеко не рады от этого франкенштейна, если это большой проект, то он пойдет под откос, потому что Вы встретитесь через какое то время с таким кол-вом проблем архитектурных несовместимостей, что половина сотрудников уволятся.
так же я думаю нормально вы не сможете использовать больше половины готовых решений WP коих огромное кол-во.
Ну и напоследок. Когда Вы будете сдавать проект, скорее всего заказчик будет ожидать Wordpress админку, под все задачи, он очень удивится.
Получается Вы заказчика просто обманули)
+14
Вообще не понимаю суть задачи.
Да, повторю вопрос — а нахера такое вообще делать?
Если кастомер хочет только Вордпресс — тогда нужно реализовывать логику в рамках вордпресса.
Многие считают что правило — «Клиент всегда прав, так как платит деньги».
Вот от такого и появляются вот такие мысли докручивать непонятно что непонятно куда.
Я уже в ожидании новой статьи как к этому всему можно прикрутить бандлы от Симфони.
Да, повторю вопрос — а нахера такое вообще делать?
Если кастомер хочет только Вордпресс — тогда нужно реализовывать логику в рамках вордпресса.
Многие считают что правило — «Клиент всегда прав, так как платит деньги».
Вот от такого и появляются вот такие мысли докручивать непонятно что непонятно куда.
Я уже в ожидании новой статьи как к этому всему можно прикрутить бандлы от Симфони.
+1
Заказчик хочет вордпресс, потому что потом придут программисты работающие с вордпрессом (и не знающие yii) и будут ставить плагины работающие с вордпрессом (кэширующие допустим) или пытаться работать через его апи (неплохое кстати), или не дай бог напрямую с БД или xml-rpc (что тоже иногда бывает)
Как думаете, что заказчик скажет, когда в разработанной Вами под него части «вордпресса» и в помине не окажется?
С тем же успехом можно было ограничить «скрещивание» размещением логотипа вордпресса:)
Как думаете, что заказчик скажет, когда в разработанной Вами под него части «вордпресса» и в помине не окажется?
С тем же успехом можно было ограничить «скрещивание» размещением логотипа вордпресса:)
+4
+5
Недавно любопытства ради интересовался вопросом возможности интеграции Wordpress с Symfony2 (благо что на основной работе собаку уже съел на интеграции legacy-кода с Symfony2). Нагуглил такую штуку: github.com/ekino/EkinoWordpressBundle — вроде бы большинство задач решает вполне грамотно. Впрочем, сам я никогда с Wordpress серьезно не работал.
-1
Простите, но это какая-то попа-боль.
У меня тоже был проект сделать корп сайт с конкурсом на WP.
Да, я люблю писать на Yii и WP вызывает аллергию по всему телу.
Я тоже нашел эти статьи по скрещиванию.
Но не смотря на всю мою ненависть к WP, проще было изучить API WP.
Ибо как уже выше писали, если заказчик прыгнет куда-то в сторону, голова болеть будет у вас, а не у заказчика :)
У меня тоже был проект сделать корп сайт с конкурсом на WP.
Да, я люблю писать на Yii и WP вызывает аллергию по всему телу.
Я тоже нашел эти статьи по скрещиванию.
Но не смотря на всю мою ненависть к WP, проще было изучить API WP.
Ибо как уже выше писали, если заказчик прыгнет куда-то в сторону, голова болеть будет у вас, а не у заказчика :)
0
У меня аналогичный опыт, но полностью скрещивать 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.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yii + WordPress = <3, или Увлекательный эксперимент получения Франкенштейна