分类目录归档:技术

在 Next.js 中直接引入 SVG

在 Next.js 中直接引入 SVG

随着 SVG 的兴起,过去使用雪碧图、IconFont 作为界面中图标用法已经过时。大家会更倾向于加载更加简单、空间占用更小、编写更容易的 SVG 作为图标的解决方案。

而 Next.js 同样对于 SVG 提供了支持。

最简单的加载方式 —— URL 加载

如果不希望对应用程序做任何的改进,一个最简单的方式是直接使用路径进行加载。只需要使用一个 img 标签,并设定 src 为 svg 文件的路径就可以了。

<img src="/logo.svg" alt="Logo SVG" />

不过,使用 URL 来加载的问题是,当你的文件夹路径和结构比较复杂的时候,你需要使用一个较长的路径来加载 SVG,比较麻烦。

当然, 你也可以简单的优化这个方案 —— 比如自行封装一个 svg component,支持传入文件名 & alt 文字和其他参数。这样在调用的时候只需要输入文件名即可。

最舒服的加载方式 —— 编程加载

在 Next.js 当中,如果你希望更加舒服的引入 SVG,那比较好的方案是使用 import 标签来进行引入。不过,由于 SVG 本身并不是一个标准的 React 组件,你需要在 Next.js 上安装插件来支持对 SVG 的解析。

加入对 SVG 的解析需要安装 @svgr/webpack 插件。执行如下命令安装插件。

# yarn
yarn add @svgr/webpack
# npm
npm install --save @svgr/webpack

安装完成后,修改 next.config.js添加相关的解析规则。

module.exports = {
  webpack(config) {
    config.module.rules.push({
      test: /\.svg$/,
      use: ["@svgr/webpack"]
    }); // 针对 SVG 的处理规则

    return config;
  }
};

修改后保存,便可以直接使用 import 语法来处理

import Logo from "../assets/logo.svg";


// usage
<Logo />

这样,你就可以直接将 SVG 作为一个 Component 引入,并使用你熟悉的 React Componet Props 来修改这个 Component 的各项属性。

总结

在这篇文章中,分享了两种在 Next.js 的方法,你可以根据自己的实际情况来决定选择具体使用什么样的方式来引入 SVG。

使用 Proxy.py 自建 HTTP Proxy

使用 Proxy.py 自建 HTTP Proxy

如果你需要对一个集群进行开发,且开发过程中需要访问内网,一个比较常见的方式是建立虚拟专有网。但倘如你不愿建立虚拟专有网,那么一个比较简单的方式是建立一层 HTTP Proxy 来访问内网当中的数据,你只需要在某一个节点上设定 HTTP Proxy,并在你自己的电脑上配置 HTTP Proxy ,就可以完成使用对应的节点来访问具体的网页,解决 HTTP 访问的问题。

原理

HTTP Proxy Servr 的原理并不复杂,就是一个标准的正向代理。你只要能搭建这样的一个服务即可。

实际操作逻辑

以下文章以 Debian GNU/Linux 10 为例

1. 在你的节点上安装 Python3 & pip 3

Python3 是运行 Proxy.py 的运行环境,而 pip3 则是安装 Proxy.py 的工具。执行如下命令来安装。

apt install python3 python3-pip

2. 安装 Proxy.py

这里我们不使用 Virtual Env 来安装,主要是方便后续加入 Systemd 来进行控制。如果你习惯使用 Supervisord 来控制的话,就可以使用 Virtual Env 来安装 Proxy.py。执行如下命令

pip3 install proxy.py

3. 启动 Proxy 进行测试

在你的节点上执行如下命令来启动一个测试服务器。

proxy --hostname 0.0.0.0 

如果你需要监听某一个特定的 IP, 则将 0.0.0.0 修改为你具体的 IP。

配置后,你可以看到如下的输出,则说明已经成功启动了 Proxy 服务器。

启动完成后,你就可以在本地测试访问如下命令来进行测试。

curl -x [服务器IP]:8899  http://httpbin.org/get

当你看到如下输出时,确认返回值当中的 origin 是否是你的节点 IP,如果是你的节点 IP 则说明你的 HTTP Proxy 已经配置成功了。后续你就可以通过这个 HTTP Proxy 来进行访问了。

测试完成后,你可以执行 Ctrl + C 来关闭当前的 Proxy Server。

4. 配置 Basic Auth Authentication

