189 8069 5689
如果不想通过代码实现隐藏可选文章和页面的标题，可以安装并激活
创新互联-云计算及IDC服务提供商，涵盖公有云、IDC机房租用、成都温江机房、等保安全、私有云建设等企业级互联网基础服务，咨询热线：18980820575
WordPress
Hide
Title
plugin插件
，在相应页面或文章的编辑窗口中，点击WordPress管理下的文章和页面菜单下需要编辑的项目即可。在编辑窗口下，有一个隐藏标题的自定义区块：
你要做的就是选中这个复选框并单击更新或发布按钮，插件将隐藏单次PV上的标题。这意味着，主页或其他分类页面上仍然会显示，只是单次PV上不再显示了。
如果你希望创建一个简单的、不显示文章标题的登录页面，这种方法确实非常方便。
隐藏所有的WordPress文章和页面标题
如果你想隐藏单一页面上所有的文章和页面标题，可以通过修改主题来实现。
最简单的方法就是在WordPress的
functions.php
文件中加一段下面的代码：
这个过滤器只是在显示单一文章或页面时的
post_class()function
中增加了一个类
.hidetitle
。但是，这个过滤器只有在WordPress主题支持post
class的情况下有效。如果你希望只对文章有效，就删除代码中的
||
is_page()。
添加这个function之后，还需要在主题样式表中添加这个CSS规则。
在上面的CSS中，我们使用了显示CSS属性来隐藏文章和页面标题。但是，这个CSS规则仅适用于WordPress主题使用的文章和页面标题是条目标题（
entry-title
）。在谷歌Chrome浏览器中打开文章，将鼠标移到文章标题上，右键单击并选择审查元素，你会看到页面的源代码中文章标题的代码，其中就有你WordPress主题所使用的CSS类。
如果主题使用
article-title
作为文章标题的CSS类，只需要如下简单更改CSS：
以上方法适用于大部分WordPress主题。但是这些方法只是隐藏标题并不能阻止加载这些标题。如果你想移除WordPress主题模板上的文章和页面标题，就需要删除主题文件中的the_title代码了。
如果你只是希望在单一PV上实现，那只需要在single.php文件中修改。
WordPress 的性能团队发布了一项功能提案，该提案将默认启用 WebP 图像，扩展对现代图像格式的核心支持。
2021 年 7 月，WordPress 5.8 引入了 WebP 支持，允许用户在其内容中上传和使用 WebP 图像。如果提案获得批准，6.0 版将默认为新的 JPEG 上传生成 WebP 图像，并默认为网站内容使用 WebP 图像。
“WebP 被开发为一种现代图像格式，可在网络上提供卓越的压缩，”WordPress 核心贡献者 Adam Silverstein 在功能提案中说。 “图像通常是网站使用的最大资源之一，使用 WebP 可以创建更轻、更快的网站。与 JPEG 图像相比，WordPress 生成的 WebP 图像几乎总是更小，文件大小平均减少约 30%（具有相同的视觉质量）。”
在默认启用 WebP 的情况下，WordPress 用户不会对其通常的图像上传工作流程进行任何更改。 WordPress 会在后台自动将 JPEG 上传转换为 WebP 并在网站上使用它们。
根据 Can I Use，94.25% 网络浏览器支持 WebP 图像格式。极少数浏览器，例如 Internet Explorer 11 或 MacOS v11 Big Sur 上的 Safari，不支持 WebP。 提议的功能将附带两个过滤器来控制或禁用 WebP 上传，并且将创建一个用户友好的插件来做同样的事情。 尽管有显着的性能优势，但对功能提案的支持并非没有人反对。参与讨论的几位贡献者对不支持 WebP 的电子邮件客户端和社交媒体平台表示担忧。
“由于之前评论中提到的所有原因，我觉得 WebP 还没有准备好成为 post_content 中的‘硬编码默认’，”Kaspars Dambis 说。 “许多网络客户端（不仅仅是浏览器）不支持 WebP 格式——RSS 客户端、电子邮件客户端、智能电视、电子书阅读器、开放图形解析器、桌面图像查看器等。这些都是网络的重要用户。” Silverstein 回答了这些问题，确认 WordPress 将一如既往地继续生成 JPEG 图像的尺寸。
“关于此功能没有改变的一个重要说明：JPEG 子弹大小仍会生成并存储在相同的元字段中，”他说。 “出于这个原因，例如 RSS 提要或 REST 媒体端点或 OG 标签的消费者将继续使用 JPEG 小尺寸版本。” 性能团队的贡献者将 WordPress 6.0 定位为默认启用 WebP，并正在寻求图像组件维护者的批准。欢迎任何人通过安装 Performance Lab 插件并激活“WebP Uploads”模块来测试该功能。鼓励考试人员在 Trac 票证或 Pull Request 上留下反馈。
新建一个插件
这个部分告诉你怎么把开发插件的理想变为现实。
名称，文件和地方
插件名
你得先想一个名字，并且努力让它独一无二。在 Plugins 或者其他宝贝地方——Google或者百度先验证一下这个名字到底是不是独一无二的。另外你的名字得让别人明白你的插件是干什么的。
插件文件
下一步是创建一个PHP文件。按照原文奇怪的逻辑，你得先想好名字。这个名字还得是从插件名衍生过来的（其实是为你自己辨认的）。举个例子吧，比如说你的插件名字叫 "Fabulous Functionality",你的PHP名字可能是 fabfunc.php。另外不要用汉语拼音（这也是我加的），还要避免重名。人民群众会把你的插件安装到一个你也知道的叫wp-content/plugins/的地方,如果名字冲突岂不要悲剧了。
你也可以选择把插件分割成几个文件。 显而易见一个php文件是必需的，同时还需要图片、CSS、JavaScript、语言（当然也可以没有）。如果有很多文件，命名一个php和一个文件夹，例如 fabfunc and fabfunc.php。把你所有插件文件放到文件夹里，然后让你的用户相信只要把你的整个压缩包解压到 wp-content/plugins/就能正常使用你的劳动成果。
在本文的其余部分，“插件的PHP文件”是指主要插件的PHP文件，无论是在的wp-content/plugins/或子目录。
Readme文件
如果你想将你的插件发布到, 你必须在插件包中建立一个标准格式readme.txt文件. 文件格式参见.
主页
最好为插件建立一个主页，以介绍插件的功能、安装方法、使用说明、适用的WordPress版本、插件更新信息等。
文件Headers
现在开始吧，首先让我们从向PHP主文件中加入一些信息
标准插件信息
插件的主文件顶部必须包括一个标准插件信息头。WordPress通过标准信息头识别插件的存在，并把她加入到控制面板的插件管理页面，这样插件才能激活，载入插件，并运行里面的函数；如果没有信息头，插件将无法激活和使用。标准信息插件头的格式为：
?php
/*
Plugin Name: 插件名
Plugin URI: 插件的介绍或更新地址
Description: 插件描述
Version: 插件版本，例如 1.0
Author: 插件作者名称
Author URI: 插件作者的链接
License: A "Slug" license name e.g. GPL2
*/
?
标准信息头至少要包括插件名称，这样WordPress才能识别你的插件。其他信息将显示在控制面板插件管理页面中。标准插件信息对各行顺序没有要求。
这样的升级机制能够正确地读出你的插件版本，建议你选择一个格式的版本号，不同版本之间，并坚持下去。例如，x.x中或x.x.x或xx.xx.xxx
注意：文件必须是 UTF-8 格式！
版权信息
通常我们还要在标准信息头中加入插件的许可证信息。大多数插件使用GPL或GPLCompatibleLicenses许可。如果使用GPL许可，要求插件中包含以下信息：
?php
/* Copyright 年份 作者名 (email : 你的邮箱)
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
?
开始编写插件
现在是时候让你的插件能干些什么了。这部分内容包括插件开发的一般思路，而且介绍了开发插件需要做哪些工作。
WordPress插件钩子
许多WordPress插件通过连接一个或多个WordPress插件钩子来完成他们的功能。插件钩子的运行机理是，当WordPress运行到不同阶段，WordPress会检查当前阶段是否注册了插件函数，如果是，那么函数将被执行。通过执行插件函数改变了WordPress的默认功能。
例如，在WordPress将日志标题和post发送到浏览器前，会检查是否有插件函数注册了名为“the_title”的“filter”钩子。如果是，标题文本将会传送到注册函数中，注册函数返回值将会传送到浏览器。所以，如果要在日志标题中加入一些信息，可以通过这种方式实现。
另一个例子是名为“wp_footer”的“action”钩子。在WordPress的HTML页脚创建之前，会检查是否有插件注册了名为“wp_footer”的“action”钩子，如果是依次执行她们。
在Plugin API了解更多如何注册“filter”和“action”类型的钩子函数，及WordPress提供了那些插件钩子。如果你发现WordPress没有提供自己想要的钩子，你可以建议WordPress加入这个钩子，很多建议WordPress都会采纳。具体方法参考Reporting Bugs。
模版标签
另一个通过插件加入新功能的方法是建立自定义的模版标签Template Tags。如果有人想用你的插件，可以在他们的主题中添加这些标签，边栏，文章内容段，或者任意的只要是适合这插件的地方。例如，一个给文章添加地理位置的插件可能定义了一个模板标签函数geotag_list_states()放在边栏上，这里列表了所有在文章中关联的州的名称，并且还带有插件提供的到这些州的文档页的链接。
定义一个自定义模板标签，仅需要写一个PHP函数，并且在你插件主页或者插件的主PHP文件中声明一下。声明函数的时候，为这个函数提供一个示例来明确如果想要应用这个函数需要加主题中加些什么文件是个相当棒的主意。
保存插件数据到数据库
大多数WordPress插件需要站点的所有者或者是博客的用户输入信息，然后在对话过程中保存起来，以便过滤器函数(filter)、动作函数(action)或者模板函数(Template)使用。这些信息必须保存在WordPress的数据库中，以便下次使用。这里有两种基本的方法用于保存插件的信息到数据库里面。
使用WordPress的"option"机制（稍后会有介绍）。这种方法适合于保存一些相对小数量的静态命名类数据--这类数据通常只需要网站的所有者在首次建立插件的时候输入，以后很少改动。
文章属性post meta(a.k.a. Custom Fields)，适用于那些只和个人文章、页面或者附件有关的数据。
参看post_meta Function Examples, add_post_meta(), 以及与文章相关函数属性post.fuction meta (a.k.a. Custom Fields).
自定义分类法。对于文章分类或者其他对象，比如用户、评论，或者用户可编辑列表中的数据名称/值，可以考虑使用自定义分类法，尤其是当你要访问的所有的文章/对象与给定的分类法项目相关联的时候。查阅 Custom Taxonomies
在数据库中创建一个新的自定义数据表。这种方法适合于与个人文章、页面、附件或者评论相关的数据，这类数据会随着时间越来越多，它们也没有专有名称。参看Creating Tables with Plugins来了解更多这类信息处理方法。
WordPress的选项机制
参看 Creating Options Pages 得到更多如何创建会自动保存你选项数据的页面。
WordPress拥有一个机制来保存，更新和检索WordPress数据库中专用，名称类数据(即"options"机制)。选项值可以是字符，数组或PHP对象(他们会被"序列化"，或在存储前转换为字符，并在被检索时解开序列)。选项名称是字符，并且它们必须是独一无二的，这样就不会与其它的WordPress插件相冲突。
它也通常被认为是一个不错的主意，将你的插件使用的选项的数量降到最低。例如，考虑存储序列化数组的10个元素作为一个单一的命名选项，而不是存储10个不同的命名选项。
这里是你的插件应用WordPress option功能的主要函数。
add_option($name, $value, $deprecated, $autoload);
建立一个新的option; 如果这个option已经存在则不做动作.
$name
必须 (string). 要添加的option的名称.
$value
可选(string), 默认是空字符. option值会存在这里.
$deprecated
可选 (string), 不再被WordPress使用了,你可以不填或NULL 如果你希望应用后面的$autoload参数.
$autoload
可选, 默认为 'yes' (enum: 'yes' or 'no'). 如果设置为 'yes' 那么这个option会被get_alloptions 函数自动检索.
get_option($option);
在数据库中检索option值.
$option
Required (string). 你想返回数值的option名称。你可以Option Reference在找到一个随着WordPress一起安装好的默认option表。
update_option($option_name, $newvalue);
更新或创建数据库中的option值(注意 add_option 不是必须被调用，如果你不想作用 $deprecated 或$autoload 参数).
$option_name
必须(string). 要更新的option名.
$newvalue
必须. (string|array|object) option的新值.
管理面板
假定你的插件有一些选项(option)存储于WordPress的数据库中(参看上一节),你可能会想要一个主控面板来允许你的插件用户查看和编辑选项值。实现这一目标的方法阐述于Adding Administration Menus。
插件国际化
在你完成了你的插件的编写工作之后，另一个需要考虑的问题（假设你准备跟大家分享你的插件的话）就是将其国际化。国际化就是将你的软件设置成能够本地化的过程；本地化是将软件中显示的语言翻译成其他语言的过程。Wordpress正在被全球的人们使用，所以全球化和本地化是他内在的特性，这其中就包括了插件的本地化。
请注意，插件的语言文件是不会自动加载。将此插件代码，以确保加载的语言文件：
load_plugin_textdomain('your-unique-name', false, basename( dirname( __FILE__ ) ) . '/languages' );
要简单地取一个字符串使用 __('String name','your-unique-name'); 返回翻译或者 _e('String name','your-unique-name'); 输出翻译。翻译，然后进入你插件的 /languages 文件夹。
我们十分希望你能够将你的插件国际化，这样其他国家的用户就可以在自己的本地使用它了。我们有一个关于国际化的综合说明在I18n for WordPress Developers，这其中就包括了一个描述插件国际化的部分。
更新你的插件
本节介绍将插件托管到 之后必要的更新步骤。特别列出wordpress.org关于使用 Subversion（SVN）的一些细节。
假设你已经提交你的插件到WordPress的插件库，随着时间的推移，你可能会发现需要将某些功能添加到插件或修正错误。更新代码，并将变化提交到你的插件主干（trunk），这些变化将是公开可见的，但仅限于在技术上志同道合的人通过SVN检查你的插件。其他用户通过网站或自己的WordPress插件管理下载都不会改变。
当你准备发布一个新版本的插件：
确保一切承诺和新版本的实际工作。注意所有版本的WordPress的插件支持，并尝试与他们进行测试。不要只是测试新功能，也确保你不小心打破一些插件的旧功能。
更改主要的PHP文件头注释中的版本号为新的版本号。
更改readme.txt文件的“Stable tag”字段中的版本号。
在readme.txt文件中添加一个新的小节“changelog“，简要介绍与最后一个版本相比，新版本有什么改变。这将列出的插件页面上的“更新日志”选项卡。
提交这些更改。
创建一个新的SVN标记作为副本主干（trunk），遵循 this guide。
给系统一个运行两三分钟，然后检查你的插件，看看更新是否一切正常，以及WordPress 是否提示插件有更新（更新检查可能有缓存，比如wordpress.org插件页面或后台安装，所以这可能需要一些时间 —— 尝试访问“可用更新”页面）。
故障排除：
wordpress.org插件的页面上仍然列出旧版本。你是否更新了树干文件夹'stable tag' 字段？只创建一个标签和或更新readme.txt文件是不够的！
插件的页面提供了一个zip文件的新版本，但按钮仍然列出旧的版本号，而且WordPress 没有装更新通知。你是否已修改主要的PHP文件中“Version”版本号？
对于其他问题，请参考： The Plugins directory and readme.txt files
插件开发建议
最后这个部分是关于开发插件的一些建议。
WordPress插件的代码应该遵循 WordPress Coding Standards. 另外请同时参考Inline Documentation。
你的插件中所有函数的名称都应该与现存的Wordpress Core函数，其他插件或主题的任何名称不同。基于这个原因，我们建议你在你的插件的所有函数的名称之前加上一个你自己选择的前缀，或者把你的插件的函数都写在一个类里面（当然这个类的名字也必须是唯一的）。
请不要把Wordpress数据库表格前缀（通常是“wp_”）直接写在你的插件里，请使用$wpdb-prefix 。
虽然数据库的读取相对便宜，但它的写入是相当昂贵的。数据库十分擅长获取信息并呈现给用户，而且这些操作（通常）是非常迅速的。然而对数据库进行改动就是一个非常复杂的过程了，而且需要使用更长的计算时间。因此，请尽量减少你对数据库进行写入的次数。在你编写程序的时候就做好所有的准备，这样就可以只在必须的时候再进行写入了。
在数据库里只SELECT你需要的东西。尽管数据库的读取十分便捷，我们依然推荐你值查找真正需要的数据，来尽量减少数据库的负载。例如，如果你只想获得表格的行数，不要使用 SELECT * FROM, 因为这样的话每一行中的所有数据都会被读出，导致内存的浪费。同样的，如果在插件中你只想获得post_id和post_author，请只 SELECT 这两项来减少数据库的负载。记住：在某一个操作的同时可能有其他上百个进程需要使用数据库，而数据库和服务器都必须同时满足所有这些进程的需求。学习怎样尽量减少你的插件对数据库的使用可以避免对这些资源的滥用。
不要让你的PHP出错。在你的wp_config.php文件中添加define('WP_DEBUG',true);，对你的所有函数进行测试来确定是否有任何的错误或者警告。有多少，就修复多少，直到再也不出现为止。
尽量不要直接调用script和style标记 —— 推荐使用 wp_enqueue_style() 和 wp_enqueue_script() 函数。他们帮助消除引用重复的脚本和样式，以及引进依赖的支持。