วิธีสร้างฐานความรู้การสนับสนุนที่เป็นมิตรกับ SEO: คู่มือฉบับสมบูรณ์สำหรับโซลูชันเอกสารที่ปรับขนาดได้

เผยแพร่แล้ว: 2016-10-26

เมื่อฐานผู้ใช้ของสตาร์ทอัพของคุณเติบโตขึ้น การสนับสนุนจะกลายเป็นส่วนสำคัญของธุรกิจของคุณ การตั้งค่าโซลูชันฐานความรู้ที่มั่นคงเป็นการลงทุนระยะยาวที่สำคัญ ซึ่งหวังว่าหากทำถูกต้อง จะได้ผลโดยการลดภาระการสนับสนุน ขยายการเข้าถึง SEO ของไซต์ของคุณให้กว้างขึ้น และสร้างโอกาสในการขายใหม่ที่ไม่เช่นนั้นจะไม่ได้รับ

นี่คือคำแนะนำทีละขั้นตอนทางเทคนิคที่ครอบคลุมสำหรับนักพัฒนา หากคุณไม่ใช่นักพัฒนา คุณควรส่งบทความนี้ไปยัง CTO ของคุณ เขา / เธอจะขอบคุณสำหรับมัน

TL; DR: ในที่สุดเราก็สร้างและเผยแพร่ฐานความรู้แบบกึ่งสแตติกที่ใช้มาร์กดาวน์สำหรับแพลตฟอร์มการสร้างรายได้ของเรา Freemius โดยใช้ WordPress ฉันกำลังแบ่งปันตำราอาหารฉบับสมบูรณ์ของการวิจัยของเราที่นี่ เหตุใดเราจึงเลือก WordPress มากกว่าโซลูชัน SaaS และเครื่องกำเนิดไฟฟ้าแบบคงที่ วิธีที่เราทำ (รวมถึงการปรับแต่งโค้ดทั้งหมดและการกำหนดค่าระดับเซิร์ฟเวอร์) สิ่งที่เราได้เรียนรู้ และวิธีที่คุณสามารถจำลองกระบวนการดังกล่าวเพื่อประหยัดเวลาอันมีค่า และตั้งค่าของคุณเองได้อย่างรวดเร็ว ปรับขนาดได้ ยั่งยืน ปลอดภัย และกึ่ง KB แบบคงที่ (ฐานความรู้) สำหรับปลั๊กอิน ธีม หรือผลิตภัณฑ์ดิจิทัลอื่นๆ ของคุณเอง

คู่มือ 15 นาทีนี้จะช่วยคุณประหยัดเวลา 44 ชั่วโมง (เราใช้การติดตามเวลา) ในการวิจัย การปรับแต่ง การทดสอบและการเพิ่มประสิทธิภาพ หากคุณยังไม่อยู่ในขั้นตอนของการตั้งค่าศูนย์เอกสารของคุณเอง เพียงแค่บุ๊กมาร์กหน้านี้และกลับมาเมื่อถึงเวลาที่เหมาะสม

คุณพร้อมไหม? ไปเลย.

แรงจูงใจ
คุณควรมองหาอะไรในโซลูชันเอกสาร
1. ปรับขนาดได้และทนทาน
2. Back Office ที่ใช้งานง่าย
3. อย่างยั่งยืน
4. ปรับ SEO ให้เหมาะสม
5. เข้ากันได้กับแบรนด์
การเลือกแพลตฟอร์มเอกสารที่เหมาะสมนั้นยาก!
- ซอฟต์แวร์ฐานความรู้ในฐานะบริการ
- ฐานความรู้แบบคงที่
- ฐานความรู้ที่ขับเคลื่อนด้วย WordPress
ทำไมเราไม่ได้เลือก Help Scout Docs หรือฐานข้อมูล SaaSy Knowledge Base
เหตุใดเราจึงเลือก WordPress เหนือเครื่องมือสร้างไซต์แบบคงที่สำหรับฐานความรู้ของเรา
เหตุใดเราจึงเลือกปลั๊กอิน WordPress ของ weDocs สำหรับฐานความรู้ของเรา
การติดตั้งและปรับแต่งโซลูชันเอกสาร weDocs
- การเพิ่มข้อมูลเมตาของ Breadcrumbs Rich-Snippets
- การปรับแต่งโครงสร้าง URL ฐานความรู้ (ลิงก์ถาวร)
- การเพิ่มหน้าแรกที่สวยงามให้กับฐานความรู้ weDocs
- ทำให้ weDocs เป็นมิตรกับมือถือ / ตอบสนอง
ใช้ Markdown แทน HTML Rich Editing
- การเลือกและติดตั้งปลั๊กอิน WordPress Markdown
- การเพิ่มการสนับสนุน YouTube และ Vimeo Markdown
- เพิ่มการสนับสนุน Shortcodes คำบรรยายภาพที่ดี
- การเพิ่ม SyntaxHighlighter สำหรับ Pretty Code
เราทำให้ฐานความรู้ WordPress ของเรารวดเร็วมากได้อย่างไร
- การเพิ่มการอนุญาตดิสก์
- เปิดใช้งานการแคช
- การกำหนดค่าการแคชระดับเซิร์ฟเวอร์
- กำลังเพิ่ม CDN
เราปรับแต่งการค้นหา KB เพื่อให้บริการข้อมูลแคชได้อย่างไร
เรารักษาฐานความรู้ WordPress ของเราได้อย่างไร
ตอนนี้คุณ

แรงจูงใจ

เอกสารอยู่ในรายการสิ่งที่ต้องทำของเราเสมอตั้งแต่ช่วงแรกๆ ของ Freemius ต้องบอกว่าเมื่อผลิตภัณฑ์อยู่ในระยะเริ่มต้น ไม่ควรรีบเร่งและจัดทำเป็นเอกสาร จุดเน้นควรเกี่ยวกับการตรวจสอบสมมติฐานและการทำซ้ำอย่างรวดเร็ว จนกว่าคุณจะได้ผลิตภัณฑ์ที่น่าพอใจในตลาด เราเริ่มต้น Freemius เมื่อประมาณหนึ่งปีครึ่งที่แล้ว และในที่สุดเราก็รู้สึกว่าถึงเวลาต้องจัดลำดับความสำคัญของเอกสารแล้ว

คุณควรมองหาอะไรในโซลูชันเอกสาร

ก่อนจะรีบหาทางแก้ไข ฉันอยากจะมีแผนอะไรบางอย่าง ดังนั้นฉันจึงสร้างรายการข้อกำหนดต่อไปนี้:

ปรับขนาดได้และทนทาน

เช่นเดียวกับโซลูชันบนเว็บอื่น ๆ จะต้องสามารถปรับขนาดตามปริมาณการใช้งานของเราในขณะที่ยังคงประสิทธิภาพเท่าเดิม นอกจากนี้ยังต้องดำเนินการอย่างง่ายดายเพื่อค้นหาคำตอบเมื่อฐานความรู้เติบโตเกินกว่าบทความโหล กล่าวอีกนัยหนึ่ง - ค้นหาดี!

Back Office ที่ใช้งานง่าย

การเพิ่มและแก้ไขบทความเอกสารควรเป็นเรื่องง่ายสำหรับสมาชิกในทีม ไม่ว่าพวกเขาจะเป็นนักพัฒนาหรือไม่ก็ตาม

อย่างยั่งยืน

ไม่มีอะไรที่เป็นอมตะ. เทรนด์การออกแบบกำลังเปลี่ยนแปลงและเทคโนโลยีมีการพัฒนาอยู่ตลอดเวลา ดังนั้นจึงควรปรับเปลี่ยน UI ของฐานความรู้ได้ง่าย และในกรณีร้ายแรง ส่งออกข้อมูลและย้ายไปยังระบบอื่นได้อย่างง่ายดาย

ปรับ SEO ให้เหมาะสม

