2016-11-30 113 views
0

我们有一个当前正在Wordpress上运行的网站。我们正在开发一个Django站点来取代它。加班,目标是用Django慢慢替换部分WordPress的网站。我们通常会设置此Django的是这样的:将ProxyPass网站安装在与wordpress相同的根网址处

ProxyPass /newcontent/static ! 
ProxyPass /newcontent uwsgi://127.0.0.1:3031/ retry=0 
ProxyPassReverse /newcontent uwsgi://127.0.0.1:3031/newcontent/ retry=0 

这将在ourwebsite.com/newcontent安装的Django/uWSGI应用。但是,这意味着所有的Django URL都将以该根目录开头,所以类似于ourwebsite.com/newcontent/aboutus。除非在conf中特别指出,否则有没有办法配置Apache将所有请求转到Wordpress的地方?我可以想象,制作大量的uWSGI条目将是实现它的一种方式,但是然后Django正在看到各种各样的基本路径,这在内部并不是很好。

最终,这将是最好的,如果我可以这样做:

# Normal Wordpress config, DirectoryIndex, etc 

# Django Specific Stuff 
/about-us    # Goes to Django 
/admin/*     # Django admin 
/our-products/*   # This and all subpaths to Django 
/static/*    # Same, all static content 

此外,我们为HTTPS总是在Django的网站,所以这将是最好也重定向任何Django的服务网址为https在Apache中。

随着时间的推移,我们会慢慢取代wordpress网址直到最后,Django是唯一的服务。在这一点上,我们可以清理配置,将所有URL发送到Django。

回答

0

一个解决方案是使用ProxyPassMatch。下面是一个未经测试的例子:

ProxyPassMatch "^/newcontent/((one|two|three|four)(/|$).*) uwsgi://127.0.0.1:3031/$1 retry=0 

在这方面,例如,onetwothreefour是应该由Django的提供服务的URL。

如果ProxyPassMatch不能这样做,它肯定可以用mod_rewrite来完成。

正则表达式很难理解。即使你没事,你周围的其他人也不会。所以最好避免它们。因此,一个替代的解决方案,如果可能的话,是要列出WordPress的网址,而非Django的网址:

ProxyPass /newcontent/five ! 
ProxyPass /newcontent/six ! 
ProxyPass /newcontent uwsgi://... 

其中fivesix是由WordPress送达。


更新:我睡在我的答案,我不知道;你说

我可以想像,使许多uWSGI条目将做这件事,但随后Django的是看到各种各样的基路径,其内部不那么有效。

那么下面的问题会是什么?

ProxyPass /newcontent/one uwsgi://127.0.0.1:3031/one 
ProxyPass /newcontent/two uwsgi://127.0.0.1:3031/two