[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-categories":3,"blog-category-wordpress":78},[4,10,14,19,24,30,36,40,45,51,55,58,62,68,73],{"id":5,"databaseId":6,"name":7,"slug":8,"count":9},"dGVybTo1NQ==",55,"AI","ai",2,{"id":11,"databaseId":12,"name":13,"slug":13,"count":9},"dGVybTo2MQ==",61,"backend",{"id":15,"databaseId":16,"name":17,"slug":18,"count":16},"dGVybToyMA==",20,"Devops","devops",{"id":20,"databaseId":21,"name":22,"slug":22,"count":23},"dGVybToxNQ==",15,"frontend",25,{"id":25,"databaseId":26,"name":27,"slug":28,"count":29},"dGVybTo2MA==",60,"GAS","gas",1,{"id":31,"databaseId":32,"name":33,"slug":34,"count":35},"dGVybTo5",9,"HTML","html",4,{"id":37,"databaseId":38,"name":39,"slug":39,"count":29},"dGVybToyMg==",22,"mac",{"id":41,"databaseId":42,"name":43,"slug":43,"count":44},"dGVybTo2",6,"node",18,{"id":46,"databaseId":47,"name":48,"slug":49,"count":50},"dGVybTo2OQ==",69,"Nuxt","nuxt",3,{"id":52,"databaseId":53,"name":54,"slug":54,"count":50},"dGVybTo1NA==",54,"office",{"id":56,"databaseId":9,"name":57,"slug":57,"count":21},"dGVybToy","omekas",{"id":59,"databaseId":60,"name":61,"slug":61,"count":16},"dGVybToxNg==",16,"vue",{"id":63,"databaseId":64,"name":65,"slug":66,"count":67},"dGVybTo1",5,"WordPress","wordpress",13,{"id":69,"databaseId":29,"name":70,"slug":71,"count":72},"dGVybTox","無","uncategorized",null,{"id":74,"databaseId":75,"name":76,"slug":77,"count":9},"dGVybTo3MA==",70,"生活","life",[79,94,107,119,130,142,154,165,176,187,198,209,220],{"id":80,"slug":81,"title":82,"description":83,"content":84,"date":85,"image":86,"imageAlt":82,"author":87,"categories":90,"path":93,"minRead":29},3818,"個人網站改版建置心得-headless-wordpress-nuxt","個人網站改版建置心得 Headless WordPress + Nuxt","一直聽過 WordPress 的無頭模式(Headless)架構，最近心一狠就把自己的網站轉移成無頭模式架構。 […]","\u003Cp>一直聽過 WordPress 的無頭模式(Headless)架構，最近心一狠就把自己的網站轉移成無頭模式架構。\u003C\u002Fp>\n\u003Cp>理由有幾點：\u003C\u002Fp>\n\u003Col>\n\u003Cli>想要更有彈性的在前台開發\u003C\u002Fli>\n\u003Cli>在前台實作一些想法\u003C\u002Fli>\n\u003Cli>體驗看看無頭模式的坑(?\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>記錄一下目前版本做了哪些事情\u003C\u002Fp>\n\u003Ch1>轉換流程\u003C\u002Fh1>\n\u003Ch2>1. 決定架構\u003C\u002Fh2>\n\u003Cp>我決定了前台採用 Nuxt ，一方面我是走 Vue 生態的開發者，二來需要有 SSR 來維持原本的 SEO 效果。\u003C\u002Fp>\n\u003Cp>簡單來說就是 Nuxt + WordPress\u003C\u002Fp>\n\u003Ch2>2. 開啟 WordPress 無頭模式\u003C\u002Fh2>\n\u003Cp>翻了一些文章，多半會推薦無頭模式要採用 Graphql ，主要是為了提高查詢效率，因此先安裝了 wpgraphql ，讓 WordPress 的 RestFul API  支援 Graphql。\u003C\u002Fp>\n\u003Ch2>3. 建置新的前台\u003C\u002Fh2>\n\u003Cp>用 Nuxt 建置了新的前台，目前版本只是先提供最基礎的內容：首頁、介紹、文章等，後續還有一些想法慢慢更新。這時實作串接原網站的 API，就能進行測試了！\u003C\u002Fp>\n\u003Cp>記得要開啟 SSR 模式，這部分除錯比較麻煩一些。\u003C\u002Fp>\n\u003Cp>另外也要處理 CORS 問題，這部分解完後，整個架構雛形就完成了。\u003C\u002Fp>\n\u003Ch2>4. 網域轉換 + SEO\u003C\u002Fh2>\n\u003Cp>將原本的 WordPress 轉換到另一個網域，並且將新前台掛在原本的網域。\u003C\u002Fp>\n\u003Cp>由於新架構的 route 已經改變，自然就會出現文章路徑的轉址問題，我另外寫了一個轉換器和對應表來處理 301 轉址。\u003C\u002Fp>\n\u003Cp>而 SEO 就要在 Nuxt 上全部處理了。\u003C\u002Fp>\n\u003Ch2>5. 關閉 WordPress 的前台模式\u003C\u002Fh2>\n\u003Cp>說是關閉，我採用的做法是強制轉址到前台網域billxu.net 啦.\u003C\u002Fp>\n\u003Cp>這些步驟做完，也差不多把整個架構調完了！\u003C\u002Fp>\n\u003Ch1>簡短心得\u003C\u002Fh1>\n\u003Cp>轉換完後有種舒爽的感覺，想到不用受到原本頁面架構的限制就覺得有種解放感！不過什麼都得重新來過，像是文章排版、資料解析等等。最近還在除錯，之後想在網站中放一些小遊戲之類的(? 到時候就再分享了XD\u003C\u002Fp>\n","2026-01-18T15:29:46","",{"name":88,"link":89},"Chih Fan","http:\u002F\u002Fpost.billxu.net",[91,92],{"name":48,"slug":49},{"name":65,"slug":66},"\u002Fblog\u002F個人網站改版建置心得-headless-wordpress-nuxt",{"id":95,"slug":96,"title":97,"description":98,"content":99,"date":100,"image":101,"imageAlt":97,"author":102,"categories":103,"path":106,"minRead":29},3766,"kinsta-主機的轉移心得","Kinsta 主機的轉移心得","Kinsta 主機的轉移心得 最近幫客戶轉移在 Kinsta上轉移主機，幸運的是從 Kinsta 轉移到 Ki […]","\u003Ch1>Kinsta 主機的轉移心得\u003C\u002Fh1>\n\u003Cp>最近幫客戶轉移在 Kinsta上轉移主機，幸運的是從 Kinsta 轉移到 Kinsta 上XD於是經驗分享與記錄一下過程。\u003C\u002Fp>\n\u003Cp>如果未來要選擇 Kinsta 主機，官方對於轉移有許多方式，可參考\u003Ca href=\"https:\u002F\u002Fkinsta.com\u002Fdocs\u002Fwordpress-hosting\u002Fwordpress-migrations\u002Fmigrating-to-kinsta\u002F\" title=\"文件\">文件\u003C\u002Fa>。\u003C\u002Fp>\n\u003Cp>大致分為：\u003C\u002Fp>\n\u003Col>\n\u003Cli>檔案轉移：使用 SFTP 與 MySQL 搬遷\u003C\u002Fli>\n\u003Cli>外掛轉移：Kinsta 推薦使用 Duplicator 或 Migrate Guru\u003C\u002Fli>\n\u003Cli>從 WordPress.com 轉移\u003C\u002Fli>\n\u003Cli>內部轉移：從 Kinsta 轉移到 Kinsta\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>如果購買的方案有Premium Migration，則可以直接請轉移團隊處理，參考此\u003Ca href=\"https:\u002F\u002Fkinsta.com\u002Fdocs\u002Fwordpress-hosting\u002Fwordpress-migrations\u002Fmigrating-to-kinsta\u002F#request-a-premium-migration\" title=\"連結\">連結\u003C\u002Fa>。\u003C\u002Fp>\n\u003Cp>剛好這次是內部轉移，則可以參考此\u003Ca href=\"https:\u002F\u002Fkinsta.com\u002Fdocs\u002Fcompany-settings\u002Ftransfer-ownership\u002F\" title=\"說明\">說明\u003C\u002Fa>。內部轉移實際上只是進行所有權的移轉，因此在 Kinsta 的操作中稱為"tranfer"，參考上述連結進行即可。\u003C\u002Fp>\n\u003Cp>進行移轉(tranfer)需要兩個條件：\u003C\u002Fp>\n\u003Col>\n\u003Cli>必須能操作或請人操作來源主機(MyKinsta)\u003C\u002Fli>\n\u003Cli>必須取得目標主機的 Company ID，並且可以操作 MyKinsta\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>流程如下：\u003C\u002Fp>\n\u003Col>\n\u003Cli>取得目標主機的 Company ID\u003C\u002Fli>\n\u003Cli>在來源主機上，進行移轉(tranfer)操作\u003C\u002Fli>\n\u003Cli>輸入 Company ID\u003C\u002Fli>\n\u003Cli>目標主機會出現 tranfer 的請求，選擇確認\u003C\u002Fli>\n\u003Cli>完成\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>幾乎是一瞬間完成，會連帶將\u003Cstrong>所有設定\u003C\u002Fstrong>以及\u003Cstrong>備份檔案\u003C\u002Fstrong>、\u003Cstrong>staging主機\u003C\u002Fstrong>和\u003Cstrong>網域設定\u003C\u002Fstrong>都移轉過來。並且不會有主機停機的狀態。另外 Kinsta 的客服回答也很立即，如果有需要的人很推薦試試看。\u003C\u002Fp>\n","2024-06-20T10:04:56","\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2022%2F12%2FWordPress-logotype-alternative.png",{"name":88,"link":89},[104,105],{"name":17,"slug":18},{"name":65,"slug":66},"\u002Fblog\u002Fkinsta-主機的轉移心得",{"id":108,"slug":109,"title":110,"description":111,"content":112,"date":113,"image":114,"imageAlt":110,"author":115,"categories":116,"path":118,"minRead":29},3757,"ddev-wordpress-走出本機端的設定方式","DDEV -WordPress 走出本機端的設定方式","DDEV -WordPress 走出本機端的設定方式 以全端工程師來說，ddev 這套工具對本機端開發真的有巨 […]","\u003Ch1>DDEV -WordPress 走出本機端的設定方式\u003C\u002Fh1>\n\u003Cp>以全端工程師來說，ddev 這套工具對本機端開發真的有巨大的幫助。像我現在針對 WordPress 相關的專案時，就先採用 ddev 作為本機開發的優先選項。\u003C\u002Fp>\n\u003Cp>而有時製作的內容想先丟給像是設計師啦、PM甚至是客戶，用直接實例呈現跟對方討論時，其實也能用一些內網穿透的proxy工具來處理，ddev 就跟最常用的 ngrok 有整合可以透過 config 直接呼叫 ngrok 啟動，讓本機端也能走到外部網路。\u003C\u002Fp>\n\u003Cp>說明文件在這邊：\u003Ca href=\"https:\u002F\u002Fddev.readthedocs.io\u002Fen\u002Fstable\u002Fusers\u002Ftopics\u002Fsharing\u002F\">https:\u002F\u002Fddev.readthedocs.io\u002Fen\u002Fstable\u002Fusers\u002Ftopics\u002Fsharing\u002F\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>簡單記錄一下設定流程\u003C\u002Fp>\n\u003Ch2>設定 ngrok 網域\u003C\u002Fh2>\n\u003Col>\n\u003Cli>註冊 ngrok ，與啟用網域，文件在\u003Ca href=\"https:\u002F\u002Fngrok.com\u002Fblog-post\u002Ffree-static-domains-ngrok-users\">這邊\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>啟用網域後，我們會拿到一組臨時網域，例如 wp23.ngrok-free.app\u003C\u002Fli>\n\u003Cli>設定 .ddev\u002Fconfig.yaml ，在文件中加入\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-php\">ngrok_args: --domain wp23.ngrok-free.app\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Col start=\"4\">\n\u003Cli>設定 wp-config-ddev.php ，因為 ddev 預設的位置應該是 \u003Ca href=\"https:\u002F\u002Fwordpress.ddev.site\u002F\">https:\u002F\u002Fwordpress.ddev.site\u003C\u002Fa> ，要修改 ddev 內的 wp-config \u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-php\">define('WP_HOME', 'https:\u002F\u002Fwp23.ngrok-free.app');\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Col start=\"5\">\n\u003Cli>檢查有無需要取代的字串，這是 WordPress 的老毛病，進行之前建議先進行 DB  \u003Ca href=\"https:\u002F\u002Fddev.readthedocs.io\u002Fen\u002Fstable\u002Fusers\u002Fusage\u002Fcommands\u002F#export-db\">備份\u003C\u002Fa> 或 \u003Ca href=\"https:\u002F\u002Fddev.readthedocs.io\u002Fen\u002Fstable\u002Fusers\u002Fusage\u002Fcommands\u002F#snapshot\">快照\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-php\">ddev wp search-replace https:\u002F\u002Fwordpress.ddev.site https:\u002F\u002Fwp23.ngrok-free.app\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Col start=\"6\">\n\u003Cli>現在執行 ddev share ，應該就能看到 \u003Ca href=\"https:\u002F\u002Fwp23.ngrok-free.app\">https:\u002F\u002Fwp23.ngrok-free.app\u003C\u002Fa> 可以用囉，就可以直接丟給外部使用者了，YA!\u003C\u002Fli>\n\u003C\u002Fol>\n","2024-05-13T10:01:51","\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2024%2F05%2Fa72d9c63-7740-4941-99cd-255a1444e0c3.jpeg",{"name":88,"link":89},[117],{"name":65,"slug":66},"\u002Fblog\u002Fddev-wordpress-走出本機端的設定方式",{"id":120,"slug":121,"title":122,"description":123,"content":124,"date":125,"image":101,"imageAlt":122,"author":126,"categories":127,"path":129,"minRead":29},3734,"wordpress-中嵌入-unity3d-封裝指南","WordPress 中嵌入 Unity3D 封裝指南","WordPress 中嵌入 Unity3D 封裝指南 如果要在WordPress上嵌入Unity3D的封裝執行 […]","\u003Ch1>WordPress 中嵌入 Unity3D 封裝指南\u003C\u002Fh1>\n\u003Cp>如果要在WordPress上嵌入Unity3D的封裝執行檔案，可以使用 \u003Cstrong>\u003Ca href=\"https:\u002F\u002Fwordpress-gpts-test.ddev.site\u002Fwp-admin\u002Fplugin-install.php?tab=plugin-information&plugin=howescape-unity3d-webgl&TB_iframe=true&width=772&height=763\">HoweScape Unity3d WebGL\u003C\u002Fa> 外掛\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Ch2>使用流程\u003C\u002Fh2>\n\u003Col>\n\u003Cli>安裝並啟動外掛。\u003C\u002Fli>\n\u003Cli>透過FTP或是你習慣的方式，進入網站檔案系統，尋找外掛目錄：\u003Cyour-site>\u002Fwp-content\u002Fplugins\u002Fhowescape-unity3d-webgl\u002F\u003C\u002Fli>\n\u003Cli>找到\u003Ccode>game_dir\u003C\u002Fcode>和\u003Ccode>game_support_dir\u003C\u002Fcode>資料夾，先將\u003Ccode>game_dir\u003C\u002Fcode>中預設檔案移除。\u003C\u002Fli>\n\u003Cli>Unity3D封裝分為\u003Ccode>Build\u003C\u002Fcode>和\u003Ccode>TemplateData\u003C\u002Fcode>，按命名規則放入對應資料夾。\u003C\u002Fli>\n\u003Cli>例：Unity3D封裝名為\u003Ccode>game-test\u003C\u002Fcode>，版本為2019.04，則\u003Ccode>Build\u003C\u002Fcode>改名為\u003Ccode>game-test_2019_4-Release\u003C\u002Fcode>放入\u003Ccode>game_dir\u003C\u002Fcode>。\u003C\u002Fli>\n\u003Cli>將\u003Ccode>TemplateData\u003C\u002Fcode>改名為\u003Ccode>TemplateData_2019_4\u003C\u002Fcode>，放入\u003Ccode>game_support_dir\u003C\u002Fcode>。\u003C\u002Fli>\n\u003Cli>確認命名正確。\u003C\u002Fli>\n\u003Cli>在頁面中插入短代碼引入Unity3D頁面：\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-jsx\">[hs_unity3d_web_gl_game src='game-test' height='500' width='600' u3dver='2019.4' buildtype='Production']\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>完成後，可在頁面看到成果。若失敗，檢查瀏覽器console，可能是專案名稱問題。\u003C\u002Fp>\n\u003Ch2>注意事項\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>此外掛較久未更新，使用前評估。\u003C\u002Fli>\n\u003Cli>官方文件短代碼可能有誤，請使用單引號。\u003C\u002Fli>\n\u003C\u002Ful>\n","2024-04-15T10:48:38",{"name":88,"link":89},[128],{"name":65,"slug":66},"\u002Fblog\u002Fwordpress-中嵌入-unity3d-封裝指南",{"id":131,"slug":132,"title":133,"description":134,"content":135,"date":136,"image":137,"imageAlt":133,"author":138,"categories":139,"path":141,"minRead":29},3672,"wordcamp-asia-2024-小記","WordCamp Asia 2024 小記","WordCamp Asia 2024 小記 原本很期待協作日和志工經驗，但因為排了手術整個打亂，加上種種因素只 […]","\u003Ch1>WordCamp Asia 2024 小記\u003C\u002Fh1>\n\u003Cp>原本很期待協作日和志工經驗，但因為排了手術整個打亂，加上種種因素只好這次當個參加者XD\u003Cbr \u002F>\n剛報到時才有種，啊真的是國際活動啊！的念頭，從進 TICC 側門後就滿滿的非華語系國家的人種走來走去，加上全英文的指示，對於外語社交障礙的我充滿了挑戰。\u003C\u002Fp>\n\u003Cp>\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2024%2F03%2FIMG_7765-768x1024.jpg\" alt=\"\" \u002F>\u003C\u002Fp>\n\u003Ch2>【議程】\u003C\u002Fh2>\n\u003Cp>這次刻意去一些非開發類的議程，想聽聽不一樣領域的內容，的確也滿有意思的，像是靠訂閱寫作年收 300 萬美金的 Ben Thompson\u003Cbr \u002F>\n分享他的發跡歷程與未來計畫 \u003Ca href=\"https:\u002F\u002Fpassport.online\u002F\">https:\u002F\u002Fpassport.online\u002F\u003C\u002Fa> —— 聽起來像是去中心化的知識(網站)聚合模式。\u003Cbr \u002F>\nkeynote 和結尾的 Matt 提到的一些概念滿有感觸，WordPress 的成功靠的是齊全的生態系，透過透明、開放的開源精神，不禁想到許多成功的作品(例如遊戲)，也是具備豐富的二創、甚至是開放工作坊等等模式，建立起內容生態系延續作品生命。產品也是如此吧，除了服務使用者外，最好能同時有一套模式可以吸引到厲害的人去改進你的產品進而提供更好的服務。成功的商業就是利他精神。\u003Cbr \u002F>\n\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2024%2F03%2FIMG_7775-1024x768.jpg\" alt=\"\" \u002F>\u003C\u002Fp>\n\u003Ch2>【場邊】\u003C\u002Fh2>\n\u003Cp>真的是第一次看到參加者組成是非華語者大於華語者，而且從最後的提問才發現中亞、南亞的參加者也相當多，而且也有許多開發者身處的政治體系不利於開發，台灣的環境已經相當幸福了，要好好珍惜。\u003Cbr \u002F>\n要離開前先前 WordCamp Taiwan 的志工夥伴小魚問我，對你來說 WordPress 的優點是什麼，我後來想到更好的回答—— WordPress 提供了一個低門檻的溝通語言，讓網路數位的從業者、愛好者能透過這個語言產生交流，並且從這樣的交流中互相影響與成長。應該是這樣吧？\u003C\u002Fp>\n\u003Cp>\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2024%2F03%2FIMG_7786-768x1024.jpg\" alt=\"\" \u002F>\u003C\u002Fp>\n\u003Cp>\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2024%2F03%2FIMG_7773-1024x768.jpg\" alt=\"\" \u002F>\u003C\u002Fp>\n\u003Cp>最後，2025 菲律賓見啦XD\u003C\u002Fp>\n\u003Cp>以及感謝 WordCamp Asia 2024 的志工們努力，讓我在台灣體驗到如此國際化的活動，讚啦。\u003C\u002Fp>\n","2024-03-11T15:01:08","\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2024%2F03%2FIMG_7786-scaled.jpg",{"name":88,"link":89},[140],{"name":65,"slug":66},"\u002Fblog\u002Fwordcamp-asia-2024-小記",{"id":143,"slug":144,"title":145,"description":146,"content":147,"date":148,"image":149,"imageAlt":145,"author":150,"categories":151,"path":153,"minRead":9},3565,"wordcamp-taipei-2023","WordCamp Taipei 2023 心得","心得與紀錄 疫情後很多實體的社群活動如雨春筍般冒出來，常感覺得在台灣有這樣蓬勃的技術社群能量真的很幸福。由於轉 […]","\u003Cp>\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2023%2F11%2F53297144260_2e94504375_k-1024x683.jpg\" alt=\"\" \u002F>\u003C\u002Fp>\n\u003Ch1>心得與紀錄\u003C\u002Fh1>\n\u003Cp>疫情後很多實體的社群活動如雨春筍般冒出來，常感覺得在台灣有這樣蓬勃的技術社群能量真的很幸福。由於轉職後比較沒事情做(\u003Cdel>沒案子\u003C\u002Fdel>)，想說就來報名 WordCamp Taiwan 2023 的志工。這篇文章就來記錄參與志工的過程與一些心得吧。\u003C\u002Fp>\n\u003Ch1>報名志工\u003C\u002Fh1>\n\u003Cp>今年 WordCamp Taiwan 2023 的報名招募可以讓人選擇組別志願，建議挑選一些有興趣但不是自己專業的組別，這樣能趁機學到很多不同面相的經驗與換位思考。\u003C\u002Fp>\n\u003Ch2>關於組別\u003C\u002Fh2>\n\u003Cp>這次的組別分為以下幾種：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>總召\u003C\u002Fli>\n\u003Cli>網站組\u003C\u002Fli>\n\u003Cli>議程組\u003C\u002Fli>\n\u003Cli>公關組\u003C\u002Fli>\n\u003Cli>場地組\u003C\u002Fli>\n\u003Cli>贊助組\u003C\u002Fli>\n\u003Cli>設計組\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>差不多4月初開始徵選，然後4月中就通知了，我進了議程組，想說還好之前曾在「世代談」當過活動執行，多少對邀約安排有點經驗XDDD\u003C\u002Fp>\n\u003Ch2>議程組要做什麼？\u003C\u002Fh2>\n\u003Cp>大致上有幾件重點事項：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>議程規劃\u003C\u002Fli>\n\u003Cli>講者招募與聯繫\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>議程規劃\u003C\u002Fh2>\n\u003Cp>就是議程的流程規劃，例如規劃活動主題、規劃報名流程、場次時段等等，畢竟 WordCamp 的核心除了交流以外就是議程了，大多數的參與者會被議程內容吸引，因此可以算是相當重要的環節。\u003C\u002Fp>\n\u003Ch3>議程報名資訊\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>規劃議程場次、時間\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>因為無預設講者數量，所以一開始沒有明確定義場次與時間。但為了明確描繪出活動輪廓，我們最後還是先定義可能的場次量與時段，這樣比較好進行準備與後續的調整。由於場次規劃跟場地有可能互相影響，因此要注意有時候會有突發狀況，例如場地更換等等。\u003C\u002Fp>\n\u003Cul>\n\u003Cli>定義議程主軸\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>如果一開始就明確的議程主軸，可以照主軸來規劃。如果沒有的話，直接海選就可以，到時再依照投稿狀況來分類與調整。\u003C\u002Fp>\n\u003Cul>\n\u003Cli>議程盡量跨領域\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>由於 WordCamp 的精神是開放與平等，盡可能讓議程內容包含很多領域，例如開發、設計、商業、社群等等，我們有規劃出一個廣泛的分類定義可以參考。(下面附錄)\u003C\u002Fp>\n\u003Ch3>釋出報名資訊\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>原本規劃：\n\u003Cul>\n\u003Cli>講者公開招募（2023 年 6 月 26 日）\u003C\u002Fli>\n\u003Cli>講者公開招募截止（2023 年 7月 31 日）\u003C\u002Fli>\n\u003Cli>講者遴選作業（2023 年 8 月 7 日）\u003C\u002Fli>\n\u003Cli>通知獲選講者（2023 年 8 月 21 日）\u003C\u002Fli>\n\u003Cli>公布講者名單（2023 年 8 月 28 日）\u003C\u002Fli>\n\u003C\u002Ful>\n\u003C\u002Fli>\n\u003Cli>後來公開招募晚了約一週，也延後了截止招募一週，後來就沒有影響太多時程。\u003C\u002Fli>\n\u003Cli>但講者通知初期規劃漏了需要二次確認，所以建議未來記得直接列出以下流程。\n\u003Col>\n\u003Cli>講者公開招募\u003C\u002Fli>\n\u003Cli>講者公開招募截止\u003C\u002Fli>\n\u003Cli>講者遴選作業\u003C\u002Fli>\n\u003Cli>通知獲選講者\u003C\u002Fli>\n\u003Cli>二次獲選講者\u003C\u002Fli>\n\u003Cli>公布講者名單\u003C\u002Fli>\n\u003C\u002Fol>\n\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>與網站組、贊助組、公關組協同作業\u003C\u002Fh3>\n\u003Cp>說起來越到後期才意識到議程組相當重要，講者招募需要與網站組和公關組協調，而贊助組、公關組會需要招募完畢後的議程規劃以利後續宣傳，以上這些事情會一起冒出來，也就是越快越好，甚至是先把議程時段規劃丟出來，開始賣盲鳥票都是可以考慮的。真的越快越好，先求有再求好。有越多資料才有很多籌碼可以配合票務與場務。\u003C\u002Fp>\n\u003Ch3>關於宣傳\u003C\u002Fh3>\n\u003Cp>由於宣傳由公關組處理，老實說不太確定他們的宣傳流程，我們就盡量提供需求資料，例如講者招募資料、一些介紹文字等等。\u003C\u002Fp>\n\u003Ch2>講者招募與聯繫\u003C\u002Fh2>\n\u003Cp>當講者招募資料完成後就差不多可以開始公開招募囉～大致有以下幾件事要處理：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>錄取資訊\u003C\u002Fli>\n\u003Cli>活動流程\u003C\u002Fli>\n\u003Cli>講題資料確認\u003C\u002Fli>\n\u003Cli>票務、禮品確認\u003C\u002Fli>\n\u003Cli>其他確認\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>錄取資訊\u003C\u002Fh3>\n\u003Cp>關於錄取資訊，我們進行了兩次講者聯絡，第一次先通知錄取講者並且在確認是否會出席，第二次則是正式通知後續溝通流程，信件內容包含了：\u003C\u002Fp>\n\u003Col>\n\u003Cli>餐點飲食\u003C\u002Fli>\n\u003Cli>議程流程時間\u003C\u002Fli>\n\u003Cli>講題大綱確認\u003C\u002Fli>\n\u003Cli>活動出席狀況(是否攜伴)\u003C\u002Fli>\n\u003Cli>簡報截止時間\u003C\u002Fli>\n\u003Cli>禮品尺寸問題\u003C\u002Fli>\n\u003Cli>其他\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>活動流程\u003C\u002Fh3>\n\u003Cp>因為講者招募狀況有很多變化，議程場次也有可能因此調整，如果講者報名數量高於或低於預期，就必須要滾動式變化。\u003C\u002Fp>\n\u003Ch3>講題資料確認\u003C\u002Fh3>\n\u003Cp>盡可能越早拿到題目越好，這部分跟宣傳有很大影響，越早釋出對招募參加者會越有幫助唷。\u003C\u002Fp>\n\u003Ch3>票務、禮品確認\u003C\u002Fh3>\n\u003Cp>活動多半會有參加者衣服與小禮物，尺寸之類、品項等等都記得跟設計組確認。\u003C\u002Fp>\n\u003Ch3>其他確認\u003C\u002Fh3>\n\u003Cp>講者在籌備過程有可能會提出問題，就盡可能持續溝通協調。\u003C\u002Fp>\n\u003Ch2>補充\u003C\u002Fh2>\n\u003Ch3>可能沒有講者？\u003C\u002Fh3>\n\u003Cp>起初其實滿擔心沒有招募到講者，這部分可以跟各夥伴一同討論與支援，例如主動邀稿等等方式都是可以執行的。\u003C\u002Fp>\n\u003Ch3>議程類型差異\u003C\u002Fh3>\n\u003Cp>這次覺得較可惜就是議程類型缺少前端、設計類型，我想這部分一樣可以透過主動邀稿方式來處理。\u003C\u002Fp>\n\u003Ch2>感謝\u003C\u002Fh2>\n\u003Cp>最後謝謝兩位夥伴 Calvin 和 Alfred 的共事，讓議程組能順利運作。也謝謝 WordCamp Taiwan 2023 所有志工夥伴，一起完成活動！\u003Cbr \u002F>\n\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2023%2F11%2FIMG_7286-1024x683.jpg\" alt=\"\" \u002F>\u003C\u002Fp>\n\u003Ch1>建議與改進\u003C\u002Fh1>\n\u003Cp>這邊提出一點建議，希望下次籌備時可以參考：\u003C\u002Fp>\n\u003Ch2>議程規劃\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>不太需要先規劃議程主軸，直接用「當年度WrodCamp」趕快先釋出報名資訊就對了\u003C\u002Fli>\n\u003Cli>也建議同步開始盲鳥票務宣傳\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>議程報名宣傳優先\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>議程組初期花了比較多時間在確認主題與招募細節，後來覺得招募細節可以建立SOP，盡可能趕快丟出招募資訊，越快越好。\u003Cbr \u002F>\n\u003Ch2>活動經驗傳承\u003C\u002Fh2>\n\u003C\u002Fli>\n\u003Cli>每個組別盡量留下籌備流程，當新的志工準備新的活動時可以直接參考。這也是這篇文章誕生的原因XD\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch1>可以參考的主題分類定義\u003C\u002Fh1>\n\u003Cp>未來籌辦時可以參考～\u003C\u002Fp>\n\u003Ch3>工程與開發相關主題：\u003C\u002Fh3>\n\u003Col>\n\u003Cli>WordPress 核心開發與探討\u003C\u002Fli>\n\u003Cli>RestAPI 相關整合或其他API應用\u003C\u002Fli>\n\u003Cli>外掛開發\u003C\u002Fli>\n\u003Cli>佈景主題開發\u003C\u002Fli>\n\u003Cli>其他語言的延伸應用， PHP ， HTML ， CSS ， JavaScript ， React 或其他技術的延伸應用\u003C\u002Fli>\n\u003Cli>金流串接與應用\u003C\u002Fli>\n\u003Cli>開發者工具與開發流程\u003C\u002Fli>\n\u003Cli>Headless 開發應用\u003C\u002Fli>\n\u003Cli>SiteEditor 應用\u003C\u002Fli>\n\u003Cli>其他開發相關主題\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>設計與使用體驗相關主題：\u003C\u002Fh3>\n\u003Col>\n\u003Cli>UI\u002FUX\u003C\u002Fli>\n\u003Cli>Mobile First 設計\u003C\u002Fli>\n\u003Cli>規劃與設計流程\u003C\u002Fli>\n\u003Cli>Gutenberg 區塊 Blocks 相關\u003C\u002Fli>\n\u003Cli>品牌設計與網站整合\u003C\u002Fli>\n\u003Cli>字體與字型\u003C\u002Fli>\n\u003Cli>其他設計相關\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>安全性、資料管理、隱私相關主題：\u003C\u002Fh3>\n\u003Col>\n\u003Cli>外掛與安全性\u003C\u002Fli>\n\u003Cli>主機與網站安全性\u003C\u002Fli>\n\u003Cli>GDPR 配置相關\u003C\u002Fli>\n\u003Cli>緊急應對與惡意攻擊對策\u003C\u002Fli>\n\u003Cli>資料保護\u003C\u002Fli>\n\u003Cli>其他安全性相關\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>商務應用與企業經營相關主題：\u003C\u002Fh3>\n\u003Col>\n\u003Cli>WordPress 電子商務整合\u003C\u002Fli>\n\u003Cli>品牌經營\u003C\u002Fli>\n\u003Cli>行銷策略\u003C\u002Fli>\n\u003Cli>公司經營\u003C\u002Fli>\n\u003Cli>Freelance 經營\u003C\u002Fli>\n\u003Cli>SEO 與內容經營相關\u003C\u002Fli>\n\u003Cli>社群媒體\u003C\u002Fli>\n\u003Cli>其他商用應用\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>生涯與個人發展相關主題：\u003C\u002Fh3>\n\u003Col>\n\u003Cli>創業與經營\u003C\u002Fli>\n\u003Cli>個人品牌經營\u003C\u002Fli>\n\u003Cli>部落格經營\u003C\u002Fli>\n\u003Cli>學習與成長\u003C\u002Fli>\n\u003Cli>育兒應用\u003C\u002Fli>\n\u003Cli>心理健康\u003C\u002Fli>\n\u003Cli>其他\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>社群與生態圈相關主題：\u003C\u002Fh3>\n\u003Col>\n\u003Cli>如何經營 WordPress 生態圈\u003C\u002Fli>\n\u003Cli>出一份力共同成長 WordPress\u003C\u002Fli>\n\u003Cli>社群的力量\u003C\u002Fli>\n\u003Cli>社群活動\u003C\u002Fli>\n\u003Cli>WordPress 如何可以更好\u003C\u002Fli>\n\u003Cli>其他\u003C\u002Fli>\n\u003C\u002Fol>\n","2023-11-10T13:57:02","\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2023%2F11%2FIMG_7286.jpg",{"name":88,"link":89},[152],{"name":65,"slug":66},"\u002Fblog\u002Fwordcamp-taipei-2023",{"id":155,"slug":156,"title":157,"description":158,"content":159,"date":160,"image":101,"imageAlt":157,"author":161,"categories":162,"path":164,"minRead":29},3528,"wps-hide-login-與-translatepress-的設定方式","WPS Hide Login 與 TranslatePress 的設定方式","WPS Hide Login 與 TranslatePress 的設定方式 記錄一下 WPS Hide Log […]","\u003Ch1>WPS Hide Login 與 TranslatePress 的設定方式\u003C\u002Fh1>\n\u003Cp>記錄一下 WPS Hide Login 與 TranslatePress 共同使用時的設定方式\u003C\u002Fp>\n\u003Ch2>關於多國語言 TranslatePress\u003C\u002Fh2>\n\u003Cp>如果要在WordPress上實作多國語言版本，有時候可能會用 TranslatePress。預設作法是使用網址的 slug 來切換不同語言版本，假設 example.com 是預設網站，那中文版可能就會稱為 example.com\u002Fzh-TW 之類。\u003C\u002Fp>\n\u003Ch2>WPS Hide Login\u003C\u002Fh2>\n\u003Cp>能修改預設 wp-admin 登入後台 slug 的外掛，避免後台網址太快被人猜出來。因為只要爬蟲或駭客發現你是 WordPress 都能嘗試使用 wp-admin 來試試看後台登入。\u003C\u002Fp>\n\u003Ch2>共同使用時的衝突\u003C\u002Fh2>\n\u003Cp>如果兩者裝好後，就會發現衝突，例如後台改成 \u002Flogin\u002F 登入位置如下： example.com\u002Flogin 。 以這樣輸入網址後，就會被跳轉到 example.com\u002Fzh-TW\u002Flogin 導致找不到位置。\u003Cbr \u002F>\n解決方式很簡單， TranslatePress 的設定 > 進階( Advanced )，找到 「Do not translate certain paths: Exclude Paths From」選項，填入你的修改位置。如果 WPS Hide Login 中設定為 login ，那這邊就填入 \u002Flogin\u002F 。\u003Cbr \u002F>\n這樣 TranslatePress 就會排除這個登入 slug 進行多語系轉址囉。\u003C\u002Fp>\n","2023-06-06T10:00:25",{"name":88,"link":89},[163],{"name":65,"slug":66},"\u002Fblog\u002Fwps-hide-login-與-translatepress-的設定方式",{"id":166,"slug":167,"title":168,"description":169,"content":170,"date":171,"image":101,"imageAlt":168,"author":172,"categories":173,"path":175,"minRead":29},3524,"在wordpress實現客家版本的多國語系網頁標題標籤titile","在WordPress實現客家版本的多國語系網頁標題標籤titile","在WordPress實現客家版本的多國語系網頁標籤titile(建議不要用) 我透過TranslatePres […]","\u003Ch1>在WordPress實現客家版本的多國語系網頁標籤titile(建議不要用)\u003C\u002Fh1>\n\u003Cp>我透過TranslatePress實作了一個雙語言的網站專案，結果設定完SEO才想到，阿勒，那多國語系網頁標題標籤(SEO的meta)怎麼辦？\u003Cbr \u002F>\n查了一下，TranslatePress很貼心的有做，但想當然要升級成專業版XDDD想了一下那就用hook硬幹吧。\u003C\u002Fp>\n\u003Ch2>補充\u003C\u002Fh2>\n\u003Cp>發現這方法不會移除原有的meta，導致會出現重複meta，因此改了另一種做法，新方式請見此篇\u003C\u002Fp>\n\u003Ch2>wp_head()\u003C\u002Fh2>\n\u003Cp>查了一下可以使用wp_head這個hook。\u003C\u002Fp>\n\u003Cpre>\u003Ccode># wp-includes\u002Fgeneral-template.php\nfunction wp_head() {\n    ...\n    do_action( 'wp_head' );\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>從這邊可以看出WordPress中渲染網頁title標籤的是透過_wp_render_title_tag。\u003C\u002Fp>\n\u003Cpre>\u003Ccode># wp-includes\\default-filters.php\nadd_action( 'wp_head',             '_wp_render_title_tag',            1     );\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>再往下追就能看到_wp_render_title_tag回傳了標籤的內容。\u003C\u002Fp>\n\u003Cpre>\u003Ccode># wp-includes\u002Fgeneral-template.php\nfunction _wp_render_title_tag() {\n    ...\n    echo '<title>' . wp_get_document_title() . '<\u002Ftitle>' . "\\n";\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>實作\u003C\u002Fh2>\n\u003Cp>因此可以使用add_filter()來覆蓋這個字串，顯示我想要的不同語言title。\u003Cbr \u002F>\n設計思維：\u003C\u002Fp>\n\u003Col>\n\u003Cli>取得URL中的slug\u003C\u002Fli>\n\u003Cli>透過slug判斷現在的語言\u003C\u002Fli>\n\u003Cli>取的頁面的原標題，跟我要的內容組合title\u003C\u002Fli>\n\u003Cli>根據語言回傳不同的title\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>因為我這個專案的頁面很單純，都是page，所以省去了一些判斷。範例如下：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>function custom_page_title($title) {\n    global $wp;\n    $url = home_url($wp->request);\n    $slug = trim(parse_url($url, PHP_URL_PATH), '\u002F');\n    $posttitle = get_the_title();\n\n    if($slug == 'zh_tw'){\n        $title = '<title>' . $posttitle.' - 中文標題' . '<\u002Ftitle>';\n    }elseif($slug == 'en'){\n        $title = '<title>' . $posttitle.' - Englishtitle' . '<\u002Ftitle>';\n    }else{\n        $title = '<title>' . $posttitle.' - 中文標題' . '<\u002Ftitle>';\n    }\n    echo $title;\n}\n\nadd_filter('wp_head', 'custom_page_title', 1);\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>老實說不是很確定有沒有發揮SEO效果，還得再觀察與研究下這個作法，但以目前來說是可以行的。\u003C\u002Fp>\n","2023-06-01T12:16:00",{"name":88,"link":89},[174],{"name":65,"slug":66},"\u002Fblog\u002F在wordpress實現客家版本的多國語系網頁標題標籤titile",{"id":177,"slug":178,"title":179,"description":180,"content":181,"date":182,"image":101,"imageAlt":179,"author":183,"categories":184,"path":186,"minRead":9},3508,"看不懂選項也可以駕馭的litespeed-cache設定法","看不懂選項也可以駕馭的LiteSpeed Cache設定法","看不懂選項也可以駕馭的 LiteSpeed Cache 設定法 WordPress最方便的就是有很多外掛、主題 […]","\u003Ch1>看不懂選項也可以駕馭的 LiteSpeed Cache 設定法\u003C\u002Fh1>\n\u003Cp>WordPress最方便的就是有很多外掛、主題，可以透過編輯器讓設計師甚至是不懂任何網頁概念的使用者作出美觀又符合需求的網頁，這也是造成設計出來的網頁可能存在效能問題的原因之一。\u003Cbr \u002F>\n尤其是\u003Cdel>(大家都知道的)elementor\u003C\u002Fdel>，因此使用WordPress架設網站後，調校效能就是另一間很多人會想做的事情了。但網站的效能調校需要具備高度相關知識，更需要耐心和溝通(?，除此外我們還會再藉由一些外掛來協助達成目標。\u003Cbr \u002F>\n這篇文章指在寫給非網頁專業的使用者，在使用LiteSpeed Cache時可以快速基本調校設定。\u003C\u002Fp>\n\u003Ch2>LiteSpeed Cache是什麼\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fwordpress.org\u002Fplugins\u002Flitespeed-cache\u002F\" title=\"LiteSpeed Cache\">LiteSpeed Cache\u003C\u002Fa> 是一個 WordPress 的外掛，如果你的 WordPress 是架設在 LiteSpeed Web Server 上，就會推薦使用 LiteSpeed Cache 作為效能調校的外掛。\u003Cbr \u002F>\n如果無法確認，那也堪用，但注意像是A2 host就有自己的效能調校外掛，所以記得先確認自己的主機傷有沒有相關服務喔。\u003Cbr \u002F>\n而如果你的主機有 LiteSpeed Web Server ，也記得要用它來開啟 WordPress 服務。\u003Cbr \u002F>\nLiteSpeed Cache 有大量使用到 QUIC.cloud 服務的功能，但這不是這篇的重點，有興趣的人請再看看 \u003Ca href=\"https:\u002F\u002Fwww.quic.cloud\u002F\" title=\"QUIC.cloud\">QUIC.cloud\u003C\u002Fa> 是什麼。\u003C\u002Fp>\n\u003Ch2>基本操作\u003C\u002Fh2>\n\u003Cp>安裝完後，記得 LiteSpeed Cache 有付費服務，但基本方案就夠用了。應該可以在後台上方的工具列看到 LiteSpeed Cache 的功能像這樣。\u003Cbr \u002F>\n\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2023%2F05%2F%E6%88%AA%E5%9C%96-2023-05-03-%E4%B8%8B%E5%8D%883.51.04-296x300.png\" alt=\"\" \u002F>\u003Cbr \u002F>\n記好「清除全部快取」，這個會很常用。\u003Cbr \u002F>\n再來是記得以下流程：\u003C\u002Fp>\n\u003Col>\n\u003Cli>每次做完任何設定 + 儲存後\u003C\u002Fli>\n\u003Cli>點擊「清除全部快取」\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>這樣重讀網頁才會看得到更動效果。\u003C\u002Fp>\n\u003Ch2>Cache 設定快取\u003C\u002Fh2>\n\u003Cp>左側找到「Cache」選項，快取簡單來說就是將你的網頁目前資料先放到一個地方，當使用者打開你的網頁時可以快速提供讀取。優點就是會變快，但也有缺點，有時候網站內容有修正不會立即反應。(所以每次變動玩記得清除，請看上面)\u003Cbr \u002F>\n雖然下面會列出每個功能的用途，但看不懂的人可以全開，\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Enable Cache – cache啟動的選項，必須ON才能啟動快取功能。\u003C\u002Fli>\n\u003Cli>Cache Logged-in Users – 如果會有很多登入的使用者，這個功能會產生多個相關快取。\u003C\u002Fli>\n\u003Cli>Cache Commenters – 針對留言的人的暫存，就開吧。\u003C\u002Fli>\n\u003Cli>Cache REST API – WordPress 的 REST API 快取功能，就開吧。\u003C\u002Fli>\n\u003Cli>Cache Login Page – 官方都在選項寫不開可能會有不好效果，就開吧。\u003C\u002Fli>\n\u003Cli>Cache favicon.ico - 透過php設定加速favicon.ico的讀取，就開吧。\u003C\u002Fli>\n\u003Cli>Cache PHP Resources - 提高php讀取效能，就開吧。\u003C\u002Fli>\n\u003Cli>Cache Mobile - 這個預設沒有開，現在誰不需要手機版本呢？記得打開。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Page Optimization 設定頁面最佳化\u003C\u002Fh2>\n\u003Cp>這裡是設定頁面最佳化，像 CSS，Javascirpt 檔案壓縮或合併、非同步載入等等，這邊的選項每次都可能會影響原先的網頁動畫、功能等等，建議一次一個選項。\u003C\u002Fp>\n\u003Ch3>CSS Settings 分頁\u003C\u002Fh3>\n\u003Cp>免費版本的話只會用到以下幾種，就加減試試看囉：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>CSS Minify – 壓縮 CSS 檔案，通常不會有問題，開吧。\u003C\u002Fli>\n\u003Cli>CSS Combine – 合併 CSS 檔案合併，可能會造成網頁顯示異常，經驗上滿常出現，如果有異常就關掉。\u003C\u002Fli>\n\u003Cli>CSS Combine External and Inline - 會合併外部和內連宣告的CSS，官方說這選項要在 CSS Combine 啟動時才有效果，能大幅減少 CSS Combine 的異常。\u003C\u002Fli>\n\u003Cli>Inline CSS Async Lib - 用非同步方式載入 CSS，意思是錯開 CSS 檔案的讀取時間，有可能提高載入速度但可能會出現部分網頁顯示異常。\u003C\u002Fli>\n\u003Cli>Font Display Optimization - 會先建議設定 Swap，但可能會出現網頁開始時先識預設字體然後再跳換成另一種字體，先開看看。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>JS Settings 分頁\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>JS Minify – 壓縮 JS 檔案，開吧。\u003C\u002Fli>\n\u003Cli>JS Combine – 合併 JS 檔案，但一樣可能會造成 JS 程式錯誤，經驗上滿常出現，如果有異常就關掉。\u003C\u002Fli>\n\u003Cli>JS Combine External and Inline - 跟上述 CSS 一樣，也要在 JS Combine 開啟時才有效果。\u003C\u002Fli>\n\u003Cli>Load JS Deferred – 選擇載入 JS 的時間，可以都試看看，有問題就切回預設。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>HTML Settings 分頁\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>HTML Minify – 壓縮 HTML 檔案，開吧，哪次不開\u003C\u002Fli>\n\u003Cli>DNS Prefetch Control  – 讓DNS擷取文檔中的URL，建議開啟\u003C\u002Fli>\n\u003Cli>Remove Query Strings - 移除連結 URL 的查詢字串，開吧。\u003C\u002Fli>\n\u003Cli>Load Google Fonts Asynchronously – 非同步載入 Google Fonts，開啟後可以讓讀取 Google 字型快一點，老實說我感覺不太出來，但開吧。\u003C\u002Fli>\n\u003Cli>Remove Google Fonts – 防止所有網頁讀取 Google Fonts ，理論上會快很多，但我也感覺不太出來，先開吧。\u003C\u002Fli>\n\u003Cli>Remove WordPress Emoji – 移除 WordPress 表情符號檔案，沒用到的人就開吧。\u003C\u002Fli>\n\u003Cli>Remove Noscript Tags – 有noscript tag 可以增加老舊瀏覽器的相容性，但會增加檔案大小，如果不考慮舊型瀏覽器相容性，就開吧。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>小結\u003C\u002Fh2>\n\u003Cp>上述設定完，如果網站沒有什麼大概，應該能提升10~20%的效能。非常有用喔。\u003Cbr \u002F>\n至於其他沒提到的設定，多半有用預設就可以了，本文的前提是給看不懂設定的人使用，所以其他設定就不要管了XDDD那麼未來有機會再寫分享更多效能調校的經驗吧！\u003C\u002Fp>\n","2023-05-03T20:07:29",{"name":88,"link":89},[185],{"name":65,"slug":66},"\u002Fblog\u002F看不懂選項也可以駕馭的litespeed-cache設定法",{"id":188,"slug":189,"title":190,"description":191,"content":192,"date":193,"image":101,"imageAlt":190,"author":194,"categories":195,"path":197,"minRead":29},3497,"多站點模式multiple-site下的worpress，site_id與blog_id的差異","多站點模式(multiple site)下的WorPress，site_id與blog_id的差異","多站點模式下的WorPress，site_id與blog_id的差異 自從將WorPress開啟多站點模式(m […]","\u003Ch1>多站點模式下的WorPress，site_id與blog_id的差異\u003C\u002Fh1>\n\u003Cp>自從將WorPress開啟多站點模式(multiple site)後，發現進行站點與使用者的管理行為就變得很複雜，當然多站點模式在某些需求下真的很好用，只是得記得它伴隨著管理難度會相對提高一些。這次在撰寫一些小功能時發現site_id在某些判斷上失效了，深入查下去才發現site_id與blog_id的真正意義。\u003C\u002Fp>\n\u003Cp>簡單來說blog_id就是子站點的id，在多站點模式下，子站點是用「blog」來稱呼，而整個系統則是用「site」，當然就是用site_id來代表其id。\u003Cbr \u002F>\n如果使用以下程式碼\u003C\u002Fp>\n\u003Cpre>\u003Ccode>$blog_id = get_current_blog_id(); \u002F\u002F取得子站點blog_id\n$current_site = get_current_site();\n$site_id = $current_site->id;\u002F\u002F取得系統site_id\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>另外如果用get_sites() 取得的所有站點資訊，也會發現這個數值。\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Array(\n    [0] => WP_Site Object(\n        [blog_id] => 1\n        [site_id] => 1\n        [domain] => example.com\n        [path] => \u002F\n        [registered] => 2013-11-08 17:56:46\n        [last_updated] => 2013-11-08 18:57:19\n        [public] => 1\n        [archived] => 0\n        [mature] => 0\n        [spam] => 0\n        [deleted] => 0\n        [lang_id] => 0\n    )\n\n    [1] => WP_Site Object(\n        [blog_id] => 2\n        ...\n    )\n)\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>未來要開發多站點模式的功能時，要記得呼叫正確的id囉\u003C\u002Fp>\n","2023-04-08T20:25:50",{"name":88,"link":89},[196],{"name":65,"slug":66},"\u002Fblog\u002F多站點模式multiple-site下的worpress，site_id與blog_id的差異",{"id":199,"slug":200,"title":201,"description":202,"content":203,"date":204,"image":101,"imageAlt":201,"author":205,"categories":206,"path":208,"minRead":29},3476,"wordpress-301-redirection-plugin","WordPress如何大量轉換文章或是頁面位置？301轉址是你的好夥伴！","WordPress如何大量轉換文章或是頁面位置？301轉址是你的好夥伴！ 有時候我們可能會遇到一種狀況，自己經 […]","\u003Ch1>WordPress如何大量轉換文章或是頁面位置？301轉址是你的好夥伴！\u003C\u002Fh1>\n\u003Cp>有時候我們可能會遇到一種狀況，自己經營的網站中有一些已經發佈出去的文章或頁面，因為某些原因會希望他們事後可以換個位置，這時我們可以考慮使用轉址來處理，精確一點稱為301轉址(301Redirect)，也能叫301重新導向。\u003Cbr \u002F>\n301轉址簡單說就是將舊網址永久轉換至新網址。轉移過程包含了網址跳轉、轉移頁面權重與流量。這個做法尤其對於SEO非常重要，因為如果讓搜尋引擎認為你的新舊網址是各自獨立，那麼頁面的流量與搜尋權重就得重新培養囉。\u003C\u002Fp>\n\u003Cp>那麼在什麼情況下會需要301轉址呢？\u003C\u002Fp>\n\u003Ch1>常見原因\u003C\u002Fh1>\n\u003Col>\n\u003Cli>\n\u003Cp>網址結構改變\u003Cbr \u002F>\n在WordPress中可能因為永久連結設定改變，而需要調整網址結構，例如：\u003Cbr \u002F>\n原本永久連結：「文章編號」\u003Cbr \u002F>\n更改為永久連結變成：「文章名稱」\u003Cbr \u002F>\n那麼就必須要建立一個規則讓「文章編號」能對應「文章名稱」\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>網站改版\u003Cbr \u002F>\n有時候網站改版會搬遷到新的主機甚至是新的網域上，為了將過去的流量接回到新網站上，就會需要使用轉址來滿足需求。不然六師累積起來的流量就很可惜囉。\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>重複內容\u003Cbr \u002F>\nGoogle的搜尋引擎演算法會針對網站的內容、相關性與頁面權重進行評比，若在不同網站中有許多頁面是重複內容，即使是自己的經營的內容，也可能被判定為抄襲而遭致懲罰，導致評比下降。這時也會利用利用301轉址到多數內容同一個網址下以解決問題。\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch1>什麼是301轉址？\u003C\u002Fh1>\n\u003Cp>每次我們的瀏覽器在對某個網址(URL)發送請求後，收到的回應會附帶一個Http狀態碼，以下是常見的狀態碼代表意義：\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>\u003C\u002Fth>\n\u003Cth>代表狀態\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>200\u003C\u002Ftd>\n\u003Ctd>連線正常\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>301\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>永久性轉址\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>302\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>暫時性轉址\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>404\u003C\u002Ftd>\n\u003Ctd>查無此頁面\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>503\u003C\u002Ftd>\n\u003Ctd>伺服器無回應(有頁面但無法回應資料)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>\u003Cstrong>301轉址意思就是這個網址被進行轉換導向，而且是永久性的。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch1>外掛Redirection\u003C\u002Fh1>\n\u003Cp>「Redirection」是個很好用的WordPress轉址功能外掛，能自動將使用者轉換錯誤網址到正確網址。\u003Cdel>而且免費，作者很佛心\u003C\u002Fdel>\u003Cbr \u002F>\n以下是外掛的連結\u003Cbr \u002F>\n\u003Ca href=\"https:\u002F\u002Ftw.wordpress.org\u002Fplugins\u002Fredirection\u002F\">https:\u002F\u002Ftw.wordpress.org\u002Fplugins\u002Fredirection\u002F\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch2>設定方式\u003C\u002Fh2>\n\u003Cp>安裝完後外掛的設定選單會在「工具」-> 「Redirection」\u003Cbr \u002F>\n啟用後應該會有個自動處理的設定過程。\u003Cbr \u002F>\n\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2023%2F03%2F%E6%88%AA%E5%9C%96-2023-03-21-%E4%B8%8B%E5%8D%883.17.21.png\" alt=\"\" \u002F>\u003Cbr \u002F>\n推薦可以先用自動處理，「Start Setup」，選則後會出現以下選項\u003C\u002Fp>\n\u003Cp>\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2023%2F03%2F%E6%88%AA%E5%9C%96-2023-03-21-%E4%B8%8B%E5%8D%883.17.40.png\" alt=\"\" \u002F>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Monitor permalink changes in WordPress post and pages:這個是監控你的網站中如果有變更過位置，會自動產生轉址資料。\u003C\u002Fli>\n\u003Cli>Keep a log of all redirects and 404 error : 監控轉址錯誤，如果有訪客使用你們網站卻出現錯誤時會有紀錄。\u003C\u002Fli>\n\u003Cli>Strore IP information for redirects and 404 error : 如果上面選項勾選後，就會挑出此選項，這個會順勢紀錄IP，但紀錄IP需要注意歐盟政策GDPR(如果你的網站是國際性最好注意)，建議不清楚的話就別開。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2023%2F03%2F%E6%88%AA%E5%9C%96-2023-03-21-%E4%B8%8B%E5%8D%883.18.06.png\" alt=\"\" \u002F>\u003C\u002Fp>\n\u003Cp>再來會檢查你的WordPress網站的REST API功能是否正常。\u003C\u002Fp>\n\u003Cp>\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2023%2F03%2F%E6%88%AA%E5%9C%96-2023-03-21-%E4%B8%8B%E5%8D%883.18.17.png\" alt=\"\" \u002F>\u003Cbr \u002F>\n都沒問題的話就完成基本設定囉！接著就根據需求來進行相關設定。以下介紹我比較常用的功能。\u003C\u002Fp>\n\u003Ch2>基本轉址功能\u003C\u002Fh2>\n\u003Cp>\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2023%2F03%2F%E6%88%AA%E5%9C%96-2023-03-22-%E4%B8%8A%E5%8D%882.18.31.png\" alt=\"\" \u002F>\u003Cbr \u002F>\n在Redirects分頁中可以進行個別的轉址設定，以下是每個欄位說明：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Source URL：來源位置的相對路徑，預設建議使用相對路徑例如\u002Ftest\u002F，右側有一些設定。\n\u003Cul>\n\u003Cli>Regex（正則表達式）：用正則表達式的格式輸入來源網址，如果不懂正規表達式可以跳過這邊XD，如果懂的話，可以參考\u003Ca href=\"https:\u002F\u002Fredirection.me\u002Fsupport\u002Fredirect-regular-expressions\u002F\" title=\"說明\">說明\u003C\u002Fa>。\u003C\u002Fli>\n\u003Cli>Ignore Slash：選取的話來源位置結尾若有「\u002F」也會被轉址；相反，沒選取就不管。\u003C\u002Fli>\n\u003Cli>Ignore Case：如有選取，來源位置會忽略大小寫的差異。\u003Cbr \u002F>\n要注意這兩個設定唷。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003C\u002Fli>\n\u003Cli>Query Parameters：看網址中的參數是否被偵測。以\u002Ftest\u002F001為例\n\u003Cul>\n\u003Cli>Exact Match，這時點擊 post.billxu.net\u002Ftest\u002F001?q=2不會被轉址，因為設定的來源位置跟\u002Ftest\u002F001一樣，有參數就不符合了\u003C\u002Fli>\n\u003Cli>Ignore：比對時忽略來源網址中的參數，以上例來說post.billxu.net\u002Ftest\u002F001?q=2就會被轉址，而且不會將參數帶過去唷。\u003C\u002Fli>\n\u003Cli>Ignore & Pass：比對時忽略來源網址中的參數，但是會將參數帶到到目標位置。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003C\u002Fli>\n\u003Cli>Target URL：目標位置，就是要轉址的目標。如果是跨網域轉址記得要填絕對路徑。\u003C\u002Fli>\n\u003Cli>Group：可以將設定內容群組化，方便管理。群組管理再另外分頁。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Permalink Migration\u003C\u002Fh2>\n\u003Cp>這是超級方便的功能，用途為將某些結構化的位置以規則方式進行轉址。舉例來說，我先前永久連結用日期，結構為「年\u002F月\u002F日\u002F文章名稱」，後來又切換成「文章名稱」，於是有些內容就會需要轉址，這時可以用這個功能，只要在欄位中輸入結構化參數，可以參考設定 -> 永久連結的內容。\u003Cbr \u002F>\n以剛剛例子就是\u002F%year%\u002F%monthnum%\u002F%day%\u002F%postname%\u002F，就會自動轉移到現在的文章永久連結，超級方便！但作者說這還是測試功能，有可能會失效，要注意這點。\u003C\u002Fp>\n\u003Cp>這個外掛還有其他設定功能，這次就只介紹這兩點我比較常用的，若有什麼問題也歡迎在下面留言討論。\u003C\u002Fp>\n","2023-03-22T20:00:36",{"name":88,"link":89},[207],{"name":65,"slug":66},"\u002Fblog\u002Fwordpress-301-redirection-plugin",{"id":210,"slug":211,"title":212,"description":213,"content":214,"date":215,"image":101,"imageAlt":212,"author":216,"categories":217,"path":219,"minRead":29},221,"wordpresscontact-form-7設定封鎖名單的簡單做法","[WordPress]Contact Form 7設定封鎖名單的簡單做法","Contact Form 7設定封鎖名單的簡單做法 WordPress很常使用Contact Form 7做一 […]","\u003Ch1>Contact Form 7設定封鎖名單的簡單做法\u003C\u002Fh1>\n\u003Cp>WordPress很常使用Contact Form 7做一些回饋表單，例如「聯絡我們」或是「意見回饋」等等，但有時候想避免垃圾回應的打擾，或是想限制留言的信箱等等，其實Contact Form 7預設就可以實作這種限制，不需要另外找外掛。\u003Cbr \u002F>\n官方文件有提過這種\u003Ca href=\"https:\u002F\u002Fcontactform7.com\u002Fcomment-blacklist\u002F\" title=\"做法\">做法\u003C\u002Fa>(Disallowed list (formerly known as “Comment blacklist”)。\u003C\u002Fp>\n\u003Ch2>CF7設定封鎖名單\u003C\u002Fh2>\n\u003Cp>作法很簡單，使用原本Wordpress的功能與CF連動。只要在左側欄位選擇\u003Cstrong>設定>討論\u003C\u002Fstrong>，找到\u003Cstrong>禁止使用的留言關鍵字\u003C\u002Fstrong>，將想要封鎖的IP或網域輸入進去就可以囉。(參考下圖)\u003Cbr \u002F>\n\u003Cimg decoding=\"async\" src=\"\u002Fapi\u002Fproxy-image?url=https%3A%2F%2Fpost.billxu.net%2Fwp-content%2Fuploads%2F2022%2F12%2F%E6%88%AA%E5%9C%96-2022-12-01-%E4%B8%8B%E5%8D%8812.21.45.png\" alt=\"\" \u002F>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>封鎖IP：輸入IP\u003C\u002Fli>\n\u003Cli>封鎖特定信箱：輸入信箱位置\u003C\u002Fli>\n\u003Cli>封鎖特定網域：輸入網域\u003Cbr \u002F>\n這邊設定完後，CF7就會跟著連動，記得回應訊息中要更改「系統判定送出的內容為垃圾郵件」，就能給予對應的提示了。\u003C\u002Fli>\n\u003C\u002Ful>\n","2022-12-30T20:00:09",{"name":88,"link":89},[218],{"name":65,"slug":66},"\u002Fblog\u002Fwordpresscontact-form-7設定封鎖名單的簡單做法",{"id":221,"slug":222,"title":223,"description":224,"content":225,"date":226,"image":86,"imageAlt":223,"author":227,"categories":228,"path":230,"minRead":29},26,"wpwordpress-rest-api-未如預期錯誤","[WP]WordPress REST API 未如預期錯誤","WordPress REST API 未如預期錯誤 在某次新建WP站台時遇到這個問題 可以在[工具] > […]","\u003Ch2>WordPress REST API 未如預期錯誤\u003C\u002Fh2>\n\u003Cp>在某次新建WP站台時遇到這個問題\u003C\u002Fp>\n\u003Cp>可以在[工具] > [網站狀態] 中發現這個錯誤訊息\u003C\u002Fp>\n\u003Cp>一開始以為是htaccess設定轉址有問題\u003Cbr \u002F>\n翻了一堆討論後發現可能是4.9.2版本的WP有這樣的狀況\u003Cbr \u002F>\n\u003Cstrong>永久連結被暫存卡住導致REST API出錯，解決辦法就是重置永久連結的設定\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>例如[永久連結] > [換一個設定] > [儲存]就可以重置囉\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fstackoverflow.com\u002Fquestions\u002F34670533\u002Fwordpress-rest-api-wp-api-404-error-cannot-access-the-wordpress-rest-api\" title=\"參考連結\">參考連結\u003C\u002Fa>\u003C\u002Fp>\n","2022-05-05T22:12:17",{"name":88,"link":89},[229],{"name":65,"slug":66},"\u002Fblog\u002Fwpwordpress-rest-api-未如預期錯誤"]