如何避免常見的 WordPress 主題開發錯誤

已發表: 2021-02-16

WordPress 以極其靈活而著稱，尤其是在主題和插件開發方面。 如果您想查看證據，只需詢問一組開發人員他們將如何實現特定功能。 您可能會收到幾種不同的方法來完成相同的結果。 支持論壇上充斥著此類示例。

但有了這種靈活性，現實情況也很容易以“錯誤”的方式做事。 現在，在這種情況下，“錯誤”意味著某些東西要么效率低下，要么在以後維護起來有點痛苦。 雖然它可能在功能上起作用，但通常有更好的方法來完成工作。

讓我們看看在主題開發中發現的五個更常見的錯誤，以及可以為您省去未來麻煩的替代方法。

1. 在模板中使用絕對 URL

如果您曾經查看過 WordPress 頁面或帖子生成的 HTML 代碼，您會注意到圖像和內部鏈接都使用絕對（完整）URL。 但這並不是在您的主題模板中添加代碼時完成任務的最佳方式。

例如，假設您正在開發一個使用臨時 URL 的網站。 模板中硬編碼的絕對 URL 意味著當您準備在其永久域上啟動站點時，您必須手動更改代碼。 雖然可以做到這一點，但很容易忘記這種類型的代碼可能潛伏的所有位置。

WordPress 具有確定正確 URL 的內置方法——直接從儀表板的Settings > General區域中提取。

對於鏈接，回esc_url( home_url() )將提供到主頁的完整路徑。 因此，您可以將一個簡單的鏈接添加回您的主頁，而不是顯式地將 URL 放在您的代碼中，如下所示：

 <a href="<?php echo esc_url( home_url() ); ?>" />Home</a>

此外，您還可以使用它來指向輔助頁面。 例如，如果我們想鏈接到我們網站的 About Us 頁面，我們可以使用以下代碼：

 <a href="<?php echo esc_url( home_url() ); ?>/about-us/" />About Us</a>

類似的片段也適用於圖像。 此示例從活動主題的/images/子文件夾中提取圖像：

 <img src="<?php echo esc_url( get_stylesheet_directory_uri() ) ; ?>/images/hello.png" />

2. 直接向模板添加腳本和样式

在 WordPress 中使用第三方腳本和样式是一個獨立的世界。 當您第一次開始構建主題時，您可能很想簡單地將<script>或<style>標記，甚至是 Google Font 代碼直接嵌入到主題的標題中。 這通常是靜態 HTML 網站的處理方式，所以在這裡做同樣的事情是有意義的。

但是，就像 WordPress 中的所有其他內容一樣，有更好的方法來解決它。 取而代之的是利用wp_enqueue_script()和wp_enqueue_style() ——它們為您添加腳本和样式表到正確的位置。 它還使管理資產變得更加容易，因為所有內容都是從主題的functions.php文件中調用的。

WordPress 主題手冊並沒有在這裡重新發明輪子，而是提供了有關如何正確地將腳本和样式添加到主題的出色指南。

做出明智的發展決策

3.調用jQuery的外部實例

在相關說明中，WordPress 的一個隱藏的秘密是它已經包含了 jQuery 的副本，以及幾個流行的 UI 功能。 因此，您不需要安裝 jQuery 或遠程調用它。 這使得利用流行的 JavaScript 庫和實現標籤、日期選擇器、對話框等元素變得容易。

唯一需要注意的是，您必須通過主題的functions.php文件專門啟用要使用的項目。 雖然這創造了一些學習曲線，但它也減少了臃腫。

而且，說實話，實現所需的 jQuery UI 元素並不太難。 例如，要啟用 jQuery UI 選項卡，只需將以下代碼段添加到您的functions.php ：

 function my_jquery_elements() { wp_enqueue_script( 'jquery-ui-tabs', array('jquery')); add_action( 'template_redirect', my_jquery_elements ', 10 );

這告訴 WordPress 從其現有庫中加載元素。 從那裡，設計您的選項卡並按照 jQuery UI 文檔中的說明定義它們。

4. 過度定制

添加自定義字段和自定義帖子類型的能力可以讓開發人員和網站內容編輯者的生活變得更加輕鬆。 它們提供便利、更好的內容組織和更直觀的用戶體驗。 但有時我們太過分了。

例如，我是自定義字段的忠實粉絲。 但即使是我也承認，有時我將主題定製到不靈活的地步。 字段非常適合我們確切知道需要輸入哪些內容的設置 - 例如員工個人資料的字段。

但是，當某人想要添加的內容類型不一致時，它可能會變得混亂。 客戶因在內容中存在“小”異常而臭名昭著，這會使使用自定義變得更加困難。 條件邏輯可以解決其中的一些問題，但您只能在 UI 失控之前將其處理到這麼遠。

這種類型的定制沒有硬性規定。 我們唯一能做的就是使用我們最好的判斷來確定哪些內容應該定制，哪些內容可以更好地留給 WordPress 內容編輯器甚至是小眾插件。 當我們添加字段或帖子類型時，只要知道事情可能會發生變化，並嘗試在此基礎上進行構建。

5. 沒有註釋代碼

我要在這裡再次承認：評論代碼不是我的強項之一。 不是我根本不使用評論，而是他們不是很清楚。 通常，我會指出特定項目的開始和結束，中間不會有太多的洞察力。 我應該做更多嗎？ 大概是這樣。

註釋很重要，因為它至少在代碼中提供了一些參考點。 在挖掘包含多個內容的 PHP 或 JS 文件時，您會想知道在哪裡可以找到特定項目。

即使您是唯一會編輯該代碼的人，也強烈建議您使用註釋。 例如，如果您需要在六個月後更改某些內容，那麼您不太可能記住您放置代碼片段的確切位置。

因此，我不會成為一個巨大的偽君子，並懇請您對所有內容進行深入的評論。 但我要說的是，即使是最小的努力也可以讓您或其他必須梳理您的工作的開發人員更輕鬆地進行未來的維護。

最少註釋的代碼

隨著時間的推移更好的技術

構建自己的 WordPress 主題可能是一種很棒的體驗。 但是，要掌握創建編碼良好且易於維護的主題的更精細的細節，確實需要一些很好的練習。 您獲得的經驗越多，您的技術就會發展得越多。

我可以誠實地說，我放在一起的前幾個主題遠沒有現在那麼有效。 而且我也確信，當真正的專家開發人員查看時，它們可能仍然不符合標準。 從這個意義上說，我們的進化是一個不斷的進化。

最後，我想指出，我個人犯了上述每一個錯誤。 只有通過反複試驗，以及對 Codex 的多次訪問，我才發現如何開始以“WordPress 方式”做事。

教訓是我們都會犯錯誤。 但每一個都為我們提供了學習和提高的機會。