idearius

Many thanks, @yuriinalivaiko. It is working now and we were able to make the DB upgrade from package 2.4.0 to 2.8.1!

As per https://docs.ultimatemember.com/article/1620-restriction-content, it seems that option should not be kept enabled. Could you expand or point me to an URL on what it does?

In case it’s related, we’re now having critical error messages when trying to update data from users (like email or password).

Thanks. As it was no longer in the WP repo, I thought it could be unsafe to use it.

Best.

Hello, @ipstenu. Is there any alternative you can recommend?

I’ve searched a while and there are a few that could fit, but they are either too bulky or with too few users to be fully trusted.

Thanks, @briantp. Here you have two screenshots:

Desktop view: https://www.dropbox.com/scl/fi/kj26iyteu89zo2amx8wq7/Screenshot-dsk.png?rlkey=qrpzo9gxdofvgco5zrvkf98qf&dl=0

Mobile view (emulated using Firefox): https://www.dropbox.com/scl/fi/8msjqrixjsp21hxf0y3ei/Screenshot-mob.png?rlkey=r9sb6sxtyk4285kotmzgxtqze&dl=0

In the mobile view you’ll see that the Logout icon is hidden, and no clues are shown indicating that the icons’ row can be dragged to the side to show the icons hidden out of view. Not sure if that’s related to the problem, or just a sub-optimal way displaying the icons.

Regards.

Much appreciated, Ernest.

Good luck with your project.

Hello, @wpdreams. Do you have a rough estimate for that functionality to be added natively to the plugin?

Hello, @d0153. Many thanks for your help.

The problem has been solved with the plugin and code you mentioned, forcing a new migration to the event data format used in the plugin version 6.

It’d be great if The Events Calendar included such solution, instead of having to rely on an additional plugin and custom code. Also, as it seems this problem is rather common, improving the visibility of the solution you provided could help many users and save you guys some time.

Finally, regarding your second answer to this ticket, at first I thought your reference to the migration of events was related to my attempts to backup the events data, not to the migration to the event data format used in the plugin version 6. It would help if in future responses to similar tickets you could include an explicit reference to what migration you are referring to.

Best regards.

Hello again, @d0153.

The migration was just part of an attempt to solve the problem once it had already surfaced. In my original post, please look at the last item of the “We tried this:” bullet list.

In fact, the export/import operations ended up having no effect whatsoever, as I finally had to delete all tables and restore a prior full backup of the database (which had all the events there from the start) due to the inability of WP All Import to restore the time of each event. That full backup, regrettably, already had the problem, too.

Here’s the troubleshooting info you asked for:

Custom Tables Migration Status
Not Required
Custom Tables Health Check
Good!

Let me know if there’s anything else you need or I can do.

Best.

Hello, @d0153. Thanks for answering.

Events were already there. WP All Import was just a (failed, due to the bug you mentioned) way to try not to lose them after a full uninstallation of the plugin. I had to restore the whole database, instead of just the events’ entries. ??

I created a test event and it SHOWS just fine! How is this possible?

There are about 200 past and future events in the system. Should we recreate each one of them to have the calendar back again with all past events included??

PS: Lately errors like this one are accumulating in the log:

[24-Apr-2023 18:53:53 UTC] WordPress database error Table 'XXXXXXXX_XXXXXXXX.wp_tec_occurrences' doesn't exist for query 
			SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID
			FROM wp_posts  INNER JOIN wp_tec_occurrences ON wp_posts.ID = wp_tec_occurrences.post_id
			WHERE 1=1  AND ( 
  CAST(wp_tec_occurrences.end_date_utc AS DATETIME) < '2214-04-27 03:00:00'
) AND wp_posts.post_type = 'tribe_events' AND ((wp_posts.post_status = 'publish'))
			GROUP BY wp_tec_occurrences.occurrence_id
			ORDER BY wp_posts.post_date ASC
			LIMIT 0, 11
		 made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/plugins/the-events-calendar/src/views/v2/default-template.php'), Tribe\Events\Views\V2\Template_Bootstrap->get_view_html, Tribe\Events\Views\V2\View->get_html, Tribe\Events\Views\V2\Views\List_View->setup_template_vars, Tribe\Events\Views\V2\View->setup_template_vars, Tribe\Events\Views\V2\Views\List_View->next_url, Tribe\Events\Views\V2\Views\List_View->get_upcoming_url, Tribe__Repository->count, WP_Query->get_posts, apply_filters_ref_array('posts_pre_query'), WP_Hook->apply_filters, TEC\Events\Custom_Tables\V1\WP_Query\Modifiers\Events_Only_Modifier->filter_posts_pre_query, TEC\Events\Custom_Tables\V1\WP_Query\Custom_Tables_Query->get_posts, WP_Query->get_posts

I’ve now seen some other posts referring to errors with the wp_tec_occurrences table…

Great! Many thanks for the addition and for the plugin itself!

Hello. Do you have an ETA on reactivating the plugin at www.ads-software.com, @srinig?

I see. It’s good to know about the Pixabay connection and that performance is not affected.

Best.

It seems something happened with stackable elements. I saw the opposite in columns that should stack one above the other in mobile view and don’t.

It was fixed after clearing all caches from WP Fastest Cache by @emrevona (https://www.ads-software.com/plugins/wp-fastest-cache/), but not from the WordPress toolbar menu. It only worked when clearing from with the plugin settings page.

All fixed. Checking the option “Use Mozilla PDF.js version 2.0.493 (dark theme toolbar)” worked fine.

Two related questions @wonderplugin:

1. How come the default PDF viewer has that strange behaviour in tablets? Could you find the answer? (The problem was definitely not related to cache)

2. Have you considered not adding the viewer settings to the URL of each PDF? Currently, settings changes do not reflect on a previously loaded PDF. We had to manually change the URL of each PDF loaded while the new viewer was set as default, so as they could use the Mozilla viewer instead.

Thanks.