一直以來，都是用

global $post; $id=$post->ID;

今天才發現，這是有問題的。

如果在page中，加上一個shortcode，而shortcode輸出一個清單（例如某個分類的文章清單），那麼這個方法就無法得到page的ID。

就是說，如果在page中有循環，那麼上邊那個方法就無法取得page的ID。

列出取得page的ID的幾種方法：

1、global

受循環影響。

global $post; $id=$post->ID;

2、get_the_ID()

受循環影響。

$postid = get_the_ID(); echo $postid;

3、get_queried_object_id()

不受循環影響。推薦。

$current_id = get_queried_object_id(); echo $current_id;

4、get_queried_object()

不受循環影響。

$object = get_queried_object(); $id = $object -> ID; echo $id;

form engine今天的迭代：

支援一個頁面多個form；

支援應用在veiws engine中，這樣一來，veiws engine渲染出來的清單就可以隨意加入各種各樣的action。

form engine的view層和control層分離。

增加一個用於下拉選擇的按鈕的欄位。

自從把form engine和views engine從低程式碼平台中分離出來並做了一些重構後，這次的迭代，徹底讓它們的能力超過了以前的版本。

被這個小問題卡了一天。

wordpress中設定cookie比較特別。要寫在theme的functions檔案中，並載入到init鉤子上。

function custom_set_cookie() { setcookie( 'key', 'value', time() + 3600 * 24, COOKIEPATH, COOKIE_DOMAIN ); } add_action( 'init', 'custom_set_cookie' );

最簡單的解決方法，就是在衝突的package後邊不加版本號，而是加上“any”，這樣flutter會自動匹配合適的套件依賴的版本。

dart_code_metrics: any

一直沒搞懂wordpress清單的分頁原理。今天終於搞明白了。

wordpress的清單和分頁資料都寫在全域參數：$wp_query中，只要把查詢出來的清單資料放進這個參數，就可以用the_posts_pagination() 或get_the_posts_pagination()將分頁顯示出來，至於點選分頁後出現的頁面，不用管，wordpress都做好了。

代碼：

global $wp_query; 

 $wp_query=new WP_Query($arg);

然後，就可以在這個清單下邊用the_posts_pagination()顯示分頁了。

# 把百度的文心千帆大模型整合進wordpress，並對比GPT

上週末，把百度的文心千帆大模型整合進了wordpress。
一、基本的過程：
1.先在百度申請體驗文心千帆大模型，需先認證。

2.通過後，開通一下大模型，因為百度的大模型使用是收費的，按token收費，需要你的帳戶中有餘額才能開通。

3.然後，建立一個應用，這樣就有了appid、api key和secret key

4、然後，再看文檔，接對應的介面。
基本就是透過api key和secret key獲得access token，然後再提交問題，取得答案。

二、關鍵程式碼
1、取得access token的關鍵程式碼

“`php
private function getAccessToken(){
$curl = curl_init();
curl_setopt_array($curl, array(
CURLOPT_URL => “https://aip.baidubce.com/oauth/2.0/token?client_id=”.$this->client_id.”&client_secret=”.$this->client_secret.”&grant_type=client_credentials”,
CURLOPT_TIMEOUT => 30,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_CUSTOMREQUEST => 'POST',
CURLOPT_HTTPHEADER => array(
'Content-Type: application/json',
'Accept: application/json'
),

));
$response = curl_exec($curl);
curl_close($curl);
$rtn = json_decode($response);
return $rtn->access_token;
}
“`

2.呼叫Ernie Bot大模型的關鍵程式碼

“`php
public function runErnieBot($message) {
$curl = curl_init();
curl_setopt_array($curl, array(
CURLOPT_URL => “https://aip.baidubce.com/rpc/2.0/ai_custom/v1/wenxinworkshop/chat/completions?access_token={$this->getAccessToken()}”,
CURLOPT_TIMEOUT => 30,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_CUSTOMREQUEST => 'POST',
CURLOPT_POSTFIELDS =>$message,
CURLOPT_HTTPHEADER => array(
'Content-Type: application/json'
),
));
$response = curl_exec($curl);
curl_close($curl);
return $response;
}
“`

