在网络环境日益复杂的今天，就连Chrome浏览器都强制要求HTTPS了，否则就会把你的网站标记为不安全网站。所以需要强制设置HTTP请求到重定向到HTTPS。

如果使Cloudflare的话，其实他们有这个选项，所以你其实什么都不用做，开启这个选项即可。

如果在Nginx端做设置的话，就需要用到一个配置：

- 阅读剩余部分 -

我这个博客就是用Typecho搭建的。刚才把var改为了core，把usr改为了exts，。

这俩目录其实在第三篇分析文章里讲过，分别是Typecho的核心类，以及插件和主题的目录，那么既然是核心类，那就是core里；既然是插件和主题，那就是对这个核心类的改进和增强，便于开发者进行二次开发，所以就是扩展，exts。

其实这个exts里，还有隐藏的设置，包括语言包(langs)，备份（backups）和上传目录（uploads）。这些都是在改这个目录名的时候发现的隐藏设置，如果不看代码，是不知道的。这个对开发者是真的不太友好。

我会考虑增加一个vendors目录，把一些优秀的第三方库涵盖进来。

在鑫鑫小店这个项目里，我走得更远，更激进，把core目录下的三个目录也改为lowercase了。然后，我发现了一个神奇的事，就是所有的class仍然可以正确加载。

Typecho的类加载机制是这样的，Typecho_Common::init这个函数，把所有的类名都做了处理，下划线（_）都被\替代了，就把className转换为php文件的路径了。我使用print_r函数把所有加载的className和转化之后的路径都打印出来过，都是首字母大写的，比如Typecho_Common，路径就是Typecho/Common.php。但仍然可以在typecho这个lowercase的目录里找得到这个Common.php文件。

但是，同样的事，如果在本博客的项目代码里做，就会报错。

所以到此为止，事情就变得非常因吹斯听了。

- 阅读剩余部分 -

这里讲一个非常细致的知识点，就是return和echo的区别。

为什么说这个知识点呢？因为在Widget_Options这个类里面，有7个函数，使用的是echo，而不是return。

一开始我还用echo来调试来着，想看看里面的某些变量的值，但发现总报错，然后就意识到，莫非echo会结束这个函数？查文档发现，仅仅说echo会以string的形式输出一些变量的值，而且echo并不是一个真正意义上的函数，因此不需要括号即可。

但echo是否会结束这个函数的执行，类似return呢？答案是肯定的。

再通过google发现，return是返回一个结果，你可以把这个结果储存在某个新的变量里，然后随后调用。这显然是废话。但echo，是直接返回一个结果，你没法把这个结果储存起来，算是一次性的吧。

这俩的区别用通俗的语言来解释就是，你问一个人一个问题，如果是return，你会从他这里拿到结果，然后自行处理，比如保密，比如转告别人，等等，都可以。但echo就是，你问了一个问题，这个人立刻把结果告诉所有人，就不需要你这个中间人了。

总之，用echo肯定不是一个好的practice，因此我把这个Widget_Options里的所有echo都换成return了。

好，这个更改，带来的副作用就是大量的报错，因为在admin和theme里，有大量的地方直接用到某个option，所以我还要在这些页面里添加echo，当然最好是用<?= ?>这样的shortcut。

逐个文件搜索，改动，工作量大的一笔。

两个大事，但其实影响很小：

一、在install.php里，有这样一段代码：

/** 设置包含路径 */
@set_include_path(get_include_path() . PATH_SEPARATOR .
__TYPECHO_ROOT_DIR__ . '/var' . PATH_SEPARATOR .
__TYPECHO_ROOT_DIR__ . __TYPECHO_PLUGIN_DIR__);

其实前几篇源码分析文章有讲过，这个代码是用于一个查找所有类所在的位置的。其实这里的/var是非常让人困惑的，这本来是Unix-Like和Linux里的目录，猛一看真的不知道是什么。

所以我就改名了，改成了Core，这个就很好解释了。这个目录是整个程序的核心代码。

其实还有一个目录，usr，这也是Unix-Like和Linux里的目录，光看名字也不知道是什么。但其实就是插件plugin和主题theme所处的目录。所以我也准备改名，但具体没想好，目前倾向于使用Exts，意为Extensions，意为延伸,是对整个程序的增强和延伸。

这个改名的影响很小的原因是，只要能从预定义的路径里找得到某个class，就可以，整个程序不关心到底这个class的位置在哪里。所以也给了我重构的机会。

二、就是Typecho_Request这个class里，有一个函数，isSecure，来判断是否是HTTPS连接。但给了用户一个选择，可以在配置文件里自定义__TYPECHO_SECURE__为True。

我完全不理解为什么要做这样一个手动的配置选项，并且这还是一个隐藏的配置选项。
首先就是对开发者不友好，你不看代码是不知道这里还有个隐藏配置的。其次，似乎让用户自定义是否是HTTS连接也不是一个好选择，完全理解不了意义何在，毕竟有多种方式来判断。
所以我就去掉了这个配置。

为啥说这个影响也很小呢？因为这个isSecure函数还有很多项检验是否是HTTPS配置的判断，完全足够来判断是否在使用HTTPS。

上面这2条改动会出现在鑫鑫小店和xinxinecho里。

本来想继续分析Widget_Archive的，但是呢，这个类太复杂了，里面内容太多太杂。而且我希望的是，读完一段之后，就可以进行一些重构。所以读了这个类的代码后，暂时放一放，继续研究install.php。

我其实一直好奇config.inc.php这个文件的来路，到底是怎么来的，但后来发现，你在install.php里搜索file_put_contents这个函数，其实会发现，就是把这个install.php文件的第1到31行代码了写入到这个新文件，然后把数据库连接配置也写入进去了。具体可以在这个安装文件里搜索初始化配置文件。如果如果要改造config.inc.php，比如写入更多的配置，可以改造第1到31行，并且修改下面的行数。

其实更重要的是，应该把这些代码都放到配置文件里， 并且在install.php里引入，然后再把数据库配置文件写入到新的配置里，比如config.db.php里。我会在鑫鑫小店里这么做。

上回说到index.php这个文件里，会初始化组件，就是Widget。然后分析了这个Widget干了些什么。接下来，其实还有三行，但这三行，是初始化插件和路由器的。

但是呢，暂时先不钻到这个黑洞里去了，因为这个事太复杂， 不如先看看theme，这个比较简单。而且更进一步了解Widget是干什么的。

好， 主题在哪里？在/usr这个目录下，有2个目录，plugins和themes。Typecho自带一个default主题，就是/usr/thems/default这个目录。

在默认主题里，显然是首先看index.php，注意，完整路径是/usr/thems/default/index.php。这个文件里包含了一些其他文件，header.php，footer.php和sidebar.php。注意看这个用的是这也一个函数<?php $this->need('header.php')。

那么问题来了，这个关键字$this是啥？

如果你有基本的面向对象的知识的话，就会知道，这个$this是某个对象（object），是哪个对象呢？

- 阅读剩余部分 -