Monthly Archives: 六月 2016

替换wordpress全站为相对路径

作者: dplord, 访问量 2295





近来有时候在自己的电脑上,单机捣鼓wordpress, 甚至有时候我想离线写一篇文章,到时候传上去。发现wordpress所有资源都是带全路径的。因此研究把自己的wordpress, 整站替换为相对路径。这样于我而言有几个好处。

① 当网站是http的时候,请求的资源是http的、当网站是https的时候,请求的资源是https的。

②  部署的时候好部署,直接替换url之类的。

③  127.0.0.1上的wordpress跟我的域名https://dplord.com上的没有任何区别,都可以本地写文章,想本地覆盖服务器可以直接覆盖。这里记下来我替换wordpress全站为相对路径的方法。

④ 当访问https://dplord.com时候,原来的历史post里面是/wp-content/uploads/2015/12/xxxxx.jpg这样的资源,由于我在nginx开启了http的80端口强制301到443的https,使用relative path可以直接命中https资源。减少多次301跳转。节省服务器资源,同时也让客户端访问更快一点。

一、哪些资源需要被替换为相对路径

想了想,大概有这些可能需要被替换

① 引用的图片资源, 比如src=”/wp-content/uploads/2015/12/cropped-banner_cosmos_20151214.jpg” 替换为src=”/wp-content/uploads/2015/12/cropped-banner_cosmos_20151214.jpg”

② 各种目录、菜单栏、近期文章、文章详情、标签链接、评论链接为相对路径

二、更新wp_posts表, 处理旧文章(附件)里面的链接

由于有些历史的wp_post已经的一些包含src=”/wp-content/uploads/2015/12/cropped-banner_cosmos_20151214.jpg”的html已经存进数据库wp_posts表了。是静态写进去了。因此要先写段程序替换所有已经存在的posts的链接。

比如这里查询一下看看有哪些历史post包含了绝对路径,

select count(*) from wp_posts where (post_content like “%/wp-content%”) or (post_content like “%/wp-content%”) or (post_content like “%/wp-content%”) or (post_content like “%/wp-content%”);

5344626

为了方便,这里写了一个ruby程序,更新下数据表。代码如下:

wordpress_update_url.rb

require 'active_record'

ActiveRecord::Base.establish_connection(
    :adapter => 'mysql2',
    :host => '127.0.0.1',
    :username => 'your-db-username',
    :password => 'your-db-password',
    :database => 'your-db-database-name'
)

class Wp_posts < ActiveRecord::Base
  self.inheritance_column = nil
  self.table_name = "wp_posts"
end

replaceStr = ['/wp-content', '/wp-content', '/wp-content', '/wp-content']

res = Wp_posts.find_by_sql('select * from wp_posts where (post_content like "%http://www.dplord.com/wp-content%") or (post_content like "%http://dplord.com/wp-content%") or (post_content like "%https://www.dplord.com/wp-content%") or (post_content like "%https://dplord.com/wp-content%")')
res.each{|post|
  replaceStr.each{|str|
    if post.post_content.include? str
      post.post_content = post.post_content.gsub! str, "/wp-content"
    end
  }
  post.save
}

更新之后, 历史post里面都是相对路径了。

三、更新wp_options里面的siteurl跟home

wp_options这个表,存了一些选项值与配置相关的。原先写入数据库的历史post的siteurl  http://www.dplord.com的值就是存在这个表里面。

update wp_options set option_value=’/’ where option_name=’siteurl’ or option_name = ‘home';

更新完了之后,查看首页的html基本都是相对路径,但是剩下来一点点残余的。比如主题资源、插件里面的资源引用、首页header image地址等。

四、替换主题资源里面的绝对路径资源引用及其他

① 修改引用的绝对路径js资源

QQ20160605-0@2x

编辑 wp-includes/script-loader.php 第65行$scripts->base_url = $guessurl; 为$scripts->base_url = ”; (该行在wp_default_scripts函数里)

修改完了刷新,

QQ20160605-1@2x

发现已经改过来了。

② 修改wordpress自定义背景图的url

这里custom-background生成了一段html

QQ20160605-2@2x

这个在你的wordpress仪表盘,重新设置下background-image即可。

③修改引用的绝对路径css资源

QQ20160605-3@2x

修改wp-includes/script-loader.php function wp_default_styles()下的第6行$styles->base_url = $guessurl;为$styles->base_url = ”;

④ 修改wordpress顶部header-image

在后台重新选择一下图片即可。

chrome扩展开发小结

