[Craig]

After a little more digging, I’m finding I can use other URLs for the singular organizer – just not /teacher/, which is what it has been since the beginning and worked fine until recent upgrades. Unfortunately, I’m not sure which update to TEC caused the problem.

Is there something that would be stuck in the database or cache that would cause it to fail now?

Thanks,
Craig

[Craig]

Ok, one more thing I’ve discovered. Please make sure to read my last response, as this is a follow-on.

To prevent the problem of WordPress guessing a URL on /teacher/, I inserted the following to my functions file:

remove_filter('template_redirect', 'redirect_canonical');

After that, I flushed the permalinks and I was able to get the ‘/organizer/*’ pages to work again with the Relabeler plugin disabled.

I tried to enable the plugin again, and it all fell apart again with the ‘/teacher/*’ pages not working. I disabled the plugin once again, and the ‘/organizer/*’ pages didn’t function until I cleared the permalinks again.

So there’s definitely an issue with the creation and persistance of the pages created when using the plugin, even after it is disabled.

Thanks,
Craig

[Craig]

I have done some more investigating, and it seems there are some database problems with the plugin. Just to answer your question, I did not have a teacher page, even in the trash, but some strange behavior is happening to that page by itself now, in which it redirects to what seems like the nearest term related to the URI. More on the issues below.

First, it doesn’t work with my theme, whereas the filter I used to use worked fine. Here is that one:

add_filter('tribe_organizer_label_singular', 'tec_change_organizer_label' );
function tec_change_organizer_label() {
	return 'Teacher';
}

Second, it seems that once the slug is set initially, it can’t be changed. I initially set the singular organizer as ‘teacher’. Since that page was having issues, I tried to set it to ‘teach’. However, when I get back to the page where I have [list_organizers], the link is still to ‘/teacher/*’. In other words, saving the new setting must not update the database.

Third is the last strange case. When I deactivate the plugin within my theme, the ‘/organizer/*’ pages still do not work. I checked to make sure that is the case whether or not I use the filter I mention above.

Without digging in anymore, it seems clear there is an issue with updating the database on save and that they are not clearing appropriately even after deactivation.

I’ll leave it up to you to figure out why that is happening. But I would like this issue to be elevated somewhat as I now can’t show the teachers at all, and that is an important SEO tool for us that was working previously.

Thanks,
Craig

[Craig]

Hi Victor,

Again, I’m a little confused on terms due to the other issue being tracked, so let’s make sure we have consistent naming.

1. Attendee List. This can be fixed with the snippet you provided in the other thread.
2. Attendee Details. This doesn’t work with Object Cache for me even if I purge the caches.

I can’t turn on the Object Cache for production servers, as the attendee details don’t record in the database at all and my client needs them. The Attendee List are different, as they are stored in the database and just wouldn’t echo to the screen without the snippet.

Are you tracking the cookie I mentioned earlier – tribe-event-tickets-plus-meta-hash – all the way through the checkout process? I installed a chrome extension to view the cookies, and it appears there’s a problem with it when the Object Cache is enabled.

Thanks,
Craig

[Craig]

Hi Victor,

Sorry, I forgot to mention this is being done with Woocommerce. While we had the object cache enabled, we received zero attendee details for any event tickets sold. This happened for about 2 months until I turned it off again.

You may be having success even with object cache turned on if you are conducting your tests on a staging server. WP Engine ignores that for staging, which is how I discovered the problem. Everything worked fine for staging, but then there was an issue when I pushed it to production.

They thought it might have to do with the cookie hash passed along through the Woocommerce checkout process.

Thanks,
Craig

[Craig]

Hi Victor,

I know we’re talking on two threads about attendee information, so I want to make sure we’re going over the right issue.

For this ticket, the issue is that the Event Tickets Pro Ticket Fieldsets (Attendee Information) is not saving when an order is placed.

So, for instance, if we ask a customer to provide a phone number (required), the field will show up on the ticket during the add to cart process. However, at some point along the way, that field is dropped and doesn’t associate with the ticket.

The field on the “attendee list” is the “Details” column. When object cache is turned on, there are no attendees with a “View Details” dropdown.

Does this make sense?

Thanks,
Craig

[Craig]

Hi Victor,

I’m not sure what you mean by switching back to 4.7.2. The only way I was able to get that version working was by replacing the get_event_attendees function with the old one from 4.6.2. As soon as I revert to the original tickets.php file, the attendees go missing again.

I did add the code you provided to the 4.7.2 version (with the original tickets.php file) and the attendees do show up again. Of course, I’d rather not have that workaround lurking around when things are updated.

Can you please advise on how this will be handled by your team? Will it be a reported bug for instance?

Thanks for your help.

Thanks,
Craig

[Craig]

Hi Victor,

I found the offending function this morning. Within /event-tickets/src/Tribe/Tickets.php, the function get_event_attendees has changed.

When I replaced the new function with the one from version 4.6.2, the Attendees show up again.

Here’s the old one for reference:

public static function get_event_attendees( $post_id ) {
			$attendees_from_cache = false;
			$attendees            = array();

			if ( ! is_admin() ) {
				$post_transient = Tribe__Post_Transient::instance();

				$attendees_from_cache = $post_transient->get( $post_id, self::ATTENDEES_CACHE );

				// if there is a valid transient, we'll use the value from that and note
				// that we have fetched from cache
				if ( false !== $attendees_from_cache ) {
					$attendees            = empty( $attendees_from_cache ) ? array() : $attendees_from_cache;
					$attendees_from_cache = true;
				}
			}

			// if we haven't grabbed attendees from cache, then attempt to fetch attendees
			if ( false === $attendees_from_cache && empty( $attendees ) ) {
				foreach ( self::modules() as $class => $module ) {
					$obj       = call_user_func( array( $class, 'get_instance' ) );
					$attendees = array_merge( $attendees, $obj->get_attendees_by_post_id( $post_id ) );
				}

				// Set the <code>ticket_exists</code> flag on attendees if the ticket they are associated with
				// does not exist.
				foreach ( $attendees as &$attendee ) {
					$attendee['ticket_exists'] = ! empty( $attendee['product_id'] ) && get_post( $attendee['product_id'] );
				}

				if ( ! is_admin() ) {
					$expire = apply_filters( 'tribe_tickets_attendees_expire', HOUR_IN_SECONDS );
					$post_transient->set( $post_id, self::ATTENDEES_CACHE, $attendees, $expire );
				}
			}

			/**
			 * Filters the return data for event attendees.
			 *
			 * @since 4.4
			 *
			 * @param array $attendees Array of event attendees.
			 * @param int $post_id ID of parent "event" post
			 */
			return apply_filters( 'tribe_tickets_event_attendees', $attendees, $post_id );
		}

