EdbMails supports the migration of mailboxes between different Office 365 tenants, which can be useful for organizations. You can migrate source Office 365 mailboxes to target Office 365 as well as live Exchange. You can also export the mailboxes to PST.
The solution helps migrate individuals as well as multiple mailboxes of any size and scale. It supports an Incremental migration feature that avoids duplicate items on the target mailboxes.

Why Office 365 Migration?

EdbMails provides plenty of advanced features for the successful migration of your Office 365 mailboxes. It simplifies the entire migration process, thus makes you achieve significant time and cost-saving.

Key Features

• Simple and Easy to use.
• Fast and Secure Data Migration.
• Automatic Mailbox Mapping.
• Supports all languages and Unicode Migration.
• Supports Multi-Factor Authentication.
• Incremental migration with no duplicate data.
• Supports selective mailbox items migration.
• Handles Office 365 throttling and connection interruption during migration.
• Supports individual as well as batch-wise mailbox migration.
• Supports migration to Hosted Exchange Server.

To Know More Visit: https://www.edbmails.com/pages/office-365-migration-tool.html

The article is here: https://www.cloudways.com/blog/gutenberg-wordpress-custom-post-type/

The fix is in the comment by John Laprairie who provides an extended list of array values for 'supports'.

In particular, at least the 'title' value is required or when a new CPT is added, there will be no 'Add Title' field in the Gutenberg editor and no way to add a title for the CPT.

It's easy to overlook the correct comment and simply use the code in the article with the expectation that it should work, without having to spend considerable time debugging. Maybe there has been an update to Gutenberg which requires the 'title' value, after this article was initially written 11 months ago.

The article was written February 11, 2019 , the comment with the correct code was written 5 months ago (August 2019). IMHO it's a pretty poor show that it is still not corrected in January 2020 and isn't on a par with other articles I have read on Cloudways.

BTW, this 'feedback' subdomain appears not to have a SSL certificate. Just sayin'.

Hi

I notice that recently you have put in place tools which force a strong username and password for staging sites. Previously the username and password could be anything at all.

I'd like to suggest that you should roll back this change. Although (of course!) I am wholly in agreement that passwords should be strong in almost all cases, I believe that staging sites should have an option for this not to be the case.

Why?

1. Mainly - because the most obvious use case here is for sharing with a client. Whereas we could previously have for instance "demo" and client name as u/p (easily memorable both for us and for clients) - now we have to create and constantly re-share passwords when the client can't remember how to get in

2. Password managers don't normally offer the option to save popup NTCR-style passwords like this so we have to resort to logging into the CloudWays interface to see what is set

3. The actual thing that is being passworded isn't very sensitive - and actually shouldn't be. A staging site is almost always just a copy of a live site where tech changes have been made. In our case, the only reason for passwording it in the first place is that we don't want Google and other bots spidering it - it isn't sensitive at all.

4. If you left this option so that you had a warning there about weak passwords - "Are you SURE you don't want a strong password for this?" then IT people like myself can make a call on whether to set it as strong or weak, depending on use case. Mandating it in the way you do is preaching to an already tech-savvy audience!

Regarding Cloudways' account verification process, please consider changing this system. I can no longer suggest my clients to use a company that doesn't put the server online within the hour. A 24-48 hours time period to get the server online it's nonsense. You guys really need to figure out another way to do this faster and easier. Also, to send documents for account verification by email is very rudimentar, I don't see this method for account verification anywhere else. Maybe upload documents on the website? Maybe let user know how long it will actually take to get the server online? Maybe verify the account within the hour? Many things to improve there in my opinion.