ฉันจะจัดโครงสร้างโครงการเว็บไซต์ WP โดยใช้ git และอัปเดตจากแผงควบคุม WP ได้อย่างไร

เป็นเวลาหลายเดือนที่ฉันพยายามวางแผนโครงสร้างโครงการที่ดีสำหรับการใช้การควบคุมเวอร์ชัน git สำหรับการพัฒนาเว็บไซต์ WordPress ที่ไม่ต้องเสียสละความสามารถในการอัปเดตคอร์และปลั๊กอินผ่านแผงควบคุม WP ไม่จำเป็นต้องมีโครงสร้างไดเรกทอรีที่แปลกใหม่ (wp - เนื้อหานอกโฟลเดอร์หลักของ WP) และง่ายต่อการจัดการและปรับใช้เว็บไซต์ทั้งหมด ฉันได้อ่านเกี่ยวกับ submodules, subtrees, repos ที่ซ้อนกันและอื่น ๆ และฉันยังคงมีเวลายากที่จะปรับมันเข้าด้วยกันและเลือกกลยุทธ์ที่เหมาะสม

นี่คือสิ่งที่ฉันกำลังคิดอยู่ในขณะนี้ด้วยความคิดของฉันสำหรับวิธีการจัดการ repos คอมไพล์ในวงเล็บ

root (main project repo)
|-- wordpress (public git repo added as subtree)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo added as subtree)
|    |    |    |-- other-plugin-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-plugin-without-git-repo (ignored/untracked)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo added as subtree)
|    |    |    |-- other-theme-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-theme-without-git-repo (ignored/untracked)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

ทำให้ฉันมีปัญหา / คำถามมากมาย

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

• การมีทรีย่อยภายใต้ WordPress core repo ทำให้ฉันไม่สามารถใช้คอมไพล์เพื่อรวมในการอัปเดตหลักใหม่หรือผลักดันการเปลี่ยนแปลงของฉันกลับไปเป็น WordPress core repo (ถ้าฉันตัดสินใจว่าฉันต้องการเป็นผู้สนับสนุนหลัก)?

• สำหรับปลั๊กอินที่ไม่มี repit สาธารณะ git การเพิกเฉยอย่างสมบูรณ์จะสร้างปัญหาที่ไม่สามารถโคลนไซต์ทั้งหมดบนเซิร์ฟเวอร์ใหม่ได้อย่างรวดเร็วโดยไม่ต้องคัดลอกไฟล์ไปยังเซิร์ฟเวอร์ด้วยตนเอง นอกจากนี้ยังทำให้เกิดปัญหาหากฉันต้องการเปลี่ยนแปลงรหัสของปลั๊กอินนั้นการเปลี่ยนแปลงเหล่านั้นไม่ได้ถูกติดตามและอาจสูญหายได้ง่ายในการอัปเกรดปลั๊กอิน

ดังนั้นเพื่อสรุปการตั้งค่า git + WordPress ที่ดีที่ช่วยหลีกเลี่ยงปัญหาเหล่านี้คืออะไร? ฉันขอขอบคุณข้อเสนอแนะของคุณเกี่ยวกับโครงสร้างโครงการที่เสนอ วิธีใดก็ตามที่คุณสามารถช่วยฉันปรับปรุงสิ่งนี้จะได้รับการชื่นชมมาก!

ป.ล. ถ้ามีฟอรั่มที่ดีกว่าสำหรับการอภิปรายนี้โปรดชี้ฉันที่นั่น

จากมุมมองของฉันมีสองประเด็นเกี่ยวกับแผนของคุณ - โครงสร้าง Git และ "ธรรมดา" ดังนั้นโดยพื้นฐานแล้วทุกอย่าง :)

1. Git (และการควบคุมเวอร์ชันโดยทั่วไป) เป็นเครื่องมือที่ไม่ดีสำหรับกองเว็บไซต์ทั้งหมด เคยไปที่นั่นทำมันเจ็บปวดมาก

2. สิ่งที่คุณเรียกว่าโครงสร้าง "แหวกแนว" ที่มีเนื้อหาแยกจากคอร์นั้นเป็นทางเลือกที่ธรรมดาและมีประสิทธิภาพสำหรับไซต์ที่จริงจัง ๆ อยู่พักหนึ่ง

3. ไม่มีวิธีเทิร์นคีย์ในการรวมทั้งไซต์สแต็คเข้ากับการอัพเดตดั้งเดิม มันไม่ได้ไปด้วยกันได้ดีเพราะมันพยายามที่จะบรรลุเป้าหมายที่แตกต่างกันในโครงการระดับต่าง ๆ (นักพัฒนาในการควบคุม vs ผู้ใช้ปลายทางในการควบคุม)

