1. 內(nèi)容定義的模糊性

• 問題的起點：內(nèi)容的定義非常寬泛（loose），這導致了許多問題（a source of a lot of grief）。
• 嘗試定義內(nèi)容：假設(shè)將內(nèi)容定義為“由 Joomla! 內(nèi)置的文章組件（com_content）管理的任何文章”。這個定義看似合理，但實際上并不充分，因為它忽略了內(nèi)容的復雜性和多維度。

2. 內(nèi)容的復雜性

2.1 媒體文件

• 媒體文件的多樣性：
  • 文章可以包含一個或多個媒體文件（如圖片、視頻）。
  • 有些媒體文件可能通過“媒體字段”（如文章縮略圖和正文圖片）鏈接到文章，這些容易被識別。
  • 其他媒體文件可能嵌入在 HTML 內(nèi)容中，可能有或沒有元數(shù)據(jù)，這使得程序化發(fā)現(xiàn)變得困難。
• 文件的歷史問題：
  • 文件不是數(shù)據(jù)庫記錄，沒有歷史記錄，因此無法確定它們是新增的、修改過的還是之前就存在的。
  • 如果遠程站點（site B）與本地站點（site A）不在同一網(wǎng)絡(luò)中，就無法知道遠程站點是否也有這些文件。

2.2 分類和權(quán)限

• 分類的復雜性：
  • 文章屬于分類，分類有訪問級別和權(quán)限，這些權(quán)限依賴于用戶組。
  • 無法確定兩個站點上是否存在相同的分類、訪問級別和用戶組，也無法確定它們的 ID 映射關(guān)系。
• 權(quán)限的復雜性：
  • 用戶組是組件級別基礎(chǔ)權(quán)限的容器，每個分類都可以為每個用戶組提供不同的權(quán)限。
  • 這使得權(quán)限管理變得極其復雜，尤其是當分類和用戶組的層級結(jié)構(gòu)不同。

2.3 自定義字段

• 自定義字段的復雜性：
  • 文章可以有自定義字段，這些字段可以屬于自定義字段組。
  • 自定義字段和字段組與特定組件和分類相關(guān)聯(lián)，而每個自定義字段的值又與特定文章相關(guān)聯(lián)。
  • 這導致了多維度的復雜性，很難確定哪些內(nèi)容是新增的或修改過的，尤其是在無法與遠程站點通信的情況下。

2.4 用戶和權(quán)限

• 用戶和權(quán)限的關(guān)聯(lián)：
  • 文章、分類、自定義字段等都與用戶相關(guān)聯(lián)，因為 Joomla! 需要知道誰創(chuàng)建、修改或簽出了這些內(nèi)容。
  • 兩個站點之間沒有用戶映射關(guān)系，也無法查詢遠程站點的用戶信息。

2.5 權(quán)限存儲問題

• 權(quán)限存儲的復雜性：
  • 權(quán)限存儲在 #__assets 表中，這是一個樹形結(jié)構(gòu)。
  • 無法直接將一個站點的權(quán)限記錄移植到另一個站點，即使有完整的分類、用戶組、訪問級別和用戶 ID 映射，也需要定制代碼來處理。

2.6 標簽和 UCM

• 標簽的復雜性：
  • 標簽不是以文本形式存儲，而是以 ID 形式存儲。
  • 需要知道每個站點上哪些標簽 ID 對應(yīng)哪些標簽文本，才能確定是否有新增或修改的標簽。
• UCM 的復雜性：
  • Joomla! 有一個名為 UCM（Universal Content Model）的輔助結(jié)構(gòu)，用于處理標簽、歷史記錄和智能搜索。
  • 需要知道 UCM 的狀態(tài)和屬性，這些屬性不會出現(xiàn)在用戶界面中，但可能會影響內(nèi)容的變更。

2.7 格式化和模板

• CSS 格式化問題：
  • 文章的格式可能依賴于模板中的 CSS。
  • 無法期望這種格式化能夠在兩個站點之間自動遷移。

2.8 擴展和跨鏈接

• 擴展內(nèi)容的復雜性：
  • 文章可能包含來自其他擴展的內(nèi)容，例如跨鏈接到特定菜單項、組件的深層鏈接、插件短代碼或嵌入模塊。
  • 確定哪些內(nèi)容是新的或修改過的，需要分析兩個站點上安裝的所有擴展及其內(nèi)容定義。
  • 這幾乎是不可能的，因為每個擴展都需要定制代碼來處理。

3. 跨站點內(nèi)容遷移的困難

• 問題的演變：
  • Joomla! 1.5 時，內(nèi)容遷移相對簡單，只要處理媒體文件、分類名稱匹配和站點間通信即可。
  • Joomla! 1.6 引入了自定義權(quán)限、用戶組、訪問級別和嵌套分類，問題變得更加復雜。
  • Joomla! 3.2 引入標簽后，問題進一步復雜化。
  • Joomla! 3.7 引入自定義字段后，確定哪些內(nèi)容是新的或修改過的變得完全不可預(yù)測，使得開發(fā)可用的解決方案變得幾乎不可能。

4. 解決方案的局限性

• 人工處理的必要性：
  • 由于內(nèi)容的定義和變更檢測是非確定性的，人工手動決定哪些內(nèi)容是新的或修改過的，并手動在兩個網(wǎng)絡(luò)隔離的站點之間遷移，可能是唯一可行的方法。
• 完整克隆的局限性：
  • 如果只需要站點 A 的完整克隆，可以備份整個站點并恢復到站點 B，但這需要手動傳輸備份文件，因為站點 B 的網(wǎng)絡(luò)與互聯(lián)網(wǎng)完全隔離。

5. 問題的普遍性

• 其他 CMS 的類似問題：
  • 這個問題不僅存在于 Joomla!，WordPress 也存在類似問題。
  • 作者推測，基于 Drupal 的內(nèi)容組織方式（內(nèi)容圖節(jié)點）和對 Drupal 7 的了解，Drupal 也可能存在類似問題。
• 內(nèi)容管理的普遍挑戰(zhàn)：
  • 一旦內(nèi)容不僅僅是簡單的文本，而是包含多種元素（如媒體文件、自定義字段、權(quán)限、標簽等），確定什么是內(nèi)容以及它是否發(fā)生了變化就變得越來越困難。

總結(jié)