project drop down is not showing up

to get a "key" from fonts.com I have logged in with my account, but it generated the key, and hidden my account login details from the form.

I don't understand what you mean here. Can you explain?

forgotten about adding what error says

Okay, so the email and password are intended to disappear once the key is loaded. Only the key is needed to load your account info and saving email and password would open up new security concerns.

So the only question then is why your key isn't loading any projects. If you can send me your key via my contact form, I can test it on my local install. Or, if you're comfortable debugging code, a dpm() of $response in fonts_com_get_projects() would be useful.

I'm also seeing the same issue with Fonts.com now:

Notice: Undefined property: stdClass::$TotalRecords in fonts_com_get_projects() (line 367 of sites/all/modules/contribs/fontyourface/modules/fonts_com/api.inc).

I have it working on a site but currently I'm moving the site to another server and when I came to setup the fonts on the new server I ran into this issue. I've found the Fonts.com side of the module to often be funny with showing projects. But now it just does not work. On my existing site the fonts continue to work but the Project does not show anymore. Fonts show in the browsing section but cannot be enabled due to no project being enabled. Maybe Fonts.com's API has changed?

Changing status to "Bug report" as this use to work fine.

I've just done a quick debug() statement on the server with the $response->data and got the following:

Debug: Decoded JSON Response:

stdClass Object
(
    [Projects] => stdClass Object
        (
            [Message] => Something went wrong please try again later.
        )

)
in fonts_com_get_projects() (line 366 of ~/sites/all/modules/contribs/fontyourface/modules/fonts_com/api.inc).

I am also seeing the same errors with my working servers so it seems the issue is specifically related to querying for the projects as the loading of the fonts themselves is working just fine.

Just in case its useful here is the debug of the entire $response object:

stdClass Object
(
    [request] => GET /rest/json/Projects/?wfspstart=0&wfsplimit=100 HTTP/1.0
Authorization: [[REMOVED]]
AppKey: [[REMOVED]]
User-Agent: Drupal (+http://drupal.org/)
Host: api.fonts.com


    [data] => { "Projects": {"Message": "Something went wrong please try again later." }}
    [protocol] => HTTP/1.1
    [status_message] => OK
    [headers] => Array
        (
            [cache-control] => private
            [content-length] => 75
            [content-type] => application/json; charset=UTF-8
            [server] => Microsoft-IIS/7.5
            [x-aspnet-version] => 4.0.30319
            [x-powered-by] => ASP.NET
            [date] => Sat, 23 Nov 2013 19:08:41 GMT
            [connection] => close
        )

    [code] => 200
)

Let me know if you want me to poke around anywhere else?

There is a chance I am running into Fonts.com having trouble with their system. Not sure on that yet but this exposed some incorrect handling of errors in the module. The attached patch fixes the error handling.

P.S. I hope I'm doing this right as the Drupal 7 upgrade of Drupal.org seems to have removed the upload field from the normal comment form :-/

Seems it was a Fonts.com problem as after a couple days the projects started showing. I think Fonts.com's systems are a bit shaky with making adjustments to project accepted domains. This may be what the op ran into as well.

I'm considering opening a new bug report on the handling of errors from Fonts.com and attaching my patch to that report. But if a dev wants to just take the patch as is, there won't be any point in doing that?