Bug #4200
closed
Create a Site, Error Message
Added by Samantha Raddatz over 9 years ago.
Updated about 9 years ago.
Assignee:
Samantha Raddatz
Category name:
Blogs (BuddyPress)
Description
When creating a new site, there is no indication of whether a domain name is already being used. In order to find out if the chosen name is available, the user has to submit the form. The page that loads has two lines indicating a problem, the first simply says there was a problem with the form and the second tells the user that the site already exists. Both appear in the same font, color and text size as the rest of the lines on the page, so the error is not obvious.
Bold and make this text red to make the error message more apparent to the user.
Files
- Tracker changed from Bug to Design/UX
- Category name changed from User Experience to Blogs (BuddyPress)
- Status changed from New to Assigned
- Assignee changed from Boone Gorges to Daniel Jones
- Target version set to 1.9
Dan, can you try to make this more beautiful? If you really wanted to get fancy, you could do some realtime checking (via ajax) of the availability of a domain. There's probably an existing plugin you could steal this from. It would also be a decent improvement for BuddyPress.
Think I've got a solution here: https://github.com/cuny-academic-commons/cac/commit/de7d819f3a1ed51d0cf0266f620c61c3d5801f08
I decided to go with an AJAX check, which I added to a JS function that was already hooked to every keystroke on the URL for blog creation pages (both in and out of groups). I didn't end up messing around with the errors, and instead just disabled the forms when the entered URL wasn't unique. I add the error in red text beneath the URL field.
Let me know if this works!
Looks pretty good - thanks, Dan! A couple small things -
- Use die() instead of wp_die() here. wp_die() shows an HTML page, which we don't want to send as part of the AJAX request.
- Make sure you check `isset( $_GET['url'] )` before setting it to a variable, or you'll fill our error logs :)
- We can save some overhead by passing `false` to the second argument of `get_blog_details()`
- We shouldn't be running AJAX requests on every keyup - we're going to DOS ourselves ;) I'd suggest moving this stuff out of check_blog_name() and into its own callback, which should be triggered on blur, or after 1000 milliseconds of no typing, or something like that.
This looks great, Dan. The one UI suggestion I'd make is as follows. If you enter a bad address, the "Sorry" message appears. If you then go back and change to a new address, the "Sorry" message sticks around until after the AJAX request has completed, which could be a second or two. This feels a little confusing. Can we hide the message as soon as the user starts editing the bad address? Like maybe an onfocus event, so that clicking back into the text field to edit will make it go away?
Yep that makes a lot of sense to me! What I did here: https://github.com/cuny-academic-commons/cac/commit/d7f5557fafefda7d7defd7bbd0084d6ba6ca790b is remove the error message on focus, but still leave the form disabled, so that way someone can't just click back into the input and press enter and find the old confusing error messages. So they'll still have to click away from the input for it to check to see if the URL is unique and re-enable the form. Does that sound alright?
- Assignee changed from Daniel Jones to Samantha Raddatz
This looks great, Dan - thanks!
Sam, I'm assigning this to you so that you can review the changes for flow. I've pulled them to cdev so you can play with it.
I tried to create a new group and group site to see the changes here, but it wouldn't let me click 'Next step' on the Settings page (step 2) to continue.
Oops you are quite right Sam! I think I fixed the problem now.
Hi Dan, that button is still not working for me... tried it on Chrome, Safari, and Firefox.
Nice update, this problem seems to be working now on cdev.
- Status changed from Assigned to Resolved
Looks like we're good here.
Also available in: Atom
PDF