上面配置好了 HTTP Proxy Server,但一个问题是这个 Server 没有安全验证,随时会被别人所利用。所以我们需要配置一些基本的安全配置,来解决这个问题。

在你的 Proxy.py 当中加入 –basic-auth 选项,则可以实现加入基本的鉴权。其中,用户密码用英文冒号隔开。比如我需要创建一个用户名是 admin ,密码也是 admin 的proxy ,就可以执行如下命令。

proxy --hostname 0.0.0.0 --basic-auth admin:admin

5. 配置开机自启动

现在 Auth 也有了,但是我们不能总是开着 Terminal 来运行我们的服务,所以一个好的办法是为其加入 Systemd ,这样我们就可以使用系统自带的能力来完成 Proxy 的自启动了。

执行 systemctl edit --force --full proxy.service 来创建一个新的 Systemd 服务,并在其中加入如下代码并保存。

[Unit]
Description=Proxy Service
Wants=network.target
After=network.target

[Service]
ExecStartPre=/bin/sleep 10
ExecStart=proxy --hostname 0.0.0.0 --basic-auth admin:admin
Restart=always

[Install]
WantedBy=multi-user.target

保存完成后,执行 systemctl enable proxy.service 配置该服务器的开机自启动 & systemctl start proxy.service ,即可实现 Proxy 服务的开机自启动,并在当前启动该服务。

总结

有了 HTTP Proxy ,你能以一个更加简单的方式来访问内网当中的服务器。你只需要控制 Proxy 节点的可访问权限,就能很好的处理内网数据的安全问题。

从企业视角,为什么要选择 WordPress?

从企业视角,为什么要选择 WordPress?

WordPress 在国内日渐式微,从过去的全民博客用 WordPress, 到后来的很少人会使用 WordPress 做博客,再到现在只有一小撮人还在使用 WordPress,伴随着 PHP 的衰落和 Golang 等新语言的兴起,WordPress 不再是国人的选择。过去曾经有一段时间,大家很喜欢用 WordPress 做电子商城,不过随着时间的流逝和国内外电商贸易环境差异的变化,使用 WordPress 开发电子商城也不再是一个选择。如今的企业,不再愿意选择 WordPress 来完成自己的业务。

不过,从我自己的视角来看,我们看待任何一个工具的时候,不能看他是否还流行,而是要看他是否还能解决我们所面临的问题。

WordPress 的优势是什么?

WordPress 最大的优势主要是三点:

  1. 插件市场足够丰富带来的更少的开发工作量:但凡提到 WordPress ,你就不能不提 WordPress 的插件市场。WordPress 海量的插件市场可以帮助你更好的完成你的工作。对于一些传统模式下需要自己开发的功能,你可以选择直接安装 WordPress 来完成工作。
  2. 服务端渲染带来的 SEO 友好:现代 SPA 也有服务端渲染的能力,不过对于开发者来说,则需要单独假设一套服务端渲染的服务来完成这部分工作。或者提前预生成所有的页面。对于页面较小的站点,预生成比较靠谱。但对于数据量极大的站点,预生成也是一个较为痛苦的过程。WordPress 因为更加的传统,所以一直采用的是服务端渲染的模式。服务端渲染在针对 SEO 进行优化时,可以获得更好的优化能力(毕竟有些时候 Spider 不一定会等你的页面在前端渲染完成)。
  3. 极强的编辑性带来的人力释放:WordPress 不仅仅是我们看到的给用户的这一套 UI,还包含了一个强大的用户后台。强大体现在 Editor (Gutenberg)、全站编辑(WordPress 5.9 开始提供的新能力)。这些能力可以让 WordPress 从一个只能用固定模板的网站,变成了提供了一定的自由度,可以通过拖拽来生成一个页面的能力。对于一些比较极致追求拖拽的人,还会使用 Elementor (不过不太好做性能优化,如非必要,不上 Elementor)。这个能力带来的时候可以释放开发团队的人力,在构建好最基础的 Block 之后,交由运营人员来完成后续的管理和维护。

WordPress 的劣势是什么?