เอกสารเป็นเนื้อหา เอกสารฐานความรู้ไม่เหมือนกับโพสต์บนบล็อกของคุณ เอกสารฐานความรู้จะเน้นที่ผลิตภัณฑ์ของคุณเท่านั้น คีย์เวิร์ดของคุณ เป็นวิธีที่ยอดเยี่ยมในการเสริมอำนาจผู้มีอำนาจ SEO ของคุณในทุกสิ่งที่คุณขาย

นอกจากนี้ เมื่อผู้ใช้ค้นหาบางสิ่ง นิสัยทั่วไปคือการใช้เครื่องมือค้นหาทันที ง่ายกว่าการเปิดไซต์ของคุณ ค้นหาลิงก์ฐานความรู้ / ศูนย์ช่วยเหลือ / เอกสาร จากนั้นจึงค้นหาวิธีแก้ปัญหา ดังนั้น คุณควรตรวจสอบให้แน่ใจว่าเนื้อหาเอกสารของคุณปรากฏต่อเครื่องมือค้นหาและได้รับการปรับให้เหมาะสมโดยเฉพาะ Google หากคุณกำหนดเป้าหมายไปยังตลาดที่ใช้ภาษาอังกฤษ

เข้ากันได้กับแบรนด์

รูปลักษณ์และความรู้สึกของฐานความรู้ควรตรงกับภาษาการออกแบบและตราสินค้าของบริษัทของเรา ซึ่งรวมถึงสี แบบอักษร ลักษณะส่วนหัวและส่วนท้าย ฯลฯ

การเลือกแพลตฟอร์มเอกสารที่เหมาะสมนั้นยาก!

ตามขั้นตอนการค้นพบตามธรรมชาติของฉัน ฉันไปขอคำแนะนำจาก Google ครั้งนี้ Google ไม่ช่วยอะไร ผลการค้นหาล้นหลาม ไม่เพียงแต่มีตัวเลือกมากมายในตลาดเท่านั้น แต่โซลูชันยังแตกต่างกันโดยสิ้นเชิง

Google ไม่ได้เป็นประโยชน์ มีตัวเลือกมากมายในตลาดและวิธีแก้ปัญหาก็แตกต่างกันโดยสิ้นเชิงTweet

ซอฟต์แวร์ฐานความรู้ในฐานะบริการ

มีโซลูชันซอฟต์แวร์ฐานความรู้ที่กำหนดซึ่งขับเคลื่อนโดยบริษัทแหล่งความช่วยเหลือ เช่น Help Scout Docs และ Zendesk Help Center

ฐานความรู้แบบคงที่

เครื่องกำเนิดไซต์แบบคงที่กำลังเป็นที่นิยมมากขึ้นเรื่อย ๆ หากคุณไม่คุ้นเคยกับแนวคิดนี้ แนวคิดทั่วไปก็คือเว็บไซต์ส่วนใหญ่ค่อนข้างนิ่ง (รวมถึงบล็อก WordPress ของคุณด้วย) และไม่มีเหตุผลที่แท้จริงที่จะเรียกใช้แบ็กเอนด์สแต็กที่สิ้นเปลือง เช่น WordPress / PHP / MySql ให้ย้ายการยกของหนักไปที่เอ็นจิ้นก่อนการปรับใช้ซึ่งจะสร้างหน้า HTML แบบคงที่ที่สามารถโฮสต์บน CDN ได้โดยไม่ต้องแตะเซิร์ฟเวอร์ของคุณ คุ้มค่า ปรับขนาดได้ และปลอดภัย

มีเครื่องกำเนิดไฟฟ้าหลายร้อยเครื่อง และเอ็นจิ้นอย่าง Jekyll และ Hugo ได้รับการยอมรับอย่างสูงในหมู่นักพัฒนาซอฟต์แวร์ที่ไม่ยอมใครง่ายๆ (ด้วยเหตุผลที่ดี!)

ฐานความรู้ที่ขับเคลื่อนด้วย WordPress

ฉันพบปลั๊กอินฐานข้อมูลความรู้ฟรีมากกว่า 20 รายการในที่เก็บ WordPress.org ปลั๊กอินเอกสารที่ต้องชำระเงินอีกโหลใน CodeCanyon และ Google และธีมศูนย์ช่วยเหลืออีกโหล

รู้สึกสับสน? ฉันทำจริงๆ ¯\(°_o)/¯

อย่างที่คุณเห็น วิธี ทางเลือกมากเกินไป ฉันตัดสินใจลองใช้กลยุทธ์อื่น โดยขอคำแนะนำจากผู้ที่มีความคิดเห็นที่ฉันไว้วางใจ ฉันเป็นสมาชิกของกลุ่ม Facebook ที่ชื่อ Selling WordPress Products ซึ่งมีเพื่อนของฉันและผู้คนเกี่ยวกับผลิตภัณฑ์ WordPress ชั้นนำมากมาย ฉันค่อนข้างแน่ใจว่า 90% ของพวกเขาเคยเผชิญกับความท้าทายแบบเดียวกันมาก่อนฉัน ดังนั้นมันจึงคุ้มค่าที่จะลอง

ก่อนที่ฉันจะอัปโหลดคำถาม ฉันได้ค้นหาและพบกระทู้จากปี 2015 ซึ่งเริ่มต้นโดย Jean Galea จาก WP Mayor ที่ถามคำถามเดียวกันทั้งหมด:

สุดยอด! ฉันคิดกับตัวเอง แล้วก็เริ่มอ่านคำตอบ...

Adrian Labos กำลังใช้ Zendesk Help Desk
Pippin Williamson (ปลั๊กอิน Pippin) และ Adam Pickering (Astoundify) กำลังใช้ Help Scout Docs
Phil Derksen ใช้ WordPress กับธีม KnowHow
Dejan Markovic (Hype Social) ใช้ WordPress ร่วมกับปลั๊กอิน weDocs
Devin Walker (WordImpress) ใช้ WordPress พร้อม CPT และปลั๊กอิน ACF
Ahmad Awais ผู้สร้างธีม DocPress กล่าวว่า "การดูแลไซต์เอกสารด้วย WordPress นั้นไม่มีประสิทธิภาพเมื่อจำนวนผลิตภัณฑ์เพิ่มขึ้น" และตอนนี้เขากำลังสร้างฐานความรู้แบบคงที่ด้วยเครื่องมือสร้างเทมเพลต Jade
Tom Hemsley (ปลั๊กอิน Mega Menu) แนะนำให้ใช้ WordPress ร่วมกับปลั๊กอิน Heroic Knowledge Base
มีอีกสามคำตอบเกี่ยวกับปลั๊กอิน WordPress เพิ่มเติมโดยผู้เขียนซึ่งเป็นส่วนหนึ่งของกลุ่ม

อย่างที่คุณเห็นไม่มีฉันทามติ น่าเสียดายที่สิ่งนี้ไม่ได้มีประโยชน์มากนัก

ประณาม – ถึงเวลาสำหรับการวิจัย…

เคล็ดลับ: โปรดทราบว่า หากคุณเป็นผู้ใช้ผลิตภัณฑ์ในแวดวง WordPress ฉันขอแนะนำให้สมัครเข้าร่วมกลุ่มนี้

สมัครสมาชิกและรับสำเนาของเราฟรี

หนังสือธุรกิจปลั๊กอิน WordPress

วิธีสร้างธุรกิจปลั๊กอิน WordPress ที่เจริญรุ่งเรืองในระบบเศรษฐกิจการสมัครสมาชิก

ขอบคุณสำหรับการสมัคร!

- เราเพิ่งส่งสำเนา 'The WordPress Plugin Business Book' ของคุณไปที่ .

อีกครั้ง

มีการพิมพ์ผิดในอีเมลของคุณ? คลิกที่นี่เพื่อแก้ไขที่อยู่อีเมลและส่งอีกครั้ง

