默认情况下,WordPress 搜索结果显示发布的文章和页面,如果想把页面从 WordPress 搜索结果中排除,可以在当前主题的 functions.php 文件中添加如下的函数:
在 WordPress 中,使用 WP_Query 进行文章查询是最常见的操作,学习好这方面的操作, WordPress 开发基本就学会了一半。
在自己代码的函数中使用 require(BASE_PATH . 'wp-load.php'); 引入 WordPress 核心代码,然后执行 WP_Query 获取特定的日志,然后就发生下面的错误:
WP_Query 是 WordPress 中最重要的 class,几乎每个页面都是用它来获取文章,但是它最大的问题是,对文章进行查询的时候是直接到数据库查询的,结果没有被缓存起来,所以真正实现站点的 0SQL 就是这里。
WP_Query 的 orderby 参数用于告诉获取的 Posts 是基于哪列进行排序的,默认是 post_date,并且 WP_Query 的默认排序顺序是降序,就是最新发布的日志排在前面。
我之前的「WordPress 文章查询教程6:如何使用排序相关的参数」中详细介绍了文章查询的排序参数,其中介绍可以通过评论数进行排序:
英文:Delicious Brains,翻译:开源中国 www.oschina.net/translate/sql-query-optimization 📷 你一定知道,一个快速访问的网站能让用户喜欢
WordPress 6.1 的时候通过提高 WP_Query 查询性能真正实现站点 0 SQL,现在 WordPress 6.2 将性能要求做到更加极致,将弃用 get_page_by_title() 函数,建议开发者直接使用 WP_Query 根据标题获取页面。
在这篇文章中,我将介绍如何识别导致性能出现问题的查询,如何找出它们的问题所在,以及快速修复这些问题和其他加快查询速度的方法。 📷 你一定知道,一个快速访问的网站能让用户喜欢,可以帮助网站从Google
前言 你一定知道,一个快速访问的网站能让用户喜欢,可以帮助网站从Google 上提高排名,可以帮助网站增加转化率。如果你看过网站性能优化方面的文章,例如设置服务器的最佳实现、到干掉慢速代码以及 使用CDN 加载图片,就认为你的 WordPress 网站已经足够快了。但是事实果真如此吗? 使用动态数据库驱动的网站,例如WordPress,你的网站可能依然有一个问题亟待解决:数据库查询拖慢了网站访问速度。 在这篇文章中主要介绍如何识别导致性能出现问题的查询,如何找出它们的问题所在,以及快速修复这些问题和其他加快
wordpress默认会根据网址调用数据,不能满足我们所有建站要求,而WP_Query可以用于查询任何你想要的内容,相当于自定义数据调用。
自定义调用文章在网站建设中很常用,wordpress也很人性化,用新建查询new WP_Query就能实现相关功能。WP_Query怎么用呢?随ytkah一起来看看吧
Query_posts语句是WordPress最实用的语句之一。 正是在query_posts的作用下,WordPress的Loop循环才能够调用并显示所有文章内容。 Query_posts的魅力在于,它可以根据你的要求,通过各种各样的方式灵活地检索并过滤日志或页面。你可以用query_posts进行简单的文章抓取,可以只抓取一篇,也可以抓取上百篇。 而说到复杂点的用法,你甚至可以利用query_posts来查询某一分类目录下某个作者发表的、带有某个标签的特定数量文章等。下面介绍的是一些更实用的用法。
最近想给自己的博客实现一个 站内搜索 功能,期望整个过程异步实现。这样用户体验度更好。
我其实一直挺困扰《每周歌词》的展示问题。原本这个栏目是我高中时期为了做站点SEO,保证博客能按时更新设定的。所以这个系列一开始都更新的很潦草,甚至大部分是在返校路上写出来的,完全没有质量可言。但是现在我已经有充足的时间更新博客虽然我也不更新,所以也越来越重视《每周歌词》的质量。如今的《每周歌词》已经逐渐变成我个人对某首歌曲和它歌词的感悟了。但是原先存在着的大量《每周歌词》非常占用首页空间,让技术相关的文章都难以找寻,这就违背了这个博客的初衷了。我曾经也尝试了很多种办法以解决,比如单独开子博客(因为数据太难迁移放弃),还有写一篇专门用来推荐的文章索引(因为懒得更新放弃),但是这些办法都不尽如人意。
前面我们介绍了 WordPress 的主循环和全局变量,那么如果需要自定义 WordPress 查询进行一些事情,可以有两种方法,最容易的方法是使用 query_posts 函数,另外一种方法就是自定义 WP_Query。
虽然玩wordpress,但对wordpress和php内部了解不多,这篇文章算是自己的视野扩展吧,不足之处,欢迎指出,老规矩,能力强的可以直接读原文。
有时我们在开发wordpress时需要调用置顶文章sticky_posts,怎么调用呢?几种写法,有用到query_post的,有用到WP_Query,也有用到is_sticky(),下面随ytkah一起来看看吧
该功能已经整合到 WPJAM Basic 插件中,并已免费提供下载,简单勾选或者设置下即可开启!
今年 10 月,我们收到了来自 GiaoHangTietKiem JSC 的 ngocnb 和 khuyenn 的报告,涉及 WordPress 中的 SQL 注入漏洞。该漏洞可能允许攻击者暴露存储在连接数据库中的数据。此漏洞最近被解决为 CVE-2022-21661 ( ZDI-22-220 )。该博客涵盖了该错误的根本原因,并着眼于 WordPress 团队如何选择解决它。首先,这是一个演示该漏洞的快速视频:
我们使用 WP_Query 进行文章检索的时候,可以用使用 orderby 参数对检索到的文章进行排序,比如使用 ID 排序
我们在使用 WP_Query 或者 query_posts 进行日志查询的时候,WordPress 都会产生很多 SQL_CALC_FOUND_ROWS 的 SQL 查询。
从2004年的1.0版本算起,WordPress在14年间已经迭代开发到了5.x版。如果说这中间哪个版本是一个质的提升的话,那应该算是2010年发布的代号为Thelonious 的 3.0版。这个版本发布了很多重要的功能,比如多站点、主题API等等,其中一个就是 Custom Post Type(自定义文章类型)。
前面罗列过 WP_Query 的所有参数,今天研究 WP_Query 的缓存,把所有相关的缓存参数都翻了一遍,做一下简单笔记。
今天ytkah在看客户的网站时发现头部提示Warning:Parameter 2 to qtranxf_postsFilter() expected to be a reference, value given in ...,出现这个原因是翻译插件定义有问题,那我们一起来看看如何修改吧
WordPress 安装 Memcached 之后,WordPress 的文章页,基本上可以做到 0 SQL 请求,但是首页或者其他列表页总是有两条 SQL 请求,怎么优化呢?
子凡把泪雪的相关推荐功能进行了重写,将原来的文章相关推荐功能做了自我感觉非常优秀的改进,相比用其它 WordPress 相关文章推荐的插件来说,我更喜欢自己来折腾,经过这一番的重写 WordPress 相关推荐,泪雪的相关文章推荐已经得到了更加完善的推荐适配。
想要使用 REST API 需要自己额外安装插件:WordPress REST API,现在 WordPress 5.0以上的版本已经默认支持 REST API了,不需要额外去安装插件。
WP-Super-Cache 作为 WordPress 的老牌静态缓存插件,它在 WordPress.Org 的一个角落一直有一份 Nginx 伪静态规则(Nginx – WordPress.org Forums)。
原来的博客系统使用的是Typecho,一个轻量、高效、快速的博客系统(至今也是)。但是Typecho的正式版已经很久没有更新,其中部分功能甚至无法兼容PHP 7;开发版虽然仍在坚持更新,但是也容易与各种过老的插件和主题产生兼容问题,并且社区的活跃度也略低,开发兴趣不高,最终导致的结果就是插件和主题不够多,功能实现全靠自己写的情况。而现在将全站迁移至WordPress也是无奈之举,一方面是更好的生态,意味着更多插件和主题选择,减少了重复造轮子魔改程序的情况,另一方面是WordPress有更频繁的更新频率,漏洞和Bug能更快得到修补。(等啥时候Typecho重出江湖我就换回来?)
WordPress本质上是一个内容管理系统(CMS),是显示、创建、发布和维护内容的软件。
例子: [is_archive] => 1 归档类页面 [is_catgory] => 1 分类目录的页面
由于我们可以在后台使用wp query来输出文章列表,所以我们并不需要文章分页的入口,砍掉了分页入口也避免了搜索引擎抓取这些页面。我们只需要在AJAX 执行的过程中向后台传递一个分页参数,就可以返回这个分页上的文章列表。再返回文章列表的时候,我们还需要返回下一分页的页码,当然如果不是最后一页的话。
但是返回的结果总是超过这个 138, 139 这两篇,甚是奇怪。后面仔细查看文档,才发现有如下这段话:
Wordpress它是世界上 最常用的开源CMS之一,在允许开发者自己构建插件和主题来管理网站的时候,由于它的便利性而被大量使用,wordpress的核心会提供插件/主题的功能来调用和使用wordpress提供的数据格式、查询数据库等功能。
要想防止网站被恶意采集,那么就需要了解大多数的采集方式和规则,这样才能够反其道而行之的去屏蔽和防采集,有时候我们辛辛苦苦写的一些文章或者大批量的文章内容成为了别人的嫁衣,同时别人采集还增加服务器负担,想想就觉得不值得啊。
领取专属 10元无门槛券
手把手带您无忧上云