เขียนธีม WordPress บนเทคโนโลยีสมัยใหม่ด้วย Sage 9 – ตอนที่ 1 แนะนำ Sage 9

Sage (ปัจจุบันเป็นเวอร์ชัน 9 ชื่อเดิมคือ Roots) เป็น Starter theme หรือธีมต้นแบบที่พัฒนาโดย Roots.io สำหรับใช้ต่อยอดสร้างเป็นธีมของเว็บขึ้นมาอีกต่อหนึ่ง (แบบเดียวกับ Underscores) และจุดเด่นของ Sage นั้นคือนำเอา Workflow และเทคโนโลยีใหม่ๆ มาช่วยในการพัฒนาธีมด้วย

• เว็บไซต์หลัก
• GitHub

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

• ใช้ Composer ในการจัดการแพ็คเกจ PHP
• ใช้ Yarn ในการจัดการแพ็คเกจสำหรับ Front-end
• ใช้ SASS ในการเขียนสไตล์ชีท
• แยก Views และ Controller ออกจากกัน
  • ใช้ Blade Template ของ Laravel ในการทำ Views
  • มี Controller สำหรับใช้ประมวลผล  แล้วค่อย expose ตัวแปรไปให้ Views แสดงผลอีกต่อ
• ปรับขนาดไฟล์รูปอัตโนมัติ  และรวมไฟล์ JS และ CSS เป็นไฟล์เดียวได้
• รองรับ Live reload ด้วย Webpack / Browser-sync

ความต้องการของระบบ

เนื่องด้วย Sage 9 นั้นจัดเต็มด้วยเทคโนโลยีใหม่ๆ ทำให้ Requirement ก็ค่อนข้างใหม่ไปด้วย  โดยมีความต้องการขั้นต่ำดังนี้

• WordPress 4.7 หรือใหม่กว่า
• PHP เวอร์ชัน 7.1.3 หรือใหม่กว่า (และเปิดใช้ php-mbstring)
• Composer ตัวจัดการแพ็คเกจของ PHP
• Node.js เวอร์ชัน 6.9 หรือใหม่กว่า
• Yarn ตัวจัดการแพ็คเกจของ Node.js (แบบเดียวกับ npm)

ทั้งนี้ทั้งนั้นแล้ว  จะทำต้องทำให้สุด  เราแนะนำให้ใช้ Isolated Development Environment ไปด้วยเลย  อย่างเช่น VVV, Local by Flywheel, หรือ Trellis

สร้างโปรเจ็กท์ด้วย Sage 9

การสร้างธีมด้วย Sage 9 นั้นสามารถทำได้ผ่านคำสั่ง create-project ของ Composer  โดยเมื่อติดตั้งเวิร์ดเพรสบน local เสร็จแล้ว  ให้เปิด terminal หรือ cmd ไปที่โฟลเดอร์เก็บธีมของเวิร์ดเพรส (wp-content/themes) แล้วรันคำสั่งต่อไปนี้

$ composer create-project roots/sage your-theme-name

จากนั้นจะเข้าสู่ขั้นตอนการกรอกข้อมูลโปรเจ็กท์ของเรา  ซึ่งมีรายละเอียดที่ต้องกรอกดังนี้

