本文目录一览：
- 1、thinkphp项目中怎么加载twig引擎
- 2、PHP twig 文件修改后如何刷新缓存或者之类的操作能看到网页修改后的效果
- 3、golang 使用twig模板引擎，站在php的肩膀上！
- 4、PHP 模板引擎的简单代码怎么弄！
- 5、为什么drupal8要选择twig作为逡
- 6、Node.js代码转php
thinkphp项目中怎么加载twig引擎
如果想用第三方的模板引擎，需配置的文件是项目配置文件；
可以去ThinkPHP/Lib/Behavior/ParseTemplateBehavior.class.php文件中查看
仔细查看默认的配置想，可以到自己的项目配置文件修改；
'TMPL_ENGINE_TYPE'= 'Think', // 默认模板引擎 以下设置仅对使用Think模板引擎有效
'TMPL_L_DELIM' = '{',// 模板引擎普通标签开始标记
'TMPL_R_DELIM' = '}',// 模板引擎普通标签结束标记
.....
你可以根据自己的需要进行设置
PHP twig 文件修改后如何刷新缓存或者之类的操作能看到网页修改后的效果
twig 没有什么缓存
我猜你的意思是 你刚刚改了个twig模板里的东西 发现刷新了好几次 还是之前的效果，然后过了一会刷新，发现效果出来了，我猜估计是这样
我猜 你php的 `opcache` 打开的，你关掉就行了！
golang 使用twig模板引擎，站在php的肩膀上！
和有些小伙伴一样，本人是从php转到了go,从事php时使用symfony框架一直享受其丰富的功能带来的便利，转到其他语言时比较直观的感觉就是twig真强，为什么其他语言没有扩展twig呢？
虽然前后端的开发模式，让模板引擎这个东西慢慢淡去，但是有时候还是需要用到这种东西，所以就有了，go调用php实现twig模板引擎的想法。
原理，go 通过exec.Command调用php,通过STDIN,STDOUT 方式进行数据交互
go在初始化阶段提供一些配置参数，比如模板引擎的为止，是否为开发环境等，php接收数据并初始化
初始换环境完毕后，当需要渲染模板，go再讲模板文件和数据以json字符串的形式写入STDIN告知php,
php接收到数据后，解析数据，选取指定的模板并渲染，然后通过STDOUT返回给go
这样一次渲染就结束了
整理好的文件打包在github上了
如果喜欢就动动你的小手指点个赞，star一下吧！
PHP 模板引擎的简单代码怎么弄！
//phpcms 的核心模板解析函数
/*
*/
function template_parse($str)
{
$str = preg_replace("/\{(\\$[a-zA-Z0-9_\[\]\'\"\$\x7f-\xff]+)\}/es", "addquote('?php echo \\1;?')",$str);
$str = preg_replace("/\{([A-Z_\x7f-\xff][A-Z0-9_\x7f-\xff]*)\}/s", "?php echo \\1;?",$str);
$str = preg_replace("/([\n\r]+)\t+/s","\\1",$str);
$str = preg_replace("/\\!\-\-\{(.+?)\}\-\-\/s", "{\\1}",$str);
$str = preg_replace("/\{template\s+(.+)\}/","\n?php include template(\\1); ?\n",$str);
$str = preg_replace("/\{include\s+(.+)\}/","\n?php include \\1; ?\n",$str);
$str = preg_replace("/\{php\s+(.+)\}/","\n?php \\1?\n",$str);
$str = preg_replace("/\{if\s+(.+?)\}/","?php if(\\1) { ?",$str);
$str = preg_replace("/\{else\}/","?php } else { ?",$str);
$str = preg_replace("/\{elseif\s+(.+?)\}/","?php } elseif (\\1) { ?",$str);
$str = preg_replace("/\{\/if\}/","?php } ?",$str);
$str = preg_replace("/\{loop\s+(\S+)\s+(\S+)\}/","?php if(is_array(\\1)) foreach(\\1 AS \\2) { ?",$str);
$str = preg_replace("/\{loop\s+(\S+)\s+(\S+)\s+(\S+)\}/","\n?php if(is_array(\\1)) foreach(\\1 AS \\2 = \\3) { ?",$str);
$str = preg_replace("/\{\/loop\}/","\n?php } ?\n",$str);
$str = preg_replace("/\{tag_([^}]+)\}/e", "get_tag('\\1')", $str);
$str = preg_replace("/\{\\$([a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*\(([^{}]*)\))\}/","?php echo \\1;?",$str);
$str = preg_replace("/\{(\\$[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*)\}/","?php echo \\1;?",$str);
}
function addquote($var)
{
return str_replace("\\\"", "\"", preg_replace("/\[([a-zA-Z0-9_\-\.\x7f-\xff]+)\]/s", "['\\1']", $var));
}
为什么drupal8要选择twig作为逡
drupal6就可以使用非PHP的模板引擎，drupal8也不是一定要用twig，也是可以用PHP做模板的。但这样就需要 前端开发人员掌握PHP才可以 。用twig有它的好处，例如前端入门门槛低，可以比较安全地把整个THEME的权限分配给其他模板团队进行开发等。
Node.js代码转php
如果你们开发团队正在使用PHP，并考虑迁移到Node.js，这篇文章很适合你。本文并不探讨从PHP移植到Node.js的细节，以及Node.js的基础知识。而是涵盖：决策制定、着手点的描述、编写 Node.js 服务器的深层次注意事项、以及部署策略。
为什么迁移？
1stdibs 决定从 Apache/PHP 迁移到 Node.js+Express 有五个理由：
代码更少
全栈式JS
开发人员幸福度更高
投入回报率
未来的优化
代码更少
1stdibs基于面向服务体系架构（SAO），前端调用后台的Java服务。这意味着需要同时维护前端模型，以及服务端PHP和客户端JS模板。试想一下，如果可以摆脱PHP，就能够统一前端展现与后台模型于一种语言：JavaScript（同时可以合并一些模板）。从维护的角度来看，这么做代码更简洁，并且没有重复逻辑。
同构JavaScript万岁!
全栈式JS（及其优点）
整个开发栈使用一种语言很简便。对开发者来说，较少的环境切换使他们开心和高效。额外的好处是工具使用更简单。相比之前使用Composer和npm两个包管理器，现在只需要一个。尽管Composer很出色，由于nbp负责工具和客户端管理，nbp总是必要的。一旦去掉所有的PHP代码，nbp将成为仅有的包管理器。
开发人员乐意
我们要保证开发人员的技能集得到扩展、职业生涯不断发展，这一点很重要。对于JavaScript工程师而言，Node.js极具吸引力。能够在服务端使用与客户端相同的工具、风格和模式，是非常顺手和高效的。此外，Node.js相当流行，在企业级开发上也得到了长足发展。Node.js是JavaScript工程师的必备技能。
投入回报率
我们在招聘优秀的JS工程师和培训初级JS工程师方面花了大价钱。由于客户端栈很复杂，我们需要高级JavaScript工程师。我们不再雇用PHP工程师，仅仅雇用了JavaScript工程师。我们的观点是，为什么不培养他们在服务端的技能呢？
未来的优化
长远而言，我们打算把两个庞大的应用分割成一系列独立部署的小应用。这很容易通过Node.js、Express和nbp实现。理论上，PHP（比如使用Slim）可以做同样的事。但我们非但得不到上述好处，还会搞得一团糟：在Apache/PHP上进行操作会更加复杂，基础设施也会变得有些奇怪。
选择框架
那个最终被我们用Node.js替换掉的PHP应用，主要有如下职责：
登录和授权
路由选择和服务端模板引擎（服务HTML）
引导前端应用
代理服务（为了回避CORS）
服务静态资源（js，css，images）
这些就是我们需要替换掉的基本功能。
我们尝试过不少框架，Express令人叹为观止（试一下我们评估过的spreadsheet）。任何未基于Express 的框架看起来都不靠谱。Express通俗易懂，并有良好的文档。另外，可以招聘到正经培训过Express的人。
我们添加了一些kraken的核心模块（express-enrouten用于路由选择、lusca负责安全）；此外，i18n-node提供国际化支持，模板引擎使用Swig（我们后来放弃了Swig。呵呵，开源软件还是有风险的）。
我们考虑过全盘使用kraken，但是从原来的服务端php模板引擎Twig切换到Swig直截了当，还很快捷。此外，kraken里面的Dust和i18n也不讨人喜欢。
编写服务器
选好了框架，下一步该写服务器了。
使用Apache+PHP时，你不需要再写一个服务器。Apache本身就是服务器，PHP是应用。如果使用Node.js，服务器和应用是同一个。从Apache/PHP转到PHP，你需要处理一些之前自然而然使用的功能，这一点很重要。使用Apache，你（或者系统管理员）配置服务器，在PHP应用里完全不用关心Apache为你处理的那些事。Node.js却以一种不同的方式来工作。
提供静态文件服务
毋庸置疑，提供静态文件服务是Apache的核心功能。Node.js与此不同，你要在应用中配置静态文件服务。幸运的是这很简单，有良好的文档说明，并且是在Express中实现的。
日志
很多基本的Apache配置为你提供访问日志和错误日志。使用Node.js时，估计你也猜到了，同样需要在应用中配置。所幸很多优秀的开源软件包使之变得很简单。Morgan是一个基本的请求日志记录器，它配置简单，允许你把日志写到输出流（标准输出设备或文件）。如果你需要把日志写到数据库，或者有别的（更高级的）日志需求，那就试一下winston吧。
代理
我们有一个基本需求：能够代理传输客户端ajax请求到后台服务。相比于处理CORS头，代理所有来自相同域的请求要简单得多。但你要想通过代理使用webpack-dev-server（正如我们所做的），就必须在Node.js应用中处理这一问题。http-proxy是一个简单可靠的解决方案。
剩下的工作
除了上面提到的，还有一些列别的工作需要完成。我们从一个MVC应用谈起，该应用基于 CodeIgniter(CI)框架，为一系列单页应用提供服务。大部分工作就是移植：
CI控制器移植到Express路由选择器和中间件（包括登录和认证）
Twig模板引擎移植到Swig（这一步比较琐碎）
Service层数据访问（以便正常启动客户端单页应用）
上面并未列出CodeIgniter模型这一关键组件。事实上根本不用重写PHP模型！太给力了！我们的客户端应用使用Backbone模型。当然这要扩展Backbone.Model.sync，从而使之全局地工作在服务器和客户端。
部署
如果你的app规模较大，不应该一次性全部上线。可以通过渐进式部署的方式逐步上线。我们因此花费了好几周。
渐进式部署的优点：
最小化bug范围
每次在发布一部分路由及功能的同时，其他工程师可以正常进行开发
对正在进行的功能开发和改进影响最小 — 新功能可以继续发布（这可能导致重复的工作）
如果操作得当，可以快速回滚到之前的服务
NGINX很不错
该如何逐步上线呢？我们在众多的服务器中挑选了Nginx。
1
2
3
4
5
+----------+
http | |---
Apache/PHP
request----| Nginx
|
| |---
Node.js
+----------+
Nginx允许你一次只“打开”一个路由（如果发现情况不妙就关掉 — 正如我们多次遇到的），这给了你很大的自由度。我们也发现打开路由的时候不用部署代码，这很有帮助。这在一周一次的发布计划里，为我们提供了一些回旋空间。
不过有一个缺点，你需要确保客户端代码同时接受旧的Apache/PHP服务器和新的Node.js服务器提供的服务。这并不可怕，不过你要把旧服务器上未优化的功能移植到新的服务器。屏住呼吸去做吧（记得写一个便利贴去清理你的技术债）。
总结
从头到尾，整个移植工作大概花费了一年。这听起来可能有点荒谬，不过这个时间表包括决策过程（比较匆忙）、基于Express写一个满足需求的核心框架、移植所有功能、逐步渐进式上线。此外，请记住，我们始终只有一两个开发者为之工作 — 并且是兼职。
如果你想尝试一下，请慎重考虑。你的团队能否受益？你的整个组织能否受益？如果你来自商业组织，请记住商业需要持续运转。你需要在商业目标和工程目标之间找到良好的平衡。