หากคุณถามฉันว่าทางออกที่ดีที่สุดสำหรับทั้งเว็บไซต์ WordPress กองอยู่ในขณะนี้นักแต่งเพลงแต่ความคิดเห็นอาจระวัง :)

ตามความกังวลเฉพาะของคุณ:

1. ดังกล่าว - การอัปเดตในตัวเครื่อง (อัตโนมัติมากขึ้น) เล่นได้ไม่ดีกับสแต็คที่ควบคุมอย่างแน่นหนา

2. WordPress คอร์ไม่ได้รับการพัฒนาใน Git และไม่ยอมรับการร้องขอแบบดึงการมีส่วนร่วมทั้งหมด (จนถึงตอนนี้) ผ่านทางไฟล์แพทช์ไปยังการโค่นล้ม

3. คุณอาจจะต้องใช้ปลั๊กอินดังกล่าวใน repo ของคุณ หรือใช้แนวทางอื่นเช่นนักแต่งเพลง

คุณอาจจะดูที่นี้ปัญหาและนี้ปัญหา

ตรวจสอบไฟล์ README ในแต่ละ repo ด้วย:

• markjaquith / WordPress-Skeleton
• davidwinter / wordpress-with-git

จาก repos ด้านบนเป็นอีกตัวอย่างหนึ่งของการตั้งค่า Git / WP ฉันสร้างมันขึ้นมา ฉันเลือกใช้ symlink สำหรับชุดรูปแบบ (ฉันพยายามครอบคลุมใน README ของฉัน )

ฉันอยู่ในเรือลำเดียวกันพร้อมกับการอัปเดตอัตโนมัติแม้ว่า ... แผนของฉันคือการอัปเดต submodule WP ด้วยตนเองเมื่อมีการอัปเดตเกิดขึ้น ฉันคิดว่าเป็นทางเลือกในทางทฤษฎี (ฉันยังไม่ได้ทดสอบตัวเอง) เพื่อให้การปรับปรุง submodule สำหรับการอัพเดทเล็กน้อย (มีการตั้งค่า WP สำหรับสิ่งนี้) จากนั้นทำการgitบังคับ / รีเซ็ต submodule เมื่อการอัพเดทครั้งสำคัญออกมา ( อาจเป็นหนึ่งในคำตอบที่นี่อาจช่วยได้ ... แน่นอนฉันคิดว่าใครต้องการกำหนดเป้าหมายแท็ก WP เฉพาะเมื่ออัปเดตเป็นรุ่นใหญ่ครั้งถัดไป)

สิ่งหนึ่งที่ควรทราบคือถ้า WP เห็น.gitในพา ธ จะปิดการอัปเดตอัตโนมัติโดยอัตโนมัติ สำหรับข้อมูลเพิ่มเติมดู:

• Automatic Core Updates เป็นการอัพเดต

เพื่อให้การอัปเดตอัตโนมัติเปิดใช้งานมีข้อกำหนดง่าย ๆ ดังนี้:

• หากการติดตั้งใช้ FTP สำหรับการปรับปรุง (และแจ้งให้มีการรับรอง) การปรับปรุงอัตโนมัติจะถูกปิดการใช้งาน
• หากการติดตั้งทำงานเป็นเช็คเอาต์ SVN หรือ GIT การอัปเดตอัตโนมัติจะถูกปิดใช้งาน
• หากค่าคงที่DISALLOW_FILE_MODSหรือAUTOMATIC_UPDATER_DISABLEDกำหนดไว้การอัปเดตอัตโนมัติจะถูกปิดใช้งาน
• หากค่าคงที่WP_AUTO_UPDATE_COREถูกกำหนดให้เป็นเท็จการอัปเดตอัตโนมัติจะถูกปิดใช้งาน
• การติดตั้ง WordPress ของคุณจะต้องสามารถติดต่อ WordPress.org ผ่านการเชื่อมต่อ HTTPS ได้ดังนั้นการติดตั้ง PHP ของคุณก็ต้องมีการOpenSSLติดตั้งและใช้งานได้
• Wp-Cron จำเป็นต้องใช้งานได้หาก cron ไม่สามารถทำงานกับการติดตั้งของคุณได้ด้วยเหตุผลบางอย่างการอัพเดตอัตโนมัติจะไม่สามารถใช้งานได้

ลิงค์อื่น ๆ ที่เกี่ยวข้อง:

• WP 3.7 อัปเดตอัตโนมัติ
• GitHub พัฒนาธีมย่อย submodule?
• ติดตั้งและจัดการ WordPress ด้วย Git

อัปเดตพฤษภาคม 2558