1. Do you want to remove the existing VCS (.git, .svn..) history? จะลบประวัติ git ของ Sage หรือไม่ (กด Enter ไปได้เลย  เราไม่ต้องการประวัติ git ของ Sage อยู่แล้ว)
2. Theme Name ชื่อธีมที่ต้องการ
3. Theme URI หน้าเว็บของธีม (ใส่เว็บเราไปก็ได้)
4. Theme Description คำอธิบายของธีม
5. Theme Version เวอร์ชันของธีม
6. Theme Author ผู้สร้างธีม
7. Theme Author URI เว็บของผู้สร้างธีม
8. Local development URL of WP site URL เว็บบน local ของเรา (เช่น http://localhost/web หรือ https://wp63.test) ตรงนี้จะใช้กับ Browser-sync
9. Path to theme directory (e.g., /wp-content/themes/wp63co) พาทไปยังธีมของเรา (ใช้กับ Browser-sync เช่นกัน) ซึ่งโดยปกติแล้วพิมพ์ตาม e.g. ไปได้เลย
10. Which framework would you like to load? เลือก CSS Framework เริ่มต้น  ให้พิมพ์ตัวเลขข้างหน้าลงไป
11. Do you want to install Font Awesome? (yes/no) ต้องการติดตั้ง Font Awesome ไปด้วยเลยหรือไม่ (ณ ตอนที่เขียนอยู่นี้  จะเป็น Font Awesome 4.7.0 ยังไม่ใช้ 5.0) พิมพ์ตอบ yes หรือ no
12. Are you sure you want to overwrite the following files? หากเลือก CSS Framework เป็นตัวอื่นที่ไม่ใช่ Bootstrap ให้ตอบ yes เพื่อเขียนทับไฟล์เหล่านี้ด้วยคลาสของเฟรมเวิร์กนั้นๆ

หลังจากสร้างโปรเจ็กท์เสร็จแล้ว  ให้ cd เข้าไปยังโฟลเดอร์ที่เก็บธีม (โฟลเดอร์จะชื่อเดียวกับ your-theme-name ที่เราระบุในขั้นตอนการสร้างโปรเจ็กท์) และสั่ง yarn เพื่อติดตั้งแพ็คเกจ front-end เพิ่มเติม

$ cd wp63co && yarn

Yarn จะใช้เวลาสักพักหนึ่งในการติดตั้งแพ็คเพจต่างๆ เสร็จแล้วให้สั่ง build อีกรอบ  ก็พร้อมทดสอบแล้ว

$ yarn run build

Yarn เป็นซอฟต์แวร์จัดการแพ็คเกจของ Node.js เช่นเดียวกับ npm ซึ่งสามารถใช้งานแทนกันได้เลย  สามารถดาวน์โหลดตัวติดตั้งได้ในเว็บนี้

ก่อนเริ่ม: มาตรฐานการเขียนโค้ด

เพราะว่าเมื่อจะทำต้องทำให้สุด  ใน Sage 9 นั้นมีการใช้ Webpack เข้ามาใช้ในการคอมไพล์โค้ดต่างๆ (JS และ SCSS) ซึ่งใน Webpack ก็จะมี ruleset ที่ระบุเกี่ยวกับมาตรฐานการเขียนโค้ดเอาไว้  และผู้ใช้จะต้องทำตามด้วย  ไม่อย่างนั้นจะไม่สามารถคอมไพล์ได้

linter ถือเป็นหนึ่งในเรื่องที่น่าปวดหัวที่สุดของคนที่เพิ่งลองเขียนอะไรแบบนี้  แม้ว่าเราจะสามารถสั่งปิด linter ได้  แต่ผมแนะนำว่าให้เปิดไว้  และพยายามเขียนโค้ดให้ตรงตามกับ ruleset ของ linter เหล่านี้  เพราะอย่างน้อยๆ มันจะช่วยให้เราสามารถเขียนโค้ดได้สวยขึ้น  เป็นมาตรฐาน  และสามารถทำงานร่วมกับคนอื่นได้ง่ายขึ้นด้วย

ในกรณีของไฟล์ JS นั้นจะมีการแจ้งข้อผิดพลาดขึ้นมาทันทีหลังจากที่สั่ง yarn run build แต่กรณีของไฟล์ SCSS นั้นจะไม่แสดงรายละเอียดข้อผิดพลาดเลย  ผู้ใช้ต้องสั่ง yarn run lint:styles เอาเองเพื่อดูรายละเอียดข้อผิดพลาด

ในผลการ lint นี้จะบอกข้อผิดพลาดทั้งหมดในไฟล์แต่ละไฟล์  พร้อมกับเลขบรรทัดและลำดับตัวอักษร (ตัวเลขสีเทาหน้าบรรทัด) ก็ให้ตามไปแก้ไขให้ถูกต้องตามที่ linter ระบุเอาไว้

ก่อนเริ่ม: โครงสร้างไฟล์

จะสังเกตุว่าเมื่อเปิดโฟลเดอร์ธีมมา  เราจะไม่พบกับไฟล์ใดๆ อย่างที่ควรจะมีอยู่ในนั้นเลย  มันไม่มีแม้กระทั่งไฟล์หลักอย่าง style.css และ index.php ซึ่งแนวคิดของ Sage เองนั้นต้องการที่จะเอาไฟล์ธีมทั้งหมดออกไปจากโฟลเดอร์หลัก (เอาไปเก็บไว้ในโฟลเดอร์ resources แทน) และให้โฟลเดอร์หลักมีเฉพาะไฟล์คอนฟิกต่างๆ เท่านั้น

Sage จะมีโฟลเดอร์ที่สำคัญอยู่ 3 โฟลเดอร์  คือ

1. ./app เก็บฟังก์ชันทำงานต่างๆ รวมถึงคอนโทรลเลอร์ของธีม  ซึ่งนอกจากโฟลเดอร์ Controllers แล้ว  ยังมีไฟล์หลักๆ อยู่อีก 4 ไฟล์ดังนี้
   1. admin.php หน้าที่หลักของมันจริงๆ คือเก็บโค้ดสำหรับ Customizer (ถ้าใช้) แต่โค้ดต่างๆ ที่จะใช้ในหน้า wp-admin เช่นการเพิ่มหน้าออพชันใหม่  ก็เอามาใส่ในนี้ได้เช่นกัน
   2. filters.php เก็บโค้ดฮุคเข้าสู่ฟิลเตอร์และแอคชันต่างๆ ของเวิร์ดเพรส  หากเราจะฮุคเข้าไปแก้การทำงานต่างๆ  สามารถเอาโค้ดมาเก็บไว้ในนี้ได้
   3. helpers.php เก็บฟังก์ชันใช้งานทั่วไปต่างๆ เช่นฟังก์ชัน asset_path() สำหรับดึง URL ของ assets ที่ผ่านการคอมไพล์แล้ว
   4. setup.php เก็บโค้ดสำหรับเซ็ตอัพฟีเจอร์ต่างๆ ของธีม  เช่น register_sidebar() หรือ register_menus()
2. ./config เก็บการตั้งค่าของธีม (หลักๆ จะเป็นเรื่องพาทต่างๆ ไม่ค่อยได้แก้)
3. ./resources เก็บไฟล์เกี่ยวกับเท็มเพลตทั้งหมด  โดยไฟล์หลักของธีมคือ style.css, index.php, และ functions.php จะอยู่ในนี้ด้วย (แต่เราจะไม่แก้ไฟล์พวกนี้กัน  ไฟล์ที่เราแก้จะอยู่ใน /resources/views) และในโฟลเดอร์นี้จะมีโฟลเดอร์ย่อยอีก 2 โฟลเดอร์คือ
   1. assets สำหรับเก็บ assets ทั้งหมด  เช่นไฟล์ SCSS, ไฟล์ JavaScript, ไฟล์รูปภาพ, และไฟล์ฟอนต์  ซึ่งไฟล์เหล่านี้จะถูกคอมไพล์และออพติไมซ์  และโยนไปไว้ใน /dist ให้โดยอัตโนมัติ
   2. views เก็บไฟล์เท็มเพลตทั้งหมดของธีม

นอกจากนี้เมื่อเราติดตั้งและบิวด์เสร็จ  จะมีโฟลเดอร์อีก 3 โฟลเดอร์โผล่ขึ้นมา (ซึ่งเราไม่จำเป็นต้องไปแก้ไขอะไร) ดังนี้

1. ./dist สำหรับเก็บ assets ต่างๆ ที่ผ่านการคอมไพล์เรียบร้อยแล้ว
2. ./node_modules สำหรับเก็บโมดูล node.js ที่เราติดตั้งผ่าน yarn หรือ npm ซึ่งปกติแล้วก็จะถูกเอาไปคอมไพล์เก็บลงใน ./dist/ ด้วยเช่นกัน
3. ./vendor สำหรับเก็บแพ็คเกจ PHP ที่ติดตั้งผ่าน composer

ในการทำงานหลักๆ นั้นเราจะแก้ไขไฟล์เท็มเพลตใน ./resources/views และ SCSS ใน ./resources/assets/styles เป็นหลัก

SASS และ Blade Template Engine

สองอย่างที่น่าจะเป็นสิ่งใหม่สำหรับชาวเวิร์ดเพรสหลายๆ คน  นั่นคือการใช้ SASS และ Blade Template Engine

SASS เป็นรูปแบบการเขียน CSS แบบหนึ่งที่ช่วยให้สามารถเขียน CSS ได้ง่ายขึ้น  เพราะมีฟีเจอร์ที่ CSS โดยทั่วไปไม่มีอย่างเช่นการเขียน CSS ซ้อนกัน, การกำหนดตัวแปรและฟังก์ชัน, การนำโค้ดเก่ากลับมาใช้งานใหม่ ฯลฯ หรือพูดในอีกมุมหนึ่งก็คือเป็นการเขียน CSS ในเชิงโปรแกรมมิ่งมากขึ้นนั่นเอง

หลายคนน่าจะเคยได้ยินคนเรียก SASS บ้าง  หรือ SCSS บ้าง  จริงๆ ตัวหลักของมันคือ SASS ซึ่งจะมีรูปแบบการเขียนเฉพาะของมันเอง  ส่วน SCSS นั้นคือการเอาฟีเจอร์ของ SASS มาเขียนโดนใช้วิธีการเขียนแบบ CSS ปกติ  ซึ่งทำให้นักพัฒนาสามารถเรียนรู้ได้ง่ายกว่า  และสามารถเอาโค้ด CSS เดิมมาใช้ได้ในทันที

ด้วยความที่ SASS นั้นไม่ได้เป็นมาตรฐานเว็บ  ทำให้โดยปกติแล้วจะต้องมีเครื่องมืออย่างเช่น Prepros ในการคอมไพล์ไฟล์ SASS ให้เป็น CSS ธรรมดา  ทั้งนี้ใน Sage นั้นจะมาพร้อมกับ Webpack ที่มีตัวคอมไพล์ SASS ให้ในตัว  เพียงแค่สั่ง yarn run build ก็พร้อมใช้งานโดยไม่ต้องลงโปรแกรมเพิ่มแต่อย่างใด

ข้อดีอีกอย่างของการเขียน SASS ร่วมกับเครื่องมือคอมไพล์นั่นคือเราไม่ต้องนั่งเขียน prefix css เอง (เช่นพวก -moz หรือ -ms ทั้งหลาย) เพราะโปรแกรมคอมไพล์นั่นจะเติม prefix เหล่านี้ให้อัตโนมัติ

ส่วน Blade Template Engine นั้นเป็นระบบเท็มเพลตที่ใช้อยู่ในเฟรมเวิร์ก Laravel 5 แนวคิดหลักๆ ของมันคือลดการเขียนโค้ดซ้ำให้มากที่สุด  โดยจะมีการกำหนดเท็มเพลตโครงหลักเอาไว้  และกำหนดส่วนแสดงผลต่างๆ (section) จากนั้นให้ไฟล์เท็มเพลตอื่นเขียน extends เอาจากโครงหลักนี้โดยไม่จำเป็นต้องเขียนโครงซ้ำอีก  แต่จะใช้วิธีเขียนเฉพาะส่วนแสดงผล (section) ที่กำหนดเอาไว้ในโครงหลักเท่านั้น

ที่เห็นบ่อยที่สุดในไฟล์เท็มเพลตของเวิร์ดเพรสคือจะมีการใช้ฟังก์ชัน get_header() และ get_footer() อยู่ในทุกๆ หน้าเพื่อเรียกส่วนหัวและส่วนท้ายหน้าเข้ามา  แต่ใน Blade จะเรียก header และ footer เข้ามาที่ไฟล์โครงหลักไฟล์เดียว  และกำหนด section เปล่าๆ ทิ้งเอาไว้  จากนั้นเท็มเพลตอื่นก็เขียน extends โครงหลัก  และเขียนโค้ดเฉพาะส่วน section นั้นๆ ได้เลย

ตัวอย่างดังนี้  อันนี้คือไฟล์โครงหลัก  อยู่ใน ./resources/views/laouts/app.blade.php

<!doctype html>
<html @php(language_attributes())>
  @include('partials.head')
  <body @php(body_class())>
    @php(do_action('get_header'))
    @include('partials.header')
    <div class="wrap container" role="document">
      <div class="content">
        <main class="main">
          @yield('content')
        </main>
        @if (App\display_sidebar())
          <aside class="sidebar">
            @include('partials.sidebar')
          </aside>
        @endif
      </div>
    </div>
    @php(do_action('get_footer'))
    @include('partials.footer')
    @php(wp_footer())
  </body>
</html>

สังเกตุว่าไฟล์นี้จะเก็บโครง HTML หลักทั้งหมดไว้  รวมถึง include ส่วน header และ footer มาให้แล้ว  และมีการประกาศ section ที่ชื่อ content เอาไว้ (ผ่านคำสั่ง @yield('content)) ดังนั้นเมื่อเราจะเขียนเท็มเพลต single เราก็สามารถสั่ง extends โครงนี้  และเขียนเฉพาะส่วน section content ได้เลย  เมื่อ Blade คอมไพล์ไฟล์เท็มเพลตของเรา  ก็จะเอาโค้ดส่วน @section('content') ไปแสดงที่ @yield('content') ให้อัตโนมัติ

@extends('layouts.app')

@section('content')
  @while(have_posts()) @php(the_post())
    {{-- โค้ดแสดงผลปกติ --}}
  @endwhile
@endsection

ข้อดีของมันคือเมื่อต้องเขียนเท็มเพลตเยอะๆ Blade จะช่วยให้โค้ดสั้นลง  และแก้ไขโค้ดได้ง่ายขึ้นมาก (พอกันทีกับการลืมแก้โค้ดในบางไฟล์)

ไฟล์ Blade นั้นจะมีนามสกุลเป็น .blade.php เช่น single.blade.php ซึ่งถ้าหากใครไม่ชินกับโค้ดของ Blade ก็สามารถเขียน PHP ปกติ  และลบ .blade ออกจากนามสกุลได้ (เช่น single.blade.php เป็น single.php ปกติ)

ข้อมูลเพิ่มเติมเกี่ยวกับ Blade Template Engine สามารถอ่านได้จากเอกสารของ Laravel ได้เลย

ทิ้งท้าย และตอนต่อไป

บทความชุดนี้จะมีอย่างน้อย 3 ตอน  โดยตอนต่อไปจะเป็นเรื่องเกี่ยวกับการติดตั้งแพ็คเกจต่างๆ เพิ่มเติม  และการใช้งาน Blade เบื้องต้น  และในตอนที่ 3 จะต่อกันในเรื่องของ Blade และเรื่องเกี่ยวกับ Controllers ที่จะใช้ในการส่งตัวแปรให้กับไฟล์เท็มเพลต

อนึ่ง ระหว่างเขียนบทความนี้ก็ถือโอกาสนั่งเขียนศึกษา Sage 9 ตามไปด้วย  ด้วยการลองเขียนธีมขึ้นมาใหม่เลย (เพราะที่ บ. ผมใช้ธีมตัวนี้ด้วย  เลยต้องหัด) อย่างน้อยๆ มันน่าจะเสร็จทันกับบทความชุดนี้เนอะ

บทความตอนอื่นๆ

1. เขียนธีม WordPress ด้วย Sage 9 – ตอนที่ 2 ระบบจัดการแพ็คเกจ
2. เขียนธีม WordPress ด้วย Sage 9 – ตอนที่ 3 Blade Template Engine
3. เขียนธีม WordPress ด้วย Sage 9 – ตอนที่ 4 ควบคุมข้อมูลด้วย Controller