[WordPress] 外掛分享: No Slug Conflicts with Trash

首頁外掛目錄 › No Slug Conflicts with Trash
WordPress 外掛 No Slug Conflicts with Trash 的封面圖片
10+
安裝啟用
★★★★★
5/5 分(2 則評價)
3570 天前
最後更新
問題解決
WordPress 3.5+ v1.2 上架:2013-11-25

內容簡介

注意:WordPress 4.5 已將此外掛的功能整併到其中,因此除非您仍在運行舊版本的 WP,否則不再需要使用它。

此外掛的實作基於一個信念,即垃圾桶內的網頁或文章不應該在網址別名方面與新網頁或文章有任何衝突。基本上,新的網頁或文章應當優先於所有在垃圾桶內的內容。畢竟,這些網頁或文章是被放到垃圾桶內的,理應有其原因。

預設情況下,WordPress 在判斷新文章的別名是否已被使用時,會盤算之前已被移至垃圾桶內的文章和網頁。當然,在一般情況下,WordPress 不應該允許重複的別名,因為這可能會影響永久連結。WordPress 的處理方案的考量在於,被放到垃圾桶內的文章/網頁在技術上仍存在,但不能夠直接存取。作者或管理員可能希望將其從垃圾桶中恢復,那麼 WordPress 認為該文章/網頁應再次使用與被刪除之前相同的永久連結。

如果您仍不明白 WordPress 的做法,這裡舉個例子: WordPress 附帶了一個名為 "About" 的網頁,其別名為 "about"。該網頁的 URL 是 http://yoursite/about/。現在,假設您將這個網頁刪除,並建立了一個新的名為 "About" 的網頁。由於垃圾桶內有一個與新網頁相同的別名( "about"),新網頁因此被分配了 "about-2" 的別名,導致該網頁的 URL 成為 http://yoursite/about-2/。使用此外掛,新的 "About" 網頁將獲得希望的 "about" 別名。

另外,此外掛會嘗試將已還原的文章恢復到其原始的別名。唯一失敗的情況是,如果新的網頁或文章使用了原來在垃圾桶內的文章/網頁的別名,此外掛就無法完成恢復操作,而必須將該還原的文章/網頁分配一個新的別名。

有關此外掛功能更多深入的解說,請參閱文件中的其他章節。欲瞭解更多此問題的討論,請參閱 WP 核心 "ticket #11863"。

相關連結:此外掛首頁、此外掛目錄頁、作者首頁。

解決方案的詳細解釋

由此外掛採用的方法概述,以解決別名可能與垃圾桶內文章發生衝突的問題。

WordPress 原始行為

為了理解實現解決方案的核心,以下簡單說明 WP 的唯一別名處理方式:

在發布之前,所需的別名會傳遞到 wp_unique_post_slug() 並返回一個安全的別名。如果任何現有的文章(包括垃圾桶內的文章)使用該別名(或者不適合 URL 永久連結,如 RSS 資源或輸出彙整),則可能導致使用的安全別名與所需別名不同。

為避免垃圾桶內文章的別名與新文章發生衝突,此外掛採用了其中兩個主要任務:

1. 允許文章使用與垃圾桶內文章相同的別名

此外掛會 hook 上 ‘wp_unique_post_slug’ 过滤器。如果所需的別名與安全別名相同,則所需的別名是唯一的,不需要進行其他處理。

如果兩個別名不同,那就必須判斷衝突是否是由於垃圾桶內的文章引起的。因此,此外掛嘗試查找是否有一篇名為該別名的已經被放到垃圾桶內的文章。

如果沒有這樣的垃圾桶內文章,衝突就是出現在一篇目前進行中的文章上(或之前完全刪除的文章上,這種情況很少發生),因此這篇文章不能使用所需別名。
如果找到了名為該別名的垃圾桶內文章,則所需的別名是希望配置給新文章的。為此,此外掛從 DB 中刪除所找到的垃圾桶內文章(而不是將其完全刪除),以便新文章可使用希望的別名。

2. 確認所有還原的文章都使用原本的別名

此外掛會監聽 WordPress 中垃圾桶功能的行爲,在垃圾桶中的文章還原的時候,它會嘗試將這篇文章的別名還原為原始別名。唯一失敗的情況是,如果新的網頁或文章使用了在垃圾桶內的文章的原始別名,此外掛就無法還原該文章的別名,必須為其分配一個新別名。