ทำไมเราไม่ได้เลือก Help Scout Docs หรือฐานข้อมูล SaaSy Knowledge Base

ฉันเป็นแฟนตัวยงของ Help Scout และเราใช้พวกเขาสำหรับระบบการออกตั๋วสนับสนุนของเรา อันที่จริงฉันเป็นเพื่อนกับผู้ก่อตั้ง ย้อนกลับไปในปี 2011 เราทำงานที่โต๊ะทำงาน 2 โต๊ะและอยู่ด้วยกันเป็นเวลา 4 เดือน ขณะที่เข้าร่วมโปรแกรม Techstars accelerator ในบอสตัน ย้อนกลับไปเมื่อ Help Scout เป็นเพียง Denny, Jared และ Nick

Docs เป็นโซลูชันด้านเอกสารที่ค่อนข้างสมบูรณ์และอาจเป็นวิธีที่ง่ายและรวดเร็วที่สุด นอกจากนี้ยังปรับแต่งได้อย่างน่าประหลาดใจ แต่เช่นเดียวกับแพลตฟอร์ม SaaS อื่น ๆ มันมาพร้อมกับข้อบกพร่องด้าน SEO

1. การตั้งค่าฐานความรู้หรือเนื้อหาอื่นๆ ในไดเร็กทอรีย่อยยังดีกว่าในโดเมนย่อยในแง่ของการจัดอันดับการค้นหาอย่างมาก Rand Fishkin ผู้ก่อตั้ง MOZ (บริษัท SEO ชั้นนำของโลก) มีวิดีโอที่ยอดเยี่ยมจากปี 2015 พร้อมกรณีการใช้งานจริงที่พูดถึงหัวข้อนั้น

ขออภัย เนื่องจากวิธีการทำงานของไฟล์ DNS Zone จึงไม่มีวิธีการตั้งค่า CNAME ให้กับไดเรกทอรีย่อย

เพื่อให้แน่ใจว่าจะไม่พลาดวิธีแก้ไขปัญหาชั่วคราว ฉันได้ติดต่อทีมสนับสนุน Help Scout และนี่คือคำตอบที่ฉันได้รับ:

“ความเกลียดชังที่จะเกิดขึ้นกับข่าวร้าย แต่ไม่มีวิธีที่จะมีเอกสารในไดเร็กทอรีย่อย เรามี API สำหรับเอกสารที่ให้คุณส่งออกไซต์และโฮสต์เองได้ แต่คุณจะต้องสร้างรูปลักษณ์และฟังก์ชันการทำงานใหม่: http://developer.helpscout.net/docs-api/
ฉันเกรงว่านี่จะเป็นทางออกเดียวหากคุณยังคงต้องการใช้เอกสารและเป็นไดเรกทอรีย่อย

2. ฉันไม่ได้ตรวจสอบวิธีแก้ไขปัญหาอื่นๆ เนื่องจากเหตุผลก่อนหน้านี้ แต่ Help Scout Docs โดยเฉพาะ ไม่รวมข้อมูลเมตา Rich-Snippets สำหรับ breadcrumbs และการค้นหา

นี่คือลักษณะของผลลัพธ์จาก Help Scout Docs ใน SERP ของ Google (หน้าผลลัพธ์ของเครื่องมือค้นหา):

นี่คือผลลัพธ์ของหน้าที่มีข้อมูลเมตาของ breadcrumbs rich snippets:

และนี่คือผลลัพธ์ของหน้าที่มีข้อมูลเมตาของตัวอย่างข้อมูลสื่อสมบูรณ์สำหรับการค้นหา:

ฉันจะไม่ลงลึกในหัวข้อนั้น แต่โดยทั่วไปแล้ว ข้อมูลเมตาของตัวอย่างข้อมูลสื่อสมบูรณ์ช่วยให้เครื่องมือค้นหาเข้าใจเนื้อหาของไซต์และโครงสร้างได้ดีขึ้น เครื่องมือค้นหาชั้นนำของโลก: Google, Yahoo และ Bing; สามารถแปลข้อมูลนี้เป็นภาพที่เพิ่ม CTR การค้นหา (อัตราการคลิกผ่าน) บรรทัดล่าง - คุณจะได้รับการเข้าชมมากขึ้น

ฉันยังส่ง Ping ให้กับ Chris Mooney ผู้ร่วมก่อตั้ง HeroThemes ซึ่งเป็นบริษัทที่เน้นโซโลเกี่ยวกับโซลูชันฐานความรู้ และเขายืนยันว่า SEO เป็นหนึ่งในสาเหตุหลักที่ลูกค้าเปลี่ยนไปใช้โซลูชันเอกสารภายในองค์กร

เพื่อเน้นย้ำถึงความสำคัญของค่า SEO ที่คุณจะได้รับจากเอกสารที่มีการเขียนอย่างดี ฉันต้องการแบ่งปันเรื่องราวสั้นๆ ในปี 2011 ฉันได้พบกับ Elad Eran รองประธานฝ่ายบริการลูกค้าที่ WiX Eran อธิบายอย่างภาคภูมิใจว่าซอฟต์แวร์ฐานความรู้และฟอรัมการสนับสนุนเป็นหนึ่งในตัวเร่งปฏิกิริยาหลักที่ช่วยให้ WiX มีอันดับสูงใน Google และรับปริมาณข้อมูลอินทรีย์คุณภาพสูงฟรี

ฟอรัมซอฟต์แวร์ฐานความรู้และการสนับสนุนเป็นหนึ่งในตัวเร่งปฏิกิริยาหลักที่ช่วยให้ WiX มีอันดับสูงใน Google และรับทราฟฟิกอินทรีย์คุณภาพสูงฟรีทวีต

ถ้าดีสำหรับ WiX ก็ควรจะดีสำหรับเรา

เหตุใดเราจึงเลือก WordPress เหนือเครื่องมือสร้างไซต์แบบคงที่สำหรับฐานความรู้ของเรา

ประโยชน์หลักของการนิ่งเฉยกับเครื่องยนต์อย่าง Jekyll คือความเร็ว ความสามารถในการปรับขนาด และความปลอดภัย

เราสามารถรับสิ่งเหล่านั้นด้วย WordPress ได้หรือไม่? คำตอบคือ – เกือบ

เนื่องจากหน้าเอกสารเป็นแบบคงที่ (ยกเว้นสำหรับการค้นหา) เราจึงสามารถติดตั้งปลั๊กอินแคชของ WordPress ฟรีได้หลายสิบตัว กำหนดค่า Nginx ให้ให้บริการไฟล์แคชโดยตรงจากดิสก์ในขณะที่ข้ามกลไกของ WordPress และยังใช้บริการ CDN ฟรี เช่น CloudFlare เพื่อแจกจ่ายไฟล์ของเราในศูนย์ข้อมูลต่างๆ ทั่วโลก อาจฟังดูซับซ้อน แต่จริงๆ แล้วไม่ใช่ และฉันจะอธิบายทุกอย่างในเร็วๆ นี้

ซึ่งจะทำให้ส่วนหน้าเอกสารของเราเป็นแบบคงที่อย่างสมบูรณ์ มันจะปรับขนาดได้มากและจะเร็วมาก (เพราะเป็นแบบคงที่) W00t! W00t!

ในแง่ของความปลอดภัย ไม่มีอะไรสมบูรณ์แบบ แต่เราสามารถใช้มาตรการป้องกันขั้นพื้นฐานได้โดยใช้ปลั๊กอินฟรีสองสามตัวและการกำหนดค่าระดับเซิร์ฟเวอร์บางอย่าง ซึ่งจะช่วยลดโอกาสในการโจมตีได้ถึง 99.9% ฉันจะพูดถึงเรื่องนี้อย่างชัดเจนในอีกสักครู่ รวมถึงส่วนผสมทั้งหมดด้วย