但同样的,没有什么东西是只有好处没有坏处的, WordPress 的坏处同样明显。

  1. 使用 PHP 编写,国内维护人员难招:WordPress 所依赖的 PHP 生态式微,则相应的,从事 WordPress 开发的人也渐渐变得更少。对于企业来说,难以找到合适的人是一个很大的问题。
  2. 目标太大,容易被安全攻击:WordPress 作为全球使用量排行第一的 CMS(内容管理系统),盯着它的黑客也多。虽然对于 WordPress 本体的安全攻击很快就会被修复。但针对普通插件的攻击则不那么容易防范。如果选择不当,很有可能把自己变成黑客的肉鸡。

总结

技术领域没有银弹。WordPress 同样也不是那个银弹。在合适的场景下, WordPress 便能放大自己的价值。而如果不合适,同样也无法放大 WordPress 的存在价值。

记录一个令人血压飙升的前端项目

记录一个令人血压飙升的前端项目

最近在看一个前端项目,里面出现了一些令人血压暴涨的骚操作。虽然可以用,但对我来说,确实是让我看到血压飙升。

1. 尽可能使用常规的指标

项目的诉求是实现页面的自适应化,在不同尺寸的屏幕上尽可能保持一致的显示。

为了实现这个诉求,我给他们的建议是使用 Bootstrap 之类的框架,在不同的屏幕上尽可能保持一致。使用 Bootstrap 之类的框架来完成。

最后研发团队选择采用了一个有用,但我看起来非常头疼的方法 —— 根据屏幕宽度计算 rem。通过这样的方式,实现了在不同的屏幕宽度下,都可以和设计稿的尺寸一比一。

但这样带来的问题是,rem 计算出的结果也是一个非常的大的值(当然也可以非常小),但依然不是一个常规的结果,需要你常常使用诸如 0.03 这样的数值来指定宽度和高度。

我觉得,这样的写法并不是说不行,只是这样的写法其实会降低整个项目的可维护性。

2. 文件放置符合规范

其次,这个项目中还出现了一个问题是 —— 文件到处乱丢。在一些项目中,大家往往会有一些明确的文件路径的规范,比如样式文件应该放在哪里。在这个项目中,就出现了样式乱丢的情况。

和 Component 放在一起
符合规范统一放在 scss 文件中

这样的混乱的写法则会导致在实际开发的时候,如果想要调整样式,可能会出现调试失效,修改起来较为混乱的问题。

3. 一个项目中混用多个不同的尺寸单位

另外一个文件采用 px 作为单位

刚刚有用 rem 的单位,另外就有一个文件采用的是 px 为单位,我非常担心在不同尺寸屏幕下出现的错位问题。

4. 放弃 Bootstrap 的样式类,转而改用手动撰写每一行样式

其实完全可以用 position-absolute d-flex 等方法来覆盖

总结

这个项目从我目前的视角来看,依然还有很大的改进空间。且留下了不少的坑。在我看来,长期来看,这些代码将会留下不可维护的问题。希望他们后续慢慢修改和调整吧。唉。

在 WordPress 中实现同一个 CSS 类在不同页面展示不同的效果

在 WordPress 中实现同一个 CSS 类在不同页面展示不同的效果

在使用 WordPress 开发时,某些时候你会遇到在同一个类在不同页面的时候,希望有不同表现的诉求。在这种情况下,一个比较简单 or 比较 Tricky 的技巧是通过 Body 层的类选择器来实现。

在 WordPress 进行渲染时,会自动在页面的 <body> 上加入 postid-[id] 的类,对比本文就是 postid-5888

比如本文的 class

类似的,如果是一个 Page,也会生成 page-id-[id] 的类。

页面生成的类是 page-id-[id],和 post 规则不完全相同

因此,如果你需要某个页面的元素样式和其他页面元素样式不同,但页面结构保持一致,一个比较好的方式是通过这些页面类选择器来实现。以你要自定义 btn 样式为例。则可以这样实现:

// 标准页面的样式
.btn{
   // your styles
}

// 在文章 ID 为 5888 的文章上的样式
.postid-5888 .btn{
  // your styles
}
// 在页面 ID 为 84 的文章上的样式
.page-id-84 .btn{
  // your styles
}

总结

借助上面的方式可以实现同一个类在不同的页面展示不同的样式。但我个人觉得,这样的实现方式可能对于 Debug 不太方便,尽可能少用。但如果你需要用的话,那一定要注意好组织代码,避免后续维护成本提升。