ฉันสร้างrepo นี้ซึ่งเป็นวิธีที่รวดเร็วสำหรับฉันในการเริ่มต้นโครงการ WordPress วิธีการล่าสุดของฉันคือการควบคุมธีมเท่านั้น กล่าวอีกนัยหนึ่งฉันติดตั้ง WP ภายใน (โดยใช้การตั้งค่าใน repo ข้างต้น) และในการผลิตจากนั้นฉันจะแก้ไขไฟล์กำหนดค่าในแต่ละระบบและgitดึงธีมของฉันเพื่อรับไซต์ที่ใช้งานได้

การพัฒนาประเภทนี้ตกอยู่ใน "ไม่ใช่เรื่องง่ายและต้องมีเวิร์กโฟลว์ที่กำหนดเองซึ่งอาจต้องใช้เวลานานกว่าจะพอใจ"

ฉันพบ Subtrees, submodules หรือ repos ที่ซ้อนกันซึ่งเป็นความเจ็บปวดอย่างมากในตูด

ความคิดบางอย่าง (ติดตามทุกอย่าง)

1. เปิดใช้งานการอัปเดตอัตโนมัติด้วย git / svn โดยใช้:
   add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

วิธีที่ปลอดภัยผ่านการส่งด้วยตนเอง + อีเมล:

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

นอกจากนี้ยังช่วยให้คุณสามารถคัดลอก / วางโฟลเดอร์สำหรับ repos ของคุณได้ตามต้องการซึ่งมักเป็นวิธีที่ฉันทำ นอกจากนี้ยังทำให้ง่ายต่อการโคลน / ทำลายเซิร์ฟเวอร์ staging หลาย ๆ ตัว git มีผลบังคับใช้กับวิธีการนี้นับตั้งแต่มีการเผยแพร่

ข้อเสีย: คัดลอก / วางโฟลเดอร์การจัดการ

วิธีอัตโนมัติ

ตั้งค่าสคริปต์บิลด์ (Phing, Ant, Bash, Capistrano, ฯลฯ ) และโค้ดที่กำหนดเองที่จะใช้คอมไพล์ add + commit เมื่อมีการใช้การอัปเดตและส่งไปยังเซิร์ฟเวอร์จริง คุณยังสามารถแยกปลั๊กอิน / ธีม repos แล้วมีสคริปต์รวบรวม / ย้าย / สิ่งที่พวกเขาและ / หรือใช้นักแต่งเพลงในการผสม

เวิร์กโฟลว์อัตโนมัติเช่นนี้มีแนวโน้มที่จะไม่ยืดหยุ่นและคุ้มค่าหากคุณเห็นความต้องการที่แท้จริงสำหรับเวลาที่ลงทุน

ข้อเสีย: ยืดหยุ่นใช้เวลาในการสร้าง

Git ไม่ควรใช้สำหรับการสำรองข้อมูลและโดยทั่วไปการพูดไม่จำเป็นต้องให้คุณโคลนประวัติการกระทำของ WP

หลังจากที่คิดเพิ่มขึ้นเนื่องจากฉันต้องการใช้ประโยชน์จากการอัปเดต WP ดั้งเดิมเพื่อช่วยตัวเองอย่างถูกต้องมันไม่มีเหตุผลที่จะติดตามสิ่งที่ WP จะอัปเดตโดยใช้ git นี่คือแนวคิดที่แก้ไขแล้ว

root (main project repo)
|-- wordpress (ignored/untracked)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo not connected to parent)
|    |    |    |-- other-plugin (ignored/untracked)
|    |    |    +-- modified-plugin (unignored, added to main project repo)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo not connected to parent)
|    |    |    |-- other-theme (ignored/untracked)
|    |    |    +-- modified-theme (unignored, added to main project repo)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

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

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

ตกลงดูการพูดคุยของมาร์ค Jaquith ที่นี่บางทีฉันอาจจะผิด นี่คืออีกแทงที่ติดตามทุกอย่าง

   root (main project repo)
    |-- wordpress (repo as subtree)
    |-- wp-config.php (ignored/untracked)
    |-- wp-content 
    |    |-- plugins
    |    |    |-- my-custom-plugin (repo as subtree)
    |    |    |-- other-plugin-with-git-repo (repo as subtree)
    |    |    +-- plugin-without-git-repo
    |    |-- themes
    |    |    |-- my-custom-theme (repo as subtree)
    |    |    |-- other-theme-with-git-repo (repo as subtree)
    |    |    +-- theme-without-git-repo
    |    +-- uploads (ignored/untracked)
    +-- other-files.txt

ฉันเดาว่าข้อเสียเปรียบหลักของเรื่องนี้คือการมีไดเรกทอรีเนื้อหาแบบกำหนดเองซึ่งทำให้เกิดปัญหากับฉันในอดีตด้วยปลั๊กอินและธีมที่เขียนไม่ดีซึ่งไม่สามารถค้นหาไดเรกทอรีเนื้อหาได้