I can’t tell for sure what is happening that it won’t work on WPEngine, so maybe you can take it from here?

[Craig]

Hi Victor,

Thanks for this. I’ll be taking a look through it this morning. I have disabled the WP Object Cache. That was a conversation about another bug we had that Attendee details weren’t saving with it turned on.

I’ll let you know how the debugging goes. Can you please leave this open for a bit until we can figure it out?

Thanks,
Craig

[Craig]

Hi Victor,

Before I run those tests, could you point me to a variable I can var_dump out of the template on the page so I can see what’s being printed to the screen? I think it will make this go faster. I could likely go in and find it myself, but if you give me a head start, it would help save me a couple hours of digging.

Once I have that, I can run it before and after the update.

Ideally, I’m looking for the place to output the following:

<?php
echo '<pre>';
var_dump($someVariable);
echo '</pre>';
?>

Thanks,
Craig

[Craig]

This reply is private.

• This reply was modified 6 years ago by Craig.

[Craig]

Hi Victor,

I have a staging site setup for this with all debug information recording. Just now I…
1. Reverted to an earlier version of the site.
2. Changed the theme to 2017.
3. Disabled all plugins except for TEC, TEC Plus, Event Tickets, Event Tickets Pro, and Woocommerce.
4. Upgraded TEC. Everything was fine after this.
5. Upgraded Event Tickets (the free version). This is when I lose the information for attendees.

The version I’m upgrading from for Event Tickets is 4.6.2. The upgrade version is 4.7.2.

There are no PHP errors reporting for this (or anything else).

I will send you 2 images privately in order to show the difference after upgrading Event Tickets.

It also makes no difference to continue the upgrade process to include TEC Plus and Event Tickets Pro.

Thanks,
Craig

[Craig]

Hi Victor,

I’m imagining the WP and Redis Object caches are a bit different, but I’m not sure. It might be worth it for your team to try using the WP Object Cache plugin to see if you can replicate the issue.

WPEngine thought it was probably the cookie generated to pass through to the cart and checkout pages. I’m seeing “tribe-event-tickets-plus-meta-hash”.

After a few other issues are resolved, I’ll see if I can get them to exclude that from caching and try the WP Object Cache again.

Thanks,
Craig

[Craig]

Hi again,

I did a test by turning off the WP Object Cache, and now the attendee details are recording again. Of course, I’d like to use the object cache to keep the site speed up. It would be much better to be able to specifically turn on caching for one element, which I think is a cookie.

Still in need of help on this…

Thanks,
Craig

[Craig]

That worked. Thanks, Jaime.

Craig

[Author]

Posts