创意的实践是有代价的
代价就是Debug.
在弄完积分系统和排行榜系统之后，我又在网站首页（PC端）增加了视频播放的功能。
很好，现在能加的都加上了，就在PC端和移动端看下效果⑧
看起来没有问题的说
但是一拿到实体机上各种奇葩的问题就出现了
我拿手机看了一下，确实存在一大堆问题。原因不是没能适配Android，而是各种环境因素的干扰。
为此，我采取了另一种思维方式：对电脑端和移动端分别使用不同的主题，其中移动端的主题要能很好的适应各种环境。
很巧的是，WordPress是PHP语言编写的，并且内置了一个函数wp_is_mobile()
wordpress函数
wp_is_mobile()是wordpress 3.4.0版本增加的一个内置函数，wp_is_mobile()函数的作用是检测当前浏览器是否运行在智能手机、平板电脑等移动设备上，返回一个布尔值。目前wp_is_mobile()函数支持Iphone、ipad、android、silk、kindle、BlackBerry、Opera Mini等众多移动设备及浏览器，使用该函数可以帮助开发者更好地制作响应式wordpress主题、独立手机主题或者各类型手机相关的插件。
从源代码可以看出，其包含了几乎市面上所有的移动终端。BlackBerry也在其列。但不得不提的是，就在今天，TCL已经宣布不再销售黑莓品牌的手机。
近期，Blackberry Mobile Twitter帐户宣布了一则信息，从2020年8月31日起，TCL通信将不再销售黑莓品牌手机。
早在2016年12月，TCL宣布已获得创建和销售BlackBerry品牌智能手机的权利。之后并陆续推出了BlackBerry KEYone，Motion，KEY2和KEY2 LE等手机的发布。KEY手机极具特色，在全面屏时代采用物理键盘的BlackBerry黑莓设计。但面对竞争日益激烈的行业环境，BlackBerry近年的手机并未在市场中获得太多反响。可能也正是出于这样的原因，TCL现在决定将会于今年8月正式终止与BlackBerry的合作。
回到我们的话题。为了实现对不同平台间主题的切换，我写了一个小小的插件。但是就这几行代码就耗费了我很多时间。
目前还没有传到GayHub上，因为不清楚有没有人做过这个。并且更重要的是没做前台设置的界面，所以要开源还是要一段时间的修改与完善。
手机端主题的选择也耗费了我许多时间，并且奇怪的是，有些主题在电脑端和手机端都使用同一主题时，移动端的CSS还可以正常加载，但一旦将PC端主题换回 Sakura就又会出现蓝字白底（未能正常加载层叠样式表）的问题。
最后，我选择了Personal22这个主题。正和 Sakura的二次元主题相反，他是极简风格的主题，对于移动端十分友好。并且已经投入使用。
前端的问题都解决了，但是后端总有一两个报错让人闹心。就譬如说这样：
本来好好的后台被这一行报错给毁了
但是我上文说过，WordPress是PHP语言编写的，所以我们可以将ini_set("display_errors",0);这行代码加入到wp-config文件中。这里简要做一些介绍：
引用自 https://www.php.net/manual/zh/function.error-reporting.php
error_reporting
(PHP 4, PHP 5, PHP 7)
error_reporting — 设置应该报告何种 PHP 错误
说明
$level
] ) : int
error_reporting() 函数能够在运行时设置 error_reporting 指令。
PHP 有诸多错误级别，使用该函数可以设置在脚本运行时的级别。
如果没有设置可选参数 level，
error_reporting() 仅会返回当前的错误报告级别。
参数
-
level -
新的 error_reporting 级别。 可以是一个位掩码也可以是一个已命名的常量。 强烈建议使用已命名的常量，以确保兼容将来的版本。 由于错误级别的添加、整数取值范围的增加， 较久的基于整数的错误级别不会总是和预期的表现一致。
可用的错误级别常量及其实际含义描述在了 predefined constants 中。
返回值
返回旧的 error_reporting 级别，或者在 level 参数未给出时返回当前的级别。
更新日志
| 版本 | 说明 |
|---|---|
| 5.4.0 | E_STRICT 成为 E_ALL 的一部分 |
| 5.3.0 | 引入 E_DEPRECATED 和 E_USER_DEPRECATED。 |
| 5.2.0 | 引入 E_RECOVERABLE_ERROR。 |
| 5.0.0 | 引入 E_STRICT (但不包括在 E_ALL 之内)。 |
范例
Example #1 error_reporting() 范例
<?php
// 关闭所有PHP错误报告
error_reporting(0);
// Report simple running errors
error_reporting(E_ERROR | E_WARNING | E_PARSE);
// 报告 E_NOTICE也挺好 (报告未初始化的变量
// 或者捕获变量名的错误拼写)
error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE);
// 除了 E_NOTICE，报告其他所有错误
error_reporting(E_ALL ^ E_NOTICE);
// 报告所有 PHP 错误 (参见 changelog)
error_reporting(E_ALL);
// 报告所有 PHP 错误
error_reporting(-1);
// 和 error_reporting(E_ALL); 一样
ini_set('error_reporting', E_ALL);
?>
注释
虽然 error_reporting 增强了
包含 E_STRICT 错误的能力（反之亦然），但大多数
E_STRICT 的错误是在编译时被评估的，
所以不会在文件中被报告。
传入 -1 的值将尽可能显示所有错误，
甚至包括将来 PHP 可能加入的新的错误级别和常量。
至 PHP 5.4，常量 E_ALL 有同样的行为。
OK，知道解决办法之后再将其扔入文件里，大功告成。
至此，最近的问题都解决了。我们有时从错误中学到的东西，可能比从美德中学到的还要多。所以以后再遇到问题时，应该放缓自己的心态，虽然对于我来说很难。因为Coder在遇到BUG时心路历程绝大多数应该是这样的：
- 我X,哪个傻X动我代码了？！
- $ git log
- commit XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (HEAD -> master, origin/master, origin/HEAD)
- Author: 我自己 <woziji@monianhello.com>
- Date: 就刚才 +0000
- 哦，是我这个傻X啊...
Comments | NOTHING