WordPress常见的所见即所得(拖动)编辑器统计:
- Elementor
Elementor用户量最大,功能最多,但是也略臃肿。
- WPBakery
WPBakery应该是好评最多的编辑器。
- Oxygen Builder
引用别人的一句话是:Oxygen is NOT a page builder is a THEME BUILDER…Big difference. 不仅仅是编辑器,还可以自己制作主题。
- Divi Builder
貌似是后出来的?好评不少。
WordPress常见的所见即所得(拖动)编辑器统计:
Elementor用户量最大,功能最多,但是也略臃肿。
WPBakery应该是好评最多的编辑器。
引用别人的一句话是:Oxygen is NOT a page builder is a THEME BUILDER…Big difference. 不仅仅是编辑器,还可以自己制作主题。
貌似是后出来的?好评不少。
Astra:https://wpastra.com/
毫无疑问,Astra是用户量最大的wordpress主题,即使是免费版的主题都很好。
GeneratePress:https://generatepress.com/site-library/
基于wordpress古腾堡的主题
Blocksy: https://creativethemes.com/blocksy/
The Most Innovative, Lightning Fast And Super Charged Free WordPress Theme.
INSERT INTO wp_posts (post_title,post_content,post_author,post_date,post_excerpt,to_ping,pinged,post_content_filtered,guid,post_type,post_status,post_mime_type) VALUES ('[标签:标题]','','[标签:authorid]','[系统时间转化:yyyy-MM-dd HH:mm:ss]','','','','','[标签:img-url]','attachment','inherit','image/[标签:image-type]');
INSERT INTO wp_postmeta(post_id,meta_key,meta_value) VALUES ([文章编号:wp_posts]-1,'_thumbnail_id',[文章编号:wp_posts]);
INSERT INTO wp_postmeta(post_id,meta_key,meta_value) VALUES ([文章编号:wp_posts],'_wp_attached_file','[标签:img-url-2]');
INSERT INTO
wp_term_relationships (object_id,term_taxonomy_id)
VALUES
('[文章编号:wp_posts]','[标签:catid]'),
('[文章编号:wp_posts]','[标签:catid2]'),
('[文章编号:wp_posts]','[标签:catid3]');
但是火车采集不支持这种SQL写法,会报错,只能每次插入一行,分开写。
set @var=[文章编号:wp_posts];
INSERT INTO wp_postmeta ( post_id,meta_key,meta_value)
VALUES
(@var-1,'_wp_attached_file','shows/[标签:img]'),
(@var-1,'_movie_poster',@var);
但是,火车采集同样不支持set变量。不过可以直接用减法运算:
INSERT INTO wp_postmeta(post_id,meta_key,meta_value) VALUES ([文章编号:wp_posts]-1,'_movie_poster',[文章编号:wp_posts]);
有时需要更新wp_posts补全其他字段,否则会报错:
INSERT INTO wp_posts (post_title,post_content,post_author,post_name,post_date,post_excerpt,to_ping,pinged,post_content_filtered) VALUES ('[标签:标题]','[标签:内容]','[标签:authorid]','[标签:slug]','[系统时间转化:yyyy-MM-dd HH:mm:ss]','','','','');
用的比较多的时posts和category、tag之间的对应关系,经常容易搞错,我做了个说明图,一目了然。
//设置sysuser_account表从88开始自增
alter table sysuser_account auto_increment=88;
下面这段代码会将文章中第一张WordPress附件图片设置为特色图像,附件图片是指上传到WordPress的图片,不需要和当前的文章有关联。
function sola_auto_featured_image() {
global $post;
if( has_post_thumbnail() ){
return;
}
preg_match('/<img\s[^>]*?class\s*=\s*[\'\"]([^\'\"]*?)[\'\"][^>]*?>/', $post->post_content, $matches);
$img_class = $matches[1] ?? false;
if( $img_class ){
preg_match('/wp-image-([\d]+)/', $img_class, $matchId);
$attachment_id = $matchId[1] ?? false;
if( $attachment_id ){
set_post_thumbnail($post->ID, absint($attachment_id) );
}
}
}
add_action('the_post', 'sola_auto_featured_image');
add_action('save_post_post', 'sola_auto_featured_image');
注意:add_action(‘the_post’, ‘sola_auto_featured_image’)会使这段代码在任何文章被加载时运行,比如archive页面,single post页面等等。好处是被人访问一段时间,你的所有文章就自动获得了特色图像,坏处就是对性能有影响。当你的特色图像设置的差不多时,应该将这一句注释掉。
继续阅读之前有写关于wordpress优化的文章:
使用下来,Opcache+Memcached+WP Rocket组合效果非常好,但是无意间发现,原来这整个组合,也没有让wordpress侧边栏被缓存,也就是说,wordpress侧边栏是动态查询的,尤其是如果侧边栏有相关推荐,等动态内容的时候,每次打开页面wordpress都会动态查询数据库,即使用了 Opcache+Memcached+WP Rocket ,也不会缓存侧边栏。
update:关闭WP Rocket预缓存,就可以缓存侧边栏,原文连接在文章结尾;
同时,下面的方法对于开启wordpress多站点的,会有问题,可能会出现因跨域加载而页面混乱。
网上找到我爱水煮鱼关于缓存侧边栏的文章,试验下效果不错。但是他的代码有几个语法错误,保存后会报错,网上其他人抄代码的,竟然都没有指出错误,错误代码一起抄!!
我已经修改过来了。
<?php
$sidebar_html = ABSPATH . "wp-content/cache/sidebar.txt";
$have_cached = false;
if (file_exists($sidebar_html)){
$file_time = filemtime($sidebar_html);
if (($file_time + 3600) > time()){ //缓存1小时
echo "<!-- cached sidebar -->";
echo(file_get_contents($sidebar_html));
echo "<!-- end of cached sidebar -->";
$have_cached = true;
}
}
if(!$have_cached){
ob_start();}
?>
在 sidebar.php 结尾加入以下代码:
<?php
$sidebar_content = ob_get_contents();
ob_end_clean();
$sidebar_fp = fopen($sidebar_html, "w");
if ($sidebar_fp){
fwrite($sidebar_fp, $sidebar_content);
fclose($sidebar_fp);
}
echo $sidebar_content;
?>
继续阅读
Update: 如果wordpress按照第三方来历不明的主题或者插件,提示open_basedir restriction in effect错误,一定得注意,该主题或者插件,很有可能有后门,包含恶意跨站攻击病毒。
wordpress下载的第三方插件,上传安装的时候,一直提示如下相关错误:
Warning: scandir(): open_basedir restriction in effect. File(/www/wwwroot) is not within the allowed path(s)
开始以为环境配置问题,调整了很久,换了不同服务器测试,也都是这个错误。
网上查询,原来只需要关闭宝塔面板中的“防跨站攻击”即可。
继续阅读火车采集到的数据,直接数据库发布,比之前web接口发布,要高效很多很多,而且不太消耗服务器资源,高效!
INSERT INTO wp_posts (post_title,post_content,post_author,post_name,post_date) VALUES ('[标签:标题]','[标签:内容]','1','[标签:slug]','[系统时间转化:yyyy-MM-dd HH:mm:ss]')
INSERT INTO wp_term_relationships (object_id,term_taxonomy_id) VALUES ('[文章编号:wp_posts]','[标签:catid]')
INSERT INTO wp_postmeta (post_id,meta_key,meta_value) VALUES ('[文章编号:wp_posts]','[标签:自定义字段]','[标签:自定义值]')
若是单表或多表无关联,则直接写INSERT语句即可;
若是多表,且存在某字段相互关联,则用 文章编号:表名XXX] 来关联上一个表的自增ID;
代码1:slug标签为URL别名,自定义url别名有利于seo,更重要的是可以给采集来的数据添加内部链接。
代码2:是给添加的文章归类;catid标签可以是一个固定值,直接从采集结果中传递过来。
代码3:给文章添加自定义字段。
WordPress添加https后出现的错误,有两种情况,我都遇到了。
网上找了很多方法,最有效的解放方法是修改wp-config.php,找到如下代码:
**
@package WordPress
*/
在下方添加如下代码:
$_SERVER['HTTPS'] = 'on';
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);
搞定。
有一个网站,文章即将突破100万+,前端、后台都极其卡顿,尤其是在搜素文章的时候,CPU陡升。网上找了一些优化教程,最后实验下来,最有效的终极方案是Opcache+Memcached+WP Rocket组合,加上用Relevanssi Search建立搜素索引。
如果是宝塔,直接在后台安装Opcache和Memcached即可,简单。以下以军哥的lnmp为例。
Memcached 是一个高性能的分布式内存对象缓存系统,用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数,从而提供动态、数据库驱动网站的速度。
安装
进入lnmp解压后的目录,执行:./memcached.sh
回车确认后就会自动安装memcache php扩展和memcached。
开启Memcached后需要将PHP Memcached 扩展object-cache.php 文件复制到 wp-content 目录下,注意不是 wp-content/plugins/。
可以参看这篇文章:https://blog.wpjam.com/article/wordpress-memcached/
opcache是php代码层缓存,memcached是数据层缓存。
此脚本是用来安装opcache的,是 Zend 开发的闭源但可以免费使用的 PHP 优化加速组件。
安装
进入lnmp解压后的目录,执行:./opcache.sh
回车确认后就会自动安装opcache。
最后是安装WP Rocket,网上有相关的破解版。
2022.5.15 update:文章量级超过百万了,Relevanssi Search也不能满足了,直接上Elasticsearch解决wordpress搜索难题。
直接在wordpress后台搜素Relevanssi Search插件并且启用设置。
这个组合,对于文章量级比较大的wordpress站点,优化效果非常明显。
宝塔会经常容易漏掉Memcached的PHP扩展。有人说要先安装Memcached的PHP扩展,再安装Memcached,否则不起作用,我没有验证过。正确保险的安装顺序是:
另外,如果同台服务器有多个wordpress站点,应该怎么同时使用 Memcached?参考:https://m.wpjam.com/m/memcached-for-sites-in-same-host/
参考:https://www.dazhuanlan.com/2020/01/17/5e213a18be00e/
WordPress其他优化技巧:https://tlanyan.pp.ua/wordpress-performance-optimization/