ในทางกลับกัน ข้อเสียของแนวทางคงที่สำหรับทีมของเราคือ:

ในฐานะทีม เราจะต้องได้รับชุดทักษะทางเทคนิคใหม่ ตั้งค่าสภาพแวดล้อมการพัฒนาเพิ่มเติม และมีกระบวนการปรับใช้อย่างต่อเนื่องเพื่อให้แน่ใจว่าการเพิ่มหรือแก้ไขไฟล์ไม่จำเป็นต้องมีการแทรกแซงจากนักพัฒนา ทำได้แน่นอน แต่ต้องใช้เวลา
การค้นหา (โดยส่วนใหญ่) เป็นฟังก์ชันแบบไดนามิก ดังนั้นหากเราหยุดนิ่ง เราจะต้องใช้ RESTful API บางอย่างหรือผสานรวมบริการค้นหาของบุคคลที่สาม เช่น Algolia ปวดหัวอีกเรื่องที่ต้องรับมือ
การควบคุมเวอร์ชันไม่ใช่ CMS เท่าที่ฉันรัก GitHub และ BitBucket พวกเขาอาจจะน่ากลัวสำหรับคนที่ไม่เชี่ยวชาญด้านเทคโนโลยี แม้ว่าสมาชิกในทีมของเราทุกคนจะเป็นนักพัฒนาซอฟต์แวร์ แต่สิ่งนี้ก็มีแนวโน้มที่จะเปลี่ยนแปลงได้ในอนาคต

เคล็ดลับ: มูลค่าการกล่าวขวัญว่าในระหว่างการวิจัยของฉัน ฉันพบโครงการที่ดีที่เรียกว่า Prose.io ที่ให้การแก้ไขเนื้อหา WYSIWYG อย่างง่ายของไฟล์ GitHub และ BitBucket

โดยสรุปแล้ว เราสามารถใช้ประโยชน์สูงสุดจากไซต์แบบคงที่โดยไม่สูญเสียความยืดหยุ่นของ WordPress ทำให้ตัวแก้ไข CMS ที่ใช้งานง่าย และแก้ไขตามเวลาจริงโดยไม่ต้องมีกระบวนการปรับใช้ที่ต่อเนื่อง

เหตุใดเราจึงเลือกปลั๊กอิน WordPress ของ weDocs สำหรับฐานความรู้ของเรา

ดังที่ได้กล่าวไว้ก่อนหน้านี้ ฉันได้เห็นปลั๊กอินและธีม WordPress อย่างน้อย 30 รายการสำหรับฐานความรู้

เนื่องจากเรากำลังดำเนินการเริ่มต้น การประเมินทั้งหมดจึงเป็นไปไม่ได้ เลยลองมากำจัดกันดู

ธีมฐานความรู้หมดแล้ว!

เราเลือกที่จะไม่ใช้ชุดรูปแบบเอกสารใด ๆ เนื่องจากส่วนใหญ่ใช้วัตถุ post เริ่มต้นและอนุกรมวิธาน category สำหรับบทความเอกสาร โซลูชันนี้สามารถใช้ได้หากคุณตั้งค่าอินสแตนซ์ WordPress เฉพาะสำหรับแอปฐานความรู้ของคุณเท่านั้น หากคุณต้องการให้ไซต์ทั้งหมดของคุณติดตั้งบน WordPress เดียวกัน รวมถึงบล็อกของคุณ สิ่งต่างๆ อาจเกิดขึ้นได้และอาจยุ่งเหยิงเนื่องจากประเภทเนื้อหาผสมกัน

เย้ ตอนนี้เรามีปลั๊กอินให้ทดสอบอีก 20 ตัวเท่านั้น...

ฉันทดสอบปลั๊กอินฟรีสี่ตัวที่แตกต่างกัน:

ฐานความรู้ CPT
ฐานความรู้ WP
ความช่วยเหลือ WP
weDocs

ฉันพบว่าพวกเขาทั้งหมดใช้ประโยชน์จาก WordPress CPT (ประเภทโพสต์ที่กำหนดเอง) และการจัดหมวดหมู่แบบกำหนดเองสำหรับแท็กและหมวดหมู่ได้อย่างรวดเร็ว ความแตกต่างหลักและที่สำคัญเพียงอย่างเดียวคือในลำดับชั้นของโครงสร้างข้อมูล

ฐานความรู้ CPT และ WP ฐานความรู้เป็นแบบเรียบ เช่นเดียวกับบล็อกโพสต์ มีหมวดหมู่ แท็ก และบทความ ไม่มีทางที่จะเชื่อมโยงบทความกับบทความหลักได้

ดังนั้นโครงสร้างของฐานความรู้ที่มีปลั๊กอินเหล่านั้นจะเป็นหมวดหมู่เป็นส่วนๆ และโพสต์เป็นเอกสาร

 หมวด 1
↳ หมอ 1
↳ หมอ 2

หมวดหมู่ 2
↳ หมอ 3
↳ หมอ 4

ประโยชน์ของโครงสร้างนั้นก็คือ คุณสามารถเชื่อมโยงเอกสารที่มีหลายประเภท และทำให้ปรากฏในหลายส่วนได้

 หมวด 1
↳ หมอ 1
...
หมวดหมู่ 2
↳ หมอ 3
↳ หมอ 1

ในทางกลับกัน โครงสร้างบทความวิธีใช้ WP และ weDocs จะคล้ายกับหน้าต่างๆ เอกสารแต่ละฉบับสามารถเชื่อมโยงกับเอกสารอื่น ๆ ในฐานะผู้ปกครองได้ แต่สามารถเชื่อมโยงกับพาเรนต์เดียวเท่านั้น (ไม่เหมือนหมวดหมู่)

 หมอ 1
↳ หมอ 2
↳ หมอ 3
↳ หมอ 4
↳ หมอ 5
↳ หมอ 6

มีประโยชน์สองประการสำหรับโครงสร้างนั้น:

มีโครงสร้างมากขึ้น มันบังคับให้คุณคิดว่าตำแหน่งที่เหมาะสมที่สุดในการเพิ่มบทความเอกสารคือที่ใด
หมวดหมู่ไม่มี "คำสั่งซื้อ" ที่เฉพาะเจาะจง ดังนั้นจึงไม่มีวิธีการจัดระเบียบหมวดหมู่ที่พร้อมใช้งานทันทีในโพสต์ที่มีพร็อพเพอร์ตี้ menu_order

เหตุผลข้างต้นคือเหตุผลที่เราตัดสินใจเลือกใช้ปลั๊กอินแบบลำดับชั้น

เยี่ยม – ตอนนี้ฉันรู้ประเภทของโครงสร้างข้อมูลที่เราต้องการสำหรับเอกสารของเราแล้ว

จากนั้นฉันก็ใช้เวลาอ่านเกี่ยวกับปลั๊กอินพรีเมียมสองตัว – wpDocs (เวอร์ชันโปรของ WP Knowledge Base) และ Heroic Knowledge Base ทั้งคู่ดูน่าประทับใจ แต่...

ฉันไม่พบความแตกต่างที่มีความหมายระหว่างปลั๊กอินพรีเมียมสองตัวนั้นกับปลั๊กอินฟรี
ปลั๊กอินทั้งสองใช้โครงสร้างข้อมูลแบบเรียบ ซึ่งเราตัดสินใจไม่ใช้

ใช่ – อาจมีอีก 10 ปลั๊กอินที่ฉันไม่ได้ดู แต่รูปแบบนั้นชัดเจน

เราตัดสินใจใช้ weDocs ผ่าน WP Help เนื่องจากสาเหตุหลายประการ:

