1.0 beta questions/issues

With the 1.0-beta update, we’re switching from the now inactive Google Docs API to the Google Drive API v2, which doesn’t use plaintext user/pass, so those can be removed regardless, and should be.

As for the other fields, if they are present, Docs to WP will default to those values, and lock out the fields in the Options page (it’ll display as greyed out and you won’t be able to alter the values).

If you have created the API connection properly, it will connect. When it says Connection Status: Error! that generally means that it’s unable to use that connection, for one reason or other.

Unfortunately, this is a critical update, as Google has shut down their previous API. We are working on better debugging tools, but don’t have an ETA on when those will be pushed out.

From the sounds of it, though, it’s not able to see the connection as active.

private function _verifyConnection() {

                $this->_drive->connect(
                                        array(
                                                'access_token' => get_option( 'docs_to_wp_auth_token' ),
                                                'token_type' => 'Bearer'
                                        )
                                );

                $response = $this->_drive->get( '/about' );
                return !isset($response->error);

        }

That is the method used to verify the connection status. If a proper API key has been generated, this will always work. This hints to me that there is an issue with the App settings.

One thing that I would suggest is verifying that you have the Drive API activated in your App. You can do this by visiting the API Console and checking under APIS & Auth -> APIs under the Enabled tab, and if you don’t see Drive API there then that is the issue.

All you have to do is find it in the API Library tab and enable it, and Docs to WP should start working again.

Well, the good news is that you were right on with the Drive API not being enabled. Hooked up that bad boy and the connection status is good.

Unfortunately, my issue now seems to be running the cron. Something about my hosting plan causes the plugin cron to timeout, and it was easier to follow your instructions on creating a real cron file than trying to track down the issue (this is how I’ve been running it for a couple of years).

When the cron runs, I get this response:

Parse error: syntax error, unexpected T_FUNCTION in
…/wp-content/plugins/docs-to-wordpress/docs-to-wp.php
on line 272

I checked, and my plan is using php 5.3.

Thoughts, oh wise one? :^) It feels like this is one keystroke away from working.

That one I can tell you what the issue is. I use some anonymous functions which I’m thinking are breaking stuff for you. I’ll push out an update later tonight / early tomorrow moving away from anonymous functions.

THANK YOU!!! You are awesome.

*happy dances*

Just pushed v1.1 with PHP 5.2 fixes. Let me know if this fixes it for you.

Good morning,

Still no dice. Today’s error message is this:

Fatal error: Call to undefined function json_last_error() in …/wp-content/plugins/docs-to-wordpress/wrAPI/apis/Abstract_Api.php on line 14
<!– html is corrupted –>

Boy, you cut off one head…

:^/

I don’t really speak code, but API…is that something on my end? Just a guess.

Yes and no. The API returned an invalid result, that didn’t come out as JSON, and the code I use to define what the error is uses json_last_error() which apparently wasn’t present in PHP until 5.3.

The solution is two-fold, but really I think you should email your hosting provider and upgrade your PHP, 5.2 is outdated, and in serious need of upgrade.

That’s why I don’t understand why we’re having issues – we are using 5.3. Do you think going to 5.4 would resolve it?

If you’re getting json_last_error as an undefined function, the PHP version thats being used to run your code is earlier than 5.3.0 according to https://php.net/manual/en/function.json-last-error.php

After a bit more reading, it looks like JSON is actually an extension, so if the code is 5.3 and you still aren’t getting the JSON functions, it may be that the extension isn’t loaded, which your host can fix easily enough.

fyi…I’m into hour two of my call into tech support.

So far we’ve discovered that the server is a lying liar who lies – it says the JSON extension is activated, but it really isn’t. Upgraded to 5.4 and it still is being a petulant little turd.

He’s now checking with co-workers to see if there’s anything he missed. I told him the server simply has a personal vendetta against me.

I’ll keep you updated.

Also, Google still hasn’t pulled the plug. I’m skating by for this round, bated breath and all.

Three hours in – they have now verified that JSON is running properly on the server along PHP 5.4.

https://quailcreekcrossing.com/json_test.php

They can’t figure out why it wouldn’t be working, but they’ve done everything they can on their end.

Thoughts?

The personal vendetta is begging to sound plausible.

In all seriousness, I’m at a loss. If you have 5.4 now, you definitely should be fine running all the code.

Exactly! (it hates meee….)

I wonder if we’re running into a plugin conflict? And straw I can grasp at this point.

*runs to deactivate everything*

if that doesn’t work, to make it work for you, you can simply remove this entire block:

switch (json_last_error()) {

                        case JSON_ERROR_NONE:
                                $error = null; // JSON is valid
                                break;

                        case JSON_ERROR_DEPTH:
                                $error = 'Maximum stack depth exceeded.';
                                break;

                        case JSON_ERROR_STATE_MISMATCH:
                                $error = 'Underflow or the modes mismatch.';
                                break;

                        case JSON_ERROR_CTRL_CHAR:
                                $error = 'Unexpected control character found.';
                                break;

                        // only PHP 5.3+
                        case JSON_ERROR_UTF8:
                                $error = 'Malformed UTF-8 characters, possibly incorrectly encoded.';
                                break;

                        case JSON_ERROR_SYNTAX:
                                $error = 'Syntax error, malformed JSON.';
                                break;

                        default:
                                $error = 'Unknown JSON error occured.';
                                break;

                }

                if( !empty( $error ) ) {

                        throw new JsonException($error);

                }

out of wrAPI/apis/Abstract_Api.php

That’s not something I’d be willing to take out of production, but for your case it would make the code work.