Hey Daniel,

Unfortunately we are still having troubles with this. I have tried both K2 and normal login forms. When a user enters in their username and password they are just taken to the default login page again - it doesn't even tell them that the username and password is incorrect. Could this lend itself to a PHP problem?

The site:
xxx

PhpInfo():
xxx

Its worth noting that any new user created on the system (i.e. admin and others) can log in fine however if an incorrect password is entered, it has the same result (takes them to the login page with no error messages).

My hands are tied being able to give you access to the system (ftp, backend, etc) however I will endeavour to provide you with all information that might be relevant.

Firstly on the backend when I select CMigrator from the Components window it alerts me to an update being found. When I 'Update to the latest version' it says the Install component Success telling me that the plg_authentication_cmigrator plugin has been successfully installed - however going back into the CMigrator screen it says there is an update again.

Could this be a permissions problem on the back end?

Checking the /plugins/authentication/cmigrator/ folder I see that it all has 777 permissions (too much I know) but that shouldn't be a problem?
File list:
xxxx

The rest of the site is 'owned' by the webuser2 user except for some K2 modules and components and the cmigrator component. Would the owner make a difference? Let's see shall we :-)

xxxxx

Then I ran the updater again, with the same results, however the timestamp on the files has updated so I guess that means the files have been updated but the Component cant tell?
xxxx

So does that mean the admin component doesn't have access? Checked:
/administrator/components

And found that a few (inc cmigrator and k2) were assigned to the www not webuser2 user, so sorted that out so them and their subdirectories and files are now all chmod'd correctly.
xxxxx
/administrator/components/com_cmigrator

Ran the updater successfully but it is still reporting there is an update available. Drupal users still can't loginto the system.

//Moving forward...

You said the cmigrator program recreates a new password for a user once they log in successfully in the 'joomla' way. I went into the _users table and found that the drupal password format exists for the old users and the admin (who can login) was in the proper format. To this end I directly manipulated the database to enter in a known joomla style password for one of our users. To my surprise the user still couldn't log in. But this gave me an idea.

One thing that different about the users now is possibly the groups they are being assigned. Is it possible they cant log in because they are not part of a default group??

And this leads us to the answer... all of the original users came across with their drupal groups and joomla doesn't recognise them as having access to login, changing these users to be part of the 'Registered' group in _user_usergroup_map allowed them to login. I will look at the best way to fix this in the next few hours (either update the users directly in the database, or play around with joomla to give those groups sufficient permissions to do what we want). I think I will move towards option A to keep the back end cleaner.

I guess my quesitons is now - did I miss something in the import process (or documentation), or does cmigrator not cover this?

Either way I hope this is helpful to other people . But I am still not sure why CMigrator reports that it is out of date in the back end?

At least I can move forward again. ;-)

Tom