如果還原的文章與現有文章衝突(即,現有文章使用了被還原文章原始的別名),則無法進行還原。因此,必須將該還原文章分配一個新的別名。

外掛標籤

開發者團隊

⬇ 下載最新版 (v1.2) 或搜尋安裝

① 下載 ZIP → 後台「外掛 › 安裝外掛 › 上傳外掛」
② 後台搜尋「No Slug Conflicts with Trash」→ 直接安裝(推薦)
📦 歷史版本下載

原文外掛簡介

NOTE: WordPress 4.5 incorporated the functionality of this plugin and thus it is no longer needed unless you’re still running an older version of WP.
This plugin implements the belief that a trashed page or post should not in any way conflict with a new page or post when it comes to slugs. In essence, a new page or post should take precedence over anything in the trash. After all, the page/post is in the trash for a reason.
By default, WordPress takes into consideration posts and pages that have been trashed when deciding if the slug for a new post is already in use. Obviously, in general, WordPress should not allow duplicate slugs because that could interfere with permalinks. The thinking behind WordPress’s handling of the situation is that trashed posts/pages are still technically present, just inaccessible. It is possible that an author or admin would choose to restore a post from the trash, which WordPress feels should then occupy that same permalink as before it was trashed.
If what WordPress does is unclear, here’s an example to help clarify things:

WordPress ships with a page called “About” with the slug of “about”. The page’s URL would be http://yoursite/about/
Let’s say you trash that page and start a new page with the name “About”.
Due to a trashed page having the slug that would normally have been assigned to the new page (“about”), the new page gets the slug of “about-2”, resulting in the page’s URL being http://yoursite/about-2/

With this plugin, for this example, the new “About” page would get the slug “about” as one would hope.
That said, the plugin tries its best to restore untrashed posts to their original slug. The only time it fails to do so is if a new page or post has claimed the trashed post’s original slug, in which case the untrashed post is assigned a new slug.
See other sections of the documentation for more insight into the plugin’s functionality. See WP core ticket #11863 for discussion on the matter.
Links: Plugin Homepage | Plugin Directory Page | Author Homepage
The Solution Explained
An overview of the approach employed by the plugin to resolve the issue of slugs potentially conflicting with posts in the trash.
What WordPress does
In order to understand the crux of the implemented solution, a quick refresher on unique slug handling by WP:
Before published use, a desired slug is passed to wp_unique_post_slug() and a safe slug is returned. The safe slug may differ from the desired slug if any existing post (including a trashed post) has that slug (or, less likely, is invalid for permalink reasons such as feeds or date archives).
In order to prevent a trashed post’s slug from conflicting with a new post, this plugin takes an approach that is comprised of two primary tasks:
1. Permit a post to use a slug that conflicts with a trashed post.
The plugin hooks the ‘wp_unique_post_slug’ filter. If the desired slug matches the safe slug, the desired slug is unique and nothing needs to be done.
When the two slugs don’t match, it has to determine if the conflict is due to a trashed post or not, so it attempts to find a trashed post with the desired slug.

If no such trashed post is found, the conflict is with a live post (or was an otherwise unsuitable slug) so the safe slug must be used by the new post (so, again, nothing needs to be done).
If such a trashed post is found, then the plugin simply inverses the traditional behavior of wp_unique_post_slug(): give the trashed post the safe slug and return the desired slug for use by the new post (rather than having the trashed post retain its slug and forcing the new post to use the safe slug). In order to be able to restore a trashed post to its original slug, the trashed post’s original slug is stored in postmeta.

2. Restore a trashed post to its original slug, if necessary and possible.
For a post transitioning away from the ‘trash’ post status, check to see if its slug was rewritten (denoted by the presence of the postmeta field only assigned if the original slug was changed due to a conflict while the post was in the trash).
If there was no original slug, the slug was never changed and nothing more needs to happen.
When there is an original slug, check to see if that slug is still in use by a non-trashed post.

If not, restore the post slug to the original value.
If so, there is no recourse but to leave the post slug as-is (it is guaranteed to be unique already).

In either case, the postmeta field for the original slug value gets deleted since the now untrashed post is exposed in some fashion with its current slug and should abide by it going forward.

延伸相關外掛

文章
Filter
Apply Filters
Mastodon