การตั้งค่าผู้ดูแลระบบลากและวาง UI ของ weDocs ที่ทันสมัย ใช้งานง่าย และดึงดูดสายตา
WP Help ไม่ได้มาพร้อมกับอนุกรมวิธานแบบกำหนดเองสำหรับเอกสาร ซึ่งหมายความว่าหมวดหมู่และแท็กจะไม่ถูกส่งออกนอกกรอบ
WP Help ไม่รองรับ breadcrumbs เลย
weDocs มาพร้อมกับชุดเทมเพลตที่กำหนดเองซึ่งจะทำให้เอกสารดูดีทันที (เห็นได้ชัดว่าจำเป็นต้องมีการปรับแต่ง UI บางอย่าง)
weDocs มีโฟลว์ UI อย่างต่อเนื่อง ในตอนท้ายของทุกบทความ คุณสามารถไปยังบทความถัดไปในบรรทัดได้

มาต่อกันที่ส่วนที่สนุก – การใช้งาน…

การติดตั้งและปรับแต่งโซลูชันเอกสาร weDocs

ในการเริ่มต้น ให้ดาวน์โหลดและติดตั้ง weDocs โดยตรงจาก repo WordPress.org:
https://wordpress.org/plugins/wedocs/

ตอนนี้ได้เวลาปรับแต่งบางอย่างแล้ว:

การเพิ่มข้อมูลเมตาของ Breadcrumbs Rich-Snippets

เนื่องจากเราไม่ต้องการเปลี่ยนปลั๊กอินจริง (ถ้าเป็นไปได้) เราจึงใช้เทมเพลต weDocs และ functions.php ของธีมเพื่อแทนที่การแสดงเบรดครัมบ์เริ่มต้น

คัดลอก /wedocs/templates/single-docs.php ไปที่ /your-theme/wedocs/single-docs.php
เพิ่มโค้ดต่อไปนี้ในไฟล์ functions.php ของธีม:
เปิด /your-theme/wedocs/single-docs.php และแทนที่การเรียก wedocs_breadcrumbs() ด้วย freemius_wedocs_breadcrumbs()
เนื่องจากเราได้แก้ไขโครงสร้าง HTML ของ breadcrumbs เป็นรายการที่ไม่เรียงลำดับ ( <ul> ) เพื่อความหมายที่ดีขึ้น ให้เพิ่มโค้ด SASS ต่อไปนี้ในธีมของคุณ:
ในการกรอก Rich Snippets คุณจะต้องเพิ่มโค้ดต่อไปนี้ในแท็ก <body> ของคุณ:
```
<body<?php if ('docs' === get_post_type()){     echo ' itemscope itemtype="http://schema.org/WebPage"'; } ?>>
```

การปรับแต่งโครงสร้าง URL ฐานความรู้ (ลิงก์ถาวร)

weDocs มาพร้อมกับโครงสร้างลิงก์ถาวรเริ่มต้นต่อไปนี้:
your-site.com/wordpress-root/docs/

เราต้องการมีเอกสารของเราใน freemius.com/help/documentation/ ซึ่งควรมีอันดับที่ดีขึ้นใน SEO เมื่อค้นหาเอกสาร นอกจากนี้เรายังต้องการเก็บหน้า "ความช่วยเหลือ" ไว้เพื่อเพิ่มศูนย์ช่วยเหลือในอนาคต เพื่อให้สามารถใช้โครงสร้าง URL เช่น /help/faq/ สำหรับหน้าคำถามที่พบบ่อย และ /help/forum/ สำหรับฟอรัม

เราสามารถทำได้โดยง่ายโดยการแก้ไขกฎการเขียนซ้ำของ docs CPT ในโค้ดของปลั๊กอิน แต่เนื่องจากเราต้องการหลีกเลี่ยงการเปลี่ยนโค้ดของปลั๊กอิน เราจึงพบวิธีการทำโดยอ้อมในไฟล์ functions.php ของธีม:
นอกจากนี้ เราได้เพิ่มการสนับสนุนสำหรับข้อความที่ตัดตอนมา (เราต้องการสำหรับการปรับแต่งครั้งต่อไป) ผู้เขียนเอกสาร ฟิลด์ที่กำหนดเอง และแอตทริบิวต์ของหน้า สำคัญ: weDocs มีโครงสร้างเป็นค่าเริ่มต้นสำหรับฐานความรู้หลายผลิตภัณฑ์ ดังนั้น หากคุณต้องการมีโครงสร้างของ /help/documentation/ ตรวจสอบให้แน่ใจว่าเอกสารระดับบนสุดที่คุณสร้างใน back office นั้นเรียกว่า Documentation (slug ต้องเป็น documentation )

การเพิ่มหน้าแรกที่สวยงามให้กับฐานความรู้ weDocs

โดยค่าเริ่มต้น weDocs มาพร้อมกับรหัสย่อที่สามารถช่วยคุณสร้างหน้าแรกที่จะมีลักษณะดังนี้:

ไม่เลว แต่โดยส่วนตัวแล้วฉันชอบเลย์เอาต์ที่สร้างโดย Help Scout Docs :

มันให้คำอธิบายสั้น ๆ เกี่ยวกับแต่ละส่วน และดูดึงดูดสายตามากขึ้นสำหรับฉัน ขั้นแรก ให้สร้างเทมเพลต PHP โดยเพิ่ม docs-header-main.php และ docs-sections.php ลงในโฟลเดอร์ /your-theme/wedocs/ คุณสามารถค้นหารหัสในส่วนสำคัญต่อไปนี้: https://gist.github.com/vovafeldman/adbf1c071a08b7565df11d709b2f1240 หากคุณดำดิ่งลงไปในรหัสของไฟล์ docs-header-main.php คุณจะสังเกตเห็นว่าฉันแอบย่องในการค้นหาที่ร่ำรวย ข้อมูลเมตาของตัวอย่าง ตอนนี้ เนื่องจาก /help/documentation/ บทความ เป็นอีกบทความหนึ่งในฐานความรู้ เทมเพลตเริ่มต้นที่ WordPress จะใช้คือ /wedocs/single-docs.php ดังนั้น เราจำเป็นต้องเพิ่มส่วนย่อยของโค้ดต่อไปนี้ที่ด้านบนของไฟล์นั้น เพื่อโหลดเทมเพลตส่วนใหม่เมื่อไม่ได้ตั้งค่าพาเรนต์ของบทความ:

if ( empty( $post->post_parent ) ) {
  wedocs_get_template_part( 'docs', 'header-main' );
  wedocs_get_template_part( 'docs', 'sections' );

  return;
}

ทำให้ weDocs เป็นมิตรกับมือถือ / ตอบสนอง

ขออภัย weDocs ไม่ได้มาพร้อมกับกฎ CSS ที่ตอบสนอง นี่คือลักษณะที่ปรากฏบนฐานความรู้ของ weDevs (ผู้พัฒนา weDocs):

ฉันจะไม่ลงลึกใน CSS แต่โดยทั่วไป เราได้เพิ่มข้อความค้นหาสื่อที่:

ซ่อนเกล็ดขนมปัง
ทำให้เนื้อหาเต็มความกว้างด้วยช่องว่างภายในที่สวยงาม
ย้ายแถบนำทางด้านข้างและการค้นหาไปที่ด้านล่างก่อนส่วนท้าย

นี่คือผลลัพธ์:

และนี่คือสิ่งที่หน้าส่วนดูเหมือน:

ยอดเยี่ยม! เราเสร็จสิ้นการปรับแต่ง weDocs แล้ว

ใช้ Markdown แทน HTML Rich Editing

ข้อกำหนดเบื้องต้นประการหนึ่งของ KB คือความยั่งยืน – ความสามารถในการเปลี่ยนการออกแบบอย่างง่ายดายและอาจเป็นแพลตฟอร์ม (จำได้ไหม) การใช้การแก้ไขเนื้อหา HTML Rich เป็นดาบสองคม ประการหนึ่ง มันมีความยืดหยุ่นอย่างยิ่งและให้อิสระในการปรับแต่งสไตล์เนื้อหาตามที่คุณต้องการ ในทางกลับกัน การขาดโครงสร้างนี้ทำให้ผู้เขียนเนื้อหาทุกคนสามารถทำทุกอย่างที่ต้องการได้ สิ่งนี้ไม่ยั่งยืน ทำให้การเปลี่ยนแปลงการออกแบบซับซ้อนและการโยกย้ายยากขึ้น ตัวอย่างเช่น การใช้ <strong> กับ <b> หรือใช้ตารางตาม <table> กับ <div> สิ่งเหล่านี้เป็นการตัดสินใจที่เกี่ยวข้องกับไวยากรณ์ และทุกคนมีสไตล์การเขียนที่เป็นเอกลักษณ์ของตนเอง

สิ่งที่ผู้เขียนเนื้อหาควรเน้นจริงๆ คือเนื้อหาและความหมาย ไม่ใช่การออกแบบ

มีภาษามาร์กอัปมากมายที่มีรูปแบบการจัดรูปแบบข้อความธรรมดา แม้ว่า Markdown จะเป็นตัวเลือกที่เป็นธรรมชาติ เนื่องจากมันถูกใช้อย่างแพร่หลายโดยยักษ์ใหญ่อย่าง GitHub, Atlassian และ WordPress เอง

การเลือกและติดตั้งปลั๊กอิน WordPress Markdown

มีเพียงสองปลั๊กอิน Markdown ใน repo ของ WordPress.org ที่มีการติดตั้งที่ใช้งานอยู่มากกว่า 1,000 ครั้ง WP-Markdown และ JP Markdown ใช่ Jetpack มีโมดูล Markdown ด้วย แต่การติดตั้ง "มอนสเตอร์" นี้สำหรับโมดูลเดียวไม่สมเหตุสมผล ตอนแรกฉันติดตั้ง WP-Markdown เพราะตามภาพหน้าจอ มันมีตัวเลือกให้เลือกประเภทโพสต์ที่จะสนับสนุน Markdown ได้อย่างง่ายดาย ขออภัย ปลั๊กอินไม่ทำงาน (อัปเดตล่าสุดเมื่อ 3 ปีที่แล้ว) ดังนั้นเราจึงไม่ได้ใช้มัน จากนั้น ฉันติดตั้ง JP Markdown ปลั๊กอินใช้งานได้ แต่มีบางสิ่งที่ฉันไม่ชอบ:

มาร์กดาวน์เปิดใช้งานโดยอัตโนมัติในทุกโพสต์และทุกหน้า
ไวยากรณ์ markdown ไม่ถูกรักษาไว้ แต่จะถูกแปลงเป็น HTML ที่มีสไตล์โดยอัตโนมัติ:

สิ่งนี้ไม่ดีเพราะข้อมูลถูกเก็บไว้ในฐานข้อมูลในรูปแบบ HTML ที่สมบูรณ์และไม่ใช่แบบมาร์กดาวน์ (ฉันตรวจสอบแล้ว) นอกจากนี้ยังไม่ได้เพิ่มข้อจำกัดใดๆ ในการแก้ไข HTML แบบสมบูรณ์ ดังนั้นหากในอนาคตเราต้องการย้ายไปยังระบบอื่น ไม่มีทางที่จะส่งออกการลดราคา

จากนั้นฉันก็พบ WP Markdown Editor ซึ่งใช้โมดูล Markdown จาก Jetpack และนั่นคือสิ่งที่เราใช้ แม้ว่าเรายังต้องทำการปรับแต่งบางอย่าง:

ปลั๊กอินปิดใช้งานการแก้ไขที่สมบูรณ์จากโพสต์และหน้าทั้งหมดเมื่อเปิดใช้งาน เราต้องการกำจัดการแก้ไขที่สมบูรณ์ในหน้าเอกสารของเราเท่านั้น
ปลั๊กอินจะแทนที่ตัวแก้ไขที่มีอยู่ด้วยตัวแก้ไข markdown ของตัวเองสำหรับบทความและหน้าทั้งหมด อีกครั้ง เราต้องการให้มีสิ่งนั้นในหน้าเอกสารของเราเท่านั้น

คุณสามารถดูการเปลี่ยนแปลงเหล่านี้ได้ที่นี่:
https://github.com/Freemius/wp-markdown-editor/commit/706bce0c23943c82d102c67a09e18dac32c66207

คุณสามารถดาวน์โหลดเวอร์ชันแยกจากที่นี่ (มีการเปลี่ยนแปลงเพียงเล็กน้อยเท่านั้น):
https://github.com/Freemius/wp-markdown-editor

จากนั้น เราได้เพิ่มฟังก์ชันสั้นๆ ที่ลงทะเบียน docs CPT เพื่อรองรับการแก้ไขมาร์กดาวน์ และยกเลิกการลงทะเบียนประเภท post และ page เพื่อให้โปรแกรมแก้ไข HTML สมบูรณ์:

สุดท้าย เราต้องปรับแต่งฟังก์ชันการส่งออกเริ่มต้นของ WordPress เพื่อให้ส่งออกโค้ดมาร์กดาวน์ ไม่ใช่เนื้อหาที่มี HTML เราทำได้โดยเชื่อมต่อกับตัวกรอง the_content_export :
ยอดเยี่ยม – KB ของเราขับเคลื่อนโดย markdown และสามารถส่งออกได้อย่างง่ายดาย

การเพิ่มการสนับสนุน YouTube และ Vimeo Markdown

วิดีโอเป็นส่วนสำคัญของฐานความรู้ใดๆ ขออภัย Markdown ไม่รองรับวิดีโอ อย่างมีความสุข WordPress ทำให้การเพิ่มชอร์ตโค้ดและโค้ดไม่กี่บรรทัดทำได้ง่ายมาก เราได้ปรับปรุงไวยากรณ์ Markdown ของเราเพื่อรองรับการเพิ่มวิดีโอ YouTube และ Vimeo:

เป็นโบนัส เราได้ทำให้ขนาดวิดีโอตอบสนองและเป็นมิตรกับอุปกรณ์เคลื่อนที่ และตอนนี้การเพิ่มวิดีโอนั้นใช้งานง่ายและตรงไปตรงมาด้วย ID วิดีโอ:
[youtube gj6aoYG4fUI]
[vimeo 185625717]

เพิ่มการสนับสนุน Shortcodes คำบรรยายภาพที่ดี

ไวยากรณ์ Markdown เริ่มต้นรองรับเครื่องหมายคำพูดบล็อก แต่ไม่มีความหมายสำหรับข้อความเสริมต่างๆ เช่น เคล็ดลับและคำเตือนซึ่งไม่จำเป็น แต่สำคัญสำหรับฐานความรู้ที่ดี

รหัสย่อ WordPress เพื่อช่วยเหลืออีกครั้ง

และนี่คือลักษณะที่ปรากฏที่ส่วนหน้า:

เราได้เพิ่มคำนำหน้า fs_ เพื่อป้องกันความขัดแย้งที่อาจเกิดขึ้นกับปลั๊กอินที่เราอาจติดตั้งในอนาคต

การเพิ่ม SyntaxHighlighter สำหรับ Pretty Code

ทั้ง WordPress และ WP Markdown Editor ไม่ได้มาพร้อมกับการเน้นไวยากรณ์ของโค้ด เนื่องจาก Freemius เป็นแพลตฟอร์มสำหรับนักพัฒนา และเอกสารของเรามาพร้อมกับตัวอย่างโค้ด การเพิ่มการเน้นไวยากรณ์จึงเป็นสิ่งสำคัญ เราเลือกใช้ SyntaxHighlighter Evolved เนื่องจากขับเคลื่อนโดย Automattic เช่นเดียวกับโมดูล Markdown หลักของ Jetpack ที่ใช้โดยปลั๊กอิน WP Markdown Editor เมื่อดูโค้ดการเรนเดอร์ markdown พบว่าพวกเขารวมเข้าด้วยกันจริง ๆ :