此外,除了通过修改 style.css 来实现,你可以考虑将 Page 单独的样式梳理在一个 page.css 中进行维护,从而降低维护难度和成本。
WordPress 当中也有一些插件来实现某个页面自定义的 CSS 能力,将这些样式放在插件中来实现也是一个不错的选择:Post/Page specific custom CSS

Reference

自定义 Bootstrap 5 的风格,实现自定义风格页面开发

自定义 Bootstrap 5 的风格,实现自定义风格页面开发

和更加自定义化的 TailwindCSS 相比,Bootstrap 显然更具备主题和模板页面开发的潜力和更易于进行模板页面的开发 —— 毕竟各种样式都已经封装好了,你可以直接使用诸如 btn 来定义一个 Button。

我有在想,提供一个基于 TailwindCSS 的 StarterKit 来快速基于 TailwindCSS 开发出一套自己的样式库,但仔细想想,其实意义不大。因为可选项太多了,想要自定义化其实没那么容易。

白宦成

而在开发 Bootstrap 的时候,大家往往会遇到的一个问题的是 —— Bootstrap 开发出来的页面千篇一律,一千个人有一千个哈姆雷特,但一千个 Bootstrap 页面却长的一模一样。而这背后的原因,主要是因为大部分人使用的是标准版的 Bootstrap —— 也就是官方所定义的样式。大家都使用一样的样式,自然就使得开发出来的页面显得雷同。

不过,其实 Bootstrap 的风格自定义并不困难。

前情提要

其实大家不去做自定义风格开发的原因倒是可以理解 —— 锅都要给 Node Sass,在 Bootstrap 5 以前,Bootstrap 使用 Node Sass 来进行样式的构建,但 Node Sass 是一个基于 C++ 编写的拓展,这使得 Node Sass 的安装十分麻烦,加上特有的网络环境,使得 Node Sass 的安装十次有九次都是无法成功安装的,大家自然也不愿意使用 Node Sass 构建的项目(包括我自己,都会刻意选择使用 Less 构建的项目)。

不过,从 Bootstrap 5 开始,Bootstrap 项目开始使用 Dart Sass 进行样式风格的开发。这使得 Bootstrap 的构建不会像过去那么痛苦,因此也可以更好的进行风格的自定义。对于如今还在使用 Bootstrap 进行项目构建的同学来说,无疑是个好消息。

自定义 Bootstrap 5 的风格

关于如何在你的项目中引入 Boostrap 的 Sass 来满足自定义的需求,可以参考官方所给出的 Customize Sass 的说明,官方提供了包括 WebpackParcel 等的接入说明,如果你连基本的配置都懒得做,官方还提供了一个空白项目,方便你 Fork 后再修改。

以我自己使用的 Next.js 为例,配置起来也比较简单:

1. 安装相关依赖

在 Next.js 项目根目录安装所需依赖

yarn add bootstrap
yarn add -d sass sass-loader

2. 创建 Scss 文件

styles 目录下创建一个新的 globals.scss 文件,并在其中加入如下代码

// custom variables
@import "../node_modules/bootstrap/scss/bootstrap";
// custom css code 

其中 custom variables 的部分是让你用来加入自定义的变量的,比如自定义 Primary 的颜色、自定义 Padding 等一系列操作,都需要在 Bootstrap 的引入前定义,这样才能确保你的引入变量会生效。

而后面的 custome css code 则是可以用来定义一些你自己编写的,没有被覆盖在 Bootstrap 内部的类。

3. 在项目中引入创建好的 scss 文件

在项目的 pages/_app.js 引入我们刚刚创建好的 scss 文件,从而确保应用在启动的时候可以自动构建 Bootstrap ,并引入至项目中。

import '../styles/globals.css'
import '../styles/globals.scss' // 这一行是新增的
function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />
}

export default MyApp

4. 在项目中使用 Bootstrap 类进行开发

当你完成上述的配置,就可以在自己的项目中引入相应的类来进行开发了。

一些小技巧

使用 Themestr.app 进行风格的快速设定

Themestr 是一个帮助你快速生成一套Bootstrap5自定义风格的工具网站。

在 Themestr 中,提供了 UI Builder、Themer 和 Customizer 三个不同的工具,其中:

UI Builder 提供了一个简单的 4 步选择器,让你定义了基本的颜色、字体、ICON 和 按钮风格,从而形成一套独特的 Bootstrap UI。

