修改WordPress 文章内分页样式

最近写了一篇比较长的隐私文章,用到了wp的文章分页功能。却发现默认的分页的页面又小又难找。于是想修改wp的默认分页,网上找了下相关的代码基本都是下面的样子:

 '

',
    'link_before'       => '',
    'link_after'        => '',
    'next_or_number'    => 'next',
    'separator'         => ' | ',
    'nextpagelink'      => __( 'Next »', 'textdomain' ),
    'previouspagelink'  => __( '« Previous', 'textdomain' ),
);
 
wp_link_pages( $args );
?>

但是我尝试了上面的方法并没有任何的效果,通过wp_link_pages( $args );传送的参数没有生效。

Continue Reading

WordPress 优化404页面

wordpress主题自带的404页面过于简单,只是显示了一个page not found,左侧区域空荡荡的,与右侧的侧边栏搭配丑的一p。于是就尝试进行改造了一下,第一次改造在404页面加了下部的随机文章。代码如下:


20, 'orderby' => 'rand', 'post_status' => 'publish' ); $rand_posts = get_posts( $args ); foreach( $rand_posts as $post ) : ?>
  • -
  • Continue Reading

    BuddyPress Theme Remove Sidebar

    主体自带了buddypress插件,于是整体的就多了一个buddypress的成员页面,但是由于我的侧边栏比较长,那么这个页面看起来就非常的蛋疼,左侧的内容只有一点点,右边长的一p。于是就想改一下去掉侧边栏,大致搜了以下没有找到合适的插件,那就只能自己动手了。根据这篇文章的内容可以知道,影响页面的其实是page.php。那么直接对page.php动手,参考这篇文章的内容,可以创建一个子主题来实现相关功能,我没有安装插件也不想创建什么新的子主题了,直接在原始的文件上动手。解决问题的方案也比较简单,判断当前页面是不是buddypress相关的页面然后根据情况进行处理即可。
    文章中提到了这么一个函数:bp_is_blog_page(),参考http://hookr.io/functions/bp_is_blog_page/的说明:

    You can tell if a page is displaying BP content by whether the current_component has been defined.

    Continue Reading

    更新Blog服务器配置

    从14年开始使用这台vps服务器,最近发现jetpack出了问题。貌似是更新php版本之后,新的php-xml模块没有安装,尝试更新相关模块的时候首先要更新epel-release,问题是更新了epel-release之后yum命令就挂了,提示找不到xz!

    于是问题就演化成了先有鸡还是先有蛋的问题,如果要解决这个问题那么:

    1. 删除epel-release 7,安装6,然后yum安装xz,xz安装成功之后更新epel-release
    2. 直接编译安装xz:
      wget https://sourceforge.net/projects/lzmautils/files/latest/download?source=typ_redirect  
      mv download\?source\=typ_redirect xz.gz tar -zxvf xz.gz  
      make &make install
      
    Continue Reading

    django 1452, ‘Cannot add or update a child row: a foreign key constraint fails

    网上这个问题搜索的概率非常高,但是实际上解决方法并不是非常完美,例如删除数据库重建什么的。由于刚开始的时候没有设计用户模块,中间添加的用户模块,此时数据库已经有很多数据了,如果删除数据重新创建是显然不可能的,于是搜索了一下,https://blog.csdn.net/qingche456/article/details/58153741 这个帖子中的方法确实能够解决问题,但是并不是十分完美,作为一个强迫症患者,一定要解决这个问题,而不是用这种投机取巧的办法。

    我这里出现这个问题的原因在于,新建的用户表用户数量已经超过了原有的auth_user数据数量,所以外键已经无法获取到正确的用户id。原始的约束如下

    ADD CONSTRAINT `django_admin_log_user_id_52fdd58701c5f563_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`);

    而我新创建的用户model为h4ckUser_hackuser,于是新创建的用户都会增加到h4ckUser_hackuser表中,而不是默认的auth_user表中。要解决这个问题就需要修改外键约束,我用phpmyadmin
    后台发现无法修改这些数据。于是只好重建一个新表,然后将两个表名称替换。此时这个问题就完美解决了,新建的表注意将上面的代码改成
    ADD CONSTRAINT `django_admin_log_user_id_52fdd58701c5f563_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `h4ckUser_hackuser` (`id`);
    此时在后台新建用户以及各种操作就完全没有问题了,日志系统也会正常进行记录。
    另外如果migrate失败,可以尝试删除migration下最后生成的文件,同时对数据库中新增加的数据进行删除。然后重新直接make migraions和migrate,为了稳妥还是最好天前进行系统备份,例如快照系统和mysql备份。

    Continue Reading