Title: Plugin does not honor database settings
Last modified: September 13, 2016

---

# Plugin does not honor database settings

 *  Resolved [tarun80](https://wordpress.org/support/users/tarun80/)
 * (@tarun80)
 * [9 years, 8 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/)
 * Noticed a few things when looking over my database.
 * **1.** Cerber does not prefix itself in the database. That is, it does not add
   a wp_cerber_* type of table, it simply adds cerber_*. (* is covering the different
   names like logs, etc.)
 * **2.** The collation is set to “utf8_general_ci” rather than the one set with
   WordPress which is “utf8mb4_unicode_520_ci” by default.
 * Aside from those two minor issues this is a fantastic plugin.
 * An option to completely disable the WHOIS lookup would be nice, too. Or perhaps
   offer a clickable link/button to request the WHOIS information for that one row
   in it’s place. Hope that makes sense, if not I can clarify.
 * Thanks!

Viewing 14 replies - 1 through 14 (of 14 total)

 *  Plugin Author [gioni](https://wordpress.org/support/users/gioni/)
 * (@gioni)
 * [9 years, 8 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8181372)
 * Hi tarun80!
 * Sorry, word honor is not applicable here.
 * 1. Tables is not prefixed intentionally. First of all, it gives ability to manage
   and protect multi site installations as whole. Secondly, the plugin tracks all
   attempts comes from “bad guys” in one shared, common table. That allows to block
   IP addresses globally on every site in multisite installation. Thirdly, network
   administrator can manage IP Access List for all sites in one place only. There
   is only one disadvantage: users are unable to backup and restore IP Access Lists
   if they have ones, but know nothing about DB schema. They should manually add
   table CERBER_ACL in a list of tables that will be backed up and restored.
 * 2. Collation utf8_general_ci is more than enough to work as intended and properly
   in any DB. Possibly there may be some issues with Japanese/China languages in
   context of lockouts explanations column on lockouts screen, but no functionality
   may be involved here.
 * 3. To disable WHOIS uncheck **Drill down IP** option in the main settings of 
   the plugin.
 *  Thread Starter [tarun80](https://wordpress.org/support/users/tarun80/)
 * (@tarun80)
 * [9 years, 8 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8184706)
 * **1.** I’d like to at least have an option to have my database table prefixed.
   I believe it makes it much neater and allows you to know what it’s associated
   with. Example: jos_ for Joomla, drupal_ for Drupal, etc. This allows for the 
   database to be kept tidy and organized.
 * Another example would be if there is a multisite and your plugin is also covering
   the main site. They use a test site/install and want to test a beta version of
   your plugin or user made modifications. That could potentially wipe the entire
   site if something goes wrong.
 * I personally use a local test/dev environment to see how it goes. Separate databases
   and all so nothing touches my live site or risks taking it down.
 * I do hope you can add that option.
 * **2.** Why not honor the settings that WordPress is using? A clean install of
   WordPress shows it’s currently using: utf8mb4_unicode_520_ci. I believe a plugin
   should honor those settings for consistency. utf8_general_ci seems to be frowned
   upon moreso than in the past, what with emojis and all the other characters, 
   etc. now available for use.
 * **3.** Must be a bug, mine is unchecked and it still performs a WHOIS on every
   entry.
 *  Plugin Author [gioni](https://wordpress.org/support/users/gioni/)
 * (@gioni)
 * [9 years, 8 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8187513)
 * 1. Probably it’s reasonable. I agree with you. But it will be a PHP constant 
   definition.
    2. Why I should honor (and track all changes) some setting that 
   I do not use anywhere? Should I waste my time on that? Sorry, no. Just for consistency?
   Sorry, no. I can change it only for compatibility with Japanese/China languages.
   3. If you mean Hostname column, yes you cannot disable it for now. If no, please
   explain me where do you get WHOIS requests?
 * Anyway, thanks for your arguing!
 *  Thread Starter [tarun80](https://wordpress.org/support/users/tarun80/)
 * (@tarun80)
 * [9 years, 8 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8187725)
 * **1.** Thank you for taking the prefix option into consideration. That may be
   helpful for some who use a single database for multiple entries. I was just thinking,
   I’ve seen Mediawiki plugins sometimes not do prefixes so that can also add to
   confusion for some.
 * **2.** I may test it on my dev environment by manually switching the collation
   and seeing how it performs.
 * **3.** Yes, it was the hostname column.
 *  Plugin Author [gioni](https://wordpress.org/support/users/gioni/)
 * (@gioni)
 * [9 years, 7 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8262816)
 * Why do you need to disable Hostname column?
 *  Thread Starter [tarun80](https://wordpress.org/support/users/tarun80/)
 * (@tarun80)
 * [9 years, 7 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8264923)
 * Because it takes time to resolve each entry? I’d rather have it on demand instead
   of resolving something I may not really care about.
 * Also, another thing pertaining to the database. The type is MyISAM, whereas all
   of WordPress uses InnoDB. Which means the tables have to be watched and occasionally
   optimized if you’re dealing with a lot of brute force attempts.
    -  This reply was modified 9 years, 7 months ago by [tarun80](https://wordpress.org/support/users/tarun80/).
 *  Plugin Author [gioni](https://wordpress.org/support/users/gioni/)
 * (@gioni)
 * [9 years, 7 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8266250)
 * What is time? How much is it take? Sending UDP request to closest DNS server?
   Plus, how often do you check Activity log? Please, admit this column as is for
   now.
 * WP used MyISAM tables all the time, probably up until now. I do not track in 
   details all changes in the WP tables. Anyway, I don’t see any reason to use InnoDB
   tables for such kind of application.
 *  Thread Starter [tarun80](https://wordpress.org/support/users/tarun80/)
 * (@tarun80)
 * [9 years, 7 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8266843)
 * Time can vary between 5-20 seconds. Checked by counting myself and with Inspect
   Element -> Network in Firefox.
 * The tables Cerber uses should be based upon the values that WP itself uses. If
   WP is using InnoDB, so should Cerber. If WP is using table prefixes, so should
   Cerber unless you specifically have an option asking if it’s a multi-site install.
 *  Plugin Author [gioni](https://wordpress.org/support/users/gioni/)
 * (@gioni)
 * [9 years, 7 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8282908)
 * Resolving host names doesn’t consume noticeable amount of server resources. Please,
   admit Hostname column as is. That is not the task that someone needs to pay attention
   to. Secondly, there is no any technical reason or goal for having DB tables based
   on “WP values”.
 *  Thread Starter [tarun80](https://wordpress.org/support/users/tarun80/)
 * (@tarun80)
 * [9 years, 7 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8290971)
 * Having to wait 20 seconds for it to finish loading is an issue. Especially when
   the setting to resolve the IP addresses has been unchecked, that was the reason
   I unchecked it. Because I did not need every single IP address to be resolved.
 * Then can you explain why it’s somehow acceptable to not use the same collation
   and database type for the tables of your plugin?
 * InnoDB performs better than MyISAM and also does not need to be optimized to 
   get rid of overhead. When you get a lot of brute force attempts and the logs 
   are regularly cleaned out, yet no optimization occurs, the overhead adds up especially
   on large websites. This is why it should honor what WordPress sets forth in the
   config.
 * utf8mb4_unicode_520_ci allows for any type of character to be recognized, which
   is a plus. Considering WordPress is a multilingual CMS, being able to support
   any and all characters is a plus, too. Accuracy and performance are two more 
   major benefits to using a good collation over the older generic utf8_general_ci.
 * If you’d like to learn more about it, this [stackoverflow](http://stackoverflow.com/questions/766809/whats-the-difference-between-utf8-general-ci-and-utf8-unicode-ci)
   is a great read.
 *  Plugin Author [gioni](https://wordpress.org/support/users/gioni/)
 * (@gioni)
 * [9 years, 7 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8303113)
 * Great explanation, thanks! You don’t need to wait some seconds for loading because,
   as you definitely noticed, name resolving operations performs independently via
   background AJAX requests. Once per page. So, you can navigate through Activity
   log pages without any delay. Don’t you?
    Secondly, my code cache every resolved
   IP address for up to 24 hours by using WordPress transients. So, sometimes you
   will barely notice several log lines with unresolved names. Mentioned option 
   named “Retrieve extra WHOIS information for IP”. Sorry, that means extra info,
   no just single name.
 * I agree with you on overhead and fragmentation of MyISAM tables. That’s an issue.
   In some circumstances it would be right to use InnoDB engine that I prefer to
   use too, anyway. But in this particular case we have write-intensive plugin, 
   especially in the case of intensive brute force attacks. Every login related 
   activity stores as a row in the log table with an index. When it comes to writing,
   InnoDB is slower then MyISAM due to transaction mechanism and more intensive 
   I/O operations. Do not forget about constantly rebuilding index. So, using InnoDB
   will decrease performance of the plugin. This is a cost of using InnoDB that 
   you need to accept.
 * Having older generic encoding utf8_general_ci doesn’t affect any of the plugin
   functionalities. It is possible that some Asian languages messages in the Dashboard
   will be displayed incorrectly. Nothing more. But using modern encoding can be
   cause of a problem with outdated MySQL servers. So I will use encoding safely
   and upgrade encoding in the 2017.
 *  Thread Starter [tarun80](https://wordpress.org/support/users/tarun80/)
 * (@tarun80)
 * [9 years, 7 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8304344)
 * Quite welcome.
 * Perhaps it can be a new option to disable the DNS resolution completely? Or somehow
   make it a link that says click to resolve, and the resolves it in the current
   fashion for that row?
 * Looking into the differences with MyISAM and InnoDB I completely understand why
   it’s set up what way. The speed and efficiency, plus the difference in resources
   plus full text search.
 * Encoding changes sounds good as well, looking forward to it.
 * Thank you for the excellent discussion. 🙂
 *  Plugin Author [gioni](https://wordpress.org/support/users/gioni/)
 * (@gioni)
 * [9 years, 5 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8537669)
 * Hi tarun80!
 * In the last version I added MyISAM table optimization query. So, we’ve got rid
   of MyISAM overhead now.
 *  Thread Starter [tarun80](https://wordpress.org/support/users/tarun80/)
 * (@tarun80)
 * [9 years, 5 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8539094)
 * I see, checking out all the nice new things now. Love the addition of reCaptcha.
   That reduces the number of plugins I need.

Viewing 14 replies - 1 through 14 (of 14 total)

The topic ‘Plugin does not honor database settings’ is closed to new replies.

 * ![](https://s.w.org/plugins/geopattern-icon/wp-cerber_77a9bf.svg)
 * [WP Cerber Security, Anti-spam & Malware Scan](https://wordpress.org/plugins/wp-cerber/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/wp-cerber/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/wp-cerber/)
 * [Active Topics](https://wordpress.org/support/plugin/wp-cerber/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/wp-cerber/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/wp-cerber/reviews/)

## Tags

 * [bugs](https://wordpress.org/support/topic-tag/bugs/)
 * [collation](https://wordpress.org/support/topic-tag/collation/)
 * [database](https://wordpress.org/support/topic-tag/database/)
 * [utf8](https://wordpress.org/support/topic-tag/utf8/)
 * [utf8mb4](https://wordpress.org/support/topic-tag/utf8mb4/)

 * 14 replies
 * 2 participants
 * Last reply from: [tarun80](https://wordpress.org/support/users/tarun80/)
 * Last activity: [9 years, 5 months ago](https://wordpress.org/support/topic/plugin-does-not-honor-database-settings/#post-8539094)
 * Status: resolved