Themer 则提供了更加全面的样式的设定和预览功能,你可以在右侧的选择界面简单的配置样式,并在左侧自动刷新的页面中查看你的配置所实现出来的效果,方便你快速找到看到你的配置所能展现出的效果,简单且直观。

Customizer 则提供了全面的 Bootstrap 的变量,方便你快速找到你要修改的变量,并帮助你生成对应的 Sass 配置文件,方便你在此修改变量,并在本地进行开发。

对于不同的场景,Themestr 提供了不同的工具来帮助你快速开发,是一个非常不错的 Bootstrap 主题开发的辅助工具。

如何找到需要修改的变量

Bootstrap 在文档中针对每一个 Component 都提供了相应的 Sass Variables 的说明,你只需要在文档中找到你要修改的组件, 并在你自己的 global.scss 中修改对应的变量,就可以实现自定义。

如何找到特定类的源码

在进行 Bootstrap 开发的时候,如果有些类你找不到样式的时候,一个很好的方式是开启开发环境,并在开发环境中可以看到对应的 scss ,并在对应的 scss 当中,点击链接跳转到对应的 scss 定义,即可看到对应的样式的源码。

在跳转后,有些时候你发现似乎并不是直接定义的样式,比如下图,则说明这样的类是通过 map 来批量生成的,你就需要修改对应的 map 来完成自定义。

如何自定义主题颜色、字体大小、间距等批量生成的类

在 Bootstrap 中存在一些批量生成的类,比如 theme-colorfont-sizefont-weight 还有 paddingmargin 等等。

这些类是 Bootstrap 使用 @each 来生成的,而生成的依据,则是 Bootstrap 的各种 map 来完成的。因此,你想要进行定义,则需要修改对应的 Map。你可以使用 map-merge 来向 map 中添加新的选项

// Create your own map
$custom-colors: (
  "custom-color": #900
);

// Merge the maps
$theme-colors: map-merge($theme-colors, $custom-colors);

而如果你想要移除一个选项,则可以使用 map-remove 方法来完成

// Required
@import "../node_modules/bootstrap/scss/functions";
@import "../node_modules/bootstrap/scss/variables";
@import "../node_modules/bootstrap/scss/maps";
@import "../node_modules/bootstrap/scss/mixins";
@import "../node_modules/bootstrap/scss/root";

$theme-colors: map-remove($theme-colors, "info", "light", "dark");

// Optional
@import "../node_modules/bootstrap/scss/reboot";
@import "../node_modules/bootstrap/scss/type";
// etc
OneInStack 中 Redis 的使用注意事项

OneInStack 中 Redis 的使用注意事项

在使用 OneInStack 时,有一些事项需要注意,不然可能会导致你的 Redis 在使用过程中出现问题。

1. Redis 默认配置内存是 122 MB

OneInStack 中 Redis 的默认内存配置是比较小的,只有 122MB ,对于一些大型应用来说,是肯定不够的,因此,在实际使用过程中,还是最好将其修改为一个更大的值。

配置文件路径: /usr/local/redis/etc/redis.conf

需要修改的项目 maxmemory 122000000,将 122000000 修改为 256000000 即可将 Redis 使用的内存设置为 256 MB,从而扩大了整体可用的内存的大小,应对大型数据库也游刃有余。

2. Redis 的逐出机制为 noeviction

OneInStack 中 Redis 的默认逐出机制是 noeviction,即内存满后不逐出,写入缓存报错,读缓存不受影响。

对于将 Redis 作为数据库的场景而言,这么干是正确的。但对于做缓存的场景,则需要修改逐出机制,比如可以将逐出机制修改为 allkeys-lru,即在全部的key中淘汰最近最少使用的key。

在配置文件( /usr/local/redis/etc/redis.conf)中加入一行配置即可

maxmemory-policy allkeys-lru
MySQLDump 导出部分数据

MySQLDump 导出部分数据

MySQLDump 是非常常用的数据库导出工具。不过,大部分时候,我们使用的都是 mysqldump -uuser -p database_name > database_name.sql

这样可以提供数据导出功能,但导出的数据会是全表数据,我们在导出数据的时候,如果希望导出部分数据,就需要借助于其中的 --where Flag,来实现导出部分数据.

此外,由于导出的数据是部分数据,因此,就涉及到需要指定导出时的表名,才能实现导出相应的数据,需要满足如下格式

mysqldump [OPTIONS] database [tables]

