tarun80

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 8 years, 5 months ago by tarun80.

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.

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.