cPanel® Blog

Update to Recent Database Prefixing Post

First, we would like to thank everyone who has provided us with feedback on our recent blog post about database name length restrictions and database prefixing.

In response to the conversations that we have had, both online and offline, we have developed a new set of minimum delivery requirements for database users and names in cPanel & WHM version 11.44.

Minimum Requirements Expansion

  1. The setting to enforce prefixing restrictions on NEW database users and database names will be preserved. This setting will be converted from an interface in WHM (Home >> SQL Services >> Disable Database Prefix) to a tweak setting that can be enabled or disabled, and it will continue to be enabled by default.
  2. We will extend the maximum system account username length from 8 to 16 characters. However, the first 8 characters must be unique for NEW accounts in order to avoid prefix conflicts.
  3. We will allow database names and usernames to be transferred from remote systems that are NOT prefixed. We will ignore prefixing restrictions so changing users and database names will be unnecessary. This allows you to avoid changes to users’ applications.
  4. If there is a conflict between database usernames or database names during a transfer, the express transfer feature will automatically be disabled for that account (if it was requested).

These improvements to the restricted restore and transfer system are expected to increase delivery time by about four weeks. However, we may still be able to deliver the system with cPanel & WHM version 11.44 if we delay the next phase of our SSL improvements project (Spring 2014 release).

Optional Feature – Database & User Pre-Transfer Name Conflict Resolution Interface

Currently, the system appends a number to the database name (for example, database2, database3, etc.) to resolve the conflict. This is a non-interactive process, and the only indication of a conflict will appear in the transfer log.

In order to improve the visibility of this type of conflict, we could develop a new system that would allow administrators to specify new database usernames and database names when a pre-transfer conflict is detected.

  • This system would download the database usernames and database names from the remote system before the transfer begins.
  • A list of conflicting usernames and databases will display. The administrator will have the option to choose a new database name and username.

These requirements for the restricted and transfer system are expected to increase the delivery time by approximately four weeks, in addition to the minimum requirements previously listed. If these are required in order to ship the new system, then we expect the system to ship with cPanel & WHM version 11.46. Also, this would push some of the features that are already scheduled to be included in cPanel & WHM version 11.46 (Fall 2014 release) back to cPanel & WHM version 11.48 (Winter Q1 2015 release).

Please let us know if this new plan better balances your needs, and if you feel we need to include the name conflict resolution interface at the expense of delaying other features. It is our goal to offer a smoother transfer process while keeping system administration as easy as possible.


I write things. Sometimes, I edit things. Then, I publish things.

14 responses to “Update to Recent Database Prefixing Post”

  1. J. Nick Koston says:

    >2) When expanding the system account username from 8 to 16 characters, I assume >this means that the prefix on the MySQL database will still remain 8 characters, or will >that also expand to 16?

    The prefix will be the first 8 characters of the username in order to comply with mySQL’s maximum database username requirements. Please see the attached table.

    >3) What would be the reverse of this scenario, for instance, if someone tried to t>ransfer an account from a prefixed server to a non-prefixed server. Would this server >accept / ignore the prefixed database and treat it as normal?

    The prefixed database would be accepted just like any other database. The restrictions will only apply to NEW databases and database users.

  2. Kenneth Power says:

    The first 8 characters of the cPanel username.

    If the cPanel username is cpanelkenneth, then the prefix is cpanelke

    If the cPanel username is foo, then the prefix is foo.

  3. query says:

    First eight (8) characters or first 1-8 characters before the underscore (_) depending on the account name length? It is an important distinction about how it is coded.

  4. Liroy van Hoewijk says:

    Good work, much better that way.
    Agreed with others here about errors showing upon multi-account transfer functions, that would be a good idea. Remember, a lot of customers are lazy. 😛 (Nahhhh not me! I swear!)

  5. Scott Neader says:

    By the way, I really like the pre-transfer conflict resolution system idea!!

  6. Scott Neader says:

    <– slow learner. I get it now. Thanks!!

  7. electric says:

    If the only indication of a conflict and automated resolution is in the transfer log, then it is almost 100% guaranteed to be missed by the admin.

    I suggest perhaps at least adding some kind of “Completed but WITH ERROR” message or something to indicate that the transfer logs need to be reviewed manually.

    As far as pushing out the release schedule… I have no problem with that, since it comes at the benefit of improved functionality.

    Thanks for listening.

  8. Kenneth Power says:

    Hey scott, thanks for chiming in here! As this blog post outlines, we will provide both long user names (up to 16 characters) while also requiring the first 8 characters be unique among all the other usernames on the server. This provides a compromise between accomplishing the goal of providing long usernames to everyone, and preserving the prefix.

  9. Kenneth Power says:

    Removing the prefix will be optional, as it has been for 4 or 5 years.

  10. James Oakley says:

    Much, much better.

    The only caution is for when doing a transfer of multiple accounts. If the only indication of a conflict is in the transfer logs, that assumes the server admin will check the transfer logs of each one. Of course they should do that every time! But some kind of flag on the final page – the list of accounts transferred, each with a link to its transfer log – would be helpful, so that admins cannot miss the fact that there is an issue in particular accounts.

  11. Kailash says:

    This is not a good move for server administrators and this will create lots of issue when server administrator plans to consolidate their 2-3 servers in one high performance server. There is a possibility of database name conflict when we consolidate 2-3 servers.

    Currently cPanel server consolidation is an easy and straight forward but after removing database prefix, I think it will not and it will be a pain for the server administrators.

  12. Scott Neader says:

    I didn’t know about the plan to have 16 character account usernames… now I understand more about the idea to de-prefix the databases. Glad prefixes will remain an option, but also curious if that conflicts with the idea of 16 character account usernames. THANK YOU for listening to users!! cPanel rocks! (even that InfoPro guy)

  13. Hey Guys,

    I think all in all this is a step in the right direction and we appreciate the fact that cPanel does listen to its user base in regards to this.

    I’d like to throw some comments out in regards to some of the points raised.

    1) I think this will be fine, I don’t foresee much change by moving the feature to tweak settings but I do agree that it needs to remain default.

    2) When expanding the system account username from 8 to 16 characters, I assume this means that the prefix on the MySQL database will still remain 8 characters, or will that also expand to 16?

    3) What would be the reverse of this scenario, for instance, if someone tried to transfer an account from a prefixed server to a non-prefixed server. Would this server accept / ignore the prefixed database and treat it as normal?

    4) Sounds good here.


    In regards to the transfer naming resolution utility. In my opinion there is not a huge need for it immediately. I can see the benefit of having such a tool, but not to the point of delaying development to push it out in 11.44

    In my opinion if a naming conflict occurs we prefer to address this conflict on the source server, primarily because DNS is still active and the customer can make the changes before the transfer rather than after. This allows us to ensure we are indeed moving a ‘working’ site, rather than moving what we think is a working site but yet we know will be a broken site after items are renamed.

    I do suggest however some type of a log / report that can be easily accessed. Perhaps a ‘important transfer information’ button that will provide you a list of transfers you can select from. This report would include basic information about the entire transfer, but also would need to include something simple that a technician could copy and paste to a customer. Such as a list of changes.

    Account bob renamed to bob2
    MySQL db bob_wordpress renamed to bob2_wordpress

    This would let the techs easily inform the customer of what has changed so the customer can make the code edits.

    All in all this is a step in the right direction and I see the merits for a conflict resolution system, it’s just that we hardly encounter this situation here so I wouldn’t delay production over it. Others may have different experiences but for us it wouldn’t be a deal breaker.

    Thanks for keeping an ear out for the community.

    Daniel C Pearson

Leave a Reply