Error on site creation on MLA Commons

[kfitz]

Testing MLA Commons... on https://mla.hcommons-dev.org/sites/create/ I filled in the required info (domain = "kftest"; site name = "KF Is Testing"; course site unchecked; visibility = public but discouraged). Clicked "Create Site"... and nothing appeared to happen. Clicked it a second time and got "Sorry, that site already exists" (Note that that error message is hard to spot! I'm wondering if we can make it red.)

So backed up, went with "kftest2" and "KF Is Still Testing" with other settings the same. Clicked "Create Site" and got a brief flash of the "Sorry" error, before it rolled me over to the success, here's your link page.

When I later visited the Sites listing, I saw that the originally requested site had apparently been created the first time I clicked "Create Site," but the page didn't reload (or maybe didn't reload quickly enough?) with the here's your link page. So when I clicked the second time the site did indeed already exist, because it had just been created.

[MartinPaulEve]

OK, so @kfitz, what is happening here is:

• The site is created almost instantly when you click the button. Good stuff.
• Behind the scenes, a load of plugins do a load of work to do all the custom integrations. In particular, we register with search. Here's the full trail:

1. wp_insert_site (priority 10) — hcommons_wp_insert_site() in plugins/hc-custom/includes/bp-groupblog.php:39. The DB row for the new site is inserted here, so the site exists almost immediately. For class sites it runs a direct $wpdb->query() to rewrite the domain. Fast.
2. wp_initialize_site — WordPress core does the genuinely heavy lifting here (creates the new site's tables, installs default content, switches into the blog). Then it fires the action hook, where the slow custom callbacks attach:

• IncrementalSitesProvisioner::provisionNewSite() at priority 50 — cc-client/src/Search/Provisioning/IncrementalSitesProvisioner.php:21. This is the culprit. It builds a ProvisionableSite document and calls SearchAPI::index(), which is a synchronous, blocking Guzzle POST to the Commons Connect Search API (SearchAPI.php:100).
• set_new_blog_defaults() at priority 900 (mu-plugins/more-new-site-defaults.php) — lightweight option writes.

4. wpmu_new_blog (priorities 10–20) — bp_groupblog_blog_defaults(), CommentPress install, HTTPS URL rewrite, theme switching for class sites, bbPress bbp_new_site(). These are local DB operations.
5. Post-creation side effects: BuddyPress bp_insert_site, Jetpack subsite registration, Google Sitemap option resets.

What happened was...

You clicked it. It did not work in good time, so you clicked again. The site was already created and so you got the "site exists" error.

The good news

The cause of this problem, in the short term, is that it is caused by the Dev infrastructure. This problem does not manifest on Production or Test environments. This is most likely because Dev has no Search provisioned.

Probably the best solution is to timeout quickly in cc-client so that we don't block this call if something goes wrong with Search. I have created an issue on the cc-client repository.

[kfitz]

Thanks, Martin! I’m glad this isn’t an issue on prod. One other possible “fix” I could imagine would be having some sign that the site is being created (“Working…”) that lets the user that things are happening in the background.