Babak Fakhamzadeh

This is for https://eleicoes.apublica.org/2016/

This happened after this website was migrated (this weekend) from the previous URL, which was https://apublica.org/truco2016/

In your site’s Jetpack dashboard, near the bottom, there should be an option for managing your connection.

Here’s another workaround: Opera has a built in VPN, which also circumvents the DNS issue.

Thanks.

It’s not just iPhone users. Macs also can use Private Relay.

Obri. Isso parece funcionar.

Obri. Isso n?o retorna um erro. Porém, isso também n?o parece funcionar como esperado.

Quando uso isso para um pedido de um produto que n?o é recorrente, ainda recebo a resposta “Ativo”.

Quando verifico o status de um pedido relacionado a uma assinatura cancelada, também recebo “ativo”.

Parece-me que essa fun??o retorna o status do pedido, n?o da assinatura.

Também observo que, quando um usuário cancela uma assinatura, a assinatura é revertida para “cancelamento pendente”. Como o cancelamento se torna definitivo?

Eu tenho isso:

60: use RM_PagBank\Helpers\Recurring;
61: $order_id = 130;
62: $order = wc_get_order( $order_id );
63: $status = Recurring::getStatusFromOrder($order);
64: echo "<h1>Status da assinatura: $status</h1>";

Agora:

Fatal error: Uncaught Error: Non-static method RM_PagBank\Helpers\Recurring::getStatusFromOrder() cannot be called statically … on line?63

Thanks Mustafa. That’s exactly what I needed.

Obrigado, Ricardo, mas isso n?o está funcionando para mim:

Fatal error: Uncaught Error: Call to undefined function RM_PagBank\Helpers\Recurring()

Yes, that’s indeed what I’m seeing. With the plugin turned on, the REST responses seem to be cached in the browser. With the plugin turned off, they are not. I had a similar problem earlier, and tried to ameliorate this through CloudFlare, but I remember that I could not get that to work.

You the man! ?? Thanks!

Thanks. That’s indeed the kind of thing I was looking for.

However, I’m not getting quite the result I am expecting.

In fact, I now discover that, even after deleting all REST cache, I’m still handling responses that seem to be cached in the browser, as no new cache is generated after requesting that for which cache was just cleared. :/

Thanks.

Indeed, when I need the cache to clear is when I’m using a custom Ajax call, not a default endpoint or function.

I did have a look at your FAQ, but I could not find something that matched my use-case.

My custom Ajax calls call ACF’s update_field() function. So, are you implying that if I follow my call to update_field() with something like the below, the cache is automatically cleared?

$my_post = array(
      'ID'           => $post_id,
  );
wp_update_post( $my_post );

Or do I actually have to update something? So, I perhaps need to do this:

$my_post = array(
'ID' => $post_id,
'post_title' => $temp_title
);
wp_update_post( $my_post );
$my_post = array(
'ID' => $post_id,
'post_title' => $actual_title
);
wp_update_post( $my_post );

Awesome! Indeed, this now works for me both in the backend, and inside a frontend acf form.

Many thanks! I very much appreciate your persistence!

I do still have the button bar in the frontend which looks funky. But I see that your ‘table’ button has the ‘table’ class. This conflicts with my Bootstrap-based theme, which also uses a ‘table’ class for displaying tables.

I can work around this with a bit of css, but it’s probably something you should look at; Bootstrap is quite a common framework, after all.

Again, many thanks!

Thanks Pierre-Henri,

Progress! I now got this to work in the frontend. Though the visualisation of the button bar is messy.

https://i.postimg.cc/43mR6HHC/Screenshot-2024-05-02-at-11-17-18.png

However, more problematic is this: I’m using this field for a taxonomy term, and in the backend, the editor now does *not* load. I get the spinner icon that never disappears.