search

barryhughes / teachblog

MU-compatible micro-blogging for students
GNU General Public License v3.0
0 stars 0 forks source link

Approval - must approve user twice to have account created #20

Open hstannard opened 10 years ago

hstannard commented 10 years ago

Created new subsite on the multi user site (www.westviewlearning.ca/WPWorkshops/sd79techmentor)

Set up the privacy for gateway Set up the form on first page Like the way it hides the internal pages. Made 3 users (Try, Hap, Blue) Showed in New Blog Requests - clicked on first, approved - same window remained. Returned to New Blog Requests - blog request still there. Click to open second - and approved it once (no change), then again and form cleared as it was suppose to. Returned to New Blog Requests - and this user was gone from list. Repeated process with other 2 and both were approved.

barryhughes commented 10 years ago

Given the usernames you tested with, is it possible that when you visit the Blog Request page you are seeing a notice at the top of the screen reading:

Please note the following problems: requested username contains special characters that should not be used in this context – try: {suitable alternative}.

But are then submitting/approving without correcting this? If so, the post will indeed be updated rather than approved and the username will be "auto corrected". Does that sound like the problem here?

hstannard commented 10 years ago

I have sometimes seen this error but not consistently. In the samples I added today without apostrophes etc in the Blog Title - no issue - so I only pressed the approve once and it was fine. will try some additional examples.

barryhughes commented 10 years ago

OK. WordPress as you'd expect sanitizes any data like usernames before accepting them into the database. What happens here, since students are suggesting there own username, is a comparison is made of the username they suggested and the same username after being passed through the sanitization filters.

If the two are the same we know they are fine - this would be true of something bland like "tommy". Something more exotic like "tommy~gun#1" would not be the same as the sanitized version and would turn out this sort of error.

In short, I think what you are experiencing is deliberate and expected - but as a further development of the plugin I could definitely try to insulate admin users from this.