3.呼叫Ernie Bot Turbo大模型的關鍵程式碼

“`php
public function runErnieBotTurbo($message) {
$curl = curl_init();
curl_setopt_array($curl, array(
CURLOPT_URL => “https://aip.baidubce.com/rpc/2.0/ai_custom/v1/wenxinworkshop/chat/eb-instant?access_token={$this->getAccessToken()}”,
CURLOPT_TIMEOUT => 30,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_CUSTOMREQUEST => 'POST',
CURLOPT_POSTFIELDS =>$message,
CURLOPT_HTTPHEADER => array(
'Content-Type: application/json'
),
));
$response = curl_exec($curl);
curl_close($curl);
return $response;
}
“`

這幾天的測試，百度文心千帆大模型在中文方面的表現的確比GPT好多了。
GPT的中文水平，就是「說明文」的水平。
百度文心千帆大模型的中文水平，至少也比「說明文」好一些。

對我自己做的平台型CMS，會員訂閱這部分一直是「簡單實作」。這個週末重新對這部分做了架構，並把核心部分開發完成。

一、方式

會員訂閱，一般來說，主要包含：會員訂閱方案及購買、會員權限控制、會員管理三個部分。

1、對於會員訂閱方案及購買

準備基於已有的商城系統做一些擴展即可。

2、對於會員權限控制，

這個要特別說一下，不打算基於角色權限系統來做，而是單獨做一個會員控制的系統。

基於角色權限系統，把會員做成一個角色系列，把每個會員做成這個角色系列的角色。聽起來，似乎很合理。但是，這樣的話，無論做起來還是用起來，都特別麻煩，尤其是業務比較多的時候，各種邏輯會很複雜，一不小心就會造成各種混亂。並且也不夠靈活。

而且，實際上，很多優秀的系統的會員訂閱部分，也不會基於角色。而是基於「標記」或基於訂單來實現權限控制。包含wordpress的許多賣得很好的會員訂閱類的外掛都是這樣來做的。

基於「用戶標記」：

本質上，其實和角色系統原理一樣。就是定義一些會員的“標記”，購買了與這個“標記”關聯的會員訂閱計劃的用戶會被“打上這個標記”，這樣就能實現會員權限的控制。

以訂單為基礎：

購買會員訂閱計劃，形成訂單，付款後，將到期時間寫入訂單。所以，就可以根據訂單來判斷用戶是否是會員、是哪一種會員，以及是否已過期。這樣就可以對控制會員權限。

之前曾經做過基於訂單的方式，這次打算基於”用戶標記“。

基於訂單並沒有什麼不好，只不過，我現在做的這個平台型CMS的訂單系統支持的訂單類型比較多，造成訂單模型比較”龐大“，不打算再給它”增加體重“了，所以選擇基於”用戶標記“。

3、會員管理

基於現有的使用者管理擴展，不打算單獨做會員管理。

二、適用場景

1.基本場景

整個產品有一個或幾個訂閱計劃，用戶購買，享受會員服務。

全域定義會員標記，每一種會員標記至少包含name、slug、關聯的訂閱計畫id，三個欄位。

當使用者購買了某個會員標記的訂閱計劃，此會員標記和到期時間就會寫入此使用者的meta資料中。

2、平台/多租戶場景

對於平台和做多租戶SAAS，有一個很重要的場景：供應商自己提供的訂閱方案。

在供應商的使用者的meta資料中定義此供應商的會員標記，供應商的會員標記的key和全域會員標記的key不能相同。

當用戶購買了此供應商的訂閱方案後，相應的會員標記和到期日期就會寫入到購買用戶的meta資料中。

這次的迭代只實現基本場景即可，但要能擴展到平台和多租戶場景。

三、登入時判斷會員是否到期

使用者登入時判斷是否到期，如果到期，更新meta資料中的會員標記為false、到期日為false。

嵌入的網頁必須是https的url才能顯示，http的url不顯示。