要在博客主题里优雅的呈现图像，是一件繁琐的事情，这货，除了类型多，特么的尺寸也多，浏览器也会对其做跨域限制，还有，像是约定好的一般，主流浏览器都不支持渲染显示 TIFF 图像，等等。如果只是满足个人需求，倒是相对简单了，不需要操这份心，比如，发布图像前，我会在调片后一并添加水印，统一输出尺寸和体积都合适的 Jpg 格式文件，也会移除 Exif 数据。这些前期准备，自然免去了在博客主题中通过代码处理图像的操作。但是，博客主题是要面向不同的用户，大家对图像有着因人而异的需求，那么，在制作博客主题时，势必要把各种使用习惯都考虑周到。最重要的要以「最低环境要求」为基线，降低门槛，确保博客主题即使在低配条件下也能稳定运行。比如，图像处理器 ImageMagick 相比 GD 库更为强大，但是，大多数用户的初始环境默认只用 GD 库；又比如，现代浏览器已经支持图像的一些新特性（如 loading="lazy" 等），但是，新特性或多或少对旧版浏览器不太友好，存在兼容问题；再比如，少部分用户通过对象存储可以方便的生成同一图像的不同尺寸链接，但是，更多用户是以博客的附件形式上传图像，只能生成一条原始图像链接，等等。这也是在重制 Snapic Plus v6 的过程中，最为烧脑的部分，需要顾及可能的边界情况。现在 SP.v6 完成了对图像较为理想的处理和测试，至少达到了预期想要的：图像链接众所周知，图像的类型不胜枚举，在以前的 Snapic Plus 主题中，使用严格的正则匹配图像的扩展名，以此初略的判断是否是图像链接，这会出现遗漏，也会导致一些通过对象存储生成的带参数的图像链接无法被匹配，尤其是那些经过编码没有扩展名的图像链接。在 SP.v6 中，使用了与 Typecho 解析 Markdown 一致的方法，修正了这一问题。图像加载延迟加载，可以说是显示图像必不可少的标配功能，在现代浏览器中，虽然可以使用一些原生属性实现图像的延迟加载，但是，会有局限性，比如，之前提到的 loading="lazy" 属性，在我使用的旧版 Chrome 浏览器中，就是摆设，加之尚不能自定义加载阈值，在当下，这一属性还是很鸡肋；又比如，图像的尺寸并非越大越清晰，使用 srcset 和 sizes 属性可以根据显示设备的像素比和视口宽度，来选择对应尺寸的图像源，以呈现高清晰度的图像，但是，如上所说，还得靠对象存储生成同一图像的不同尺寸链接；再比如，图像除了 img 标签外，各大搜索引擎更推荐使用 figure 包裹 img 和 figcaption 用以关联图像和描述，让搜索引擎晓得这张图像是个啥，但是，Typecho 在解析图像链接时，是硬编码为 img 格式输出，虽然也可以在后期重构格式。在 SP.v6 中，使用了兼容性更好的方式实现图像的延迟加载，也基于「最低环境要求」为前提，保持传统的单一图源，毕竟不是所有用户都能使用对象存储，或许等到这些服务低至白菜价了，再给博客主题做调整。此外，也会对加载完成的图像做渐现处理，以避免突然的惊悚显示。图像跨域这是被反馈最多的，其实，和博客主题压根没有任何关系，这是浏览器的安全机制，限制非同源资源进行交互，不仅是图像，其他诸如音视频等文件同样会被限制。如果图像有跨域问题，虽然可以正常显示，但是，在分享海报时，图像无法绘制到画布，在读取数据时，无法获取图像元数据。在 SP.v6 中，对图像做了信息反馈，可以根据提示了解图像的状态，比如：是否加载完成、是否可以下载、是否存在跨域等，以方便快速排查和正确配置图像资源。图像数据这里特指图像的 Exif 数据，想必是每位爱好摄影的用户都会关注的。个人觉得嘛，图像 Exif 数据对于提升拍照技术，没有半毛钱帮助，毕竟大多数放出来的摄影作品，无一不后期，所有通过相机物理功能得到的效果，在 Ps/Lr 中都能够真实复刻，图像 Exif 的意义，只是显得这张图像有这么一丢丢专业，仅此而已，多的没有，如果非得肯定它的价值，顶多也就是 GPS 数据。刚好，在 SP.v6 中，我把图像 GPS 数据应用到了地图服务中，可以在 GoogleMap 和 OpenStreetMap 以及高德、腾讯、百度地图中查看拍摄位置。处理图像的 GPS 数据，也是一个讨人嫌的过程。某些原因，国内的坐标系统会在国际的坐标系统的基础上进行加密，衍生出了国测局坐标系统，百度更是奇葩，在国测局坐标系统的基础上，又搞出了自家的二次加密坐标系统。如果把图像的 GPS 数据应用到国内的地图中，会产生严重的漂移，需要做纠偏处理。 回到正题，图像的 Exif 数据以二进制的方式存储在 jpg jpeg webp tiff 类型的文件中。在后端，可以通过 PHP 的 EXIF 扩展获取，在前端，可以通过第三方库获取，两种方式各有优缺点，需要组合运用，目前没有看到一劳永逸的方案。比如，后端 PHP 的 EXIF 扩展还无法直接读取 WebP 图像的 Exif 数据，也仅限获取少数知名厂牌设备的专属元数据（如：镜头信息）；又比如，前端老牌 exif.js 库无法读取 WebP 图像的 Exif 数据，也无法读取镜头信息（自己手搓添加标签后，可以）；再比如，读取图像的 Exif 数据，前后端都需要下载完整的图像资源，那么，就说到痛点了，如果把一张不经过压制的十几兆大小的图像扔进博客里，还开启了显示 Exif 数据，这等同于给服务器和浏览器做压力测试，不崩才怪。在 SP.v6 中，使用前后端搭配，在适当的时机按需获取图像 Exif 数据，有效的解决了可能出现的性能问题。图像布局瀑布流 masonry 是当前最接近完美的展示尺寸杂乱的多张图像的布局，具有等宽不等高，全显不裁图的优势，但是，不是单单引入 masonry.js 就能自称使用了瀑布流布局。鉴于 masonry 的运作机制，和图像延迟加载一起使用时，简直是悲催二人组，会陷入依赖困境：布局需要数据，数据需要加载，加载需要布局。这就好比「先有鸡还是先有蛋」的矛盾，如果没有妥善处理，会出现布局抖动，典型的现象是：瀑布流元素满天飞，当你浏览这张图像时，冷不丁被挤出了视口，当你要点击这张图像时，又冷不丁被弹到了别处，等等。对于图像较大，或网络不畅的场景，这个现象更为突出。在 SP.v6 中，沿用了 v5 版的思路，当然，也对 v5 版的这一实验性功能做了全新编写，同时，也会基于「最低环境要求」为前提，即使不使用 aspect-ratio 新特性，也能有效的解决瀑布流布局的以上通病。另外，瀑布流元素的封面需要缩略图加持，才能让低带宽的图像也能流畅的加载。在 SP.v6 中，分离了 v5 版的生成缩略图功能，改进为使用独立的面板操控，支持设置缩略图宽度、画质，支持一次性批量处理，支持自动断点连接，等等，有效的降低了服务器处理图像的压力。当然，如果自有对象存储生成的缩略图参数，也可以自定义使用之。在图像布局方面，SP.v6 还支持任意文章选择使用轮播布局、翻屏布局、等高布局来展示图像，不再仅限于独立页使用。还可以通过内容模块，实现比图和热区功能：比图，即在同一容器中，通过滑块对比两张图像。使用场景：调片前后图对比，建模渲染图对比，城建卫星图对比，等等。 热区，即在底层图像上标记热区，当触发某个标记点的 hover 时，显示该标记点的图像和描述。使用场景：电商可购物热点，徒步路线兴趣点，等等。 图像灯箱个人认为，灯箱的作用在于，可以清除无关元素，让浏览者专注于图像本身。毫不夸张的说，所有图像灯箱系统都可以做到，它生来就为这事，但是，当这些灯箱系统需要在同一个灯箱中处理多图，同时又可以使用缩略图进行索引时，那就不尽相同，有的怕是一言难尽了。在 v5 版中，经过比对、筛选多款图像灯箱系统后，选择了 MIT 开源的 PhotoSwipe 项目，自己再往里新增一些功能后，也够用，但是，后来发现（也是事先没有预料到的），当面对几十上百张为一组的组图时，这个 PhotoSwipe 会力不从心。和 PhotoSwipe 相似，大多数灯箱系统，在展示组图时，普遍需要预知分组后的全部图像，当组图中的图像数量又很多时，会使得 DOM 节点数量庞大，影响页面渲染而变得卡顿。在 SP.v6 中，针对这些状况一一作了修正，不仅替换 PhotoSwipe 改用 Glightbox 灯箱系统，也将组图中的图像，按需获取，开灯箱，则加载，关灯箱，则销毁，有效解决了 v5 版的性能问题。和 PhotoSwipe 相似，灯箱 Glightbox 不仅 MIT 开源，也很轻量化，甚至极简到了需要爆肝来新增以下：1. 指示器，显示当前图像序位； 2. 拍摄设备，提示当前图像有 Exif 数据，并可以看详情； 3. 缩略导览，使用缩略图，不使用原始图，避免性能开销； 4. 下载，一键保存图像，有信息反馈； 5. 滚轮翻图，使用鼠标滚轮左右翻图； 6. 等等 那么，为什么不使用 Fancybox 灯箱系统，也是不少用户建议的，我都会回复，早期的 Fancybox 是免费开源的，新版 v4+ 采用了新的商业许可，需要付费许可使用。可想，假若哪天国内有公司代理了该项目，被法务部致函是妥妥的事，别不信，当年的某款软件已经干过这事，俗称「隔空点穴」不劳烦境外作者亲自动手。数据查询不局限于图像，涉及从数据库获取数据的也会适用。这也是之前在制作主题、模板、插件时，都被忽视的，主要原因还是受限于知识面。Typecho 使用 get() 方法连接数据库，本身对数据库对象做了静态缓存处理，而在查询数据时，返回的是即时的数据，那么，如果博客主题在 foreach 等等操作中，调用了查询数据的逻辑，会频繁查询数据库，然而，这个数据其实是同一个数据。在 SP.v6 中，对涉及从数据库获取数据，或是从缓存文件获取数据，等等情况，均使用了静态缓存的方式，在同一个请求中，除了首次计算外，其余从缓存调取数据，有效提升了性能。主题 Snapic Plus v6 当前进度 92% ...
完成了 Snapic Plus v6 功能方面的制作，只沿用了 v5 版不到 1% 的代码，其他的都做了重构。接下来是没有难度，但相当繁琐的写样式和写文档，还有著作权登记。v6 版的功能围绕 Lopwon 个人爱好展开，着重呈现图像作品。包含 v5 版大部分功能（个别已弃用），布局做了调整，功能做了新增，比如：通过旅行路线导览文章内容，等等。尤其是对数据的获取，由 v5 版的一次性获取，使用前端隐藏，变更为按需获取，有效避免了页面加载时的阻塞。主题 Snapic Plus v6 在金属音乐和炭烧咖啡的作用下进行重制，当前进度 90% ...
有边做事边听歌的习惯，期望国内常用的音乐软件能够日推一些符合自己喜好的新歌。然而，自翻唱李鬼原唱，洗歌冒充原曲，抢占流量破坏音乐生态后，如今这些音乐软件变本加厉的又多出了不少奇葩乱象：只要听出付费感觉的免费歌曲，大概率会在近期被标记为试听。同一首曲目会在接下来的日子里反复推送，不胜其烦，不得不怀疑资源库已濒临枯竭。装洋气的国内歌手层出不穷，虽然取着字母名称（甚至称不上是英文名称），唱着英文歌词，使用外文介绍，但是他们似乎没有意识到，他们的唱腔中普遍夹杂着中文唱法，还有，即便是一级英语水平的我，也能听出的一口臭青的英文发音，就如欧美歌手用中文演唱一般，带着强烈的违和感，使人难受。最反感的是，即使屏蔽这类歌手，也会在往后的日推中不断复现，好似无法冲入下水道的蟑螂那般让人厌恶。嗯，估计是支付了推广费用。因此想起了二十多年前带着 CD 随身听走街串巷淘打口碟听歌的日子，纯粹。
近段在重制 Snapic Plus v6 的过程中，一些功能的必要性，总得花点时间反复权衡、审慎考量，也为此参阅了国外大量的摄影创作者和视觉设计师的个人站点，欲寻求共性以此形成定夺功能有无的标准。我希望使用者可以借助 Snapic Plus v6 优雅的展示他们的摄影、设计、绘画等图像作品，不想让胡里花哨的功能扰乱了这一初衷。在浏览这些个站时，也在思考自己当下这博客，为何而写，确切的，为何拍摄？嗯，当初不正是只想在日常通过拍摄，迫使自己慢下来观察周遭事物，用文字记录所感，借由图志留存那一刻的生活片段，在日后翻阅时，梳理思维，精神自治么！既然写博客的动机与目的从未指向为他者而写，更不是为搜索引擎而写，那么是该回归初始的状态了。对于自己来说，只需要一个能够随时随地舒适撰写图志的页面，把内容生成 md 文件，由后端解析 Markdown 格式的同时，渲染生成 html 文件，提供前端访问，就足够了。在向 AI 咨询这个方案的可行性时，竟也发现与主流的静态博客系统有着几分相似的流程，靠谱。
在那个使用调制解调器拨号上网，把 8MB 容量的 U 盘挂在胸前炫耀的年代，曾经盛行着「免费空间 + 免费二级域名」的服务，这些免费的组合，推动了初代网民在网络建设网上家园的热情。虽然已过二十多年，依然清晰记得自己在 [#Lycos] 提供的 20M 带广告的免费空间里，安装 [#vBulletin] 免费的社区程序，通过 [#Yeah] 提供的免费二级域名访问，搭建了班级论坛。印象最深刻的是，在胡乱折腾后，竟也是完美的屏蔽了免费空间自带的右侧栏广告。 和现在一样，在个站互换链接也是当时必不可少的操作，并且还带有如今看来更具独特个性的 88×31 像素站标。这些小小的图标，不仅是点击后打开对方个人主页的链接，更是精心制作的，在风格上承载站长思想的视觉符号。时至今日，添加友情链接的初衷似乎没有本质的改变，在相互认可时，在观点共鸣时，都可以触发交换链接的行为，反倒是当前多了以做外链为目的的动机。对于做外链，个人认为，一种，无非是为了增加权重，提升在搜索引擎的曝光量，然而在当下，搜索引擎已不再是流量的唯一入口，更何况整个网络的页面索引量相较于当年，那可是天文单位级别的增长，以此方式得到的入站效果是肉眼可见的不尽如人意。另一种，无非是在流量可观的的入口，展示自己的链接，比如联盟、聚合等导航类站点，然而在当下，目标群体是否还会主动打开这些导航类站点，在多如牛毛的链接里刚好不小心的点开你的链接？要知道，只能在类似 DMOZ 人工编辑的站点目录中找到兴趣信息的时代，已经过了。回想当初也是随大流的在某联盟提交自己的链接，甚是觉得好笑，可想而知，得到的结果并不是对等的，在我这，他是 100% 的曝光量，在他那，我是 0.01% 的曝光量。十年过，从他那过来的点击量仅为八千不足。只是出于对等原则，保留了对方的链接没有撤下。这是唯一一次向导航类站点提交链接，其他的，也就偶尔看到对方添加了，自己握手性的挂上。 对于导航站，在浏览此类站点时，虽然会有一种探索的自主感，和意外发现宝藏的乐趣。但是，在点开链接期待即将看到不确定的惊喜时，往往呈现的内容质量，甚至还不如个站站长友链栏里推荐的。毕竟个站站长在互链时，除了遵循着相互认可、观点共鸣的初衷，也会经常维护这些链接。而导航站嘛，大部分由个人或少数人打理，面对数量不少，跳转可变的链接，就显得力不从心了，必然导致了各种问题链接的存在。那么，不妨思考下，在算法主导的时代，不要去做中心化的站点聚合，你要做的，准确的说，让算法去分析不同站点的内容特征，作为标识，当然需要避免人为干预，让数据可靠可信。在互联网中，携带标识的站点（A），会被推送到订阅某个标识的其他站点（B，C，D，……），这些站点可以决定是否展示站点（A），如果展示，则被展示的站点（A）会接收到提醒，同时，也可以决定是否展示对方的站点。同样的，任何一方撤下站点时，对方也会接收到提醒。诚然，方案尚显粗陋，倘若能启发到你，且有落地之日，还望不吝提及 Lopwon
在重制 Snapic Plus 过程中，需要把 JSON 字符串转换为数组，于是构建了以下函数： function jsonStringToArray($jsonString, $associative = true) { if (!is_string($jsonString) || empty(trim($jsonString))) { return $associative ? [] : null; } $decodedData = @json_decode($jsonString, $associative); if (json_last_error() === JSON_ERROR_NONE) { return $decodedData; } return $associative ? [] : null; } $data = '{"last_update_timestamp":"1760160739","total_media_count":576}'; jsonStringToArray($data); // 转为数组 jsonStringToArray($data, false); // 转为对象 事后细想，这是常用的功能，Typecho 或许有内置的，果然，在 var/Typecho/Common.php 文件里找到了： $data = '{"last_update_timestamp":"1760160739","total_media_count":576}'; Json::decode($data); // 转为对象 Json::decode($data, true); // 转为数组 这样的现象还挺普遍，由于官方提供的使用文档略显粗犷，主题、插件的开发者们常常会忽略这些自带的方法、组件等，这么一来，无形中增加了制作的时间开销，也存在升级新版 Typecho 时，主题、插件代码失效报错的情况，比如（这里）提及的偏方。此外，不少主题会使用诸如以下的标记方式对文章内容进行替换，以输出自定义的丰富版式，但是，由于官方似乎没有制定统一的开发规范，导致不同开发者使用了不同风格去实现相似的渲染结果，致使在切换主题时，无法正确兼容适配。 [photos][/photos] // 开发者 A [fotos][/fotos] // 开发者 B
昆明草海东风坝开合浮桥试通行期间，人们在浮桥上等候连通处闭合，这座浮桥的建成，连接了草海东西两岸。
十年前的今天，在灭了最后一支香烟后，就再也没有点燃过香烟，甚至是没再触碰过香烟。戒烟，并不为吸烟有害健康，而是听从母亲的忠告，履行诺言！吸烟于我来说，不是耍酷，不是社交，而是当香烟、咖啡、音乐杂糅在一起时，能够在合法的界线内，把自己置身于一种亢奋的状态之中，保持思维活跃。即使吸烟时期，也不会有烟瘾，一周顶多两包，希尔顿和 555 是常买的，万宝路太冲容易犯咽炎，偶尔会买。以上，可能也是能够轻易戒掉香烟的原因吧。
插件 Lopwon Comet 提示近期会有一颗高亮周期彗星 C/2025 A6 Lemmon 进入视野，于是，在 Stellarium 星空软件里，导入这颗彗星的数据，模拟查看彗星的轨迹位置，嗯，有盼头。在11月08日过近日点之前的一周内，日落后月升前，彗星在西落状态时，位于天蝎座和银河带附近的地平高度 30 度左右的西边天空。意味着会有一个小时的观测拍摄窗口，如果彗星没有解体消失，如果彗星突然爆发增亮，那么，大概率可以拍摄到带地景带银河的彗星美照，当然，如果有硬件加持的话。[cid-3824] [cid-3819] [cid-1545] [cid-429] [cid-3799] [cid-3820]
正在重制 Snapic Plus 相册主题，和重制 Snapic Paper 图志主题的方式相似，也是从空白页面开始码代码，运用个人知识面内最优策略从新实现所需功能，会把精力放在性能优化上：比如，分离非依赖组件，让用户通过插件选择性操作；比如，按需获取数据，避免一次性加载带来的阻塞；比如，移除所有第三方 API 接口，避免服务商吃相难看时的被动付费使用；比如，解决 v5 版中相当混乱的 JavaScript 带来的兼容问题，等等。当然，也会添加一些新功能，比如，被不少用户提到的「无限加载」。其实，自己很反感这个功能，因为你永远无法正常的查看页脚信息，总会被没完没了的无限加载的内容挤压到视口之外。那么折中，提供三种选择：滚动触发无限加载，点击触发无限加载，以及原有的按键翻页加载。平日里，除了喜爱拍照记事，比较在意视觉传达，也去关注影像美学，自认为多少了解：该如何优雅的展示图像，以及该给浏览者提供怎样的用户体验。但受限于某些前提（比如编写代码的能力等方面）之下，主题 Snapic Plus 不可能面面俱到，也有不尽如人意之处。所以，主题的每一次改进都有赖于各位使用者的反馈和协助，如果你的建议和意见被应用于 Snapic Plus 主题中，你的昵称将出现在贡献者名单里，以此鸣谢。希望 Snapic Plus 相册主题能够满足：呈现你所创作的摄影、设计、绘画等图像作品的需求。主题不会喧宾夺主的增加与图像无关、胡里花哨的功能，这也是 Snapic Plus 一直以来不曾改变的初衷。主题由来2015年 Lopwon 建立「照片故事」分享一些偶然间看到的、自认为不错的、其他人拍摄的照片。一年后，由于疏于管理和域名过长，最终停更废弃。直到2018年03月01日，重启为「断片」，并保持每周一更至今，也是 Snapic 相册主题的开始。最初的 Snapic 是款免费的主题，仅具有单一的图像瀑布流布局功能，当时称为 Snapic Free 主题。在往后不断迭代完善的过程中，发现耗费的时间也随之增加，于是才有了 Snapic Plus 付费版的主题。
完成了 Snapic Paper 主题的重制，这有别于升级，可以说等同于在空白页面一行行码代码，使用更优的方式实现旧版上的功能。毕竟随着知识面的扩展，解决问题的思路会相对清晰些，方案也会更高效些。主题 Snapic Paper 除了保留旧版的风格和沿用部分功能外，也加入了 Snapic Just 640px 的绝多数功能，当然也做了改进和优化。比如，在 Snapic Just 640px 主题里，文章章节的显示会受限于视口大小，而在 Snapic Paper 里，则通过滑窗唤出，在任何视口宽度下都可以启用。在以往制作主题时，通常会引入各种开源组件，减少时间开销。如：专题幻灯片、图片延迟加载、图片灯箱看图等等，而这些组件往往是不同作者贡献的项目，凑在一块多少会存在冲突的情况，也会有功能上的冗余。这样会导致主题带 bug 运行，虽然不是显性的，但在特定环境下会有可能暴露显现，这种现象在 Snapic Plus v5 相册主题尤为突出（也是计划在年内重制一版 Snapic Plus 主题的原因）。主题 Snapic Paper 除了图片灯箱看图、获取图片元数据、代码高亮外，其他前端功能完全由原生 JavaScript 编写，不依赖第三方库，有效避免了各种组件之间的兼容缺陷和代码冗余。主题 Snapic Paper 依然延续「没有多余页面元素，能够看到干净文本，专注于安静浏览博客日志」的初衷，还对版式做了较多的调整，比如，可收起可展开的侧栏；同时新增了不少功能，比如，添加标题前缀将各篇文章关联起来，相对于 Typecho 自带的相关文章 Related 组件更为精准；也迁入了已经下架停售的一些模板的功能，比如，日志 Snapic Logs 模板。目前正在给 Snapic Paper 做软件著作权登记1，预计十月发布，期间可以正常购买旧版使用，新版发布后可以免费升级。P.S. 已登记，已发布 如何申请软件著作权登记？ ↩
预料中的又倒下一批 Typecho 主题、模板、插件
前两天，网友「央」提醒 Typecho 发布了 1.3.0 rc 版，我下意识地深吸口气。果然，昨天对在售的主题/模板/插件，传入新版 Typecho 中运行，各种报错。一种情况是，自己在制作时，有些功能使用了偏方获取数据，出现兼容问题，如： foreach ($result as $value) { // 遍历文章数据 $result $value = Typecho_Widget::widget('Widget_Abstract_Contents')->filter($value); // 坊间偏方获取数据 $permalink = $value['permalink']; // 文章链接 } // 在查询文章表时，坊间流传以上方式获取文章链接，但在 Typecho 1.3.0 rc 版，报错且失效 // 解决方法，使用内置方法 widgetById 获取文章对象，通过匹配文章 cid 获取对应文章链接 foreach ($result as $value) { // 遍历文章数据 $result $lopwon = Helper::widgetById('Contents', $value['cid']); // 内置方法 widgetById 获取文章对象，详见 var/Utils/Helper.php 文件 $permalink = $lopwon->permalink; // 文章链接 } 另一种情况，实属无奈，发现 1.3.0 rc 对附件 attachment 描述 text 的数据存储，由原来的 PHP 序列化字符串，调整为现在的 JSON 字符串，这就让之前通过反序列化获取数据的方式，全都失效了。为了让两种数据类型都能兼顾，且在新旧版本的 Typecho 下都能正常运行，只好判断获取： foreach ($result as $value) { // 遍历文章数据 $result $textData = $value['text']; // 该值之前为 PHP 序列化字符串，现在为 JSON 字符串 $valueText = null; // 先尝试解析 JSON (Typecho 1.3.0 rc) $jsonData = json_decode($textData, true); if (json_last_error() === JSON_ERROR_NONE) { $valueText = $jsonData; } // 如果不是 JSON 再尝试反序列化 (Typecho 1.2.1) else { $unserializedData = @unserialize($textData); if ($unserializedData !== false) { $valueText = $unserializedData; } } // 如果解析失败，则跳过 if ($valueText === null) { continue; } // 其他 } 这两天，已对 Snapic Nojs / Snapic CMS / Snapic Just 640px 主题，以及 Snapic Page / Lopwon Link Ultra 单页模板，还有 Lopwon Hub 插件，做了 Typecho 1.3.0 rc 版的适配。P.S. 计划年内重制 Snapic Paper 和 Snapic Plus 主题。后记除了附件描述的数据存储方式做了改变外，发现 1.3.0 rc 对主题配置、插件配置的数据存储也做了同样的调整。另外，当主题配置函数 themeConfig() 表单 Text Textarea 等，第三个参数（即表单默认值）非 null 时，而在配置主题设置时，清空表单保存设置后，版本 1.3.0 rc 会使用该表单默认值填充表单，但是，数据库存储该表单的数据却是 null 值，只有再次点击保存设置后，数据库才会更新该表单的数据为具体的值，显然，这样的处理方式会带来困扰。换言之，表单中的值，与数据库中的值，在以上首次提交保存设置的情况下，不是同步的，即：看似表单有值，其实数据库无值的情况。
给 Typecho 博客添加申请友链、站点收藏等功能
把之前制作的模板 Lopwon Link 和 Lopwon Link Pro 整合成 Lopwon Link Ultra 独立页模板，也加入了 Lopwon Links 插件的一些功能，主要用于展示友情链接，管理站点网址，也可以浏览 RSS 聚合订阅内容，等等。购买过模板 Lopwon Link 或 Lopwon Link Pro 的用户，可以免费升级使用 Lopwon Link Ultra 模板（演示）。P.S. 受到不少社交平台评论区的「作者赞过」启发，最近，还折腾出了一款类似功能的 Lopwon Hub：Praised 插件。
给 Typecho 博客添加旅行足迹地图标记功能
其实，早几年制作的 Lopwon Footprint 插件已经实现如题功能，也一直作为博客的「我的足迹」展示。直到一周前，地图上毫无预警的出现鳞次栉比、赤焰灼目、颠覆认知的巨大水印。果然，使用第三方提供的免费 API 服务，特么的不靠谱。估计是稍早前，在重制 Lopwon IPLoc「IP 转属地」插件，对并发数进行优化测试的时候，频繁触到了 API 的 QPS 上限。么么！原本就少得可怜的配额全都归零。这明摆着是要人付款买流量包呐。幸好之前在制作 Lopwon Echarts「数据可视化」插件的过程中，无意瞥见 [#Echarts] 支持渲染 GeoJson 地图数据，刚好前段时间用这款开源图表库制作过 Lopwon LitCities「点亮城市」插件，练过手。于是乎，折腾不到 Lopwon Footprint 五分之一的制作时间，完成了 Lopwon Roming Solo 插件，优雅替换。插件 Lopwon Roming Solo 使用本地库和数据，无需依赖第三方 API 服务，交互友好，界面清爽……全页地图（见这），坐标定位（演示），文内地图（如下）：
前些年制作的 Lopwon Author 插件，其实已经实现过类似的功能，甚至更为全面些。只是，当时是为了熟悉 Typecho 的运作机制，才去捣鼓，在数据处理上难免拉胯。花了两天，使用相对理想的方法，在当前博客折腾了相似的功能，可以一目了然的呈现评论者在博客里的评论状况，省了去数据库检索的麻烦。与 Lopwon Author 插件不同，此方法通过新增路由，在前端按需查询匹配评论者的数据。输出诸如：该评论者的所有评论列表，以及对应的评论固定链接；该评论者的总评论数量；该评论者首评至今的时长，等等。功能演示博客内任意一篇文章页，点击评论者头像，可见。如何实现电邮 lopwon@qq.com 付费改造。
在挺长的一段时间里，我从事的是与视觉传达相关的工作，把个人思想通过兴趣点延伸开，争得不容易遇到的同温层群体的认同与共鸣。虽说不是主业，与前端设计也无关，但于我认为，将所累积的经验运用至具有相似特征的博客主题的页面制作中，也是相通的。这样的风格，或者说是性格的映射，同样也体现在我拍摄的照片中，以及听歌喜好里，甚至是生活中。这样的风格，也未必会得到周遭人们的欣赏，毕竟与大众的审美观没有交集。可能，这即是 lifestyle 吧，是时间积淀的养成，是附体于身的印记，更是一辈子的事情，也因此让我难以理解：为何要把博客整成信息密度堪比门户网站的样子。博客所记录的文字，所展示的图片，不应该是能让自己得以勉励，给观者在浏览时，提供停留和思索的时间与空间，从而受到启发，产生互动嘛？我曾在几天里打开了不下百来位建博时间有十来年的博客，这些博客，大部分依旧可以访问，大部分仍在持续更新，大部分关于工作生活，最重要的是，这些博客，大部分主题简洁清爽。这些博主们，几乎是从博客时代走过来的，促使他们仍在写博客的动力，不是因为博客那一键可更换的免费付费的胡里花哨的 Themes，而是他们能在日常中，感受到点滴，并写入博客。他们，不折腾博客主题。前些年制作的 Snapic Paper 主题，也是自己 lifestyle 的体现，在现在看来，它似乎还不够纯粹，于是，萌发了捣鼓主题 Snapic Just 640px 的念头。这可能是已知的首款使用无感翻页翻篇的 Typecho 主题，这个功能的灵感，最初源自几年前在制作 Snapic Visual 模板时的全屏画廊滚动翻页，当时在想：能否把类似的功能应用在 Typecho 的归档翻页和文章翻篇上呢？嗯，由于思路没搞通，就没再去践行，也就搁下了。所谓无感翻页翻篇，指的是：不使用传统点击的方式进行翻页和翻篇，而是在电脑端通过鼠标滚轮，在滚动条触顶触底时，实现跳转至翻页翻篇的页面，而在移动端，则是通过手势滑动，同时，应该具有阻尼效果，避免过于灵敏误触执行。当然，考虑到兼容性，也会保留点击翻页翻篇的功能，只不过将其隐藏，使用按需唤出显示。在制作 Snapic Just 640px 时，除了延续 Snapic Paper 「没有多余页面元素，能够看到干净文本，专注于安静浏览博客日志」的理念，还做了版式上的提炼，尽量不至于视觉难受，如：对容器间距，对内容行距、段距，对文本字号、字重、字色的和谐相融处理。主题 Snapic Just 640px 以 max-width: 640px; 为内容区宽度，只有三部分（2 个页面 + 1 个滑窗），暂时不使用任何库依赖，摒弃了个人觉得不痛不痒、可有可无的功能，也置入了一些极少或甚至从未被实现过的功能，如：获取当前文章在博客所有文章中的序号，以提示当前的浏览状态。Snapic Just 640px 会是一款开源免费的主题，你可以自由使用、修改、移植、分发，但禁止商用，包括衍生品，也希望你能保留主题作者 Lopwon 的信息，以及在你的项目中提及 LopwonP.S. 已发布
花了两周时间，把之前制作的依然在售的几款 Typecho 插件和单页模板，整合成了一款 Lopwon Hub 多合一的功能集插件。在插件管理列表中，Lopwon Hub 是以单一父级插件的形态存在，当打开设置界面时，则以数量不限、用途各异的子级插件呈现，每款子级插件可以按需启用，各自配置，也可以根据需求继续添加子级插件。这次升级，除了优化代码外，还新增了一些功能，同时，避开容易冲突的接口，使用更为稳妥的方案，最重要的是对 JavaScript 进行分离封装，方便异步动态加载。目前正在给 Lopwon Hub 做软件著作权登记1，在证书发放后会上架发布，购买过的用户可以免费升级对应款。P.S. 已登记，已发布 如何申请软件著作权登记？ ↩
继前几日拍下 C/2023 A3 (Tsuchinshan - ATLAS) 彗星后，就惦记着能否制作一条小视频。即使彗星的亮度已经逐天变暗，即使当前是满月，即使天气有变数，即使城市光污染，即使现有的设备有些寒碜……2024年10月18日，预估彗星亮度 3.7 等，日落时满月尚未升起，彗星地平高度 35 度，意味着有一个小时的理想拍摄窗口，另加一个小时满月下的拍摄时段。出发，18:30 抵达另一处曾经来过的滇池边，找好块空地，设置好相机，静等拍延时。好吧，依然是习惯性的天边飘来一朵云，紧跟着便是一朵朵云，到最后连闪闪亮的金星都瞧不见，窗口期尽是满屏幕的云卷云舒。当西边云散开时，奈何满月已露出，彗星 C/2023 A3 那是黯淡无了光。戴耳机，看视频（流畅 / 卡顿）Music by Sol Rising 番外：如何将 192 张延时照片剪辑出 15 秒视频在 2 小时的延时拍摄中，一台相机拍了两个机位，一个机位拍下 120 张，一个机位拍下 72 张，每间隔 30 秒拍摄一张（手动对焦 / 自动快门 / 光圈 4.5 / 感光度 200 / 自动白平衡 / 关闭降噪），以 24 张/秒来计，后期仅能生成 8 秒视频。在素材有限的束缚下，大多数人为了图省事，会按常规操作，将两段素材拼接后搭上音乐，完事。而对于执着 15 秒视频的自己来说，要让视频凑够时长，又要画面内容丰富，且不用反感的特效，嗯，只能掏出多年积累的剪片经验，把 192 张（4896 × 3264 px）照片，折腾出（1920 × 1080 px）大型纪录片「我裁我裁我裁裁裁」A 呈现云层变幻 B 呈现金星移动 C 呈现最大景别 D 带出钓鱼的人 E 呈现钓鱼的人 F 带出树梢彗星 G 呈现彗星移动
又错过了最佳观赏期，被连续十多日的阴雨天耽误。咦！为什么说「又」？嗯，几年前在观测 C/2020 F3 NEOWISE 彗星时，也经历过相似的境况。[cid-1545]彗星 C/2023 A3 Tsuchinshan-ATLAS 早已过了近日点，逐渐远离太阳，从东升转为西落，亮度也由负星等慢慢变暗，天再不放晴，那就连最后一睹的机会也将失去。在关注了好几天 [#Windy] 气象雷达和卫星云图后，预测傍晚会有短暂的多云天，在 18:30 云散雨停时，匆匆忙搭上公交车前往十多公里外，曾观测 NEOWISE 彗星的地方。时过境迁，前往滇池边的小路已经围上了铁栅栏，大意了，没有事先踩点。在月色下摸索着找到了一处钓鱼人弄出的豁口，踏着雨后的泥水路，穿过滴水的杂草丛。在抵近水边时，才留意到金星的高度已经很低了，这意味着当下观测彗星的时间窗口会很短，加之东边有一颗即将满月的大月亮，西边有座海拔不低的西山，山后还有安宁市区的城市灯光污染，这个观测条件可谓差到了极致。来都来了，开始寻找彗星，除了 -4.7 星等的金星闪眼外，其他亮星目视吃力，更何况预估只有 1.9 星等的彗星，肉眼那是任何迹象也没发现。好彩自己是位天文爱好者过来人，于是，凭借经验拿起手机朝向彗星的方向拍摄，果然，原形毕露，被我看到架起 Fujifilm X70 / 定焦 28mm / 光圈 4.5 / 感光度 200 / 快门 10s 一刻钟后，云层飘来，遮天盖月；几刻钟后，电闪雷鸣，大雨倾盆。幸好，得到了超出预期的回报。[cid-3799] [cid-3820]
在给在用主题进行重制时，一不小心掉入了 SEO 的坑，虽然，对这些玄乎的搜索引擎优化不怎么感兴趣，但是，当经过自己改造、修正的页面通过了 Google 和 Bing 的官方验证时，是一件挺有意思的事。在检验搜索引擎收录效果时，可以明显的体会到：Google 和 Bing 在索引网页时，比国内搜索引擎更遵循自己制定的规则。大白话是：给博客内容做国内搜索引擎优化，如果依规操作，会有种打水漂的感觉。除了在主题里嵌入 JSON-LD 结构化数据、微数据、微格式外，还使用插件增强站点地图和资源提交，加上之前已有的，搞出了 SEO 合集，其中的 Lopwon Sitemap Topic 是一款在 SEO 方面，能让人惊喜的插件。[cid-3782] [cid-3814] [cid-3798] [cid-3781] [cid-3783] [cid-3734] [cid-3733] [cid-3736] [cid-3670] [cid-3664]趁着热情尚在，又折腾出了以下插件，其中的 Lopwon VEA 解决了一直以来让人劳神的问题：把人工审核邮箱地址的有效性，转交给插件自动处理完成。[cid-3766] [cid-3770] [cid-3776] [cid-3777] [cid-3784] [cid-3786] [cid-3811] [cid-3812] [cid-3830] [cid-3831] [cid-3833] [cid-3834] [cid-3845] [cid-3785] [cid-4000]这回已吸取教训，新制作的插件不再做分享，以避免再遇到「尝了白糖却还抱怨没有蜂蜜甜」的人。
2022年底，成昆高铁全线通车，老成昆线的过往和现况也渐现式地被人们知晓，除了解到修建铁路艰辛的历史外，还关注到了老成昆线上八个铁路展线。当我在 Google Earth 卫星地图里逐一查找这些展线时，着实被震撼到了：当年为了抵消高差，让火车畅通在山谷中，但限于基建条件，铁路只能以弯弯绕绕盘山和多次穿山跨江的方式修建，与当下基建狂魔般长驱直入山体建成的高铁线，形成了强烈的反差。2017年，乘坐昆明至西昌的火车，开始两个月的《征途一夏》续梦之行。然而时至今日，那段火车旅程的记忆完全丢失，也没有找到任何留存的影像，这就很诡异了。模糊的印象中，在旅行尚在进行时，似乎曾经为了腾出存储卡空间，格式化了相机的 SD 卡。2024年09月22日秋分时节，搭乘（昆明站 - 7466次元谋西 - 7465次昆明站）火车一日往返，尝试记起那段旅程。戴耳机，看视频（流畅 / 卡顿）
博客十年，确切的是域名 lopwon.com 使用了十年，写博客最早于2005年的 MSN Spaces 分享空间。期间，陆陆续续通过添砖加瓦修修补补的方式，给博客新增功能和改善布局，还作为制作插件、模板、教程时的演示页面，不但改动了程序不少源代码，也使得主题代码重复冗余嵌套严重，出现删改一处会全盘崩溃的窘况，结果是难以维护耗时费力脑壳疼，也影响内容加载。现在，哪些必要哪些常用哪些鸡肋，需求已经明了，趁这时机重制主题，重拾好好写图志不去瞎折腾。[cid-1366][coid-2411][coid-2400][coid-2402]
日推听到一首挺有感觉的西语歌曲，翻出移动硬盘找到几段在《一季山河：冬行长江》出行时拍摄的视频素材，剪辑成小短片存档：戴耳机，看视频（流畅 / 卡顿）
在制作 51 款插件 30 件单页 6 套主题，以及分享 17 篇教程后，对 Typecho 有了一些了解，在实现功能扩展时，相对能游刃有余。Typecho 相册主题 Snapic Plus v5 正是在此基础上，对过往版本进行迭代和全新重制升级。期间经历了更换配置服务器、软件著作权登记、笔记本电脑故障，以及响应各位使用者的建议对主题做优化完善，等等各式各样的状况，在多次反复测试调整后，终于可以正式发布了！也算是给博客「立云图志2014/07/19」~十周年 2024/07/19做个纪念吧。演示 / 介绍 / 文档
在过去的一年中，陆续制作了百来款与 Typecho 相关的「主题/模板/插件/教程」。虽说，大部分的功用算不得复杂，但是，真实的费时间，折腾得费时间，可能也是许多 Typecho 开发者渐渐对贡献周边扩展代码失去热情的原因吧。这期间，遇到热心协助测试和提出好建议的朋友，也看到用这些作品违约牟利的人，可以说，在任何一个圈子里，都能阅尽世间百态。后记功能的实现，可能只占制作时间的 10% 不到，省下的 90% 有甚，是考虑如何规避可能不到 0.01% 的人的非正常行为。[chart-ec_type][chart-ec_price][chart-ec_avg]以上统计截止2023年10月12日
这次行程，源起七年前的一句话，无意中给自己挖的坑。既然还惦记着，那得把坑填上，刚好也走走当年骑行云南时，由于时间关系而没有去成的西南边陲：德宏州。正如此行短片所表达的，在这九天的行程中，心绪会随着所遇事物不断地变换，有焦虑、有心安、有躁动、有平和、也有期许。戴耳机，看视频（流畅 / 卡顿）疫情的解封，版纳的拥堵，让有着相似民俗风情的德宏州上了热搜，外加地方官媒的大力顺势推广，和大理至保山铁路的通车，这国境边陲的滇西南也成了热门旅游目的地，或也成了西双版纳的平替。即使已过了春节的长假，还是能看到不少旅行者，只是，和他们多数人不同，自己不是被短视频忽悠到德宏州，而是，为了填坑，为了如愿。[chart-ec_20230212]在以往的出行中，吃的、玩的费用会占比很少，毕竟自己不是吃货，也更愿意看到无须买票的，不是人为的自然风景。出发前，想着要为填坑行剪辑一段小视频，不得已在这两项中花费更多的精力取素材，也因此打破了慢行拍照的习惯。行的大理至保山铁路在去年开通运营前，前往德宏州不算是件易事，这里山高谷深、河流密布，这段铁路耗时十多年建成，而且还是单线铁路，在实际的体验中，至少 85% 以上的路程是在隧道中行进。而大理至瑞丽铁路全段中的保山至瑞丽段，依然还在建设中。嗯，（大大理 - 瑞瑞丽）和东侧的（昆昆明 - 磨磨憨）铁路，将是绕开「美控」马六甲海峡的战略运输线。每到一地，都会去留意有没有共享电单车停在街边。幸运的是，在停留的芒市、瑞丽、盈江和腾冲都能骑着电单车穿街窜巷，这样的方式比步行省力比打车省钱，涵盖的区域也更广，但要注意是否越界：在瑞丽的姐告口岸，沿着中缅边境骑行，就是这么不巧，共享电单车在警戒处「哈啰」一声之后断了电，身旁就是岗亭和一只正在直视我的狗狗。住的Airbnb 在去年停止了中国区民宿的业务，使得预订合心意的客房成了头疼的事情。那些在《一季山河：冬行长江》时，常常能入住到的，或是别致的家庭式单间公寓，或是倾注了房东审美的居所……已经很难找到。只能住进无论房间布局和室内功能都千篇一律的酒店、宾馆和招待所。没办法，家里没矿，可选的受限，要以价格为首要筛选条件，其次才是地段、环境和用户评价。吃的对于美食完全免疫的自己来说，吃！只是满足了不饿的需求。对于手里和嘴里都没有食物的自己来说，在小吃摊前录视频，是一件让人提心吊胆的事情，要避免老板唠叨，那得先帮衬买些什么吧。于是，在吃这件事上，也就有了一些初探：一路下来，在尝试各种非酸即辣的小吃后，感觉用七八种水果拼配，机打成汁，虽不知何味，但却很对胃，起码同价的钱能搞那么多款水果，超值！正经地，还是腾冲松花糕的苦凉口味最对味，还有芒市使用山胡椒根调味米线的吃法也不错。玩的和版纳一样，德宏州也是佛教之地，虽然自己对宗教没有任何研xìng究qù，但相较于内地和藏区，这里的佛像、佛塔和寺庙，在外观上还是有着很直观的差别。初见德宏州首府：芒市，若不是建筑和门头的佛教装饰，若是直接空降此地，尽管街边有着高大的棕榈树、茂盛的榕树，有着很热带的氛围，也会让人觉得身处南方的任意一座城市。说句大白话，很多城市的风貌都大同小异，需要短租小住些日子，才能感受当地的气息。 德宏州与缅甸接壤，尤其是边境小城：瑞丽，聚集着缅甸人、尼泊尔人、印度人，以及说着各种方言的外省人。人们捧着一种叫翡翠的石头，为之疯狂，为之暴富，为之破产，为之丧命。除此外，瑞丽也是缅甸毒品入境、缅甸红木中转、国际贸易通关的关隘，边境线有别于以自然河流为界，这里与缅甸交界处往往需要筑起铁栏杆和铁丝网，需要有人全天的岗亭值守，尤以疫情三年为甚。德宏州只有两座城市：芒市和瑞丽，可赏玩的风光比较分散，要探索傣族村寨，还是要摩旅或自驾才能深入抵达和了解。 从瑞丽到腾冲，走了西侧的路线，为的是不走重复路。途径的盈江县，在两座山脉之间的坝子上，出产洋芋和烟叶，还巍然矗立着造型优美的允燕佛塔。填坑腾冲，是要填的坑，确切地，是 60 公里外的界头镇。凭着模糊的记忆，用一天往返，摸索着来到了七年前挖坑的村边小树林，站在同一位置望着远方的山形、村寨和油菜花田，看着当年拍下的那张照片，激动地无以言喻，无奈地用 xwǒxcāo 两字抒发情感。时隔七年，这坑我填上了。
结束《一季山河：冬行长江》的旅行已过一年，才想起在行程中记录下的音频文件没有整理。当我回听这些声音，打开与之同时间拍下的照片时，又明白了自己为什么会有这样一个「有声」项目：在拍照的时候，录下当时的原声，在将画面和声音同时呈现时，更多是对音频的关注，画面只是在增强声音的现场感，能让人发散想象，这与视频画面是焦点，声音是氛围的效果刚好相反。[cid-2956] [cid-2954] [cid-2952] [cid-2950] [cid-2948] [cid-2946] [cid-2944]
继问天舱上天三个月后，今日，「梦天舱」舱箭组合体已转运至发射区，在接下来的几天里，只须留意「文昌交警」的微博动态（发布交通管制的信息），即知火箭发射准确日期。通常，火箭发射都有时间窗口，是可以预测的，尤其是带有任务的火箭发射，但是，依照惯例，官方只会说「近日将择机发射」。除了关注「文昌交警」外，还可以通过非官方渠道提早获知火箭发射日期，做好去文昌观看和拍摄的准备。网站 [#Next Spaceflight] 就罗列了世界上每一次火箭发射的详细清单。 在一周内，文昌将会有两次火箭发射，把梦天实验舱段（2022.10.31）和天舟货运飞船（2022.11.06）带上中国空间站，天宫站也将完成一期工程。在一周里，能体验两次火箭发射，实在难得。可惜，文昌目前还在多轮的开展全域核酸筛查，意味着前往文昌后，可能要呆在酒店里落实 3 天健康监测。后记天舟五号货运飞船发射时间延后至：2022.11.12 11am
入夜，楼下突然有人在谈论着什么，与平日相比稍显热闹。没在意，继续忙着自己的事情。一刻钟后，手机显示陌生来电。没理会，继续忙着自己的事情。十分钟后，又是那个陌生来电。接通……下楼后惊呆，拉起警戒线，架有遮阳棚，摆着长座椅，站着五六人。过来做下核酸，楼里有接触者。回屋瞧瞧吃的，嗯，还够三天。好吧，又到了退票扣手续费的时刻。后记封控第一天。大白：楼上下来做核酸啰！开始每日一检。2022年08月22日 昆明 封控第二天。白天停电！2022年08月23日 昆明 封控第三天。坏消息：封控时长由三天延至七天。好消息：附近大润发超市还能配送。2022年08月24日 昆明 封控第四天。防控人员：今天解封了。2022年08月25日 昆明
至此，《一季山河：冬行长江》的游记和影像全部更新完毕，为了凑个整数（280P），放了张自拍照。近万字旅行札记，近三百张出片量，还有行程中遇到的人和事，都在潜移默化地影响着自己……
原定21号前往海南文昌，感受下即将发射的「问天舱」升空。没料到行程（昆明 —高铁 北海 —渡轮 海口 —高铁 文昌）中要途径的北海和海口，在近日相继被新冠疫情「攻陷」。希望10月能顺利成行：观看中国空间站「天宫」的另一个舱段「梦天舱」上天。
结束《一季山河：冬行长江》的旅行已接近半年，一直没有头绪起笔。总会和朋友开玩笑地说：这两个月（65 天）「游荡」的地方有点多，搞得自己的记忆有点错乱了。是的，在行程中，虽然每天入睡前，都会写些日程札记，记下或喜或悲或有当头棒喝的历程，但现在还是需要打开地图和照片，才能回忆起稍微具体的事情经过。如题图所示，此行由宜宾市开始，沿着长江中游至九江市；随后经过南昌、长沙和张家界，折回重庆和贵州；最后沿着乌江下游前往贵州黔东南地区。以此为引。
使用场景写文章时（比如出行游记），如果在内容区一张一张的插入很多很多图片，会显得文章比较冗长，尤其是使用竖版构图的图片，往往高度霸屏。此时，若能以相册的方式，在当前页面集中呈现这些照片，会大大增强浏览体验。主要效果1. 相册以九宫格（可调数量）的形式呈现在文章末尾。 2. 九宫格的图片以随机形式呈现，刷新页面可见效果。 3. 点击图片后以灯箱的形式呈现，并能添加图片描述。 4. 点击最后方块可以链接至相关内容，如文章或相册。 实现方式方式一：在文章 A 的文末调用文章 A（或文章 B）的附件中所有图片作为相册展示，并链接至相关内容（如文章 B）。查看演示（当前页文末九宫格图集），刷新页面可见随机图片效果。方式二：在文章 A 的文末调用通过 Snapic Page（Typecho 独立页相册模板）创建的相册 A，并链接至相册 A。查看演示（演示页文末九宫格图集）。如何实现电邮 lopwon@qq.com 付费改造。也可以选择 Typecho 的 Snapic 相册。
两年多前，给博客添加了「昔日」功能，类似于 QQ 空间的「那年今日」。对于当时使用 QQ 空间的用户来说，「那年今日」是一项没有得到完善就草率上线的新功能，是备受争议的：有人认为自己的隐私，甚至已经删除的黑历史，在不经许可的情况下，被强制展现出来，被冒犯了。 有人觉得也挺有趣的，能够重温过往的小感动，看到逗比矫情的自己，与今时今日对比，在成长着。 在用户褒贬不一的使用反馈下，「那年今日」在升级中有了更多的「自主选择权」……回到 Typecho，与博客常用的随机文章、相关推荐功能不同，「昔日」是通过时间维度，把每年相同月日所发布的文章串联起来。思路1、使用博客现有的功能让操作简单化。 2、每篇文章需要一个具有共性的标记，如分类、标签、自定义字段或者内容等。 3、这个标记能便捷添加在每篇文章中。 4、具有共性标记的文章，最终通过（archive）页面，使用「搜索」的方式呈现出来。 这么分析对比下来，如果使用标签（tags）作为每篇文章的共性标记，就会产生 365 个日期标签，显得冗长；如果使用自定义字段（fields），现有的博客搜索功能又无法对其起作用，除非修改核心代码，新增搜索范围。嗯，只能使用比较绕的方法：在每篇文章内容中添加时间关键词，即以上提到的「共性标记」。方法1、在每篇文章中，根据不同的发布时间，添加统一的日期格式。为了美观，可以使用 CSS 将其隐藏。 日期格式： 其中，Mar 代表「三月」，25 代表「25日」。逢个位「日」时，用零补上，如：Mar05 2、在文章页 post.php 中，根据喜好位置添加链接 a 标签代码，跳转至搜索呈现页面（archive）： <a href="<?php $this->options->siteUrl(); ?>search/<?php $this->date('Md'); ?>/">昔日 如果博客链接带有 index.php 则使用以下代码 <a href="<?php $this->options->index(); ?>search/<?php $this->date('Md'); ?>/">昔日 演示博客内任意一篇文章页翻篇处的「昔日」。后记博客中的「昔日」（那年今日）功能，已替换使用更为便捷的方式实现：不需要像以上提到的，在每篇文章中添加统一的日期格式，只要一次性改造搜索页面即可实现。电邮 lopwon@qq.com 付费改造。
在 TikTok 看到俄乌交战的惨烈，很多画面多出自亲历这场战事的居民拍摄，上传时间也就 20m、3h、1d 之前，地域上很遥远，时间上却感觉事件就发生在身边。这些视频画面，有军队出征，有两军交火，有残骸废墟，有避战逃离，有投降求和……也有不少画面来自两军士兵的个人 TikTok 账号，当往上滑动页面刷屏时，看到的是战争前，这位士兵的家庭日常生活片段，也许这些账号里，有的再也没有机会更新了。P.S. 词曲与文无关。
2011年二月，抵昆。某夜零零星星的飘雪，虽然触及便消失不见，但依然抑制不住激动的心情，那是第一次看到雪花。之后的冬季，春城偶尔也会下雪，却无今日落地积雪的效果。只是，自己对这场雪竟是内心毫无波澜……
“数字并无情感，但背后藏着你走过的山川与湖海，遇见过的人、听过的故事。”—— Airbnb 当我把这些年的足迹呈现在热力地图上的时候，才意识到一些重要的事情：__ __ 为wéi家！
在前往某地之前，我们往往会对目的地做出预想：生活形态的、人文景观的、自然风貌的……这些预想通常来自关于当地的文学作品、影像记录，以及自己的认知。但是，当我们抵达目的地时，常常会发现：所见所闻所感会与预想的存在较大的偏差。甚至会发觉，我们的预想过于主观和自私：我们期待遇到有时间沉淀保留完好的事物，但他们更希望自己的居所和生活得到改善。以此影像纪念《一季山河：冬行长江》。戴耳机，看视频（流畅 / 卡顿）
这是一款来自1996年，在当时，需要半年工资才能买到的数码相机：Kodak DC20。嗯！我现在土豪地拥有两台。先后淘到这两台远古的数码相机，都是裸机购入，不知功能好坏。由于相机使用的是内置闪存和 3.5 的输出口，还没有显示屏，使得浏览查看和传输下载图片成了难题。好吧！翻墙搜索阅读资料，寻找相机的软件，查找数据线类型，使用虚拟机安装旧系统……一切都感觉妥妥地时候，第一台呈现在电脑中的画面竟然是，黑幕好吧！试下另一台……在不断地折腾后，当相机拍摄的影像出现在眼前的那一刻，兴奋得已经无法言喻。哦豁！这是一张来自相机内自带的照片，应该是卖家遗留下还未删除的。参数相机品牌：Kodak 相机型号：DC20 上市时间：1996年 等效焦距：未知 有效像素：0.18MP（18万像素） 精细画质：493x373（8张） 普通画质：320x240（16张） 内置闪存：1M 显示荧幕：无 电池型号：CR123A 实操情况一。如果具备以下条件，相当于返回当年（九十年代）的环境中，恭喜！一切将变得顺畅。硬件：1. 拥有一台带有九针串口数据接口的台式老电脑，并且有光驱。 2. 有相机自带的光盘和数据线。 3. 相机没有故障。 软件：1. 电脑安装有 Win XP 以前的 32 位系统，如 Win 95、Win 98 和 Win XP 系统。 2. 从相机自带的光盘里，通过电脑光驱，获取数据线的驱动和传输照片的软件。 情况二。如果手头只有相机，恭喜！这将是探知求索的过程，能感受到导出照片那一刻的喜悦。A. 现在的电脑大都没有九针串口，加之相机的输出端是罕见的 3.5 接口，所以，买到能用的数据线，这一经历是比较痛苦的，因为不知道用什么关键词搜索产品，且大部分搜索到的结果都是 3.5 音频线，是不能传输相机图片数据的。即使买到接口匹配的，也会遇到无法安装驱动不能使用的窘况（如：文章图七左侧的数据线）。最终，通过转接的方式，找到能用的数据线连接笔记本电脑（文章图七右侧的数据线）。B. 由于 Kodak DC20 传输照片的软件只能在旧版系统中打开运行，所以，必须在你过于先进的电脑里安装当年（九十年代）的 32 位系统。这就需要 VMware Workstation 虚拟机来实现，它只是个平台，接下来需要在 VMware 虚拟机里安装系统，这是关键，可以前往 I Tell You 下载需要的系统。这期间会遇到各种状况，需要一个个解决，比如：虚拟机需要安装跨系统的复制粘贴和连接网络的功能扩展插件；系统版本不合适或者需要序列号注册等等问题。C. 确保相机没有故障。D. 经验提示：使用 Google 搜索，能找到想要的一切。百度三下，全是广告。E. 相关链接：[#相机资料] [#官方文档] [#相机评测] [#数据线型号] [#数据线驱动下载] [#虚拟机下载] [#系统下载] [#相机软件下载]
在闲鱼以 19.9 元包邮的价格拿下这台疑似故障机（图示右）。根据机身上的铭牌（Oregon Scientific Autobrite），百度不出关于这台相机的详细信息，只知道中文名称是「欧西亚」。科学上网谷歌一下后，满是惊喜，[#ebay] 和 [#amazon] 显示：相机品牌：Oregon Scientific 相机型号：DS6618 上市时间：2003年 等效焦距：47 mm 有效像素：0.3 MP（30 万像素） 精细画质：640×480（26 张） 普通画质：320×240（101 张） 内置闪存：8 M 相机厚度：6 mm 由于年代久远，这厚度只有 1 毫米，薄如纸片的内置电池（图示 A）已经老化，相机无法正常使用。在万能的淘宝买到一块 3 毫米厚，大小类似的电池（图示 B），8.9 元包邮。拆机换电后，当按下快门时，液晶屏的剩余拍摄张数有减少，奇迹出现！找来数据线连接 Win 电脑，没反应！再仔细阅读 ebay 上的参数介绍和 amazon 上的顾客评论后，才了解到，这台相机需要接上支持 Windows XP 以前旧系统的产品软件后才能读取照片。好吧！继续谷歌，找到了相机软件；使用 VMware 虚拟机，安装了 XP 系统。终于！在不断地折腾后，这台产自2003年，号称当时世界上最纤薄的数码相机，复活！后记居然和早一年发布的 [#Fujifilm Axia eyeplate] 同款。
有种强烈的预感，即将会离开这里。（2020年11月13日字）各位来访的朋友们，不妨推荐下你生活的城市吧，最好是小镇。（2020年11月16日字）不要埋怨任何人，相反，他们刚好是「促使」你，对事优柔寡断时，做出最后决定的人。（2021年09月18日字）
在用的 OnePlus 3T 已经将近五年，电池老化以至于每天需要两充。自己对手机依赖不大，一不玩游戏，二不玩自拍，除了一些软件越更越大，用着有些卡顿外，已经够用了。想着买块新电池，拆机换电后，能够满血回归，再战两年。谁料！一使劲，手机后盖没撬开，倒是把屏幕撬开了，伴着清脆的啪的一声，返回按键的排线断了（见图右下）。好吧，全拆开，扫扫灰。换电复原后，除了返回键失效，其他一切正常。搜索了一下，还好有配件，嗯！可以再战两年。后记两个多月后，更换的电池鼓包。手机要一直连着移动电源才能使用，甚至在天气寒冷时，手机更是无法启动，让在旅途中的我很是抓狂。在硬撑一个月后，花了 100 元在途经的县城找师傅改换了一块华为的电芯，继续使用到行程结束。之后，自己又重新替换上一块有品牌的电池。
给这台产自2000年的佳能 IXUS 系列初代相机，拆解清灰。除了之前的四台潜望式卡片机外，又抵不住好奇心，淘了一台1996年上市的远古的 Kodak DC20。哦豁！这是淘二手也要剁手哈。
不关注娱乐八卦，不刷看抖音快手。不少明星和网红，要不是被新闻报道上了热搜，要不是被品牌方解约撇关系，还真不知道他们是谁！他们嘛，也就是资本运作的工具，却还真能自我感觉良好。P.S. 图与文无关。雨夜查看公交车信息的人。
使用 Fujifilm Z1 拍街头照，文件名已经是 DSCF0530.JPG，数量过了 500 张，但只有不到十分之一的照片稍感满意，而且多数为盲拍背拍，失焦的没脸的居多。持续努力中……给自己制定了进阶拍摄计划：1、能拍到：多走多看多想，练习观察能力。近些再近一些，融入目标空间。不引人注目的，拍摄主角正面。 2、能拍好：嗯！这是一个很难界定的话题。
在擦肩而过的一刹那，掏出随身携带的 Fujifilm Z1，在行进中开机盲拍，没有停止脚步，感觉错过了最佳的角度。在相机显示屏预览时，判定是张废片。但是，在电脑处理时，察觉了一些有意思的现象，保留了这张照片：自己正在悄悄的改变着，以往拍摄风景时养成的那些追求四平八稳构图的强迫症。拍街头照，觉得嘛！能拍到大于能拍好。早开门营业的人。老板有些残疾，行动不便，手部弯曲，脸部也有些变形，说话吐字不清晰，貌似小儿麻痹症。照片是老板打开拉闸门，稍作休整的瞬间，刚好歪打正着的没有拍到脸部。
去年，因为有需求，需要一台轻便小巧的，性价比高的，能够随身携带的数码相机，即时拍照！遂将目光放在了老款卡片机上。在淘货的过程中，发觉这些无论画质，无论性能，无论操控…都不如当下手机，且被淘汰很多年的 CCD 相机，正在被某些人热炒中，直至现在，依然！近来，或是出于怀旧，想淘淘自己在2003年曾经购入使用的第一台数码相机 Kodak CX4230 的同款。那一年，是电商刚刚兴起，淘宝刚刚成立的一年，也是自己第一次体验网络购物。在网上搜索打开陌生的购物网站（记忆中站名带有「徳」字）下单，通过邮政汇款 1500 元，在等待很长的的日子后，收到了从北京寄来的包裹。 在闲鱼蹲了挺长时间，没有淘到满意的 Kodak CX4230 同款，或者是觉得当年这款相机使用的感受不佳（体积大、费电池），于是另购入了 Minolta X 和 Sony T7。现有的这四台相机中，只有 Fujifilm Z1 是从个人闲置手中购得，其余均是来自二手贩子。在 Sony T7 的存储卡中，还保留着原相机主人拍摄的照片和视频。自己将尝试给这些十多年前的影像，制作一支小短片（已完成）。戴耳机，看视频（流畅 / 卡顿）
早上，Fujifilm Z1 被曲奇猫当玩具玩耍了一阵，导致快门和变焦的按键失灵，屏幕显示错误，无法拍照。赶忙上闲鱼搜索这款相机，想着寻找同款替代。之后，神奇的事情发生了：把相机连续的，随意的，使劲的拍向手掌，居然恢复了正常。看来嘛，老式的电子产品，都有拍一拍就好的偏方。
年初计划的5月西藏徒步，因为看到一篇他人写的攻略里，途径的多个垭口在6月时冰雪仍未化开，导致延期，改定于7月再入藏进山。但是，协助自己工作的小姑娘，在这个节骨眼离开返校准备继续念书，又让这次行程化为乌有，或许还会无限期搁置……好吧，往好处想想：也许会因此逃过一难，因祸得福呢？！
现在进山徒步拍风景的机会少了，开始转向以能够随时操作的街拍的方式，使用卡片机 Fujifilm Z1 拍摄，甚至刻意地拿廉价的儿童玩具相机练习抓拍和构图。上图即是 30 元购买的「器材」拍到的曲奇猫，还挺喜欢的，无关画质，是这光影有种负片的感觉，第一眼看到时被惊艳到了。
近来，一直积极地去尝试街（zhua）拍遇到的场景。只要走在路上，就会手握 Fujifilm Z1，眼观四路耳听八方的留意周遭可能出现的可以按下快门的瞬间，好似间谍一般。为了弥补这台十五年的老龄数码产品的不足，如：对焦慢又无法设置超焦距；宽容度不够；屏幕取景不佳……自己适应出一些拍照方法：1、提前估焦，对着合适的地面距离半按快门，事先锁定对焦。 2、降低曝光补偿，方便后期有余地处理明暗关系。 3、使用盲拍方式，避免挨揍。 …… 正在休息吃食的人们。逗不笑的帅气小朋友。周末还赖床的曲奇猫。一次薅下的曲奇猫毛。等待绿灯的电动车们。单人座两人坐的哈啰。呼啸而过的机车男女。公交车站台上的人们。雨天车窗外的女士们。查看公交车来况的人。
昆明又到了划船看海的季节，电动车少了，挤乘公共交通和驾驶私家车出行的人们多了，嗯，看来大伙们平日普遍是在节省用油，为城市空气环境做贡献。使用随身携带的 Fujifilm Z1，抓拍了一些场景。相机很小巧便携，只是这对焦速度真是让人着急，画质也不算高，毕竟是十五年前的数码产品，但是用来练习构图还是不错的，尤其是这 CCD 的黑白效果。公交车上面的人们。等待公交车的人们。公交车里面的人们。等待绿灯的私家车。