Dagens iteration af formularmotor:

Understøtte flere formularer på én side;

Understøtter applikation i veiws engine, så forskellige handlinger kan tilføjes til listen gengivet af veiws engine.

Formmaskinens visningslag og kontrollag er adskilt.

Tilføj et felt til en rulleknap til valg.

Siden form-motoren og visningsmotoren blev adskilt fra lavkode-platformen, og der blev foretaget en del rekonstruktion, har denne iteration fuldstændig gjort deres muligheder ud over den tidligere version.

被这个小问题卡了一天。

wordpress中设置cookie比较特别。要写在theme的functions文件中，并加载到init钩子上。

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

}
add_action( 'init', 'custom_set_cookie' );

Den enkleste løsning er at tilføje "enhver" i stedet for versionsnummeret efter den modstridende pakke, så Flutter automatisk matcher den relevante version af pakkeafhængigheden.

dart_code_metrics: nogen

一直没搞懂wordpress列表的分页原理。今天终于搞明白了。

wordpress的列表和分页数据都写在全局参数：$wp_query中，只要把查询出来的列表数据放进这个参数，就可以用the_posts_pagination() 或get_the_posts_pagination()将分页显示出来，至于点击分页后出现的页面，不用管，wordpress都做好了。

代码：

global $wp_query; 

 $wp_query=new WP_Query($arg);

然后，就可以在这个列表下边用the_posts_pagination()显示分页了。

# integrerer Baidu's Wenxin Qianfan store model i WordPress og sammenligner den med GPT

Sidste weekend blev Baidus Wenxin Qianfan-model integreret i WordPress.
1. Grundlæggende proces:
1. Ansøg først for at opleve Wenxin Qianfan store model på Baidu, som kræver certificering først.

2. Når du har bestået, skal du aktivere den store model, fordi Baidu's store model opkræves for brug og opkræves pr. token. Du skal have en saldo på din konto for at aktivere den.

3. Opret derefter et program, så det har appid, api-nøgle og hemmelig nøgle

4. Læs derefter dokumentationen og tilslut den tilsvarende grænseflade.
Grundlæggende får du adgangstokenet gennem api-nøglen og den hemmelige nøgle, og indsender derefter spørgsmålet og får svaret.

2. Nøglekode
1. Få adgangskodens nøglekode

"php
privat funktion 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 => sandt,
CURLOPT_CUSTOMREQUEST => 'POST',
CURLOPT_HTTPHEADER => array(
'Content-Type: application/json',
'Accepter: application/json'
),

));
$respons = curl_exec($curl);
curl_close($curl);
$rtn = json_decode($response);
returner $rtn->adgangstoken;
}
“`

2. Kald nøglekoden til Ernie Bot stor model

"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 => sandt,
CURLOPT_CUSTOMREQUEST => 'POST',
CURLOPT_POSTFIELDS =>$besked,
CURLOPT_HTTPHEADER => array(
'Content-Type: application/json'
),
));
$respons = curl_exec($curl);
curl_close($curl);
returnere $respons;
}
“`

3. Kald nøglekoden til Ernie Bot Turbo stor model

