norelidd

That’s definitely an interesting take. Last night I figured out how to write a custom shortcode to get what I needed, but I think I’ll supplement it with the cfdb-json shortcode and jquery to build and populate the fields I need.

Thanks for the reply!

That fixed it for me too. I recompiled PHP and Apache (WHM EasyApache) without eAccelerator and the backup works now. Lovely!

I still have this issue. I deleted the old key and put a new S3 key in, but it still has the same problem.

In the S3 settings section of the job details, under S3 Bucket, it says

Bucket selection Invalid signature type: s3

I’m seeing the same thing. I had mine up and running running for about a week before failing tonight and last night with this error.

From my log

[08-Mar-2014 04:16:38] Compressing files as TarGz. Please be patient, this may take a moment.
[08-Mar-2014 04:19:46] Backup archive created.
[08-Mar-2014 04:19:46] Archive size is 1.10 GB.
[08-Mar-2014 04:19:46] 14517 Files with 1.65 GB in Archive.
[08-Mar-2014 04:19:46] 1. Trying to send backup file to S3 Service …
[08-Mar-2014 04:19:46] ERROR: S3 Service API: Invalid signature type: s3
[08-Mar-2014 04:19:46] 2. Trying to send backup file to S3 Service …
[08-Mar-2014 04:19:46] ERROR: S3 Service API: Invalid signature type: s3
[08-Mar-2014 04:19:46] 3. Trying to send backup file to S3 Service …
[08-Mar-2014 04:19:46] ERROR: S3 Service API: Invalid signature type: s3
[08-Mar-2014 04:19:46] ERROR: Step aborted: too many attempts!

There’s always the premium wpmudev Domain Mapping plugin: https://premium.wpmudev.org/project/domain-mapping/

But at $10 a month, it’s not worth it for my profitless network.

Yep, that fixed it. I unchecked “Remote Login” and “Redirect administration pages to site’s original domain ” in Domain Mapping Configuration, and that seems to have done it. Now the sites reference their new domains instead of the mapped domains.

Thanks for the help!

The only problem (a small one, but still) is that now I have to log into each site individually as the cookies aren’t cross-domain. Is there any fixing this?

In my case, I have Jetpack network-enabled and logged in with each site I manage.

Jetpack/publicize all lives in the admin back-end.

The publicize function happens on the post menu. You first set up Publicize by linking it to the appropriate accounts you want to share posts on. You select which sites to share your new post on and when you publish a post, it will share a link to it on those sites.

I’m seeing this, too. On anything that has to do with URLs, WPMS is using the subdomain instead of the mapped domain.

This affects creating internal links in pages/posts, Jetpack publicize, and more.

Is this due to an error in my domain mapping setup?