piantadosi

Hi tararebeka. Did you try going to the Google developers site in another browser? Forgive me if you already tried this, but I usually work in Chrome and when caching mysteries arise, I just open Firefox and delete everything (history/cache) and then try signing in.

Are you still using the old Docs to WP version successfully? I’m thinking of going back to it since having docs transfer successfully but bring along none of the text formatting or categories or GD comments is breaking my back (and other things). Tomorrow I’ll be two weeks’ worth of posts behind. Argh.

Hey thank you again very much.

We use a simple folder structure (Future, Edit, Print, Images) on Drive for our print workflow. So we don’t add docs to the category-matching folders until they’re ready to go to WP (and those folders are all contained in a top-level folder called “Categories”).

So I guess the answer to the question about subfolders is yes (since all the category names are subfolders of the “Category” folder). If you meant folders on the WordPress side, it doesn’t seem to matter if the folder is a child or parent as long as the name is an exact match for the folder in GD. Hope that helps. And happy birthday.

Roger

Removing and reinstalling seems to have worked. We are transferring documents again! @anubisthejackle — thanks for sticking with this.

The ajax issue seems to also have gone away.

However, it doesn’t seem to be transferring character attributes (bold, italic, etc.) to WP, and it’s also not picking up categories or authors the way it used to (matching GD folders with WP categories and authors whose Google email before the @ sign matches their WP username, etc.) — a few of the excellent reasons to give up copying and pasting for Docs to WP in the first place. correct h1-5, li and p formatting is coming through.

No, the cron file is in the WP root, and the browser shows the “It works” echo. Going to remove and reinstall the plugin.

@anubisthejackle — no PHP errors in the log. no errors at all since reactivating the plug-in. (most recent entry looks like it was three hours ago and does not seem related).

just thought something really stupid — would an htaccess ban on IP addresses to /wp-admin/anything be the problem? (we were attacked not long ago by some friendly russian hacking students). if so i’m happy to feel like an idiot and go fix it before i re-download the plugin.

@anubisthejackle — not working. new cron job is active, and the browser method doesn’t seem to work either. you think it would it do any good to delete the old App at Google and create a new one?

5.4.36

@anubisthejackle — thanks for the cron code and tips, and definitely a Yes vote here on the transfer button.

@tararebeka — as usual, I forgot that I actually had created a cron job before via the control panel, so with your help I found it again. thanks. will be trying the new script momentarily. so, did you get the update working? (I saw in your other thread that you were going back a version, but I thought the old version only works with the now-defunct Docs API.)

Thanks for the quick response.

Offline access was granted with the same account we’ve been using all along, which is the same account I used to create the App, for which the Drive API is activated. Hmm.

I would like to test with a “real” cron job and the installation notes do say what to put in a cron file but I am not a real coder so . . . not sure where that file goes (wp install root?) or how to get the server to execute it. That probably be my problem, not yours, but any pointers appreciated.

Tha ajax issue seems to be across the admin dashboard (calendar thing is on the admin new/edit Event, a custom post type created by the ECP plug-in; the other authors thing is on any admin panel that contains the Authors-Plus field, which is basically an enhanced version of the Author field). Relative to the transfer issue, though, it’s a minor thing. We’re a weekly paper and do the transfers about once a week, so I can deactivate Docs to WP while we’re entering events.

Thanks again for getting back.

Thanks, that’s a big help, and sorry for not searching the support threads diligently enough, although I’m not sure the www.remarpro.com forums make that very easy.

Also, maybe this is a feature request, but we’ve been using summary_large_image as the type for all our posts (we only Tweet the posts with large images), but again our theme prevents me from changing the post type to “Image.” I didn’t see any hooks for filters like the ones you kindly pointed out for choosing the image size, so for now I edited amt_twitter_cards.php to use summary_large_image for standard as well as image posts. I know I shouldn’t oughta do that, but I thought, if you were just sitting around waiting for feature requests to arrive . . . ??

thanks again,
Roger

The images sizes I have set (medium, large, etc.) are set to work within the display of the theme I use, and in that case the size for “medium” is 300 px wide. I don’t understand why your plug-in chooses the WP-resized “medium” size for a Twitter or FB image metadata tag — why not (as do a couple of other similar plug-ins that have other problems) use the original uploaded image?

FB and Twitter summary cards will not display in that “attractive” big-picture format if the image tag is a reference to a 300px-wide image. And if I change the “medium” size in my media settings, it breaks the entire site’s layout.

Maybe I’m missing something, but any help would be much appreciated.

Roger

That did the trick. Thank you, and thanks also for the quick response.

Hi — no, I forgot to say that. Tried it both ways, with [forecast] and [wunderground]. Thanks for any ideas you might have; for now we’re fine with using the earlier version but would like to use the update, which seems we could customize to a greater extent.

Answering for rhodie (we work together, although not always in the same room, or even zip code). We fixed it, but I was thinking the solution could be helpful if it happens to anyone else. Somehow the business name field had gotten changed, in the Manage Form Fields admin, from ‘textfield’ to ‘textarea,’ which turned off linking.

You are right, as usual. Somehow footer.php disappeared from the theme folder; everything is back to normal now, thanks.