Payment modules missing in Admin

[RodG]

So the next step will be to pull all the files, as suggested, and add them back in.
If that doesn't produce any results

I have 99.99% confidence that this will lead you to the source of the problem.

BTW, only re-add those that you are actually using. Adding the other serves no useful purpose (and it can be argued that doing this can decrease security by a tiny amount. Files that don't exist can't be used for exploitation :-)

I'll consider starting over to see if I can spot the issue as I rebuild it.

If this *is* needed, then
1) I'd be VERY surprised.
2) There is more to the problem than the symptoms would suggest.

Cheers
RodG

[David R]

RodG, right on both counts!
1) Removing everything and loading them back in, one pair at a time, demonstrated that all but one of the payment types could be loaded with no trouble. The offender? authorizenet_aim. and...
2) It was the file below the one I could see, and it was causing the trouble.
[With everything else in, I can add it and kill everything, or remove it and they all come back.]
I did a file compare between the language and program versions I have of this and the original 1.54 download files, and they come back identical.
Unfortunately, AuthNet AIM is *exactly* what I've been using and need to set up.
So I'm wondering -- because I brought over database values from our 1.39 version, could something in the stored data for the old setup be causing the new program file to choke?
Is there a way to reset the MySQL data for this method so I can try installing it again?
Thanks again. I'm really enthused about not having to start over. :-)

[RodG]

So I'm wondering -- because I brought over database values from our 1.39 version, could something in the stored data for the old setup be causing the new program file to choke?

My kneejerk response would be 'No', but I'm not going to rule out the possibility.

Is there a way to reset the MySQL data for this method so I can try installing it again?

Based on a recent vaguely similar discussion relating to a problem with one of the shipping modules (after a similar upgrade), try this:

Step#1: Remove the two AuthNet AIM files from the server.
Step#2. Log into your admin, navigate to the modules/payments section and deactivate one of the active modules. If there aren't any active modules, then activate one of them. Go back to the main screen.
Step#3. Replace the two AuthNet AIM files.
Step#4 Go back to the /modules/payments section to check if the problem has 'gone away'. If so, (re)activate the modules you want and check the various config settings.

If the problem still persists you should then take a look at your log files.

I have to state that I'm not at all confident that this will make any difference whatsoever, but in the absence of any other suggestions, and the fact that it'll take less time to do than it took me to write, there is nothing to lose by trying it.

Cheers
RodG

[DrByte]

In a properly functioning v1.5.4 site, any PHP errors should be stored in the /logs/ folder as myDebug-xxxxxxx.log files.
If for some reason your server is not allowing that interception, then the PHP errors will be stored wherever the server has PHP/Apache configured to put them ... could be in the Apache logs, or a specific log for PHP errors. Your hosting company should be able to point you to them (or if they're not accessible by "you", then "they" can extract parts of it from a specific time period for you).
Or it could just be that your /logs/ folder isn't writable so the intercept is failing.
And, it could be that they're being stuffed in your /cache/ folder if you happen to be using old-style configure.php files instead of a new set built for your server (by doing a fresh install ... but remember, a fresh install will wipe the database, etc, so do the fresh install in another folder and then edit that foldername out of the generated files).

Anyway, if the error is caused by a "this site needs to be running SSL", then make sure your "admin" configure.php file has HTTP_SERVER defined with a URL starting with "https://" instead of the usual "http://", so that the entire admin is secured with SSL protection. This assumes of course that you actually have a dedicated SSL certificate for your site. And you should. And you should do this "entire admin as SSL" thing anyway.

Further, if you can't find logs of PHP errors, you could edit the /admin/includes/extra_configures/enable_error_logging.php file and change the 'display_errors' value from 0 to 1 so they're output to the screen. (This should NOT be done for normal operation, because displaying errors to the screen can give hackers easy clues about whatever subtle intrusion attempts might be doing against your site, and give them info you don't want them to have. This suggestion is for LAST RESORT use to attempt to sort out this specific problem, TEMPORARILY.)

[David R]

I apologize for the delayed reply. I got pulled off this for a week.
I was going to start commenting out the authorizenet_aim.php code sections to isolate what was causing it to fail loading.
... and ...
When I went to do that, I saw a note in the header -from me- that I'd updated the file.
"bug fix for card type not posting - lne 292 2015-03-25 dr"
I think this dates back to 1.5.3, but simply replacing it with the REAL authorizenet_aim.php file from the 1.5.4 distribution fixed it.
sigh.
thank you very much. The troubleshooting tips will save me countless hours going forward.
I really appreciate all the help.
David

[DrByte]

When I went to do that, I saw a note in the header -from me- that I'd updated the file.
"bug fix for card type not posting - lne 292 2015-03-25 dr"

Good call. I'm always glad to see people recording notes for themselves. It's saved my bacon a thousand times. ;)