这是一个创建于 3912 天前的主题，其中的信息可能已经有所发展或是发生改变。
起因是一个 Wordpress 站点前端的 bug。
三个 span4 在一行 row 里面，第二第三列会比第一列略低一点。于是开始折腾。
LZ的技能树是前端了解最基本HTML/CSS/JS等，差不多10/100；后端了解最基本的PHP/Rails等，差不多10/100。基本上只能看看和改改，写是写不了的。
1. 0-15分钟
认为是字体的问题，以前遇到过字体导致一个span移到下一行，这时还没细看html源码，认为每个 span4 里的结构肯定是一样的，看了下每个块的字体，没有什么特殊的啊。
2. 15-30分钟
开始F12细看html源码，发现有某些行多了一个空的<p></p>对，其中还有一行注释<!-- ./span4 -->，因为其格式的原因，导致第二第三列低于第一列一丁点儿。这时认为是主题模板渲染的问题，开始看模板代码。
3. 30分钟-1小时30分钟
初步查看主题帮助手册，了解其渲染模板的构成，有几类Block，几类Module，每个Block由不同的Module组成（http://forum.tagdiv.com/modules-and-blocks/），然后浏览对应的Block和Module的php文件，这里不得不吐槽一下php直接写的代码耦合程度不是盖的，重复度也不是盖的，臃肿度也不是盖的，怪不得要MVC框架，要Rails。浏览了主题的php文件（几乎所有）后感觉php的技能树有所提升15/100了。可惜仍然没有找到那个该死的<p><!-- ./span4 --></p>的任何踪迹，代码虽然复杂了点但是这个Block的这个Module没有渲染额外的东西啊。
4. 1小时30分钟-2小时
还是不信邪，继续看源代码，死活找不出错误，开始认为问题不出在主题模板里。这时已是凌晨一点，熬不住了，睡觉。
5. 2小时-3小时
今天早晨起床继续折腾，既然不是后端模板问题，应该是主题设置的问题，查阅和测试了几乎所有主题设置选项，没有找到可能产生影响的选项。
6. 3小时-3小时30分钟
莫非是Home页可视化编辑器的问题？哪里的设置改错了？这是我目前觉得最靠谱的原因，再次试验，无果。
7. 清明游-吃中饭-清明游-吃晚饭
8. 3小时30分钟-4小时
晚上回来重新在VPS见了个全新的对照组（其实早该这么做的），用原始主题和原始demo data导入，发现居然没有这个问题！
9. 4小时-4小时30分
因为每个修改过的原主题文件都做了备份（functions.php style.css等），所以每个单独尝试还原，无果。
10. 4小时30分-5小时
怀疑“七牛云存储插件”导致测试无法正常进行，关闭之。再测试，没有出现问题！我突然意识到这也许是这个插件引入的问题。继续测试2x2组合成4种情况，发现果然是这个插件导致的。
11. 5小时-5小时30分
暗骂一句，实在受不了折腾了，果断删了这个插件和现有七牛空间，重新建立七牛空间并换成了WP Super Cache插件。目前没有问题。
总结：
1. 其实到最后我也不知道哪里（插件的哪行代码，云缓存或其他）有问题。不过我解决了。
2. 一开始就应该采取对照组的方法，可以迅速排除“主题模板有问题”这个猜想。节省时间。
3. 不要死盯着bug，要多休息。
4. bug永远存在。
5. 不是工业级的产品还是不要追根溯源已经“绕过”的bug了，珍爱自己的生命。
6. 工业级产品还是要死磕所有细微的bug的，珍爱他人的生命。
请注意：您不必点击下面网址。
网址： http://www.eleconomy.com/ 业余，较水，较卡，logo用inkspace零基础花3h做的，主题有钱再买，先赊着。后期准备迁Drupal 8，等待中。
三个 span4 在一行 row 里面，第二第三列会比第一列略低一点。于是开始折腾。
LZ的技能树是前端了解最基本HTML/CSS/JS等，差不多10/100；后端了解最基本的PHP/Rails等，差不多10/100。基本上只能看看和改改，写是写不了的。
1. 0-15分钟
认为是字体的问题，以前遇到过字体导致一个span移到下一行，这时还没细看html源码，认为每个 span4 里的结构肯定是一样的，看了下每个块的字体，没有什么特殊的啊。
2. 15-30分钟
开始F12细看html源码，发现有某些行多了一个空的<p></p>对，其中还有一行注释<!-- ./span4 -->，因为其格式的原因，导致第二第三列低于第一列一丁点儿。这时认为是主题模板渲染的问题，开始看模板代码。
3. 30分钟-1小时30分钟
初步查看主题帮助手册，了解其渲染模板的构成，有几类Block，几类Module，每个Block由不同的Module组成（http://forum.tagdiv.com/modules-and-blocks/），然后浏览对应的Block和Module的php文件，这里不得不吐槽一下php直接写的代码耦合程度不是盖的，重复度也不是盖的，臃肿度也不是盖的，怪不得要MVC框架，要Rails。浏览了主题的php文件（几乎所有）后感觉php的技能树有所提升15/100了。可惜仍然没有找到那个该死的<p><!-- ./span4 --></p>的任何踪迹，代码虽然复杂了点但是这个Block的这个Module没有渲染额外的东西啊。
4. 1小时30分钟-2小时
还是不信邪，继续看源代码，死活找不出错误，开始认为问题不出在主题模板里。这时已是凌晨一点，熬不住了，睡觉。
5. 2小时-3小时
今天早晨起床继续折腾，既然不是后端模板问题，应该是主题设置的问题，查阅和测试了几乎所有主题设置选项，没有找到可能产生影响的选项。
6. 3小时-3小时30分钟
莫非是Home页可视化编辑器的问题？哪里的设置改错了？这是我目前觉得最靠谱的原因，再次试验，无果。
7. 清明游-吃中饭-清明游-吃晚饭
8. 3小时30分钟-4小时
晚上回来重新在VPS见了个全新的对照组（其实早该这么做的），用原始主题和原始demo data导入，发现居然没有这个问题！
9. 4小时-4小时30分
因为每个修改过的原主题文件都做了备份（functions.php style.css等），所以每个单独尝试还原，无果。
10. 4小时30分-5小时
怀疑“七牛云存储插件”导致测试无法正常进行，关闭之。再测试，没有出现问题！我突然意识到这也许是这个插件引入的问题。继续测试2x2组合成4种情况，发现果然是这个插件导致的。
11. 5小时-5小时30分
暗骂一句，实在受不了折腾了，果断删了这个插件和现有七牛空间，重新建立七牛空间并换成了WP Super Cache插件。目前没有问题。
总结：
1. 其实到最后我也不知道哪里（插件的哪行代码，云缓存或其他）有问题。不过我解决了。
2. 一开始就应该采取对照组的方法，可以迅速排除“主题模板有问题”这个猜想。节省时间。
3. 不要死盯着bug，要多休息。
4. bug永远存在。
5. 不是工业级的产品还是不要追根溯源已经“绕过”的bug了，珍爱自己的生命。
6. 工业级产品还是要死磕所有细微的bug的，珍爱他人的生命。
请注意：您不必点击下面网址。
网址： http://www.eleconomy.com/ 业余，较水，较卡，logo用inkspace零基础花3h做的，主题有钱再买，先赊着。后期准备迁Drupal 8，等待中。
 |
1
Lax 2014-04-06 09:47:11 +08:00 via Android
到图书馆找本入门的CSS书，从基础学一下CSS。一天学习受用终身。
基本的CSS知识配合浏览器自带工具，几分钟就能看到原因了。 |
 |
2
belin520 2014-04-06 12:57:06 +08:00
看到如此高端有深度的标题
还以为说在内核级别的开发中遇到无法预知原因的bug而发出的感叹！ |
 |
3
dorentus 2014-04-06 19:20:07 +08:00 via iPhone
不是。
需要绕过的也一般是知道原因但是暂时不好改才绕的。 |
Select Language