EVE Technology Lab

Gary:

One person so far has asked for such a feature, not "so many". I maintain that 100% of all human users should always be in the Registered Users group, EVE usage aside. To only show the link to users who have not already registered is a bad idea also, as it doesn't make it easy for people to change their API key if they feel like it or to change their registered character (if they have multiple in registered corps.).

The Registered Users group should always be in the ignore list. It's a bad idea to remove users from that group.

You shouldn't have to add any lines to the code to do that. Line 115 of the current code for check-users.php is where you can set the forums group failed users go into upon failure. However, and this is the contention of this whole argument, to change that value is unsupported and in my opinion a bad idea, so I don't have any plans to add it to the configuration, in order to prevent confusion and data loss (the accidental removal of a bunch of users from the Registered Users group).

Drake:

I still don't understand. If you don't want failed API users to cause trouble, then don't give the Registered Users group very much power. There's no reason why a failed API user should be in a different category than a random Joe Blow that freshly registers on the forums as far as permissions go.

Anyway, as said, you can change it on line 115, but until someone gives me an explanation of the broad appeal of this, which I contest should be 0 with my current knowledge, it's an unsupported option.

New version released.

From my changelog: "2011-10-06 - 1.56 - Fixed users having registration deleted when EVE API server gives error messages other than authentication failures. Made similar fix in registration script to differentiate between a bad key and the API server giving other errors. Added forums link to end of registration script success message. Caused the Username column to sort case insensitively in registration list. Minor documentation changes."

Changed files (replace): setup.inc.php, eve-api-get-names.json.php, admin/index.php, readme.html

Much thanks for the update!

:)

For one, it requires Javascript, but I assume you have that enabled.

When you change focus away from the API Key ID or Verification Code boxes (clicking anywhere else basically), either you should get some form of error message, or the characters list should populate with characters you have in registered corps.

If you want to send me a mail or email with your comms. details, I could help walk you through it.

I prefer just having it load the latest version of jQuery from Google. Many people already have it cached anyway, as a lot of sites do that.

My PHP Info shows all that is ON. My hosting company allows us to change php.ini settings, but the script is def stalling someplace. I hate when things pause and give ya no clue on where it paused lol.

Also TA5E you can get the latest version of jquery from http://jquery.com/ and put it into your site.

Rache: You're welcome to use the HTTP version if you want, but there's nothing wrong with the HTTPS site on their end, and I recommend the HTTPS over the HTTP for the fact that when you use SSL you aren't transmitting API Key information in plain text.

Eugene: I've thought about some sort of loading thing, but as you say, it would only be a meaningless passive loading indicator like a GIF. I'll plan to do that for the next release, On mine, as long as the API server isn't down, it's instant. The most I ever see it take is about 3 seconds. I've also never had anyone mention that as a problem in the past in my alliance, but I admit I've thought of it myself. Working with it the other day when the API server was sluggish/down for a while, though, I definitely saw where the need might be in that area either the API server or one's web server is slow.

My 1and1 webhost doesn't seem to want to do "exec("php check-users.phhp"); or any "exec("php...");

Tho exec("echo 'hello'"); works.

EDIT: Nm.


1 And 1 user here as well... I do have some sort of fix here but I can't recall what it took to get mine working...

I'll need to look into that when I get the chance.

Odd thing to report.... I only see 1 user reported in the error log but no one else shows up in that log.

TASE:
You need to edit line 263 of index.php in the current package and change "php" to "/usr/bin/php5" (the full path to PHP5 on your host). You also need to change the cron job to use "/usr/bin/php5".

I may make that a config. option in the next release. I won't be able to fix the cron job part, but I guess I can make a note about it in the documentation. In a properly configured environment, in my opinion, "php" should point to the latest version of PHP on the server, but in 1and1's case, they're using PHP4 and PHP5 concurrently, so for compatibility, they have PHP4 as the default.

I believe you also need to do as Rache says on 1&1 with the php.ini file (make a php.ini file in the directory that contains "allow_url_fopen = On"). I think Drake had to do that as well.

Drake:
Either you haven't had anybody lose their registration and haven't otherwise had errors, or there's a problem. Try editing your entry directly in the EVE Registration table in the database so that your Verification Code is invalid, and set your Cached Until timestamp to something way in the past, and see if it then revokes your privileges and puts an error in the log.