I'm having problems restoring aMember. It's to the same domain and server, but a fresh install because I deleted all files from site after a hack. I've tried various ways, each unsuccessfully. OPTION #1 1 Create a new database and import into it a phpMyAdmin-generated dump of the whole database. 2 Upload aMember files to server. 3 Add database settings to .../amember/application/config.php. I'm now thinking 'I should be able to login using the admin details from the dump, and all the users/etcetera should be in place'. But, after login, the admin area is minimal - minus most of the usual stuff. OPTION #2 1 Create new database. 2 Upload aMember files to server. 3 At '.../setup/', enter config parameters - new, blank database. As expected, this completes a fresh install - no users/etcetera. 4 Use 'admin-restore' link to import an aMember-generated dump of user/other data from previous install - it completes ok. Now, any admin menu link triggers a login, but... 1 The admin user created on this install triggers a 'The Member ID or password is wrong.' 2 The 'lost password' option delivers 'User is not found in database'. 3 Using 'lost password' with the email address for an admin from the imported dump triggers '[User] has no permissions to do selected operation in AdminFieldsController'. 4 Then if I try to login again using the same details from #3, I get the admin area minus most of the usual stuff. Sensible suggestions welcomed - please and thanks.
A quick update... After further tests, with a fresh install... I can reimport newly generated (by aMember) dumps, but when trying to do so with the original (aMember-dump created a year or so ago when I took the site offline) the admin area becomes devoid of the normal links etcetera. So it seems to be a problem with the 'old' aMember-dump. I still don't understand why I can't install using the 'option#1' method... Presumably, during the initial install aMember does three things: 1 Create the sql tables. 2 Add the db details to /application/configs/config.php. 3 Add the RewriteBase to .htaccess. So if... 1 The old tables are imported into a new database. 2 config.php is edited to contain the connection details before uploading. 3 The original aMember files and the modified config.php are uploaded to the original location. ... surely aMember has the info needed to simply connect and work as it was before removal?
Looks like it's currently just me on this one, so another update... After much odd behaviour (and I'm wondering if part of this is due to Opera caching when it shouldn't), I now have it sorted.