[wp-trac] [WordPress Trac] #30932: Store blacklist_keys in a separate table

[WordPress Trac]

#30932: Store blacklist_keys in a separate table
-------------------------+-------------------------------------------------
 Reporter:  ott          |      Owner:
     Type:  feature      |     Status:  new
  request                |  Milestone:  Awaiting Review
 Priority:  normal       |    Version:  4.1
Component:  Comments     |   Keywords:  blacklist_keys moderation keys
 Severity:  minor        |  blocklist
  Focuses:               |
-------------------------+-------------------------------------------------
 WordPress stores moderation keys in the options table as the
 `blacklist_keys` option. When a comment is tested for blocked characters
 or words it fetches the entire contents of the `blacklist_keys` option and
 does a case insensitive sub-string comparison of each line against the
 author, email address, URL, comment, IP address and user agent. Obviously,
 this is a linear search and takes at least O(n) time to search the
 blocklist and O(n) memory to keep it in memory. The
 [https://github.com/splorp/wordpress-comment-blacklist wordpress-comment-
 blacklist] blocklist has 16124 entries and takes at least 180 KiB to store
 in memory. So neither the comparison or the memory requirements are
 negligible for larger sites. The option `blacklist_keys` was most likely
 never designed to store such big blocklists and is rather meant to for
 blog owner to manually block certain words.

 WordPress could instead store the entries of `blacklist_keys` in a
 separate database table and search it in O(log n). Is there a chance that
 this feature is added to WordPress in one of the next versions or should
 it be implemented as a plugin?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30932>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform