Martin Taylor

Thanks for replying, @qtwrk.

Just to be clear, the steps I follow are:

• Upload an image to the media library – say xxxxx.png
• After a while, LiteSpeed creates xxxxx.png.webp in the uploads folder. Actually I don’t know how long this takes, but I guess it depends on a cron. When I look at the media library, I see over to the right that there is a webp version.
• Now I delete the media item
• I upload the same media item again
• This time, WP changes the uploaded filename to xxxxx-1.png. I think this is because WP has found the webp version still in the uploads folder, so it is trying to avoid a naming clash

Right now in my test, LiteSpeed has not created the webp version, so I cannot yet complete the test. I’ll report back when the webp version has been created.

Thanks for your reply, @prasunsen . Sorry, but I still maintain that there is a problem being caused by Namaste. I’ve now had the chance to trace the code.

The URL for a WP taxonomy query is something like mysite.com/taxonomy-name/taxonomy-term. This should list all the items tagged in “taxonomy-name” with the term “taxonomy-term”, and we should see all the post types registered to the taxonomy.

So WP does not initially populate $query->query_vars[‘post_type’] for a taxonomy page. Instead, the post type is populated later in WP_Query’s function get_posts(), in the section with this comment:

// Do a fully inclusive search for currently registered post types of queried taxonomies.

The problem caused by Namaste is that the pre_get_posts filter is called, and at that point, $query->query_vars[‘post_type’] is legitimately blank, so Namaste puts in the value ‘post’ and its own post types. When we return to the get_posts() function, because there is now a non-blank post type, the taxonomies are not used to add the post types we need to see.

Namaste is setting the post types too soon. Rather than pre_get_posts, it might be better to use posts_where or posts_clauses so that WP has a chance to populate the post types for the taxonomy. Maybe, if we’re on a taxonomy page (is_tax()), Namaste shouldn’t attempt to add its own post types at all.

As I mentioned before, this issue is preventing us from using Namaste.

I’ve found that ESI has to be “On”, in order for Vary Groups to work.

So going back on my previous post:

Cache Logged-In Users = “Off”.
ESI = “On”
Set the Vary Group numbers so that each role has a non-zero value. Some of them might have the same number, so will be in the same group.
LSC will then create a cache for each group, and another cache for people who are not logged in.

Hi @ryankienstra

I’ve worked out that this is mainly an issue with the other plugin (TablePress). The author Tobias is usually pretty helpful when I’ve asked for support, and I will ask him for his view.

So – here’s the block I’m using:

<?php
$tableid = filter_var(block_value('table-id'),FILTER_SANITIZE_STRING);
$showname = filter_var(block_value('show-name'),FILTER_VALIDATE_BOOLEAN);
// if (function_exists('tablepress_print_table')) {
        $f = fopen($_SERVER['DOCUMENT_ROOT'].'/blockdebug.txt','a');
        fputs ($f, 'Debugging block at '.date('H:i:s'));
        fclose ($f);
        echo '<div class="blocktable">';
        tablepress_print_table( array( 'id' => $tableid, 'use_datatables' => false, 'print_name' => $showname ));
        echo '</div>';
// }

As it stands, this crashes WordPress. What I’ve found is that tablepress_print_table() is only enabled “on the front end”. Here’s Tobias’s code:

if ( is_admin() ) {
	$controller = 'admin';
	if ( wp_doing_ajax() ) {
		$controller .= '_ajax';
	}
} else {
	$controller = 'frontend';
}
self::$controller = self::load_controller( $controller );

The function is only enabled as a result of that last ‘frontend’ condition.

What’s still a mystery to me though is why WP invokes the block twice. On the first pass, the function isn’t available, but on the second pass it is. So when I reinstate the if (function_exists condition, it works OK – and it displays the function’s output in the editor.

And that’s the obvious workaround – check for the function’s availability before invoking it, but it’s still odd.

• This reply was modified 5 years, 2 months ago by Martin Taylor.
• This reply was modified 5 years, 2 months ago by Martin Taylor.

@ryankienstra

Hi Ryan – I think that has done the trick. I see what you mean, that when creating the block, the default is now “false”, but that’s not the issue that I had.

My issue was when using the block. Although the default was “true”, and the UI was showing the Toggle / Checkbox controls as checked, they were passing “false” to the block.php handler.

I did have to delete and recreate the block with the updated plugin before it worked as expected, but that’s no big deal in my case.

Happy to do some more checks/diagnostics if that would help.

Martin

Thanks for supporting the idea. In my case, the organisers would probably be companies or organisations, so not WP users as such.

I can probably add organisers by defining a new custom post type, and then using other plugins such as Advanced Custom Fields to add a new “Organiser” attribute to an EM event. But it would be good to have it built in to the EM plugin.

I saw in the EM placeholders docs that there are values such as #_CONTACTNAME and #_CONTACTURL. Those would perhaps do what I need, but I can’t see where you would define them on an event.

Just to add that the problem only affects events that I have created or updated with TEC 5.0.3.1. If the event was created with 5.0.2.1 or earlier, then it appears correctly on the front end regardless of the block editor setting.

I wonder if it’s something to do with this “known issue”?

https://theeventscalendar.com/known-issues/#additional-fields-block