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

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

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

2.1 媒體文件

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

2.2 分類和權(quán)限

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

2.3 自定義字段

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

2.4 用戶和權(quán)限

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

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

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

2.6 標(biāo)簽和 UCM

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

2.7 格式化和模板

• CSS 格式化問題：
  • 文章的格式可能依賴于模板中的 CSS。
  • 無(wú)法期望這種格式化能夠在兩個(gè)站點(diǎn)之間自動(dòng)遷移。

2.8 擴(kuò)展和跨鏈接

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

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

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

4. 解決方案的局限性

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

5. 問題的普遍性

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

總結(jié)