Hello Brett,
Simple bug, with the 1.7 beta release. Whenever i click on the blogs plugin:
"mod/blog/everyone.php".
It shows the token error.
Regards,
Uddhava dasa
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by Raül Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
Okay turned off everything on my localpeeps.net website except captcha and userbyemail.
Install number is as above 1.7a1
usename: TahoeTahoe
pass: Spud0987
http://localpeeps.net/action/email/confirm?u=57&c=e8131cd989359d539f7e3379bc9eee71
Feel free to play with the usename and password. I have so far yet to log in a second user on both websites!! Error is the same.
No, that is not the beta. The beta is Release - 1.7b, Version - 2010012901
The URL sent in the email should be something like:
http://example.org/pg/uservalidationbyemail/confirm?u=456&c=95754b0b66ff5d8ec5a482ca3bc7a8ca
Notice it is not pointing to an action.
@TahoeBilly The validation URL shouldn't use an action. The correct URL would be something like http://localpeeps.net/pg/uservalidationbyemail/confirm?u=57&c=e8131cd989359d539f7e3379bc9eee71
Can you confirm the uservalidationbyemail plugin is the correct one from the 1.7 beta package?
@TB
Look in your Elg 1.7x dir..
If you see this -->
elgg17b\mod\uservalidationbyemail\start.php
$link = "{$CONFIG->site->url}pg/uservalidationbyemail/confirm?u=$user_guid&c=$code";
-- means you're ok
if you not see... you're fubar
just kill your *test site(s) and
reinstall 1.7b1
** from scratch
I am clearing house and reinstalling the latest, I just assumed overwriting 1.7a would work.
Okay that was the problem. 1.7b is working fine so far. I suppose upgding from one 1.7a to 1.7b wasn't what I was thinking. I will be more careful next time.
LOLZ
;-)
yepperz.. be MORE careful or ELSE...
I'm not quite sure what is causing this error, but I suppose a core of Elgg 1.7: when a new group is created, it's always with ACCESS_ID 0, no matter what access id is set in site settings. I'm investigating it, but maybe someone already has a solution?
@vazco - I cannot reproduce. In fact, if invisible groups are turned off, the access is hard coded to public: $group->access_id = ACCESS_PUBLIC;
@Cash - Next time, WARN ME when you are going to post something humorous in your post!!! I almost fell off my chair at this!:
Cash is always so straight-laced and serious, business like, in his posts! That really blind-sided me! :-D LOLZ!
- Previous
- 1
- ...
- 6
- 7
- 8
- 9
- 10
- 11
- Next
You must log in to post replies.