$this->use_code_shortcode = class_exists( 'SyntaxHighlighter' );

สุดยอด! ใช่ไหม? น่าเสียดาย ที่ดูเหมือนไม่มีอะไรสมบูรณ์แบบตั้งแต่แกะกล่อง และโค้ดก็แสดงผลอย่างไม่ถูกต้อง มันทำให้ส่วนโค้ดหลายบรรทัดของ Markdown ยุ่งเหยิงโดยการหนีอักขระพิเศษไปยังเอนทิตี HTML ที่เกี่ยวข้อง ไม่เพียงแต่จะ "ทำลาย" โค้ดที่แสดงบนส่วนหน้าเท่านั้น แต่ยังจัดเก็บส่วนโค้ด HTML ของ Markdown เวอร์ชัน Escape ไว้ในฐานข้อมูลด้วย และนั่นไม่เป็นผลดีต่อการเก็บรักษาเนื้อหาและการส่งออกข้อมูลที่อาจเกิดขึ้น ดังนั้นเราจึงไม่มีทางเลือกอื่นนอกจากทำการปรับแต่งเล็กน้อยในโค้ดของปลั๊กอิน คุณสามารถดูการเปลี่ยนแปลงที่แน่นอนได้ที่นี่:
https://github.com/Freemius/wp-markdown-editor/commit/672695be8b29c57f7fa7ca580d29368b9e57af68

ตอนนี้เรามีฐานความรู้ที่ใช้ Markdown ที่สวยงามและเป็นมิตรกับอุปกรณ์เคลื่อนที่ พร้อมการสนับสนุนวิดีโอ คำบรรยายภาพ และการเน้นไวยากรณ์ของโค้ด ใช่!

เรายังคงต้องทำให้มันรวดเร็วและปลอดภัย (เกือบเสร็จแล้ว!)

เราทำให้ฐานความรู้ WordPress ของเรารวดเร็วมากได้อย่างไร

เราเลือก WP Super Cache เนื่องจากเป็นที่นิยมกันอย่างแพร่หลาย (การติดตั้งที่ใช้งานมากกว่า 1 ล้านครั้ง) พัฒนาและดูแลโดย Automattic ฟรี และตั้งค่าค่อนข้างง่าย

การเพิ่มการอนุญาตดิสก์

สร้างโฟลเดอร์แคชที่เขียนได้: mkdir /path/to/your/wordpress/wp-content/cache/ setfacl -Rm user:apache:rwx /path/to/your/wordpress/wp-content/cache หากบรรทัดการอนุญาตไม่ได้ ทำงาน ใช้สิ่งต่อไปนี้: chmod 777 /path/to/your/wordpress/wp-content/cache/

เปิดใช้งานการแคช

เปิดใช้งานการแคชโดยเพิ่มสิ่งต่อไปนี้ใน wp-config.php ของคุณ:

/** Enable Caching */
define('WP_CACHE', true);
define( 'WPCACHEHOME', '/path/to/your/wordpress/wp-content/plugins/wp-super-cache/' );

ตอนนี้ทั้งหมดที่เราต้องการคือเปิดแคช คุณสามารถทำได้ผ่าน WP Admin → Settings → WP Super Cache: อย่าลืมคลิกปุ่ม "อัปเดตสถานะ" เพื่อบันทึก คุณสามารถยืนยันได้ว่าแคชทำงานโดยเปิดหน้าส่วนหน้าในเว็บไซต์ WordPress ของคุณในโหมดไม่ระบุตัวตน และตรวจสอบซอร์สโค้ด เมื่อ WP Super Cache ทำงาน คุณควรเห็นความคิดเห็น HTML ต่อไปนี้ที่ด้านล่างของซอร์สโค้ดของหน้า:

<!-- Dynamic page generated in 0.848 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2016-10-13 21:35:40 -->

<!-- super cache -->

นั่นเป็นวิธีที่ดีกว่าการแสดงหน้าโดยไม่ต้องแคช แต่สิ่งนี้ยังคงทริกเกอร์ PHP, WordPress และ MySql ทั้งหมด หากเราต้องการทำให้ไซต์ของเรารวดเร็วทันใจ เราต้องเพิ่มการแคชระดับเซิร์ฟเวอร์

การกำหนดค่าการแคชระดับเซิร์ฟเวอร์

หากคุณกำลังใช้ Nginx เหมือนกับเรา นี่คือการกำหนดค่าที่เราใช้: WP Super Cache Nginx Config Rules เคล็ดลับ: กฎการกำหนดค่า Nginx จะรวมกฎ if จำนวนมาก เพื่อประหยัดเวลาอันมีค่าของคุณ ตรวจสอบให้แน่ใจ if กฎทั้งหมดนั้นอยู่นอกคำสั่ง location มิฉะนั้น จะทำให้การประมวลผลทั้งหมดเสียหาย (ฉันเสียเวลาสองสามชั่วโมงในการค้นหาสิ่งนี้) หากคุณใช้ Apache คุณจะพบกฎ .htaccess mod_rewrite ได้จากหน้าคำแนะนำในการติดตั้งปลั๊กอินบน WordPress.org: https://wordpress.org/plugins/wp-super-cache/installation/ วิธีที่ง่ายที่สุดในการทดสอบ การแคชระดับเซิร์ฟเวอร์โดยไม่ส่งผลกระทบต่อไซต์ของคุณ ให้ทำตามขั้นตอนเหล่านี้:

