pwtyler

Hey Risto, yes, this has been tested and can be used with the latest version of WordPress— we just haven’t shipped a feature release in a bit that updates the .org homepage. I will try to get something out that includes a “Tested up to” update soon.

Best, Phil

Alright we’ve got this tracked on GitHub and internally, but in the meantime if you get something working with ChatGPT’s second suggestion there, let us know here or in Github, as I expect any generalized solution we end up with would look pretty similar.

Hi there—

Glancing at the ChatGPT conversation, it looks like ChatGPT hallucinated that filter pantheon_wp_edge_max_age, but the second approach looks promising— Pantheon’s cache control filters rest_post_dispatch at priority 10, so firing your filter after that should work.

I wanted to confirm that you are indeed asking to adjust the max age for the REST API but not the rest of the website, correct? The current filter available, pantheon_cache_default_max_age would cover every page, but I think is more than you’re asking for.

add_filter( 'pantheon_cache_default_max_age', function() { return 600; } );

I double checked that this wasn’t already an option with our filters, and it’s definitely a solid feature/option to have— I’ll open an issue on GitHub and get it into our internal systems as well.

Re the docs screenshot, looks like we’ve got that tracked in our documentation team’s queue (which is probably still on me to fix ??) as well.

Hey @mdifelice, this definitely looks like something we should address, I’ve copied the details here to an issue on our github repo, and will get this slotted into our bug process to be prioritized.

@thr87 @dbrieck—

Sorry about that! Looks like an issue with our deploy pipeline meant that a faulty version was tagged for release without the vendor directory. We’ve just released 2.1.3 with the vendor directory restored.

Instead of symlinking, you can copy the source file to wp-content/object-cache.php and then make your changes— any future plugin updates would not overwrite the object-cache.php file outside of the plugin directory.

I don’t expect object-cache.php to change too often (it most recently did to fix PHP 8.2 compatibility), but you will want to keep an eye on future releases changing object-cache.php which would no longer be applied.

If you have a sense of how you might achieve your changes to object-cache.php using hooks/actions, you might also fork the plugin and open a PR to https://github.com/pantheon-systems/wp-redis/

@earphanb, are you looking for a hook/action that doesn’t exist?

Thank you!

Hi Paul,

Sorry for the (very) belated response here, I only just saw the notification here on www.ads-software.com.

If you are still having trouble: the simplest answer is to use “do_shortcode()”.
echo do_shortcode( '[table id="'.$tablepress_id.'" responsive=scroll]' ); should do the trick.

There are other (smarter/faster) ways to avoid do_shortcode and use tablepress_print_table(), but I’m not sure how straightforward that is. It could be something as simple as

$args = array(
  'id' => get_field( 'your_field_here'),
  'responsive => 'scroll'
);
if ( function_exists( 'tablepress_print_table' ) ) {
  tablepress_print_table( $args );
}

But I have not tested the code above. I am, however reasonably certain do_shortcode() will work fine. Let me know if you are still having trouble and I can play around with it a little more.

Best,
Phil

Hi Dan—

It seems like get_field (or whatever you are using in the template) is returning a literal string of ‘null’, which I’ve actually not been able to replicate. When I do not choose a table in the dropdown, and use the following code in my template,

$tablepress_id = get_field( 'tp' );
$args =[ 'id' => $tablepress_id ];
if ( function_exists( 'tablepress_print_table' ) ) {
  tablepress_print_table( $args );
}

I see on the front-end [table “” not found /], which I would say is to be expected. My guess is, you will want to amend the if statement you wrapped the display part of the code to also check that $tablepress_id does not equal ‘null’, something like

$tablepress_id = get_field( 'tp' );
if ( ! empty( $tablepress_id ) && $tablepress_id != 'null' ) {
    $args =[ 'id' => $tablepress_id ];
    if ( function_exists( 'tablepress_print_table' ) ) {
      tablepress_print_table( $args );
    }
}

I’m sorry I don’t have a better explanation as to WHY it’s happening, but could you tell me exactly what code you are using in your template, and what version of ACF you are using? I tried both ACF 4 and 5, but neither returned a literal ‘null’ string like you’re getting.

Hi Dan—

Sorry for the belated response, I just saw this, I’ll take a look and get back asap!

best,
Phil

Hi there—

ACF:TablePress should not load jQuery anywhere (although I believe TablePress may?), is it possible your conflict could be with another plugin?

Best,
Phil

The code examples can be added to your theme’s template file. You can see an example using a child theme of 2015 and a quick walkthrough in our website docs here.

Best,
Phil

Hi there,

The logged in/logged out issue with the “HTML output” seems to have been a problem with this plugin since its inception, and the fix is not as simple as I might have hoped. I recommend using ID output with either of the following code snippets—

$tablepress_id = get_field( 'your_field_here' );
 echo do_shortcode( '[table id="'.$tablepress_id.'"]' );

or

$tablepress_id = get_field( 'your_field_here' );
$args = array(
  'id' => $tablepress_id,
);
if ( function_exists( 'tablepress_print_table' ) ) {
  tablepress_print_table( $args );
}

We have an update pending to be pushed that will remove HTML output as an option, as finding a stable fix is a bit beyond my scope/schedule at the moment when we have a stable solution with the ID output. There are a couple of other bugs/updates that need to be tweaked before the plugin is ready for the repo, so it may yet be a couple of weeks before you see an update in the dashboard.

If you have any other questions/issues, you can follow up here, or at [email protected]

Best,
Phil

Hi there—

What code are you using in your template to add the table? As I mentioned in the other thread, the logged in/logged out issue with the “HTML output” seems to have been a problem with this plugin since its inception, and I recommend using ID output with either of the following code snippets—

$tablepress_id = get_field( 'your_field_here' );
 echo do_shortcode( '[table id="'.$tablepress_id.'"]' );

or

$tablepress_id = get_field( 'your_field_here' );
$args = array(
  'id' => $tablepress_id,
);
if ( function_exists( 'tablepress_print_table' ) ) {
  tablepress_print_table( $args );
}

I’m only now getting to that update I promised four months ago to hide the HTML output option.

I’ve not used the rowdetails extension before, but I’m happy to try to help with it. I installed it in my test environment, and it seems to be working with ID output and the following tweak to the do_shortcode version:
echo do_shortcode( '[table id="'.$tablepress_id.'" datatables_row_details=true]' );

does that work for you?

Best,
Phil