Automatic publication has stale content

Hi @jkburges, that’s quite an interesting case. Staatic hooks into the post_updated and save_post actions to track changes. When editing a post, the post_updated action hook should be triggered after the post has been updated, and only then Staatic will start the publication process.

Do you by any chance have a caching plugin enabled? That could cause Staatic to see cached results while crawling the updated post.

Also, just to see if it changes anything, would delaying the hook propagation make any difference? This could be achieved by adding the following code into your theme’s functions.php file, or in a separate mu-plugin file (e.g. wp-content/mu-plugins/staatic_delay.php):

<?php

add_action( 'staatic_change_event', function () {
    sleep( 5 );
}, 5 );

This will delay the saving of a post by 5 seconds, so it is not really a solution. However, it can help answer some questions.

If this does not make any difference, it could be the case that Elementor updates the post in multiple stages. In that case we could consider delaying the publication trigger itself.

Looking forward to your feedback.

I tried this, it didn’t have an effect initially but then I noticed that Elementor takes quite a lot longer than 5s to complete saving, so I bumped the timeout way up to 120s.

That still didn’t seem to work; it did deploy the creation of a publication (i.e. I didn’t see it created until after the Elementor save had definitely completed), but still ended up with stale version in the staatic deploy.

I don’t have any caching plugins installed. I should’ve said though: it’s not just Elementor, but a bunch of other Elementor-based plugins that we have (elementor-pro, the-plus-addons-for-elementor-page-builder, theplus_elementor_addon, ultimate-elementor, unlimited-elements-for-elementor-premium) so it could also be a weird interaction with one of those.

Is there a way to log events – maybe that would help diagnose?

Thanks for providing the additional information. We will be performing some further tests and will get back to you as soon as we know more. Will keep you updated.

After further testing we have been able to reproduce the issue locally. We noticed that during the saving of a post, the post changes are spread across several updates. Since Staatic is immediately triggered after the first update, subsequent updates may not be included in the publication.

We have prepared a workaround for the next plugin version, which will add a small delay to the trigger, causing all updates to be picked up in the publication. This update is planned to be released before the end of this month.

That’s great news. Thanks for your excellent support.

Hello, just checking if 1.4.4 includes the workaround?

Hello, just checking if 1.4.4 includes the workaround?

Yes, it absolutely does. Please feel free to give it a try and looking forward to hear if it works well for you.

Update: please disregard below, it was a misconfiguration in my test env.

Trying 1.4.5 since that’s now the latest, and getting error:

• 2023/05/31 at 1:05 am – Publication failed during initiate_deployment taskStaatic\Vendor\AsyncAws\Core\Exception\Http\ClientException: HTTP 403 returned for “https://us-east-1-biteable-www-static-20230324013310485600000001.s3.us-east-1.amazonaws.com/?list-type=2&prefix=”.
  
  Code: AccessDenied
  Message: Access Denied
  Type:
  Detail:
  in /var/www/html/wp-content/plugins/staatic-premium/vendor/async-aws/core/src/Response.php:259
  Stack trace:
  #0 /var/www/html/wp-content/plugins/staatic-premium/vendor/async-aws/core/src/Response.php(271): Staatic\Vendor\AsyncAws\Core\Response::Staatic\Vendor\AsyncAws\Core\{closure}()
  #1 /var/www/html/wp-content/plugins/staatic-premium/vendor/async-aws/core/src/Response.php(93): Staatic\Vendor\AsyncAws\Core\Response->getResolveStatus()
  #2 /var/www/html/wp-content/plugins/staatic-premium/vendor/async-aws/core/src/Result.php(32): Staatic\Vendor\AsyncAws\Core\Response->resolve(NULL)
  #3 /var/www/html/wp-content/plugins/staatic-premium/vendor/async-aws/core/src/Result.php(87): Staatic\Vendor\AsyncAws\Core\Result->resolve()
  #4 /var/www/html/wp-content/plugins/staatic-premium/vendor/async-aws/s3/src/Result/ListObjectsV2Output.php(149): Staatic\Vendor\AsyncAws\Core\Result->initialize()
  #5 /var/www/html/wp-content/plugins/staatic-premium/vendor/staatic/framework/src/DeployStrategy/AwsDeployStrategy.php(193): Staatic\Vendor\AsyncAws\S3\Result\ListObjectsV2Output->getIterator()
  #6 /var/www/html/wp-content/plugins/staatic-premium/vendor/staatic/framework/src/StaticDeployer.php(59): Staatic\Framework\DeployStrategy\AwsDeployStrategy->initiate(Object(Staatic\Framework\Deployment))
  #7 /var/www/html/wp-content/plugins/staatic-premium/src/Publication/Task/InitiateDeploymentTask.php(47): Staatic\Framework\StaticDeployer->initiateDeployment(Object(Staatic\Framework\Deployment))
  #8 /var/www/html/wp-content/plugins/staatic-premium/src/Publication/BackgroundPublisher.php(238): Staatic\WordPress\Publication\Task\InitiateDeploymentTask->execute(Object(Staatic\WordPress\Publication\Publication), true)
  #9 /var/www/html/wp-content/plugins/staatic-premium/vendor/deliciousbrains/wp-background-processing/classes/wp-background-process.php(127): Staatic\WordPress\Publication\BackgroundPublisher->task(‘Staatic\\WordPre…’)
  #10 /var/www/html/wp-content/plugins/staatic-premium/src/Publication/BackgroundPublisher.php(151): Staatic\Vendor\WP_Background_Process->handle()
  #11 /var/www/html/wp-content/plugins/staatic-premium/vendor/deliciousbrains/wp-background-processing/classes/wp-background-process.php(66): Staatic\WordPress\Publication\BackgroundPublisher->handle()
  #12 /var/www/html/wp-includes/class-wp-hook.php(308): Staatic\Vendor\WP_Background_Process->maybe_handle(”)
  #13 /var/www/html/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters(”, Array)
  #14 /var/www/html/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
  #15 /var/www/html/wp-admin/admin-ajax.php(203): do_action(‘wp_ajax_nopriv_…’)
  #16 {main}
  

The bucket is private, so it makes sense that accessing via HTTPS is 403ing. Is there are way to go back to how it used to be?

• This reply was modified 1 year, 5 months ago by jkburges.

Also, I’d like to try premium 1.4.4 but cannot find where to get it.

Hi, I think this is very close to working with 1.4.5. The S3 objects are now being updated with the correct versions after “update” button clicked in Elementor.
The only issue remaining now is that the Cloudfront invalidation is not matching the index.html object in S3, e.g. invalidation has object path such as “/blog/create-beautiful-charts/” but needs either “/blog/create-beautiful-charts/*” or “/blog/create-beautiful-charts/index.html”.

Also, I’d like to try premium 1.4.4 but cannot find where to get it.

Older releases of Staatic are currently only available through our package repository at https://packages.staatic.com/ – see also https://staatic.com/documentation/setup/installation/#composer. We will add the ability to download older releases from the customer portal at https://app.staatic.com/ in the near future though.

The only issue remaining now is that the Cloudfront invalidation is not matching the index.html object in S3

The invalidation URL should depend on the permalink structure of your WordPress site, not on the actual file path in S3. Just to be sure, on your public site, is the URL of the page https://example.com/blog/create-beautiful-charts/ or https://example.com/blog/create-beautiful-charts/index.html?

Older releases of Staatic are currently only available through our package repository

Ah ok, that’s good to know, thank you.

on your public site, is the URL of the page?https://example.com/blog/create-beautiful-charts/?or?https://example.com/blog/create-beautiful-charts/index.html?

The former, i.e. literally https://biteable.com/blog/create-beautiful-charts/

Right, so I need to change some wordpress config somewhere then?

Thanks,

Jon

The former, i.e. literally https://biteable.com/blog/create-beautiful-charts/

Right, so I need to change some wordpress config somewhere then?

No, in that case Staatic invalidates the correct path by invalidating “/blog/create-beautiful-charts/”. CloudFront invalidation is based on the URL path segment. The fact that the URL internally translates to an S3 object path “/blog/create-beautiful-charts/index.html” should not matter.

Of course, you are right. I will go back and test things again; from memory, the published site didn’t seem to be updating and I thought this (imagined) issue was the reason.

Sure, and if you need any further assistance, feel free to get back to us any time.