作者: dplord, 访问量 1842





上次参加公司内部Hackthon做了一个chrome插件,这里记录下Chrome扩展开发小结。

一、Chrome扩展的结构

Chrome扩展就是一个目录,这个目录包含一个manifest.json,  就是一个chrome扩展了。具体的文件组织,只需要一个manifest.json, 其他的资源文件组织方式是只有的。

比如我做的是一个根据url,捕获url在发送http Request之前,在url里面添加一些Header实现的内部开发的dev插件。

我的manifest.json 声明如下:

{
  "manifest_version": 2,
  "name": "你的插件名字",
  "description": "你的插件描述",
  "version": "1.0",
  "permissions": [
    "webRequest",
    "webRequestBlocking",
    "storage",
    "http://www.example1.com/",
    "http://www.example2.com/"
  ],
  "browser_action": {
    "default_icon": "你的logo图",
    //右上角看到的logo
    "default_popup": "popup.html"
  },
  "icons": {
    "16": "你的logo图",
    //在chrome://extensions/ 页面看到的logo
    "48": "你的logo图",
    "128": "你的logo图"
  },
  "background": {
    "page": "background.html",
    "persistent": true
  },
  "options_page": "options.html"
  //设置页面
}

主要是声明一些资源文件、popup页面、background资源、options页面。

比如我开发的一个扩展的目录结构如下:

QQ20160604-7@2x

二、各种文件的具体作用

popup.html

有人看到,”default_popup”: “popup.html” 。popup.html是什么呢。比如一个chrome扩展Xmarks在chrome的菜单栏显示,点击这个扩展会弹出一个小框框,如下图红色框框区域,这个页面其实就是popup.html, 我们只要定义了popup.html页面,就可以在该html里面控制它的样式。

QQ20160604-5@2x

 

background.html

background.html是什么呢,顾名思义,是一个运行在后台的,其实我做的插件中background是没有页面的空html, 作用是有些执行在后台的js, 比如我的background.js ,需要在manifest.json声明background.html, 然后在background.html里面<script src=”js/background.js”></script>引用background.js这样,background.js就可以始终在后台运行了。

options.html

options.html顾名思义,是设置页面。从chrome://extensions/ 页面,点击你插件的选项,就到了设置页面,也是个html。

三、开始开发一个dev的网络插件

chrome插件其实都是标准的html 、js那套,就跟做网站一样,唯一注意的是资源的引用权限、资源的跨域问题啊,执行的先后顺序,popup.js、backgroud.js、options.js的作用时间以及什么时候回触发。

首先画好各种界面,然后组织好文件,引用各种js,温馨提示: chrome扩展里面用到的html都不能在html写<script>你的js代码</script>,必须要写到js文件里面,<script src=”your-js-file”></script>这样的引用。

各个js之间传递数据之类的,可以自定义存储方式啊,用html5的localStorge、indexeddb、websql那一套,我们采用的是在localStorge里面存放json文本的数据,各个js都操作这些数据,同一个chrome扩展下的localStorge是共享的。

先画好界面,设置好页面,引用好各种实现动作的js。

然后在js里面开始实现你的逻辑了。我们的核心逻辑就是before HTTP Request,加一个监听器,实现一些操作,这些可以看chrome扩展的API,比如捕获http请求、操作chrome tab、操作书签、添加道理, chrome都给js封装了接口。监听一个请求的代码如下:

background.js

chrome.webRequest.onBeforeSendHeaders.addListener(
    function (details) {
        //do-something
        //添加自定义HTTP头
        details.requestHeaders.push({name: "MySpecifiedHttpHeaderName", value: "MySpecifiedHttpHeaderValue"});
        return {requestHeaders: details.requestHeaders};
    },
    {urls: ["*://*.example.com"]},
    ["requestHeaders", "blocking"]
);

这样在启用你的插件后,匹配到*.example.com 就回运行这段代码在http header里面,添加一行里自定义的header “MySpecifiedHttpHeaderName: MySpecifiedHttpHeaderValue” 出去。注意这个捕获到*.example.com的请求的网络权限,在manifest.json 的permissions 里面申请好。

其他的设置界面等等都是跟正常的html js dom操作那一套一模一样,就不多提了。

是不是很简单,有需求的可以自定义插件玩玩儿啊。

最后插件开发好,发布的时候,需要在chrome://extensions/页面,点击打包扩展程序,选择你的扩展目录,打包成一个your-chrome-extension.crx扩展(其实就是个标准zip压缩包)。