Ok, Did you install a language pack? Did you edit the language file? On the re-validation email there should be a validation link. Probably you edited it by mistake

Rodolfo Hernandez

Arvixe/Elgg Community Liaison

As I said there is no link in the re-validation e-mail...just instructions to reply. We are going to look into upgrading the site to a newer release of the 1.7 branch. Looks like there are some issues with e-mail validation on older builds.

To my knowledge we have not installed any language packs or edited the language file.

What version of 1.7 are you on? Please report back if upgrading to the latest solves the problem.

Also, in version 1.8 users are no longer un-validated when they change their email addresses.

All you need to change is the first path. You can run this as raw SQL from PHP MyAdmin and it will be fine.

This is using a few subqueries to make the change in one very confusing go. It's the same as saying these separate queries:

$dir_root_name_id = SELECT * FROM elgg_metastrings WHERE string = 'filestore::dir_root';

$dir_root_value_id = SELECT value_id FROM elgg_metadata WHERE name_id = $dir_root_name_id;

UPDATE elgg_metastrings SET string = '/srv/www/vhosts/envirn_data/' WHERE id = '$dir_root_value_id';

"Update the metastrings table where the ID is the value_id for metadata with the name_id of 'filestore::dirroot'"

If it's still not working, make sure you have trailing slashes on all of your paths and the permissions are correct on the data path. What error does it give when trying to upload something?

One of my wild stabs in the dark with SQL must have worked, hence the "Rows Changed:0" response. This was a multi-layered problem. Firstly, the filestroe data directory path wasnt changed in the db. Secondly...the user was trying to upload a file that was WAY too large. So the first time around the Apache error logs were saying the directory could not be found (still referencing the data root on the OLD Webserver). Once this was resolved the Apache logs revealed the allowed memory size was being exhausted.

The file the user was uploading was only 800k or so, but was a BIG jpeg when un-compressed. PHP was gacking on it...and once I reduced to a reasonable size we were able to upload it just fine.

Still a novice at interpreting Apache error logs, but they pointed me in the right direction and I was able to muddle through it.

@Brett - Thank you for explaining how those SQL commands were "nested". It makes more sense when I see it broken down into seperate queries. I think its interesting that its called a querry, when in fact you aren't asking (what "querry" means to me) MySQL anything...you're telling it to do something!

:D

Problem solved...thanks again.