在网络环境日益复杂的今天,就连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文件。

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

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

- 阅读剩余部分 -

这里讲一个非常细致的知识点,就是returnecho的区别。

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

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

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

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

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

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

好,这个更改,带来的副作用就是大量的报错,因为在admintheme里,有大量的地方直接用到某个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个目录,pluginsthemesTypecho自带一个default主题,就是/usr/thems/default这个目录。

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

那么问题来了,这个关键字$this是啥?

如果你有基本的面向对象的知识的话,就会知道,这个$this是某个对象(object),是哪个对象呢?

- 阅读剩余部分 -