stenberg.me

Hi,

Thanks for reporting this.

Does this happen with the latest version on Content Staging as well, 2.0.1?

Hi,

Normally you would find the debug.log in wordpress/wp-content/debug.log. If you do not find it or there are nothing in it, try turning debugging on by adding the following to your wp-config.php file:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

Then try to sync a post containing a featured image again and see if there is any information added to your debug.log.

Good luck!

Version 2.0.0 of the plugin has now been released with support for setting the endpoint directly through WP Admin.

If you decide to set endpoint through WP Admin, remove the endpoint settings from your wp-config.php files (otherwise the wp-config settings will take presence).

Hi!

Syncing featured images are supported, might be a permissions problem. Can you see if there are more information in your debug.log for your “production” environment?

Images embedded in the content field is not supported though, this is something we want to change in the future, see https://github.com/stenberg/content-staging/issues/7

Thanks!

Hi!

You are right, this is a bit misleading. The CONTENT_STAGING_ part of the constant is meant as a prefix to avoid collisions with other settings (e.g. other plugins).

In order for this to be correctly understood you would have to ignore the CONTENT_STAGING_ part and only read it as ENDPOINT.

We’re planning to release a new version (shortly I hope) of the plugin where this can actually be configured through WP Admin instead. If you want to try this out, have a look at https://github.com/stenberg/content-staging.

Thanks!

Hi phillyj8,

Modify the page that you deployed and try to deploy it again. My guess is that you will still have two copies of the page (not three), one of them will be the updated version?

Content Staging is using the guid field in wp_posts to compare posts from your staging environment to posts on your live environment. My guess is that when the database was copied to the staging environment, the domain was replaced with the domain of the staging site.

Now that’s fine, but for Content Staging to be able to compare posts, the guid field must be left unaltered in the copying process.

I hope this helps, let me know if you have any questions.

Thanks!

Great to hear, thank you for reporting back!

Thank you @phillyj8 for verifying!

The plugin handles updating posts, I have a theory on what’s going on.

Could you please open up a new support thread for this issue and I’ll answer in there?

Thanks!

Might be that Cloudways block WordPress XML-RPC functionality, in that case your stage server won’t be able to communicate with your production server.

Check with Cloudways support if that is indeed the case. If it is, ask if they can enable XML-RPC support.

There are ways to disable part of the XML-RPC functionality provided by WordPress without removing support entirely.

@qriouslad @phillyj8

I’ve pushed new code to the GitHub repo that will hopefully fix the permission issues you are experiencing after deploying a batch.

To give it a try, grab the latest code from the develop branch:
https://github.com/stenberg/content-staging/tree/develop

Would be really grateful if you reported back whether this solves the issue or not.

Thanks!

Hi,

1) Absolutely, would be quite messy having to change wp-config over and over. I’ll get back to you when I come up with a better solution for this.

2) Correct, the default behaviour is to remove the batch upon completion. You can override this by adding the following piece of code to e.g. functions.php:

add_filter( 'sme_batch_list_statuses', function( $statuses ) {
	$statuses[] = 'draft';
	return $statuses;
});

Thanks for your feedback!

Hi,

Interesting requirement. Nothing that is supported out of the box, what you would have to do is to first deploy to Live, then change wp-config (CONTENT_STAGING_ENDPOINT) and deploy to Dev.

I’ll give this issue a thought and see if I can come up with anything (https://github.com/stenberg/content-staging/issues/67).

Thanks!

When Content Stage is trying to connect to Production it gets back a HTTP status header of 403 Forbidden.

Does it work to access the site URL you’ve specified in CONTENT_STAGING_ENDPOINT through your browser? Do you have to authenticate (e.g. with basic authentication)?

Thanks!

Hi!

Content Staging handles deploying new posts as well as updated posts, let me know if you experience any issues with this.

The plugin only sync the specific posts you have selected to include in the batch you want to deploy to production. All other data in _posts, _postmeta, etc. are left untouched.

Custom post fields are included in the content being deployed to production.

Interesting case, deploying to different environments. At the moment you would have to change CONTENT_STAGING_ENDPOINT in wp-config to make this happen.

I’ll consider supporting deploying to multiple endpoints (https://github.com/stenberg/content-staging/issues/67).

Thanks!

@qriouslad Content Staging should actually work even if it is not a plain copy of the production site.

I’ll see if I can come up with anything that fixes the issue you experience with permissions. Is it the same thing for you that wp_capabilities has a prefix in the wp_options table (e.g. wp_bmrcf2zpf2_capabilities)?