peter8nss

Just installed 5.6.1. That does indeed seem to have fixed it. Thank you for sorting this so promptly.

Thanks for the prompt response. I think it was the refactoring, I have to go back to version 5.3.0 before it starts doing the full export properly.

Two other things I noticed:

• There is a hardcoded ‘posts_per_page’ set to 3000 in Export_Dropin::download_export and that appears to be a factor in how many records are returned in the export file.
• The current export appears to contain around 3000 records but has a few more recent records tacked on the end.

Furthermore, the export page still says “The export function will export the full history.”

I use Google API library too. Looking at the version I use, I think they have already fixed this problem. So, if you rebuild with a later version it should be fixed.

I run my live site with error messages turned off already. However, I run my development sites with errors on so I can try and pick up potential problems before they bite.

Thanks for all your help.

It occurs when I access “Basic options” /wp-admin/admin.php?page=sgdg_basic.

I’m using Firefox to access my site and the error is showing up when I go to Firefox “Console” log (https://firefox-source-docs.mozilla.org/devtools-user/browser_console/index.html). So not something visible directly to a user.

I’m not using any page builder.

• PHP: 8.3.13
• WordPress: 6.7.1
• Event Calendar: 6.8.3
• Theme: Proprietary

Looks like 6.8.2.1 fixes the calendar register cases.

Next ones are in Tribe__Events__Aggregator__Errors->__construct where __ is used when calling tribe_register_error.

require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, Tribe__Main->plugins_loaded, do_action('tribe_common_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, Tribe__Events__Main->bootstrap, Tribe__Events__Main->addHooks, tribe, TEC\Common\lucatume\DI52\Container->make, TEC\Common\Contracts\Container->get, TEC\Common\lucatume\DI52\Container->get, TEC\Common\lucatume\DI52\Builders\Resolver->resolve, TEC\Common\lucatume\DI52\Builders\Resolver->resolveBound, TEC\Common\lucatume\DI52\Builders\ClassBuilder->build, Tribe__Events__Aggregator->load, Tribe__Events__Aggregator__Errors::instance, Tribe__Events__Aggregator__Errors->__construct, __, translate, get_translations_for_domain, _load_textdomain_just_in_time, _doing_it_wrong

And after that Tribe__Events__Aggregator__API__Origins->__construct:

require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, Tribe__Main->plugins_loaded, do_action('tribe_common_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, Tribe__Events__Main->bootstrap, Tribe__Events__Main->addHooks, tribe, TEC\Common\lucatume\DI52\Container->make, TEC\Common\Contracts\Container->get, TEC\Common\lucatume\DI52\Container->get, TEC\Common\lucatume\DI52\Builders\Resolver->resolve, TEC\Common\lucatume\DI52\Builders\Resolver->resolveBound, TEC\Common\lucatume\DI52\Builders\ClassBuilder->build, Tribe__Events__Aggregator->load, Tribe__Events__Aggregator->api, Tribe__Events__Aggregator__API__Origins->__construct, __, translate, get_translations_for_domain, _load_textdomain_just_in_time, _doing_it_wrong

Initial reaction is that might be the last of them.

Re “I don’t know how to try to trace it back to what code is causing it”:

Use the doing_it_wrong_run hook to call a function that uses wp_debug_backtrace_summary to get the callling stack and then log that somewhere for you to look at.

And there are similar issues in:

Tribe\Events\Views\V2\iCalendar\Links\iCal->register
Tribe\Events\Views\V2\iCalendar\Links\Outlook_365->register
Tribe\Events\Views\V2\iCalendar\Links\Outlook_Live->register
Tribe\Events\Views\V2\iCalendar\Links\iCalendar_Export->register
Tribe\Events\Views\V2\iCalendar\Links\Outlook_Export->register

If you clear those, I think the next one will be Tribe__Events__Aggregator__Service->register_messages calling esc_html__. Unfortunately, it look like only the first case gets reported so until that is fixed you don’t see the next one.

Is there an internal bug number for this so I can look out for it in the changelog?

Installed version 6.8.2, now seeing this error when displaying installed plugins either from dashboard or WP CLI. The traceback is:

_load_textdomain_just_in_time; Trace: require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, Tribe__Main->plugins_loaded, do_action('tribe_common_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, Tribe__Events__Main->bootstrap, Tribe__Events__Main->bind_implementations, tribe_register_provider, TEC\\Common\\Contracts\\Container->register, TEC\\Common\\lucatume\\DI52\\Container->register, Tribe\\Events\\Views\\V2\\Service_Provider->register, TEC\\Common\\Contracts\\Container->register, TEC\\Common\\lucatume\\DI52\\Container->register, Tribe\\Events\\Views\\V2\\iCalendar\\iCalendar_Handler->register, tribe, TEC\\Common\\lucatume\\DI52\\Container->make, TEC\\Common\\Contracts\\Container->get, TEC\\Common\\lucatume\\DI52\\Container->get, TEC\\Common\\lucatume\\DI52\\Builders\\Resolver->resolve, TEC\\Common\\lucatume\\DI52\\Builders\\Resolver->resolveBound, TEC\\Common\\lucatume\\DI52\\Builders\\ClassBuilder->build, Tribe\\Events\\Views\\V2\\iCalendar\\Links\\Link_Abstract->__construct, Tribe\\Events\\Views\\V2\\iCalendar\\Links\\Google_Calendar->register, __, translate, get_translations_for_domain, _load_textdomain_just_in_time, _doing_it_wrong

Which suggests another source of the problem is calling __ in Tribe\\Events\\Views\\V2\\iCalendar\\Links\\Google_Calendar->register.

ps: Would you prefer this to have been raised as a separate item?

• This reply was modified 4 months ago by peter8nss.

My site runs with WP_DEBUG off but, because my site involves a significant amount of PHP, I have a separate development environment with WP_DEBUG on. That way I pick up faults in my own code before they get released. It also means I pick up issues in plugins (and core WordPress). I report these to help with their open source development.

I have recently been upgrading my site to a more recent version of PHP – as PHP8.2 goes out of active support in just over a months time https://www.php.net/supported-versions.php, hence spotting this (and other) issues.

This does not block my development environment from running – the import function still completes. For me it is just annoying, but please be aware that deprecated features often indicate some misconception in coding. In this case I think Tribe__PUE__Checker::get_installed_version may always be returning null so not really doing what its name would imply. That is perhaps what your developers might care to look at.

I agree this is low priority, but it would be nice to have a Internal Bug Ticket Reference linked to it so I can spot in the changelog.

As a “service”, event aggregator won’t be in the list of “plugins” returned by get_plugin_file. Hence, my concern that the problem in the code is more than just a deprecation issue.

ps: Your PHP 8.x: Understanding what the Deprecation notices mean) states “However, if you are using wp_debug for development purposes and encounter any issues that stop the code from executing and providing the expected result, we encourage you to contact our support team“.

I have replied using the email.

My guess is that some “bot” is programatically trying to submit the form and providing an array of select values rather than the single one that the form would get if used by a human.

So, whilst your code is correct for normal usage, it has not considered a programatic form submit. Hence, my suggested change to make the code fail gracefully in this case.

A simple workaround, to avoid the deprecated null, is to add

return ''

At the end of the version_compare() function. But I don’t know if that hides in that function.