举个例子来说,假设我们需要导出数据库 wordpress 的 wp-options 表中的 ID 小于 20 的数据,则需要执行如下命令:

mysqldump --where="id < 20" wordpress wp-options

上述命令就实现了从数据库中导出符合特定要求的数据。

Next.js 实现动态引入,实现对非 SSR 组件的支持

Next.js 实现动态引入,实现对非 SSR 组件的支持

在使用 Next.js 进行开发的时候,会遇到某些组件是不提供 SSR 支持的(很正常,毕竟 SSR 是一个相对比较小众的应用场景。此外,某些组件会依赖浏览器环境的上下文),在这种情况下,我们需要一种方式来实现对非 SSR 组件的支持。

一般而言, 有两种方式,一种是使用 useEffects 来控制组件的载入,从而实现只在客户端层面加载组件,服务端渲染的时候就不再加载该组件。

另外一种方式是可以考虑借助于 Next.js 自带的 Dynamic Import 的特性,来完成组件的引入。

在使用层面比较简单,引入组件的方式从直接引入改为最外层套一层 dynamic 函数即可

import dynamic from 'next/dynamic'

const DynamicComponentWithNoSSR = dynamic(
  () => import('../components/hello3'),
  { ssr: false }
)

function Home() {
  return (
    <div>
      <Header />
      <DynamicComponentWithNoSSR />
      <p>HOME PAGE is here!</p>
    </div>
  )
}

export default Home

总结

这个问题的解决让我再次激起了对于 Next.js 的兴趣。过去因为不确定如何解决在浏览器和客户端环境下的问题,对于 Next.js 有些畏难;如今问题已解决,可以继续放心的使用 Next.js 了。

参考阅读

https://nextjs.org/docs/advanced-features/dynamic-import

那些影响你前端开发体验的问题(1)

那些影响你前端开发体验的问题(1)

最近在研究和体验一些 GitHub 上的前端项目,遇到了一些让人体验不佳的点, 这里梳理一些我遇到的,一方面是留存,记录那些让我体验不好的事情。另一方面警示自己在开发前端项目的时候应该注意一下开发体验,确保不会让别人在开发的时候也遇到这些问题。

1. 项目应该有文档

这是不少 GitHub 上面项目的普遍问题。现有的文档要么是以 Framework 生成的 Readme 为主,要么直接没有文档。

但没有文档对于后来者的开发其实非常不友好,比如几个常见问题:

  1. 如何启动一个 Server & 如何设置后台 API 的 Prefix?
  2. 项目的组织结构是什么样的?
  3. 涉及到的第三方服务应该如何配置?

上面这些文档是帮助后来者快速使用你的项目所必需的(换句话说,如果你要做开源项目,想要打造开源社区,这也是必要的)。

2. 项目控制算法复杂度

我在开一些前端项目的时候,明显会感到浏览器的响应变慢了,我以为是我的 Mac Mini 2012 性能不行。但我打开自己的博客,依然如丝般顺滑,我就明白了。问题不在于我的电脑性能跟不上,而是这个前端页面加入了大量的有用或无用的代码,使得 CPU 需要大量的计算。

虽然进入 SPA 的时代以后,我们开始将算力的使用从服务端往客户端转移,但也建议各位工程师控制自己项目的复杂度,不要一开网页,风扇就呼呼的转。浏览体验不好,还凸显自己的技术不行。

3. 使用 debuuger 调试,而不只是 console.log

在编译型语言当中,使用 Debugger 来进行调试是一项基本技能,因为需要在运行时去看不同的变量的值,以此来完成调试。

爆炸的 Console

但在前端领域,因为 console.log 的过于好用,大家开始习惯于使用 console.log 来打印变量,但对于大型项目来说,大量的 console.log 也会让你的项目输出许多无意义的内容,让整个项目的调试和开发受到阻碍。

总结

最近看项目,总结了三条自己觉得影响体验的点,后续随着看的项目的深入,会逐渐总结出更多影响体验的点,引以为鉴。

WordPress Contact Form 7 的正确用法

WordPress Contact Form 7 的正确用法

Contact Form 7在实际使用过程中,有些人为了简化表单的设计和使用,会选择直接在多个地方使用同一个表单,并通过页面选择器来实现不同的样式(常见于基于 Elementor 构建的页面)。