สร้างและเผยแพร่โพสต์จำลอง ตั้งค่ากระสุนต่อไปนี้ `dummy-cache-test'
โหลดหน้าในโหมดเบราว์เซอร์ที่ไม่ระบุตัวตน ตรวจสอบให้แน่ใจว่าได้แคชไว้
เพิ่มรหัสต่อไปนี้ที่ส่วนบนของ wp-config.php ของคุณ:
```
if ( false !== strpos($_SERVER[REQUEST_URI], 'dummy-cache-test') {
    echo 'Server caching is off';
    exit;
}
```
หลังจากเพิ่มโค้ดแล้ว ให้โหลดหน้าเว็บซ้ำในโหมดเบราว์เซอร์ที่ไม่ระบุตัวตน หากโหลดหน้าเว็บอย่างถูกต้อง – การแคชระดับเซิร์ฟเวอร์เปิดอยู่ หากคุณได้รับข้อความ "การแคชเซิร์ฟเวอร์ปิดอยู่" แสดงว่ามีบางอย่างผิดปกติ

อย่าลืมลบส่วนเพิ่มเติมนั้นออกจาก wp-config.php และลบโพสต์จำลองเมื่อคุณทำเสร็จแล้ว ยอดเยี่ยม – เราได้ตั้งค่าการแคชแล้ว ขณะนี้ทุกหน้าให้บริการโดยตรงจากไฟล์ HTML ที่แคชแบบสแตติก ข้าม PHP และ WordPress

กำลังเพิ่ม CDN

แม้ว่า KB จะอยู่ในสภาพที่ดีอยู่แล้ว แต่การดูหน้าเว็บทุกหน้าจากเบราว์เซอร์ใหม่จะ "กระทบ" เซิร์ฟเวอร์ของเรา ดังนั้น ฉันต้องการกำจัดสิ่งนั้นโดยเพิ่มอีกหนึ่งเลเยอร์ – CDN

ประโยชน์ที่ชัดเจนของ CDN คือการกระจายศูนย์ข้อมูลทั่วโลก ความพร้อมใช้งานสูง และทรัพยากรเซิร์ฟเวอร์ที่ลดลงอย่างมาก โดยเฉพาะอย่างยิ่งเมื่อสิ่งต่างๆ เป็นแบบคงที่ หน้าจะถูกโหลดโดยตรงจาก CDN โดยไม่ต้อง "แตะต้อง" เซิร์ฟเวอร์ของเรา

ฉันไม่สามารถพูด CloudFlare ได้มากพอ เราใช้ CDN ของพวกเขา (และสินค้าพิเศษของพวกเขา) มาหลายปีแล้ว และสิ่งที่ไม่ดีเกี่ยวกับมันทั้งหมด – คุณสามารถใช้ได้ฟรี! ถูกต้อง – ฟรี 95% ของคุณสมบัติทั้งหมด

เพื่อให้ตัวอย่างแก่คุณ สมมติว่าคุณมีหน้าเว็บคงที่ยอดนิยมบนไซต์ที่มีการเข้าชมที่ไม่ซ้ำ 5 ล้านครั้งต่อวัน ละเว้นพร็อกซีเซิร์ฟเวอร์และการแคช ISP การดำเนินการนี้จะทริกเกอร์ Hit อย่างน้อย 5 ล้านครั้งต่อวันไปยังเซิร์ฟเวอร์ของคุณ เมื่อคุณใช้ CDN เช่น CloudFlare หน้าสแตติกนี้จะถูกโหลดจากไซต์ของคุณเพียงไม่กี่ครั้งต่อวัน (ตามความถี่การล้างแคช CDN)

นี่คือสถิติจริงบางส่วนจากโดเมนย่อยที่เรามีซึ่งให้บริการเฉพาะรูปภาพ:

ดูตัวเลขเหล่านั้น - เราบันทึกแบนด์วิดท์มากกว่า 600 GB สำหรับเซิร์ฟเวอร์ของเรา หากคุณตั้งค่าปลั๊กอิน WordPress + WP Super Cache + แคชระดับเซิร์ฟเวอร์ + CloudFlare CDN คุณอาจใช้หยด DigitalOcean มูลค่า $5 / mo ได้โดยไม่มีปัญหาเรื่องการปรับขนาด!

มาทำคณิตศาสตร์ด้วยกัน… WordPress ฟรี WP Super Cache ฟรี CloudFlare CDN ฟรี… โอ้ – เพียง $5 / เดือน สำหรับ WordPress ที่ปรับขนาดได้ บ้าจริงเหรอ!

เราปรับแต่งการค้นหา KB เพื่อให้บริการข้อมูลแคชได้อย่างไร

ตามค่าเริ่มต้น โครงสร้างลิงก์ถาวรของการค้นหาของ WordPress ใช้พารามิเตอร์สตริงข้อความค้นหา s= เพื่อส่งคำค้นหา ด้วยเหตุผลที่ดี WP Super Cache จะละเว้นสตริงการสืบค้น ดังนั้นเราจึงต้องทำการปรับแต่งเล็กน้อยในโครงสร้าง URL การค้นหาเพื่อให้ใช้งานได้:

การอัปเดตนี้เปลี่ยนโครงสร้าง URL เป็น freemius.com/help/documentation/search/{query}/ ซึ่งแคชไว้โดย WP Super Cache

บูม! แม้แต่ผลการค้นหาของเราก็ยังถูกแคชไว้

เรารักษาฐานความรู้ WordPress ของเราได้อย่างไร

ความปลอดภัยเป็นกุญแจสำคัญ สิ่งสุดท้ายที่บริษัทใดๆ โดยเฉพาะบริษัทสตาร์ทอัพต้องการจัดการคือการละเมิดความปลอดภัย มันสามารถทำลายชื่อเสียงของคุณ เสี่ยงต่อทรัพย์สินทางปัญญาของคุณ และใช้เวลาหลายชั่วโมง หรือแม้แต่เป็นวันในการกู้คืนการควบคุมและข้อมูล

นักพัฒนาหลายคนชอบที่จะพูดเรื่องไร้สาระเกี่ยวกับ WordPress และบอกว่ามันไม่ปลอดภัย ตามตัวเลข – ใช่ พวกเขาน่าจะถูก เนื่องจาก WordPress เป็นแพลตฟอร์มเว็บที่ได้รับความนิยมมากที่สุด จึงเป็นเป้าหมายอันดับ 1 สำหรับแฮกเกอร์ และตัวเลขก็สมเหตุสมผล – ดะ...

สิ่งที่พวกเขาไม่เข้าใจก็คือ WordPress ในฐานะแพลตฟอร์มน่าจะเป็นหนึ่งในโครงการที่ปลอดภัยที่สุด ช่องโหว่ส่วนใหญ่มาจาก WordPress เวอร์ชันเก่า ล้าสมัย ปลั๊กอินและธีมของบุคคลที่สาม และจากผู้ใช้ที่ตั้งรหัสผ่านที่ไม่รัดกุม

So the first thing we would like to do is eliminate any notion of WordPress in our source code to reduce the chances of an attack.

1. WordPress adds a bunch of (mostly) unuseful metadata to the head of every page which is pretty much unique to WordPress, let's get rid of that by adding the following code to the theme's functions.php file:

2. Many WordPress plugins add HTML comments with a unique thumbprint that are easily identified. For example, Yoast SEO adds the following code:

<!-- This site is optimized with the Yoast SEO plugin v3.7.0 - https://yoast.com/wordpress/plugins/seo/ -->

That makes it easy for attackers to identify the site as WordPress.

Remember CloudFlare?

It has a checkbox to automatically minify HTML and get rid of all the HTML comments added by different plugins, themes and WordPress core:

เสร็จแล้ว!

3. Another known identifier of WordPress is the /wp-admin/ path to the login page. We installed WPS Hide Login, and configured our own “secret” path to the login page.

Assuming you set your login to your-site.com/my-secret-login/ make sure you add that path to WP Super Cache exclusion list. You can find it under WP Admin → Settings → WP Super Cache → Advanced:

Otherwise, it might mess up things when using SSL.

4. No need to mention – you and your team should be keeping your passwords strong! You can use a plugin like Force Strong Password to enforce a 'strong passwords' policy.

5. Force your login and WP Admin browsing via HTTPS to prevent password sniffing. You can achieve that by adding the following defines to the wp-config.php file:

define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);

6. One of the most popular attacks on WordPress sites is Brute force attack. Having a strong password policy helps, but can't really protect against it. Thus, we installed Google Captcha plugin that adds a simple captcha validating it's a human being:

Also, we installed Login Watchdog, a lightweight plugin that automatically bans suspicious IPs after pre configured amount of failed logins.

And if you are using CloudFlare as I recommended, it comes with a security layer against any threats, and since it's widely used, it has a “network knowledge” to protect your site from IPs that were attacking other sites powered by CloudFlare.

7. You should also secure WordPress on the server layer, preventing direct access to files like wp-login.php , hiding sensitive files, etc. Just follow this post:
https://lamosty.com/2015/04/14/securing-your-wordpress-site-running-on-nginx/

So yes – as long as there is a login page to our WordPress, it would never be secure as a pure static website. But the fact that we have turned our KB's frontend to static, hidden any evidence that we are using WordPress, added brute force protection and forced the login via HTTPS with a strong password policy, makes it very very (very) hard to hack.

I would dare to say that the only way the Knowledge Base will be hacked is if a security dojo will target our site specifically (that's rare, and I'm NOT calling anyone for a challenge).

ตอนนี้คุณ

Hopefully, this (very) elaborate article/tutorial will be useful for you when you come to make the important decision of what to go with for your knowledge base documentation solution.
No doubt, there's a lot to take into account here, and many of the decisions we made were influenced by our very specific needs & desires.

You could either copy & paste the entire process and customizations, or go deeper and customize it according to your specific needs. What's more important is to grasp the line of thought that lead the decision making and choosing & picking what's right for us. It was not easy because as I've shown – there are quite a few viable options out there, however, it did pay off, as Freemius now has an awesome Knowledge Base center, which is super customizable, lightning fast and scalable!

Hope you have a clear view how you can get started implementing and setting up your own documentation solution.

ขอให้โชคดี!