"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 => sandt,
CURLOPT_CUSTOMREQUEST => 'POST',
CURLOPT_POSTFIELDS =>$besked,
CURLOPT_HTTPHEADER => array(
'Content-Type: application/json'
),
));
$respons = curl_exec($curl);
curl_close($curl);
returnere $respons;
}
“`

I de sidste par dages test er ydeevnen af Baidu Wenxin Qianfans store model på kinesisk faktisk meget bedre end GPT.
Det kinesiske niveau for GPT er niveauet for "forklarende tekst".
Det kinesiske niveau af Baidu Wenxin Qianfan Large Model er i det mindste bedre end den "forklarende tekst".

Til det platform CMS, jeg selv byggede, har medlemsabonnementsdelen altid været "simpel at implementere". I weekenden omstrukturerede jeg denne del og udviklede kernedelen.

1. Metode

Generelt omfatter medlemskabsabonnement hovedsageligt tre dele: medlemskabsabonnementsplan og køb, medlemstilladelseskontrol og medlemsadministration.

1. For medlemskabsabonnementer og køb

Bare forbered dig på at lave nogle udvidelser baseret på det eksisterende indkøbscentersystem.

2. For medlemstilladelseskontrol,

Dette skal nævnes specielt. Vi planlægger ikke at gøre det baseret på et rolletilladelsessystem, men et separat medlemskontrolleret system.

Med udgangspunkt i rolleautoritetssystemet laves medlemmer om til en rolleserie, og hver type medlem laves til en rolle i denne rollerække. Det lyder fornuftigt. Men i dette tilfælde er det meget besværligt at gøre eller bruge, især når der er mange forretninger, de forskellige logikker vil være meget komplicerede, og alle former for forvirring vil opstå, hvis du ikke er forsigtig. Og det er ikke fleksibelt nok.

Desuden er medlemskabsabonnementsdelen af mange fremragende systemer faktisk ikke rollebaseret. I stedet implementeres tilladelseskontrol baseret på "mærker" eller ordrer. Mange velsælgende medlemskabsabonnement plug-ins, herunder WordPress, er lavet på denne måde.

Baseret på "brugertag":

I bund og grund er det samme princip som karaktersystemet. Det er for at definere nogle "mærker" af medlemmer. Brugere, der køber medlemskabsabonnementet, der er forbundet med dette "mærke", vil blive "mærket med dette mærke", så kontrollen af medlemstilladelser kan opnås.

Baseret på ordre:

Køb et medlemskabsabonnement og lav en ordre Efter betaling vil udløbstiden blive skrevet ind i ordren. Derfor kan du ud fra rækkefølgen vurdere, om brugeren er medlem, hvad det er for et medlem, og om det er udløbet. På denne måde kan du kontrollere medlemstilladelser.

Jeg har tidligere lavet en ordrebaseret metode, og denne gang planlægger jeg at bruge "brugertags".

Der er ikke noget galt i at være baseret på ordrer, men ordresystemet i platformen CMS, jeg bygger nu, understøtter mange ordretyper, hvilket gør ordremodellen relativt "stor, jeg har ikke planer om at "lægge vægt" på den længere. så jeg valgte Baseret på "brugertags".

3. Medlemsstyring

Baseret på den eksisterende brugerstyringsudvidelse planlægger vi ikke at lave medlemsstyring alene.

2. Gældende scenarier

1. Grundscenarie

Hele produktet har en eller flere abonnementsplaner, som brugerne køber og nyder godt af medlemstjenester.

Definer medlemsmærker globalt. Hvert medlemsmærke indeholder mindst tre felter: navn, slug og tilhørende abonnementsplan-id.

Når en bruger køber en abonnementsplan med et medlemsmærke, vil medlemsmærket og udløbstiden blive skrevet ind i brugerens metadata.

2. Platform/multi-lejer scenario

For platforme og SAAS med flere lejere er der et meget vigtigt scenarie: abonnementsplanen leveret af leverandøren selv.

Definer leverandørens medlemstag i leverandørens brugers metadata. Nøglen til leverandørens medlemstag kan ikke være den samme som nøglen til det globale medlemstag.

Når en bruger køber et abonnement hos denne udbyder, vil det tilsvarende medlemsmærke og udløbsdato blive skrevet til den købende brugers metadata.

Denne iteration implementerer kun grundlæggende scenarier, men den skal kunne udvides til platforms- og multilejerscenarier.

3. Find ud af, om medlemskabet er udløbet, når du logger ind

Når brugeren logger ind, vurderes det, om det er udløbet. Hvis det er udløbet, opdateres medlemsmærket i metadataene til falsk og udløbsdatoen til falsk.