但这样会造成长期的可维护性问题:

  1. 每个页面单独写样式选择器来控制样式,且在样式命名方面没有习惯的话, 会导致页面的样式混乱,修改成本较高。
  2. 不同的页面的样式采用了相同的类名,在进行样式修改时,交接性极差。

如果想要解决这个问题,有两个方式:

  1. 规范页面样式类规范:不同风格和样式的按钮采用不同的类名,如(.blueBtn.yellowBtn);
  2. 多处使用的表单,采用复制的方式,而不是使用同一个表单:Contact Form 7 提供了 Duplicate 功能,可以非常方便的复制一个表单,并根据表单的位置来命名。降低配置表单的成本。
Duplicate 一个表单
从一封钓鱼邮件聊起:针对普通人的钓鱼邮件设计

从一封钓鱼邮件聊起:针对普通人的钓鱼邮件设计

收到了一封钓鱼邮件,刚好最近没有什么内容要写,就聊聊这一封钓鱼邮件。

我收到的这一封钓鱼邮件是这样的

接下来看看里面的钓鱼邮件设计的三个巧妙之处:

1. 针对独立域名的钓鱼邮件

我的对外的邮箱目前使用的是 bestony@linux.com 的邮件,而由于 Linux.com 邮箱设计,实际上并不会有一个邮箱给你使用,而是你可以选择一个邮箱地址,系统会将发送到这个地址的邮件自动转发给你,我将邮件转发到了我自己的 Google 邮箱当中。

所以实际上我收到的邮件有两种:以 gmail 地址收到的邮件和以 linux.com 地址收到的邮件。

可以看到,上面的这个邮件当中我的收信地址是 linux.com 的地址,而不是我的 gmail 地址。

这正是这封邮件设计的巧妙之处:为特定人群发送特定内容的钓鱼邮件。试问自己:如果你的 QQ 邮箱收到了上述的邮件,你会把他当成是企业给你发送的安全邮件么?显然不会,因为你知道, QQ 不会给你发送这样的邮件。

但如果你的邮箱刚好是一个自定义域名,且刚好你所在的企业的 IT 并没有拦截到这封邮件,那么这封邮件对于那些安全意识不高的人来说,马上就会中招。

2. 使用了一个内网的地址来降低警惕度

对于绝大多数人来说,可能对于内网地址和外网地址没感知。可能直接就点击进去了。但对于一些对于计算机网络略有耳闻的人来说,可能会熟记的一个地址是 192.168.0.1,这个地址被不少的路由器作为默认的地址和网关地址来使用,从而成为不少人的心中的安全地址。

邮箱中的 192.168.22.23 这个地址就会让一些人放下警惕,然后点击进去查看内容 —— 然后成功的掉进陷阱中。实际上邮件只是用内网地址来作为一个表面展示的文字,真正的链接地址是 http://szfdxled.com/function/uploadfile/20220412/20220412000529_78464.html#bestony@linux.com

这提醒了我们,如果邮件当中有链接,最好复制出来,而不是直接点进去(说不定别人替换了呢?)

3. 自动识别的邮箱域名

我点击链接进去以后注意到,他在顶部加入了对应的邮箱域展示和 Icon 的展示。设计的挺巧妙。

如果点击进去展示的是无关的域信息,可能你也不会点击进去查看。但如果展示的是你自己的邮件域,会进一步放松警惕(特别是你以为你点击进去的其实是 192.168.xxx.xxx 时)。

对于意识不太强,或者平时不常使用网页版的人来说,可能真的就直接输入账号密码登录了。我还试了试,如果把 URL 后缀的邮箱域修改了,还会自动替换邮箱域和对应的 icon(应该是抓的 favicon,但不知道为啥抓到的是这个。

不过,也有一些设计的比较蠢的地方

1. 用了 Reply To 的字段暴露了自己的信息

在看这封邮件的时候,我注意到他设定了 Reply To 字段。Reply To 当中暴露了自己的 QQ 邮箱。

然后我搜了一下,发现能搜到这个人,看起来似乎还像是正常使用的 QQ 号。。。如果是一个经验丰富的 Cracker ,可能会选择使用一个更加安全的沟通方式。

总结

这封钓鱼邮件中给我不少的启发,里面的一些设计也很有意思。但对于有充足安全意识的人来说,这些问题确实都可以规避掉,从而不受诈骗的影响。此外,Cracker 的产品设计值得我们学习,一些好的设计,确实可以帮助用户更省事。